Geoff Chappell - Software Analyst
Research and writing has not exactly stopped but is slowed. The last six months of full-time research and writing were a catharsis after five years of full-time employment that permitted external research in theory but frustrated its practice. Now such work goes back to nights and weekends while I use my working week to seek clients for consultation. Please recommend to anyone you know who might make good use of an expert Windows programmer: they possibly don’t themselves know. Meanwhile, enjoy what little new work comes this month, and perhaps catch up with what I did in October.
You might think that basic updating—of user-level features, no less—is ideal for part-time attention. But then you start tracking changes across half a dozen versions and their service packs. Working through it all with reasonable care is no picnic: at least I’m not trying to do it in a ridiculously noisy office!
The attempt over the last few months to document the ZwQuerySystemInformation function and its companions and all their numerous cases and related structures will keep me tidying up for a long while yet.
And there are inevitably diversions. Like others, I find myself fascinated by the execution of the Windows kernel under a hypervisor not to run multiple installations of Windows on one computer, as for testing, but just so that the one installation can be much more secure by using the processor’s support for virtualisation. The hypervisor functionality that is needed for this Virtual Secure Mode is new for Windows 10 but isn’t yet covered in the Hypervisor Top-Level Functional Specification, which today (12th November 2016) offers as its most recent version a PDF that is dated August 2013. If we’re naive about the Microsoft Open Specification Promise, we might soon expect an updated version of that documentation.
Less like others, I find myself as much fascinated by where some hypervisor details leak from Microsoft. The many flags that Microsoft’s hypervisor can produce in response to the CPUID instruction are interpreted by both the loader and the kernel. Both plainly have structural definitions to work from, but no type information for those structures gets into the symbol files for either. Of itself, this is nothing strange: many structures that exist for the kernel’s internal use don’t show in the public symbol files and wouldn’t be expected to. These structures, however, aren’t kept as internal. They do show in some symbol files. What’s bizarre is which ones. In the whole of the symbols packages that Microsoft publishes for 32-bit and 64-bit Windows 10, only one symbol file in each has type information for these hypervisor flags—and the corresponding binary is a key component not of Windows but of Internet Explorer! Weren’t these games of building Internet Explorer with programmatic access to internal Windows details supposed to be long done and dusted?
You might think there’s nothing much to write about an ancient and generally deprecated function that’s among the most familiar of the thousands of functions in the Windows API. In some versions, it’s only five CPU instructions—including the return. It must be thoroughly picked over by now. And yet…
This has been in preparation for months, having been put aside as I found ever more to write and new topics to research. Still, I do mean to finish it.