NTDLL 3.51 Exports

The table below lists all the functions that are exported from NTDLL version 3.51. In the absence of an earlier version to inspect, this study counts these exports as the originals. Most are still exported as of version 10.0.

Of the 2,680 functions that have ever been exported from NTDLL, 950 date from as far back as Windows NT 3.51. Since by far the next largest addition was for Windows Vista, it is striking that in terms of available functions, though not perhaps in terms of what can or should be done with them, a fully-informed low-level user-mode programmer from the mid-1990s would not have had much to learn for a decade. Also striking is that hardly any of these original functions are yet documented as being available in user mode as exports from NTDLL. This is not to say that all (or even most) should be, just that few are.

Documentation status is conveyed by colour coding. If you browse with scripting enabled, hovering over any text that has a background colour should produce a tooltip that explains the formatting. NTDLL exports that have all along had their own non-trivial documentation as exports from NTDLL are shown with no background colour. So too are the NTDLL implementations of documented functions and variables from the C Run-Time Library. If the whole of the documentation is just that the function is reserved or obsolete, without even giving a prototype, then the function is highlighted red or highlighted pink, respectively. Functions that look to be completely undocumented are highlighted yellow. If a function is documented now but is known not to have been documented immediately, especially in the contemporaneous Software Development Kit (SDK), then it is shaded yellow to retain some of its previous status as undocumented. If the delayed documentation came specifically from the function’s listing among the Settlement Program Interfaces in late 2002, then the shading is less yellow since Microsoft at least acknowledged that the documentation was late. An undocumented function is highlighted orange, as semi-documented, if it is at least declared in one or another header file from an SDK or, exceptionally, a Windows Driver Kit (WDK). NTDLL is low-level enough that some functions are documented in the Windows Driver Kit (WDK), typically as exports from the NT kernel for use by ring 0 software such as device drivers, but sometimes with non-specific talk of being callable from user mode. Such functions are shaded blue if they seem always to have had such documentation, but a brighter blue if the WDK documentation was not immediate. A function is shaded grey if it seems not to be documented but is known to be the entire low-level implementation of some function in a higher-level DLL such as KERNEL32 or ADVAPI32. Identifying these is a work in progress.

For the handful that are yet documented as NTDLL functions and the more whose kernel-mode equivalents are documented in the WDK, Microsoft either lies about the applicable versions or says nothing. Though the latter is unhelpful, it seems the less unethical and is anyway par for the course at this level: the WDK documentation never has bothered much about versions. Or so things stood until 2009. Preparation of a second WDK for Windows 7 (version 7600.16385.1, dated 1st December 2009) included the addition of “Available in Windows 2000 and later versions of Windows” to the documentation of just about 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. For now, this development is ignored in the table below, which has as its reference version only the first WDK for Windows 7 (version 7600.16385.0, dated 18th June 2009).

Of course, where Microsoft documents versions for which a function is available, the intention may just be that those are the versions for which the function is implemented well enough to consider usable 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 many of these original functions are said to be available starting from whatever Windows version was contemporaneous with the function’s introduction to the documentation. That is perhaps how RtlGetDaclSecurityDescriptor is dated from Windows Server 2003 SP1 (yes, so precisely) and is surely the only way anyone can credibly mean that ZwLockFile is not usable until Windows 7. Just as discernable a pattern is that where the documentation gives one implausibly recent version the relevant header file gives another (by declaring the function only for the right values of the NTDDI_VERSION macro), and this other is typically less recent. For instance, programmers in general are told that NtSetInformationToken is available from Windows 7, but the WDK evidently has been prepared so that some programmer, presumably at Microsoft, had the use of this function even when developing for Windows XP.

Special mention must be made of a few NTDLL functions that Microsoft documented as Settlement Program Interfaces in late 2002 apparently because they are used by Microsoft Middleware products such as Internet Explorer. There were not many at this low level. A good proportion have become re-undocumented in the years since, at least as exports from NTDLL. It should anyway not go unnoticed that Microsoft’s selection of functions to document for the settlement was very strict, if not grudging and perverse. See for instance that RtlTimeToSecondsSince1970 got documented but its inverse RtlSecondsSince1970ToTime did not.

Though most of these original NTDLL functions are still exported as of version 10.0, there are some notable changes. The several dozen functions for floating-point emulation eventually got discontinued in what looks to have been a clean-up across multiple versions (contemporaneous with the release of 64-bit Windows for the x64 platform). These functions drop out from version 5.1 at Windows XP SP2 and from version 5.2 at Windows Server 2003 SP1 and do not survive at all to version 6.0. Some may say this was long past time, especially once Windows started requiring the cmpxchg8b instruction and thus in practice a CPU recent enough to be sure of having a built-in floating-point unit.

One oddity had better be remarked on now lest it be thought a mistake in the table. The NtGetTickCount function was dropped just for version 5.1. Its companion, ZwGetTickCount, was also dropped for version 5.1 but only NtGetTickCount reappears for version 5.2.

One of the Remarks signals correction of a bug. See that several of the NTDLL exports correspond closely to functions that are exported from KERNEL32, though not in all versions. The KERNEL32 export is typically a forward to NTDLL, so that it resolved from KERNEL32’s export directory without needing any code in KERNEL32. That ordinarily means that if the NTDLL function is undocumented, then the documentation for KERNEL32 is as good for NTDLL. However, one of the forwards demonstrates an exception. The KERNEL32 function HeapFree is originally forwarded to the NTDLL function RtlFreeHeap, but the former returns a BOOL and the latter a BOOLEAN. When RtlFreeHeap fails, it returns zero in the al register, leaving the high 24 bits of eax undefined. Forwarding from HeapFree then has the unwanted effect that the return value of a failed HeapFree may be non-zero, as if for success. This eventually got corrected in version 6.0. Presumably by oversight, it is restored in Windows 7 for HeapFree as an export from the new KERNELBASE.