It's kind of cool, so many things (computers or otherwise) have padding built in.
Remember BASIC, the classic 10/20/30 line numbering scheme? Don't want to be caught without room to expand your program.
Microprocessors manufacture in extra gates in case they need to fix something.
Even in large construction projects you see evidence of mystery tunnels, pipes and other things that enable post-construction changes. Some of the road fly-overs in my area have branch points that are only connected in one direction (since obviously it would be ridiculously hard to retrofit the piers at the intersection 10 years from now to add a road going the other way).
It's used a bit. Adding hotpatch support was a major feature in Wine a few years back, when Steam added their in-game overlay feature. I believe one of our devs did most of the legwork getting the ms_hook_prologue attribute into GCC so we could support this.
Raymond mentions MS Detours in this article on patching. I've had great success troubleshooting 3rd party DLLs with Detours interception of function dispatch, specifically Excel XLLs.
I haven't used Detours in years, so was surprised to see that they have a "professional" version now - it's like $10K in the Windows Store. I only used the free version, but it was awesome to work with and made trampolining a lot easier than trying to hack it all in by hand. We used it to integrate some of our in-house trading system's interfaces into a third-party order management system that we didn't have the source code for.
If it weren't for the "fastcall" convention using ECX for an actual argument value, they could have used "MOV ECX,EDI" and then the change to a "JMP $-5" would have been possible with a single byte store to the opcode (0x89 -> 0xeb), removing any worries about a two-byte store straddling a cache-line or page boundary.
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.
Remember BASIC, the classic 10/20/30 line numbering scheme? Don't want to be caught without room to expand your program.
Microprocessors manufacture in extra gates in case they need to fix something.
Even in large construction projects you see evidence of mystery tunnels, pipes and other things that enable post-construction changes. Some of the road fly-overs in my area have branch points that are only connected in one direction (since obviously it would be ridiculously hard to retrofit the piers at the intersection 10 years from now to add a road going the other way).