NTDLL 3.51 Named Exports

The table below lists all the functions that are exported from NTDLL version 3.51. Most are still exported as of version 6.1.

Of roughly 2,400 functions that have ever been exported from NTDLL, nearly 1,000 date from as far back as Windows NT 3.51. Since by far the most of the other half were added 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.

Documentation status is conveyed by colour coding. NTDLL functions that actually are documented as exports from NTDLL are shown with no background colour. So too are the NTDLL implementations of documented functions from the C Run-Time Library. Functions that 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, are lightly shaded blue. Documented functions that are known not to have been documented immediately they were introduced are a darker blue if the only known documentation is in the WDK, else pink. If the delayed documentation came specifically from its listing among the Settlement Program Interfaces in late 2002, then the function is less pink since Microsoft at least acknowledged that the documentation was late. 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. Functions that look to be completely undocumented are highlighted yellow. However, an undocumented function is shaded yellow, as semi-documented, if it is at least declared in one or another header file from the WDK or, exceptionally, the SDK. If you browse with scripting enabled, hovering over any text that has a background colour should produce a tooltip that explains the formatting.

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 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 un-documented 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 6.1, there are some notable changes. The several dozen functions for floating-point emulation eventually got discontinued in what looks like 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.