Update 2020/12/05: it seems that the Universal CRT libraries are not loading in Windows XP - working on getting that to work now
This project is about adding Win32/WinAPI functions to the Windows XP SP1/2003 codebase that are only available in newer versions of Windows. By adding these functions using applications under Windows XP/2003 - that are only working under Windows 2003R2/Vista/2008/2008R2/7/8/8.1/2016/10/10H2/2019 - will become a reality.
The functions have to be added to the C-sources of several system libraries (DLL's typically available in the
c:\windows\system32 folder), build into binary form (compiling/linking), and replaced with the standard ones to be available to applications.
Since the source code has become available this can be done, see Windows Server 2003 (NT 5.2.3790.0) build guide
However as the source for these missing functions is not publicly available, the best available source is the source code of the Wine project project (link to source of DLL's) or approximations of code that has been reverse-engineered with tools like Ghidra/IDA.
Documentation on them can be found on Microsoft's site at https://docs.microsoft.com/en-us/windows/win32/api/ like:
- the correct function signature, which usually differs in Wine's code
- a proper description of the input and output parameters
- purpose of the function
- sometimes a C-code usage example
- minimal supported version of Windows
- what C-header file (*.h) of the Windows 10 SDK (link to headers) defines the function declaration and (possible) custom datatypes
e.g. documentation for GetDpiForWindow
The latest status can be seen in the tables below.
This is not intended to be a secure implementation for now, it just intended to provide compatibility. Some functions are being tested now, as Python 3.9 and other applications do crash when starting, using a small program (WIP) calling the function with an input value, see TestHarness.
New C-source files that are implementing functions start with an
_. Missing functions in applications can be found out by loading the executable into Dependency Walker.
Needs help as they are many functions to be back-ported!
A message box shows an unfriendly 0xC0000142 NT status to the user (STATUS_DLL_INIT_FAILED).:
Further analysis in WinDbg for
pythonw.exe 3.9 revealed:
LDR: LdrpInitializeProcess - Failed running initialization routines; status c0000142
[6a8,6b4] LDR: DLL_PROCESS_ATTACH for dll "downlevel\ucrtbase.dll" (InitRoutine: 0050B170) failed
This ucrtbase.dll is included in the ApiSet/downlevel package below and might require a fix...
This paper from 1999 goes deeper into how to debug these errors: https://manualzz.com/doc/19760582/loading-exe-and-dll-programs-matt-pietrek
Trying to load
LoadLibary using the test program:
ucrtbase.dll failed to load: 1114
A dynamic link library (DLL) initialization routine failed.
On Windows 10, this program loads fine, so possibly due to installation of other components, changes to kernel, currently missing in Windows XP it does not load.
UCRTBASE.DLL is part of Universal CRT, see https://docs.microsoft.com/en-us/cpp/windows/universal-crt-deployment?view=msvc-160
Here are more links.. http://www.geoffchappell.com/studies/windows/win32/apisetschema/index.htm?tx=3 https://ofekshilon.com/2016/03/27/on-api-ms-win-xxxxx-dll-and-other-dependency-walker-glitches/
After reading these it seems as if
- it is necessary to create a new
UCRTBASE.DLL, as it seems to require things only available in the Windows 10 kernel - regarding loading of functions/ApiSets, so now building one from scratch with a few implemented is an idea
- there is a check in place looking for a 'valid' Windows version and then stopping the execution, that needs to be overridden
(Original reference to error found here: https://github.com/mtth-bfft/win32k-mitigation)
Currently trying to get following software to work.
|DOSBox X 0.83 Win32\Release
||Does not come up: WinDBG analyze:
|MS Paint for Windows Vista||Does not work - Missing
|Google Chrome 87.0 (Offline Installer)||Installer does not come up: WinDBG analyze:
|Portable Apps OpenJDK 14||crashes with The application failed to initialize properly 0xc0000142)||2020/12/02|
|Node.js 14.15.1||Does not work - Missing
|Codeblocks 20.03||crashes with The application failed to initialize properly 0xc0000142)||2020/12/01|
|Foxit Reader 10.1||Does not work - Missing
|Firefox 83.0||Does not work - Missing
|Python 3.9||Shows command window and crashes with The application failed to initialize properly 0xc0000142) - Misses proper
|MS Paint for Windows 10
||Does not work - Missing
|Windows Explorer for Windows 10
||MANY missing functions from KERNEL32.DLL||2020/11/23|
|Notepad for Windows 10
||Does not work - Missing
|Task Manager for Windows 10
||Does not work - Missing
||Works - just starts Wordpad||2020/11/21|
- A x86 version of Windows 2003 / XP SP1 with source code available: see build-win2k3
- Disable Windows File Protection when DLL's replacing after installation, see https://www.technipages.com/enable-disable-wfp
- Ability to execute executables built for newer versions than Windows XP SP2 / Windows Server 2003 RTM (NT 5.2): https://rentry.co/kernel32-version-unlock
- The changes in place in either source code and then installing the build or replacing the DLL's after installation
- WinDbg/OllyDb/etc to debug
|NTDLL.DLL||exports the Windows Native API. The Native API is the interface used by user-mode components of the operating system that must run without support from Win32 or other API subsystems. Most of this API is implemented in NTDLL.DLL and at the upper edge of ntoskrnl.exe (and its variants), and the majority of exported symbols within these libraries are prefixed Nt, for example NtDisplayString. Native APIs are also used to implement many of the "kernel APIs" or "base APIs" exported by KERNEL32.DLL. The large majority of Windows applications do not call NTDLL.DLL directly|
|KERNEL32.DLL||exposes to applications most of the Win32 base APIs, such as memory management, input/output (I/O) operations, process and thread creation, and synchronization functions. Many of these are implemented within KERNEL32.DLL by calling corresponding functions in the native API, exposed by NTDLL.DLL.|
|ADVAPI32.DLL||provides security calls and functions for manipulating the Windows Registry.|
|Changes in MSVCRT.DLL||Software intended to run on later than Windows 8/2012, does use
|Changes in MSVCIRT.DLL||When Windows boots, it compares the (kernel) version of Windows, typically NT 5.2, running with the version of MSVCRT.DLL \ MSVCIRT.DLL , the (main) Visual C++ Runtime (function) Library. If it doesn't match, it shuts download Windows immedialy or will show this BSOD:
To get the above software to work some Windows 10 DLL's have to be copied, as these apps need it (except Hello World and Write.exe); the ones that do live in
c:\windows\system32\downlevel (on 32-bit Windows version)
These are socalled ApiSets, see https://docs.microsoft.com/en-us/windows/win32/apiindex/windows-apisets
First this directory must be added to Windows XP/2003, then the path where they are stored needs to be added Windows XP's
PATH environment variable. These are slightly patched, to match the import:
kernel32.VirtualProtect : see https://rentry.co/extras-downlevel
|kernel32-version-unlock||When a new executable (.exe-file) is launched, Windows will call a variant of the CreateProcess / CreateProcessInternalW function from the KERNEL32.DLL library, which will eventually call the BasepIsImageVersionOk function which will detect if that executable is build for NT version 5.2 or lower and allow the executable to run. When this is not the case, thus in case of a Windows 10 (NT version 10) executable: Windows will stop the execution with a popup-message: ...exe is not a valid Win32 application.|
|msvcrt-excepthandler4common||Software intended to run on later than Windows 8/2012, does use
|extras-sal||Enable source-code annotation language (SAL) support|