Why do Windows functions begin with a pointless MOV EDI, EDI instruction? (2011) | Hacker News Reader

Why do Windows functions begin with a pointless MOV EDI, EDI instruction? (2011)

blogs.msdn.microsoft.com

136 pointsmau31 comments

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).

Apparently, hotpatching never really took off: http://www.itwalkthru.com/2010/10/hotpatching-great-idea-mic...

Not sure if anything has changed in recent years, though.

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.

is this the same as shims?

https://www.youtube.com/watch?v=LOsesi3QkXY

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.

More articles like this in Raymond's blog, which is full of anecdotes from his time at Microsoft.

https://blogs.msdn.microsoft.com/oldnewthing/

Got a few good ones? I don't really feel like trawling through almost 5000 articles.

I love this one, about DirectX not trusting drivers responses to capabilities requests: https://blogs.msdn.microsoft.com/oldnewthing/20040211-00/?p=...

I thought guids weren't based on MAC addresses anymore.

They aren't, but they were when this original "bug" in drivers was fixed.

So they wasted a perfectly good network card for nothing.

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.

Why was Pinball removed from Windows Vista? https://blogs.msdn.microsoft.com/oldnewthing/20121218-00/?p=...

A few good ones from my browser history:

GetRandomRgn: http://blogs.msdn.com/b/oldnewthing/archive/2012/06/18/10321...

A good idea ruined by bad application programmers: http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532...

How window minimization really works: https://blogs.msdn.microsoft.com/oldnewthing/20041028-00/?p=...

See you later. J: https://blogs.msdn.microsoft.com/oldnewthing/20060523-10/?p=...

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.

[0] https://msdn.microsoft.com/en-us/library/windows/desktop/bb7... [1] https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...

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.

I've got a bunch I like, here are some of my favorites:

Itanium processor overview (series) https://blogs.msdn.microsoft.com/oldnewthing/20150727-00/?p=...

Lock-free algorithms (series) https://blogs.msdn.microsoft.com/oldnewthing/20110405-00/?p=...

Undefined behavior (also see John Regehr's posts on this): https://blogs.msdn.microsoft.com/oldnewthing/20140627-00/?p=...

Windows debugging specifics:

Rescue broken stack trace: https://blogs.msdn.microsoft.com/oldnewthing/20110309-00/?p=...

Underlying object behind COM pointer: https://blogs.msdn.microsoft.com/oldnewthing/20070424-00/?p=...

View stack of user-mode thread when kernel stack is paged out: https://blogs.msdn.microsoft.com/oldnewthing/20141114-00/?p=...

Identifying an object whose DLL is unloaded: https://blogs.msdn.microsoft.com/oldnewthing/20070425-00/?p=...

Raymond also posts "little programs" occasionally, which are great small examples of various Windows techniques.

his time at Microsoft?

I had the impression he was still there last year.

The phrase doesn't necessarily imply that he has left.

I miss the old The Old New Thing look. I also miss when all links to it weren't broken.

On first blush I thought this was a knowledgebase article. I guess all MSDN blogs have to look homogeneous now.

Consistent look is great. Lets me get on with reading the content, which is the important part.

There's no excuse for breaking existing links though, particularly for a blog as popular as this one.

http://blogs.msdn.com/b/oldnewthing/archive/2011/09/21/10214..., from https://news.ycombinator.com/item?id=3022224, redirects to the right page. Which links are broken?

Some of the variants of the links are broken, acknowledged via blog post: https://blogs.msdn.microsoft.com/oldnewthing/20160118-01/?p=...

Oh, I guess they fixed it. It was broken before.

Consistent look is great for consistent content. But if the content is different, having a different look helps the user get to the content.

for patching if i remember right.

That's what the article says; indeed, it is the entire text of the second paragraph.

Reply on news.ycombinator.com