NTIOAPI_X.H

The public symbol file NTKRPAMP.PDB for the original release of Windows 10 tells that the kernel is built with the NTIOAPI_X.H header at

d:\th.public.fre\internal\sdk\inc\minwin

and draws from it the type definitions that are shown in the table below. NTIOAPI_X.H is published in the “minwin” directory of the Windows Driver Kit (WDK) for Windows 10 in the original and Version 1511 editions. This disclosure is here thought to have been an oversight. Publication is not continued in later editions.

All types that the kernel is known to pick up from NTIOAPI_X.H are defined in the standard header WDM.H or in the slightly less standard header NTIFS.H. The line numbers on the left of the table are from NTIOAPI_X.H as known from the symbol file. All agree with the NTIOAPI_X.H from the WDK for the original release of Windows 10. The line numbers on the right are from the WDM.H and NTIFS.H in the same WDK.

Explanation of what can be known of the correspondence between definitions in NTIOAPI_X.H and in the others is easier if NTIOAPI_X.H is treated as a master from which definitions in the other files are copied, but keep in mind that NTIOAPI_X.H may itself be tool-generated. Still, at least for NTIOAPI_X.H, more is known than just its name, some of the types it defines, and the line numbers that have the opening braces of these definitions. Few candidates as master headers are supplied even in the “minwin” disclosure, and NTIOAPI_X.H is by far the largest. Its availability means that the mapping of line numbers in NTIOAPI_X.H to line numbers in WDM.H can be known not just for the relatively few that are identified by the symbol file. Instead, It can worked out with good confidence in its entirety.

Certainty would require access to the extraction tool, but a good sense of the scheme seems safe to infer from observation. Lines in NTIOAPI_X.H are copied to other headers if they end with a comment in a particular form or they are between comments in a particular form. For these comments the other headers have names such as “wdm” for WDM.H. Ranges of lines to copy are book-ended by single-line comments that can contain apparently any number in any mix of begin_name and end_name. The copying to a header is just of lines between this header’s begin and end comments, non-inclusively. There looks to be no requirement that begin and end comments for the same name must balance. Ranges for different names look to be independent. A single line is copied to a header if it ends with a single-line comment that names the header. (Presumably, it becomes copy-able to multiple headers by having multiple names in the comment, but NTIOAPI_X.H has no example.) Where a line that is copied to a header has a comment that would select some other header, the comment may be copied or not: what rule governs this is unclear. See for instance that a “begin_winnt” and “end_winnt” at lines 32 and 94 in a range for copying to WDM.H become empty lines in WDM.H but a seemingly similar pair at lines 7231 and 7315 are copied whole to NTIFS.H.

The mapping from the 8719-line NTIOAPI_X.H to the other headers would be tedious to show in its entirety. For instance, lines are copied to WDM.H and to NTIFS.H in 15 and 34 distinct ranges. A summary is easier from the reverse perspective. Each of several headers from the WDK for Windows 10 or the contemporaneous Software Development Kit (SDK) has one range of contiguous lines that can all be accounted for as copies from NTIOAPI_X.H, either intact or after stripping selection comments:

The headers are ordered according to some rough and subjective measure of specialisation or of distance from kernel-mode programming. The first four are standard in the sense that driver code of the right sort can be written without including any of the other standard headers. NTOSIFS.H is slightly different in that it adds less public material to the more readily available NTIFS.H. It’s available for inspection only because it’s another “minwin” disclosure. WINNT.H and WINIOCTL.H are, of course, for user-mode programming. WUDFWDM.H is for user-mode drivers.

Extraction is also defined for several headers that have not been found in any kit. Their names in comments are: ntndis, ntoshvp and wudfpwdm.