Geoff Chappell - Software Analyst
This page lists the 45 exports that were newly exported from the Windows kernel for the original Windows Server 2003. All but one are still exported as of version 10.0.
Also listed are the 97 and 2 more that are first exported from the Windows kernel in the builds of version 5.2 for Windows Server 2003 SP1 and SP2, respectively. This is the one and only time that a service pack adds more exports than did the same version’s original release. The reason, of course, is that Windows Server 2003 SP1 is the first x64 build.
To convey more detail with less text, the page relies heavily on several types of shortcut.
The first is that although a few of the kernel’s exports are of variables rather than functions, I tend to talk of all as functions, hoping that no confusion will be caused by the loose terminology. The variables are indicated by a parenthetical “data” after their first appearance in the Functions column.
Documentation status is summarised by colour coding. (Had the website’s scripts run as expected, then hovering over any colour-coded text would produce a tooltip that shows why the text is coloured.) (To decode a colour, hover for a tooltip.)
Functions that appear to be completely undocumented are highlighted yellow. If a function is documented now but was not documented in the first contemporaneous Device Driver Kit (DDK), Windows Driver Kit (WDK) or Installable File System (IFS) Kit, then it is shaded yellow to retain some of its previous status. If a function is documented as reserved or obsolete, it is shaded red or shaded grey, respectively. Otherwise, functions that have their own non-trivial documentation are left with no background colour.
Many undocumented functions and some variables have C-language declarations in one or another header file. To show them as being not completely undocumented they are shaded orange, except for one special case. Some declarations are known only from “minwin” headers that Microsoft published in early editions of the WDK for Windows 10 which seem since to have been withdrawn. These are highlighted orange to indicate that public disclosure even of the declaration was exceptional.
The default understanding is that exporting continues for all later versions, and in both the x86 and x64 builds. Exceptions are sketched in a column headed Export History.
The description “x86 only” means that the function is not exported from any known x64 build but is exported from the x86 build of at least some version that has an x64 build. If it had already ceased as an export before Windows Server 2003 SP1, the “x86 only” is left unstated.
The description “x64 only” means straightforwardly that the function is exported from x64 builds but not from any known x86 build.
That a function is “discontinued in” some version means that the function is exported up to but not including the stated version and not in any later version unless “restored”.
It’s nothing but fair to note that the majority of these functions were not documented immediately. Even more were then or later said to require later versions. These misrepresentations of actual availability show also in C-language declarations for the functions’ use in programming. Conveying these differences between what the kernel exported and what Microsoft presented for drivers to import is the concern of columns headed Documentation History and Declaration History.
Conventions still in development!
As much as I might like to condense into one table as much as might be imagined is possible to summarise about all these functions’ history of availability both in the binary and according to the documentation and headers, many functions both individually and in groups demand additional explanation in text. I therefore break the tabulation according to Microsoft’s scheme of prefixes for separate areas of functionality within the otherwise monolithic kernel. Each function has its own row in one table, but please be sure to check for explanatory text before and (more usually) after the table.
Not quite half of these new exports for version 5.2 are nowadays documented, i.e., after nearly 20 years. For most, the documentation states (correctly) that the function is “available on Microsoft Windows Server 2003 and later”. A handful are documented as if they are not available until Windows Vista. A handful are documented only as being reserved, without saying which versions have them. Another fifth of the new functions are undocumented but with declarations in one or another of the WDK header files. Declarations, both of these and the documented functions, are mostly conditional (again correctly) on building for Windows Server 2003 or higher. The remaining third of the new functions had neither documentation nor declaration for well more than a decade. Then, apparently only by oversight for those early editions of the WDK for Windows 10, Microsoft published declarations for most of them!
| Function | Export History |
|---|---|
| DbgCommandString |
| Function | Export History | Documentation History | Declaration History |
|---|---|---|---|
| ExAcquireFastMutex | starts in SP1; before 6.2, x64 only; (x86 from HAL since 3.50) |
since 6.1 revision, documented start is 5.0 | since 6.0, declared start is 5.0 |
| ExAcquireRundownProtectionCacheAware | starts in SP1 | ||
| ExAcquireRundownProtectionCacheAwareEx | starts in SP1 | ||
| ExAllocateCacheAwareRundownProtection | starts in SP1 | ||
| ExEnterCriticalRegionAndAcquireFastMutexUnsafe | starts in SP1 | ||
| ExEnterCriticalRegionAndAcquireResourceExclusive | starts in SP1 | before 6.3, declared | |
| ExEnterCriticalRegionAndAcquireResourceShared | starts in SP1 | ||
| ExEnterCriticalRegionAndAcquireSharedWaitForExclusive | starts in SP1 | ||
| ExFreeCacheAwareRundownProtection | starts in SP1 | ||
| ExInitializeRundownProtectionCacheAware | starts in SP1 | ||
| ExQueryDepthSList | starts in SP1; x64 only |
since 6.1 revision, documented start is 5.0 | |
| ExReInitializeRundownProtectionCacheAware | starts in SP1 | ||
| ExReleaseFastMutex | starts in SP1; before 6.2, x64 only; (x86 from HAL since 3.50) |
since 6.1 revision, documented start is 5.0 | since 6.0, declared start is 5.0 |
| ExReleaseFastMutexUnsafeAndLeaveCriticalRegion | starts in SP1 | ||
| ExReleaseResourceAndLeaveCriticalRegion | starts in SP1 | before 6.3, declared | |
| ExReleaseRundownProtectionCacheAware | starts in SP1 | ||
| ExReleaseRundownProtectionCacheAwareEx | starts in SP1 | ||
| ExRundownCompletedCacheAware | starts in SP1 | ||
| ExSizeOfRundownProtectionCacheAware | starts in SP1 | ||
| ExTryToAcquireFastMutex | starts in SP1; before 6.2, x64 only; (x86 from HAL since 3.50) |
since 6.1 revision, documented start is 5.0 | since 6.0, declared start is 5.0 |
| ExWaitForRundownProtectionReleaseCacheAware | starts in SP1 | ||
| ExfReleasePushLockExclusive | starts in SP1 | ||
| ExfReleasePushLockShared | starts in SP1 | ||
| ExfTryToWakePushLock | starts in SP1 | ||
| ExfUnblockPushLock | |||
| ExiAcquireFastMutex | starts in SP1; x86 only |
before 6.2, declared | |
| ExiReleaseFastMutex | starts in SP1; x86 only |
before 6.2, declared | |
| ExiTryToAcquireFastMutex | starts in SP1; x86 only |
before 6.2, declared | |
| ExpInterlockedFlushSList | starts in SP1; x64 only |
||
| ExpInterlockedPopEntrySList | starts in SP1; x64 only |
||
| ExpInterlockedPushEntrySList | starts in SP1; x64 only |
The ExAcquireFastMutex, ExReleaseFastMutex and ExTryToAcquireFastMutex functions have earlier history as exports from the HAL. In this sense, they date from version 3.50 and have always been documented. The x64 processor architecture brought a rethink of how some functionality is distributed between the kernel and the HAL such that x64 Windows has only ever known these functions as exports from the kernel. The x86 implementations also moved to the kernel at this time but with the complication of being renamed to start with the Exi prefix. When this was tidied for Windows 8, the Exi functions joined the few kernel exports that have been lost from the declarations and become undocumented.
Though ExQueryDepthSList is an exported function only on x64 builds, it is older as an x86 macro. This is first defined in the NTDDK.H from the DDK for Windows NT 4.0 and is first documented in the DDK for Windows 2000.
| Function | Documentation History |
|---|---|
| FsRtlAddBaseMcbEntry | |
| FsRtlGetNextBaseMcbEntry | |
| FsRtlInitializeBaseMcb | before 2018, declared |
| FsRtlLookupBaseMcbEntry | before 2018, declared |
| FsRtlLookupLastBaseMcbEntry | |
| FsRtlLookupLastBaseMcbEntryAndIndex | |
| FsRtlNumberOfRunsInBaseMcb | |
| FsRtlRemoveBaseMcbEntry | before 2018, declared |
| FsRtlResetBaseMcb | |
| FsRtlSplitBaseMcb | |
| FsRtlTruncateBaseMcb | |
| FsRtlUninitializeBaseMcb | before 2018, declared |
For very many years, Microsoft did not document any functions that work with the BASE_MCB structure, which version 5.2 extracted from the older LARGE_MCB. That they are all declared but undocumented looked to be still true when checking online on 13th October 2018. Now in 2020, Microsoft’s website has documentation for four of them, all dated 19th October 2018.
| Function | Export History | Documentation History |
|---|---|---|
| InitializeSListHead | starts in SP1; x64 only |
before 2018, SDK documented start is 5.0 |
The InitializeSListHead function dates from version 5.1 as an x86 macro defined concurrently with the newly exported functions InterlockedPopEntrySList and InterlockedPushEntrySList. These provide for lock-less use of the sequenced single-linked list that had been introduced for version 4.0. Lock-less use presented some difficulty for early 64-bit Windows which could not (yet) require the cmpxchg16b instruction. Perhaps to have more freedom over the implementation’s development, 64-bit Windows has only ever known InitializeSListHead (and ExQueryDepthSList, above) as exported functions, not macros. How this matters for a historical survey is that these functions for lock-less use of sequenced single-linked lists were for many years documented not in any DDK but in the Software Development Kit (SDK) for user-mode progamming. Not until 2018 when Microsoft reorganised its programming documentation around which headers have functions’ declarations is InitializeSListHead explicitly documented for kernel-mode programming. How it is then said to have been available as early as 5.0 is not known.
| Function | Export History | Documentation History |
|---|---|---|
| IoCsqInitializeEx | ||
| IoCsqInsertIrpEx | ||
| IoGetPagingIoPriority | before 6.0, declared | |
| IoIs32bitProcess | starts in SP1; x64 only |
documented start is 5.1 |
| IoTranslateBusAddress | starts in SP1 | |
| IoWMIDeviceObjectToProviderId | starts in SP1; x64 only |
since 6.1 revision, documented start is 5.0 |
The IoIs32bitProcess function was documented well in advance, in the DDK for Windows XP, as “only available in Windows XP and later, for 64-bit platforms.” Though the DDK for Windows 2003 dropped the warning that “This is preliminary documentation and subject to change”, the function is to this day presented as “Available in 64-bit versions of Windows XP and later”. Given this study’s restriction of interest to x86 and x64 processor architectures, the only known 64-bit Windows XP is in fact version 5.2 SP1.
Also documented well in advance, though starting with the DDK for Windows 2000, is IoWMIDeviceObjectToProviderId. It is documented for both 32-bit and 64-bit Windows. Its x86 support is by macro.
| Function | Export History | Documentation History |
|---|---|---|
| KdChangeOption | starts in SP1 | before 6.1, declared |
| KdRefreshDebuggerNotPresent | before SP1, declared | |
| KdSystemDebugControl | starts in SP1 |
| Function | Export History | Documentation History | Declaration History |
|---|---|---|---|
| KeAcquireGuardedMutex | starts in SP1 | documented start is 5.2 | |
| KeAcquireGuardedMutexUnsafe | starts in SP1 | documented start is 5.2 | |
| KeAcquireInStackQueuedSpinLock | starts in SP1; before 6.2, x64 only; (x86 from HAL since 5.1) |
since 6.0, declared start is 5.1 | |
| KeAcquireInStackQueuedSpinLockForDpc | before 6.0, undocumented; documented start is 6.0 |
since 6.0, declared start is 6.0 | |
| KeAcquireInStackQueuedSpinLockRaiseToSynch | starts in SP1; before 6.2, x64 only; (x86 from HAL since 5.1) |
||
| KeAcquireQueuedSpinLock | starts in SP1; before 6.2, x64 only; (x86 from HAL since 5.0) |
before 5.1 (IFS) to 6.0, undocumented | since 6.0, declared start is 5.1 |
| KeAcquireQueuedSpinLockRaiseToSynch | starts in SP1; before 6.2, x64 only; (x86 from HAL since 5.0) |
||
| KeAcquireSpinLockForDpc | before 6.0, undocumented; documented start is 6.0 |
||
| KeAcquireSpinLockRaiseToDpc | starts in SP1; x64 only |
since 6.0, conditionally declared start is 5.0 | |
| KeAcquireSpinLockRaiseToSynch | starts in SP1; before 6.2, x64 only; (x86 from HAL since 4.0) |
before 5.0, declared | since 6.0, declared start is 5.0 |
| KeAreAllApcsDisabled | starts in SP1 | documented start is 5.2 | |
| KeDeregisterNmiCallback | |||
| KeEnterGuardedRegion | starts in SP1 | documented start is 5.2 | |
| KeExpandKernelStackAndCallout | starts in SP1; before 6.0, x64 only; |
before 6.0, declared | |
| KeGenericCallDpc | |||
| KeGetCurrentIrql | starts in SP1; x64 only; (x86 from HAL since 3.10) |
since 6.1 revision, documented start is 5.0 | |
| KeInitializeCrashDumpHeader | starts in SP1 | before 6.2, not declared | |
| KeInitializeGuardedMutex | starts in SP1 | documented start is 5.2 | |
| KeInitializeThreadedDpc | before 6.0, undocumented; documented start is 6.0 |
||
| KeInvalidateAllCaches | before 6.0, declared | ||
| KeIpiGenericCall | before 6.0, declared | ||
| KeIsWaitListEmpty | starts in SP1 | ||
| KeLastBranchMSR (data) | starts in SP1; x64 only |
||
| KeLeaveGuardedRegion | starts in SP1 | documented start is 5.2 | |
| KeLowerIrql | starts in SP1; x64 only; (x86 from HAL since 3.10) |
since 6.1 revision, documented start is 5.0 | |
| KeQueryMultiThreadProcessorSet | starts in SP1; x64 only |
||
| KeQueryPrcbAddress | starts in SP1; x64 only |
||
| KeRaiseIrqlToDpcLevel | starts in SP1; x64 only; (x86 from HAL since 4.0) |
before 5.1, declared; since 6.1 revision, documented start is 5.0 |
|
| KeRegisterNmiCallback | |||
| KeReleaseGuardedMutex | starts in SP1 | documented start is 5.2 | |
| KeReleaseGuardedMutexUnsafe | starts in SP1 | documented start is 5.2 | |
| KeReleaseInStackQueuedSpinLock | starts in SP1; before 6.2, x64 only; (x86 from HAL since 5.1) |
since 6.0, declared start is 5.1 | |
| KeReleaseInStackQueuedSpinLockForDpc | before 6.0, undocumented; documented start is 6.0 |
since 6.0, declared start is 6.0 | |
| KeReleaseQueuedSpinLock | starts in SP1; before 6.2, x64 only; (x86 from HAL since 5.0) |
before 5.1 (IFS) to 6.0, undocumented | since 6.0, declared start is 5.1 |
| KeReleaseSpinLock | starts in SP1; before 6.2, x64 only; (x86 from HAL since 3.10) |
since 6.1 revision, documented start is 5.0 | since 6.0, conditionally declared start is 5.0 |
| KeReleaseSpinLockForDpc | before 6.0, undocumented; documented start is 6.0 |
||
| KeSignalCallDpcDone | |||
| KeSignalCallDpcSynchronize | |||
| KeTestSpinLock | before 6.0, declared | ||
| KeTryToAcquireGuardedMutex | starts in SP1 | documented start is 5.2 | |
| KeTryToAcquireQueuedSpinLock | starts in SP1; before 6.2, x64 only; (x86 from HAL since 5.0) |
before 5.1 (IFS) to 6.0, undocumented | since 6.0, declared start is 5.1 |
| KeTryToAcquireQueuedSpinLockRaiseToSynch | starts in SP1; before 6.2, x64 only; (x86 from HAL since 5.0) |
||
| KeTryToAcquireSpinLockAtDpcLevel | starts in SP1 | in 6.0, declared start is 5.1 (x86) | |
| KfRaiseIrql | starts in SP1; x64 only; (x86 from HAL since 3.50) |
||
| KiCheckForKernelApcDelivery | |||
| KiCheckForSListAddress | starts in SP2; x86 only |
||
| KiCpuId | starts in SP1; before 6.2, x64 only; discontinued in 6.3 |
Documentation even in 2020 would have it that the several functions that work with the guarded region and guarded mutex are available on Windows Server 2003 without requiring SP1. The original Windows Server 2003 certainly does have the notion of a guarded region and plausibly has inlined routines that implement a guarded mutex as a fast mutex acquired in a guarded region, but it does not export any functions for this work.
Though the Interrupt Request Level (IRQL) is fundamental in kernel-mode programming it was at first the business of the HAL. For x86 Windows, functions that work with the IRQL are HAL exports only and functions that work with the various types of spin lock are distributed between the HAL and the kernel according to whether they involve the IRQL. For x64 Windows, the IRQL has direct support from the processor (through the cr8 register) and the HAL’s involvement is simplified away. Old friends from the 32-bit HAL, along with some obscurities, become new exports from the 64-bit kernel. Thus does it happen that a function is listed above as newly exported from the kernel but is documented as having earlier availability. This is not remarked on above, when correct for the function as a HAL export.
Between x86 and x64 Windows, the KeAcquireSpinLockRaiseToDpc function is genuinely new for Windows Server 2003 SP1, but it does have earlier history, just not for the x86. The DDK for Windows NT 4.0 declares it as an exported function for all processor architectures other than the x86. It is first documented in the DDK for Windows XP. Starting with the revised WDK for Windows 7, it is said to be “Available in the 64-bit versions of Windows 2000 and in later 64-bit versions of Windows.” No 64-bit Windows 2000 is known to this study, which is limited just to the i386 (x86) and amd64 (x64) processor architectures. A 64-bit Windows XP is, but only as a marketing name, its kernel actually being version 5.2 SP1. ;
The KeDeregisterNmiCallback and KeRegisterNmiCallback functions are documented in the DDK for Windows XP as being available for Windows XP. So may have been the plan, but they were not exported so early, nor even declared in any header, and there is no support for the callback in the version 5.1 kernel’s NMI handling.
That KeAreAllApcsDisabled has always been documented as being available in Windows Server 2003 without the qualification of needing SP1 may tell something of Microsoft’s methods for browsing its source code for what to document. If the function does exist before Windows Server 2003 SP1, it is only as an internal routine and only then inline (which can be seen very plainly in the internal routine that symbol files name RtlpCaptureStackTraceForLogging).
The KeInitializeCrashDumpHeader function is documented from the start as being “Declared in wdm.h and ntddk.h” but the WDK for Windows 8 is the first that actually does declare the function in any header.
The KeTryToAcquireSpinLockAtDpcLevel function has earlier history that is not shown above. Even on the x86, this function would not have been a HAL export. Indeed, it can be identified in the x86 kernel even in version 3.10 as the internal routine that symbol files name KiTryToAcquireSpinLock. The intention seems to have been to export this, renamed and slightly changed to __fastcall, from the version 5.1 kernel. It’s documented in the DDK for Windows XP and declared in NTDDK.H and WDM.H. As late as the WDK for Windows Vista, it has an x86-specific declaration in a conditional block for Windows XP and higher. Even so, the x86 kernel doesn’t export this function until there’s also an x64 kernel.
| Function | Export History | Documentation History | Declaration History |
|---|---|---|---|
| MmAllocatePagesForMdlEx | starts in SP1 | before 6.0, declared | |
| MmCreateMirror | before 6.0, declared | ||
| MmDoesFileHaveUserWritableReferences | starts in SP2 | before 6.1, undocumented; documented start is 6.0 |
declared start is 6.0 |
| MmIsIoSpaceActive | before 6.0, declared |
| Function | Export History | Documentation History |
|---|---|---|
| PsGetCurrentProcessWin32Process | starts in SP1 | |
| PsGetCurrentProcessWow64Process | starts in SP1; x64 only |
|
| PsGetCurrentThreadProcess | starts in SP1 | |
| PsGetCurrentThreadProcessId | starts in SP1 | |
| PsGetCurrentThreadTeb | starts in SP1 | before 6.2, undocumented; documented start is 6.1 |
| PsGetCurrentThreadWin32Thread | starts in SP1 | |
| PsGetCurrentThreadWin32ThreadAndEnterCriticalRegion | starts in SP1 | |
| PsGetProcessSessionIdEx | ||
| PsGetProcessWow64Process | starts in SP1; x64 only |
|
| PsIsSystemProcess | starts in SP1 | |
| PsWrapApcWow64Thread | starts in SP1 |
| Function | Export History | Documentation History | Declaration History |
|---|---|---|---|
| RtlCopyMemory | starts in SP1; x64 only |
since 6.1 revision, documented start is 5.0 | |
| RtlCopyMemoryNonTemporal | starts in SP1; x64 only |
before 2018, declared; documented start is 5.2 |
|
| RtlInitAnsiStringEx | |||
| RtlInitUnicodeStringEx | since 6.0, declared start is 5.1 | ||
| RtlLookupFunctionEntry | starts in SP1; x64 only |
documented only in SDK | |
| RtlPcToFileHeader | starts in SP1; before 10.0, x64 only |
documented only in SDK | |
| RtlRestoreContext | starts in SP1; x64 only |
documented only in SDK | |
| RtlUnwindEx | starts in SP1; x64 only |
documented only in SDK | |
| RtlVirtualUnwind | starts in SP1; x64 only |
documented only in SDK |
The RtlCopyMemory function has x86 support as a macro, simply reinterpreting it as the C Run-Time memcpy (which may anyway be treated by the compiler as intrinsic). The definition dates from the DDK for Windows NT 3.1, though documentation waited for version 3.50 or 3.51. Even as an exported function in x64 Windows, it has no implementation in the kernel: it is just a forward to memmove.
The RtlCopyMemoryNonTemporal function is first declared in the DDK for Windows XP. The declaration is specificially for the amd64 architecture. For all others, the function is instead defined by macro as an alias of RtlCopyMemory. Whether as a function or macro, it is not in Windows 10 WDK documentation as published for integration into Visual Studio 2015 and I have no record of it in surveys of Microsoft’s online documentation in 2016 or 2018. What’s online now is dated 19th October 2018 and I see no reason to doubt this as a date of first publication. Since this documentation does not say the function is for 64-bit Windows only, the stated availability (Windows Server 2003 even before SP1) must count as a little too early for the function as an export without being early enough for it as a macro.
What to say about RtlLookupFunctionEntry?
| Function | Export History |
|---|---|
| SeReportSecurityEvent | starts in SP1 |
| SeSetAuditParameter | starts in SP1 |
| Function | Export History |
|---|---|
| WmiTraceFastEvent | discontinued in 6.0 |
| Function | Export History | Documentation History | Declaration History |
|---|---|---|---|
| ZwAddDriverEntry | |||
| ZwDeleteDriverEntry | |||
| ZwEnumerateDriverEntries | |||
| ZwModifyBootEntry | |||
| ZwModifyDriverEntry | |||
| ZwQueryDriverEntryOrder | |||
| ZwSecureConnectPort | starts in SP1 | before 6.1, declared | in 6.0, declared start is 5.2 SP1 |
| ZwSetDriverEntryOrder |
To be clear, since it is unusual, the NTIFS.H from the WDK for Windows Vista declares ZwSecureConnectPort, and then the declaration disappears except for the presumably accidental disclosure of ZWAPI.H in early editions of the WDK for Windows 10.
| Function | Export History | Documentation History |
|---|---|---|
| __C_specific_handler | starts in SP1; x64 only |
before 2015-2022, declared |
| __chkstk | starts in SP1; x64 only |
|
| __misaligned_access | starts in SP1; x64 only |
|
| _local_unwind | starts in SP1; x64 only |
|
| _setjmp | starts in SP1; x64 only |
|
| _setjmpex | starts in SP1; x64 only |
|
| longjmp | starts in SP1; x64 only |
|
| memcmp | starts in SP1; before 6.2, x64 only |
An image-relative reference to the __C_specific_handler function is generated by Microsoft’s 64-bit compilers for the unwind data information of any function that uses Structured Exception Handling (SEH).
Calls to the _local_unwind function are generated by Microsoft’s 64-bit compilers when C and C++ functions leave a __finally block non-trivially. Contemporaneous 32-bit compilers generate calls to _local_unwind2 instead. The latter is exported from all known x86 builds of the kernel and got its own page of documentation as early as Visual Studio 2012. The 64-bit form, however, looks to be undocumented.
Not shown above is that version 5.2 restores ObDeleteCapturedInsertInfo as an export. In terms of version number, though not chronologically, this function is exported first from Windows 2000 SP4. It is not exported from version 5.1, including from all three of its formally released service packs.
Slightly different is that FsRtlCreateSectionForDataScan and IoEnumerateRegisteredFiltersList are restored as exports in version 5.2 SP1. Reckoning by version number, these functions are exported first from Windows XP SP3, apparently too late chronologically to be exported from the original release of version 5.2.
Version 5.2 stops exporting a few functions. For each, the version in parentheses tells when the function was first exported:
Two of these are restored as exports in version 6.0, again because they are new exports for Windows Vista but appear in this survey for version 5.1 because they were back-fitted to Windows XP for its last service packs.
Of course, many exports from earlier versions continue for the x86 builds but are not taken up for exporting from the x64 builds. It’s perhaps as well to list them: