Geoff Chappell - Software Analyst
Beware: this is old material being reworked.
For the vast majority of Windows Kernel Exports, Microsoft either lies about the applicable versions or says nothing.
Though saying nothing is unhelpful, it seems the less unethical and it anyway was readily understandable in the early years as natural neglect: not until version 4.0 does the kernel trouble to export any sort of function that tells drivers which Windows version they’re running on. Early Device Driver Kit (DDK) documentation only rarely mentions any Windows version other than the one the kit was prepared for, so much so that the DDK for Windows XP stood out for what would otherwise have been routine promotion of new functionality as new for Windows XP.
The first big change from mostly saying nothing was not in the documentation but in the declarations. The Windows Driver Kit (WDK) for Windows Vista, with headers dated 2nd November 2006, wrapped many declarations in conditional compilation blocks such that functions are exposed for programming only if building with an expected value of the NTDDI_VERSION macro. The lowest defined of these expected values was for Windows 2000. As appropriate as this may have been for a kit that had Windows 2000 as its oldest supported target version for building drivers, conditional blocks were added even for functions that long pre-date Windows 2000. These functions’ declarations might just as well have been left unadorned as far as could affect any programming.
A second change in 2009 carried this notion of Windows 2000 as the beginning of time into the documentation. The second WDK for Windows 7 (version 7600.16385.1, dated 1st December 2009) added “Available in Windows 2000 and later versions of Windows” to the documentation of nearly every function for which no minimum version was yet specified. This is not unreasonable inasmuch as it means only that Microsoft no longer supports earlier versions of Windows, but of course it will easily be taken by some as accurate history.
Of course, where Microsoft documents a function as available only in some versions, the intention may just be that those are the versions for which the function is implemented well enough for Microsoft to commit to its use by programmers in general. It could be that the function is exported from earlier versions but in an experimental or even defective implementation that Microsoft cannot support. Certainly, a pattern is discernable in which a function is said to be available starting from whichever Windows version was contemporaneous with the function’s introduction to the documentation. This is perhaps how RtlGetDaclSecurityDescriptor is dated to Windows Server 2003 SP1—yes, so precisely—even though it was by then ten years old as an original export (not only from the kernel but NTDLL too).