If you think that's bad, look at all the stuff that redirects to https://docs.microsoft.com/en-us/windows/desktop, which is honestly worse than just leaving the URL out entirely to surface the (I presume) default "Return to main site" button.

I am passionate about MSI and dislike EXE installers but they are never going to go away. Heck people around here don't want to stop there. They want to be able to extract random ZIP files and somehow "install" them.

I'm not sure what the problem is with ZIP? It's not going to go behind winget's back like EXEs do ...

If you archive the repository, it will be more clear that this isn't where stuff happens anymore.

@mklement0

[...] (note: Desktop and DesktopDir, though technically distinct, seem to refer to the same location in practice; the former is distinguished from the latter as being the "logical Desktop rather than the physical file system location" - not sure what that means).

• Desktop
• DesktopDirectory

Note to the uninitiated: Just to be confusing, "the shell" refers to an entirely different component of Windows than PowerShell or cmd.exe. You probably know it as explorer.exe, though naturally most of it is actually implemented in DLLs ...

I think this distinction is/was only relevant with SHGetSpecialFolderLocation and SHGetFolderLocation, which build paths in the shell's namespace (ITEMIDLIST structures, also called PIDLs for some reason). CSIDL_DESKTOP would give you the thing that's actually represented on your desktop; CSIDL_DESKTOPDIRECTORY would give you the place you get to when you type e.g. %USERPROFILE%\Desktop into Explorer's address bar.

[The documentation seems to imply that both values do the same thing since Vista, but I'm not going to assume that's actually true.]

In particular, CSIDL_DESKTOP would have whatever extra items [Computer, Recycling Bin, etc.] the user has configured to appear on the desktop, as well as items contributed from CSIDL_COMMON_DESKTOPDIRECTORY (i.e. the All Users desktop shortcuts).

Naturally, none of this is in any way relevant to the return value of System.Environment.GetFolderPath.

At least, I hope I did this right.

I just happened across a report of the problem at http://www.virtualdub.org/blog/pivot/entry.php?id=386 and figured I might as well see if the relevant page had made it to GitHub or not.

The page says:

For a general discussion about Image Color Management, see the Microsoft Windows SDK documentation.

... but there's no link. That was probably less of a problem when the SDK documentation used an offline HTML Help system so you could look it up in the index or something ...

All I can seem to find are:

• The https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wcs tree
• https://docs.microsoft.com/en-us/previous-versions//dd372446 (which looks like it should redirect to https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wcs/windows-color-system; it looks like the only difference between these two pages is that one of them uses opaque page IDs and the other uses human-chosen paths, and all the linked pages redirect to the human-chosen paths)

The "previous-versions" bit doesn't really inspire confidence, though.

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 66c3c003-71bd-0d57-91f6-a29718c90560
• Version Independent ID: 74ade7b7-0d53-ac6e-d199-090aa54024ad
• Content: Image Color Management - Windows drivers
• Content Source: windows-driver-docs-pr/display/image-color-management.md
• Product: windows-hardware
• Technology: windows-devices
• GitHub Login: @lorihollasch
• Microsoft Alias: loriwhip

Still needs wording, though.

@corob-msft WHICH dev team? The thing you linked to never seems to have been routed to any dev team ...

This information can be found in the individual extensions themselves. For example, the "Dependencies" section of OES_element_index_uint states: "Promoted to core and no longer available as an extension in WebGL API 2.0 specification." If this documentation is missing from any specific extension please feel free to file an issue against it.

Well, sure, but:

1. The reference in the WebGL 2.0 spec, https://github.com/KhronosGroup/WebGL/blob/a503e4226c7b1095f2e8a0051021f0b20bbe585b/specs/latest/2.0/index.html#L3286-L3288 ...

   ... doesn't say anything about having to check individual extension specs.

2. This is darned inconvenient!

Sounds like something doesn't do a good job distinguishing between a Billion laughs attack and a file that just happens to be really big. Seems like the parser shouldn't really complain unless the expanded:raw size ratio is high, rather than flat-out refusing to process anything that expands to more than 50 million characters ...

Anyway, it looks like you can at least adjust this with the jdk.xml.totalEntitySizeLimit system property, or the http://www.oracle.com/xml/jaxp/properties/totalEntitySizeLimit API property...

Oh look, it's even documented: https://docs.oracle.com/javase/tutorial/jaxp/limits/limits.html

For convenience, here's that link in English. (Or just delete the language code component from the URL to get the default ...)