Geoff Chappell - Software Analyst
For various reasons that I leave unstated, I have in September and October got myself more than a little concerned to strengthen the pages that provide overviews and frameworks. As much as I like getting into the detail, the fact is that the most-read pages at this website are the catalogues that I prepare as my own reference to the history to frame my "actual" work. I tend to approach these pages half-heartedly, if not resentfully. Working through thousands of functions, not just in the code but in dozens of editions of Microsoft’s documentation, following this or that structure’s development through some twenty or so Windows versions, all takes time, and although I do benefit—I am a big believer that one gains useful, and even invaluable, insight from immersion in data—I can’t help grumble that such background material ought to be prepared as paid scholarship for common benefit. In the study of Windows, whether for programming or security or whatever else, wouldn’t we all do more advanced work—and do it better—if freed from repeatedly tending to the basics? Still, the appeal of these pages to readers is no small success. I start to realise that these pages are more important than I had let myself appreciate and I would better put flesh on what I had been happy to leave as bones.
So, I announce and begin an off-and-on commitment to revise this website’s lists of API functions. The presentation is changing substantially, not least so that I can hang on those bones a paragraph here or there that may look like a throw-away but which nobody could think to write except as an outcome of serious research. I’m also attending to a hobby horse: tracking not just whether a function is documented now but how (slowly) it got disclosed. This commits me to a lot of tedious picking over archived collections of documentation. This is presently under way for the kernel-mode lists. I very possibly will not take it further, but you’ve all understood that despite my occasional and even lengthy explorations even as far out as Internet Explorer, it’s kernel-mode Windows that has my abiding interest.
Inevitably, I get diverted by new work, some of which motivates me to update pages for new releases of Windows. I’m always behind. The pages listed below now cover up to and including the 2004, i.e, April 2020, edition of Windows 10. For most, that is all the revision they have received. This is enough, though, to bring to mind that several of these pages, notably for the KTHREAD, really need some heavy reworking to bring them under control.
The page on the KUSER_SHARED_DATA has substantial newly written material on the early history of getting the time in user mode—and inevitably on what Windows time even means.
All these pages on structures will be moved in the near future. But even the plan is still too much in development to write about. That said, if only to mark the space and perhaps even to commit me to seeing it through, I offer a taste without further explanation.
Well, some explanation will be needed, if only in passing, else you may get over-excited by thoughts that Source, below, means I’m presenting anything illicit. I am repeatedly amazed at how people I correspond wth or know socially think I have some sort of inside knowledge. Some even think I have access to Microsoft’s source code! I do not. Quite the opposite. Unlike many who write about Windows as experts, I make a point of using nothing but Microsoft’s widely (if not freely) published resources for Windows programming and, of course, the Windows binaries. I don’t attend presentations on new features. I don’t cultivate Microsoft programmers semi-socially for background. I do my own research and I do it as independently of Microsoft as possible.
Another difference of my approach from others’ is that I don’t see reverse engineering Windows as compensating for not having the source code. The increasingly popular (and, one hopes, increasingly capable) tools that attempt to reconstruct source code have no attraction to me. Reverse engineering is for me an elaboration of debugging. Still, binary code is better understood for knowing how it gets built and I have not been doing this so intensely for so long without having picked up more than a thing or two about the Windows source code—not from having it, but by deducing from publicly available material.