Geoff Chappell - Software Analyst
Some paid work in February had me making what might have been routine use of Image File Execution Options for getting a particular process to run automatically under a debugger. Slightly less routine is that this was wanted before any user was yet logged on, so that the user-mode debugger had to be operated through the kernel-mode debugger from a second computer.
Still, this sort of work is bread-and-butter for a consultant on low-level Windows programming. Of course, if you have a low-level Windows problem but this is not bread-and-butter for you, then please take a moment to consider how much easier your problem might be dealt with if you consult!
What changed the work from routine to initially impossible was interference from software that injects its DLLs into arbitrary other software. Too much of this is done without a full understanding of what Windows functionality they disturb. Hardly ever is it done with any sense of responsibiilty for the costs imposed on by-standers. When you finally get past the numerous deflections that the maker of this arrogantly faulty software puts in your way, you find their attitude is anyway that they did what they needed to for their purposes and that’s that. I’d happily see these guys get drummed out of business, along with most makers of anti-virus software, meaningful difference between their products and malware being sometimes hard to discern.
Anyway, the spill-over to my unpaid work is that it got me looking again at the exported functions for querying Image File Execution Options. Somehow, I wrote about one of them one day more than a decade ago without ever returning to it or its companions. There have, of course, been developments. And I have in the meantime got more interested in the early history. Image File Execution Options actually are ancient.
One of the quirks of the API for Image File Execution Options is that an option can be in the registry as a string but can be queried as a dword. Indeed, it wasn’t until Windows 2000 that an option could be in the registry as anything other than a string. It’s well past time, then, to document the low-level helper that parses a dword from a string. You’d think such a function is straightforward. It always has been documented. But look at the documentation and ask why it goes to the trouble of presenting examples. Then ask whether Microsoft would have added these without experience of this simple function causing real-world problems. Then look into how Microsoft’s documentation of this seemingly simple utility function has changed through the decades and wonder how anyone at Microsoft ever has the nerve to tell programmers to keep to the documentation.
Perhaps inevitably, documenting one supposedly simple function that Microsoft already documents led soon enough to others. The UNICODE_STRING is so basic a structure in kernel-mode programming that you’d think there can’t be anything useful to write about it. But the structure has always been widely appreciated as having a problem with strings that are too long for faithful representation. Microsoft’s documentation of this itself and of various attempts at correcting it is far from commendable. Problems surely lurk in real-world code, even in 2019, for even if Microsoft’s programmers are scrupulously careful we can be sure that third-party programmers aren’t, not least because their quick reading of Microsoft’s documentation won’t have alerted them.
Certainly not new, but new to this website! As best as I can now determine, the small collection of pages that I now add to the Notes was published at my old website from 1999 until I finally discontinuted the site in 2011. Somehow, these pages never got transferred to this website when I created it in 2007. Most plausibly, I thought they belonged in some bigger work so that I didn’t simply archive them, and then I forgot about carrying them over for the bigger work. Their subject is what was in 1999 still the relatively recent introduction of cryptography to Windows. I only thought of them now—twenty years later—because a correspondent asked me about the fuss that some people made that year over findng the name NSAKEY in some Windows symbol files.
While taking this trip down memory lane, I also noticed a page that certainly never was more than a throw-away. The wonder is how I ever came upon its subject. It dates from a time when newsgroups were the closest the Internet yet had to social media and I still participated before I realised that giving away information and solutions in public for free mostly just got me a deluge of emails that expected information and solutions in private but still for free. (I say expected because I remember that very few even bothered with a please or thankyou.) Microsoft’s Internet News program must have presented some irritation that prompted me to cast my eye over a hex dump. Are easter eggs still a thing?
It turns out they are, such that in November 2021 I thought to write a little about a much more substantial easter egg in Windows 95. Thus motivated I looked harder into the history of my study of the Internet Mail and News program and found that the spur was not, after all, an irritation in that program but the thought that a quick study of it might add to what I had recently written about an irritation in different software that Microsoft had also named Internet Mail.