Can I just point something out about the "Shell Folders key" article... So he whines that developers don't read documentation. So I went and got the "SHGetSpecialFolderLocation" docs[0] which say at the top:
> [SHGetSpecialFolderLocation is not supported and may be altered or unavailable in the future. Instead, use SHGetFolderLocation.]
Alright, so I go and get the SHGetFolderLocation documentation:
> Deprecated.
So neither SHGetSpecialFolderLocation or SHGetFolderLocation are still the correct function for this and I have no clue which is the correct win32 function here because on the "Deprecated" one they don't tell me? And all because I went to MSDN and actually tried to read the official docs.
Microsoft always likes to blame crappy developers, but their documentation is terrible too. Instead of removing the documentation for the registry shell folder key, they should have left documentation and in that article explained why they exist and why you should not use them.
Ultimately Microsoft, particularly in the 1990s, had terrible documentation and they're in no small part to blame for how badly software was written to the platform.
I agree MSDN's documentation isn't perfect, but trust me, it is far, far, far better than almost every other API's documentation that I've seen. I can't speak to its quality in the 90s.
Also, your second link says """As of Windows Vista, this function is merely a wrapper for SHGetKnownFolderIDList. The CSIDL value is translated to its associated KNOWNFOLDERID and SHGetKnownFolderIDList is called. New applications should use the known folder system rather than the older CSIDL system, which is supported only for backward compatibility."""
(Fun Fact: I implemented much of the knownfolder and some of the old shell32 PIDL folder stuff in Wine :) )
Midway down the page for SHGetFolderLocation is a remark that says this function is a wrapper for SHGetKnownFolderIDList, which seems to be the one to use.
They destroyed it ostensibly so that they had a stronger guarantee that that GUID would never be generated again. That said, I suspect they understood it wasn't strictly necessary and were looking for an excuse to have some fun.
Note that even in the MAC-based generation algorithm, it is difficult (but not impossible) to accidentally generate the same one again even on the same hardware since there is a high resolution time component as well.
Random UUIDs have a different encoded version number so it's actually impossible for a modern one to collide with the one they generated.
