Jump to content

Project Saphire Dragon: Port LLVM and Clang


Recommended Posts


Windows XP/Server 2003 requires a Overhaul of it's outdated compiler tool set, @user57  & I have successfully managed to port LLVM 16.05 & LLVM 17.01 to WIndows XP along with CLANG.

CLANG and LLVM have superior performance characteristic to Microsoft's compiler, official build system of Chrome & Firefox uses LLVM.

Special Thanks:  USER57 for taking Herculean task of developing all these patches.

                          LLVM Project for their amazing work to bring cutting edge opensource tool chain throughout Unix/ MACOS/Linux & Windows.

Project Goals:

* LLVM 17.X/18.X with Clang  [Archived]

* SDK  upgrade for Windows XP/2K3

* Thread Local Support for NT5 [Windows 2000/XP/2K3]

* LLD Linker with ThinLTO 

* C++ 17/20/23 with LibC++

* Inline x86/x64 ASM 

* Native SEH 

* Intrinsic Support 

* Multithreaded Compilation 




1. Create C:\Program Files\LLVM\                                                   [For Other Address, edit reg file as instructed]


2. Copy all content from bin folder of download  to your newly created LLVM folder.


3. Apply llvm_xp.reg from installation/reg 


4. Copy content of installer/LLVM_VS2010.zip [Depending on your Visual Studio version] to C:\Program Files\LLVM\    




5. Extract Content & run install.bat


6.Change Tool CHain to LLVM in VIsual STudio


Link for Binary:

LLVM 16.05 : https://www.mediafire.com/file/8pk5ak2alrx1v5r/LLVM_XP_v16%281%29.zip/file

LLVM 17.01:  https://www.mediafire.com/file/hqhcwrcyaknun8h/LLVM_1701_XP_2K3.zip/file

[Microsoft Visual C++ Redist 2019 is required]


We are looking for more developer in this project.to archive all our goals.


Source Code:
It will be uploaded soon to Github along with Patch file for Windows 10 SDK 10.0.19041.0 & with User57's File Patcher tool which changes Subsystem & Major OS version of PE/Binary file kept under folder. Source code for LLVMXP.dll & other patches will be updated in Github Repository.



Guide on C++17 on Visual Studio 2010 By Win32:


Source COde: https://mega.nz/file/yzJRzapZ#_naxMXLDrplDUuSP8dQZF0jSRVWTI-esMkesiFXImWs

Edited by Dibya
Link to comment
Share on other sites

Can't commit to this since working other things but I really should since I need to for the https://www.vogons.org/viewtopic.php?f=5&t=84578&hilit=vogonsorg

Here are some interesting links:


https://www.vogons.org/viewtopic.php?p=1021297#p1021297 (This post and various others before it)

Stay far away from MSYS2 unless you use a win32 thread build of mingw-w64 and compile all third party libraries yourself. pacman and vpkg precompiled binaries are all posix.

Last time I tested mingw-w64 on Linux and WSL were win32 thread.

As of 2021 latest current GCC could compiled for NT3.51+.

For Posix XP support was broken with those commits.

So right now if I were to start I would:

1. Verify on Linux and WSL that latest GCC win32 thread could compile a working binary. If so and don't need posix then you're done!

2. If Posix needed then download a last known working build by downloading a working mingw-w64 package from repos, start from before those commits. My MSYS2 environment where I compiled via clang for XP was created on 5/31/2018.

3. Once you have a working Posix environment then save it and keep it safe!

4. Download mingw-w64 from just after those two commits, revert them and compile. If working environment then save it!

5. Work upwards until you have the latest mingw--64

Keep in mind that pre-compiled mingw-w64 is  i686+ so if you need to support less than that you'll need to recompile. I'm lazy so I just use regular mingw for i386+ for those binaries but it's always been on my list to look into recompiling mingw-w64 for that support.

You shouldn't have to limit yourself to an old version of VS, latest version should be fine as long as you use mingw-w64 to compile unless I'm missing something.

Edited by DosFreak
Link to comment
Share on other sites

Link to comment
Share on other sites

there is already a problem

1 function isnt found by visual studio 


so i looked the ntdll.lib and the lib file has got the function 

RtlRaiseStatus is present in ntdll.dll in windows xp

ntdll.lib is added in the linker list


so i added the function to at first my cpp file then on winnt.h

    DWORD Status

but the visual studio compiler keeps telling me that it dont find that 

i also tryed with NTSTATUS instead of DWORD but that doesnt change anything

what is causeing that problem?



i know i could go for a loadlibrary and getprocaddress

or maybe the definition from reactos 




well i choosed a solution just by doing the same thing windows is doing 

RtlRaiseStatus(IN NTSTATUS Status)
    EXCEPTION_RECORD ExceptionRecord;

    ExceptionRecord.ExceptionAddress = _ReturnAddress();
    ExceptionRecord.ExceptionCode = Status;
    ExceptionRecord.ExceptionRecord = NULL;
    ExceptionRecord.NumberParameters = 0;
    ExceptionRecord.ExceptionFlags = EXCEPTION_NONCONTINUABLE;





Edited by user57
Link to comment
Share on other sites

  • 11 months later...
Posted (edited)

Documentation for Project:

[Github not working at this moment]

Compile API Library LLVM XP from Here: https://www.mediafire.com/file/s2q3upkqx54tv3n/llvmxp_dll_source_code.zip/file

Get Rest of Patches from Here: https://www.mediafire.com/file/qsoxzy93tnwgg6f/llvm_xp_v2.1.7z/file

Get LLVM compiled first as per Official Instruction:

Open psapi.h and Change following Code

    _In_ HANDLE hProcess,
    _Out_writes_bytes_(cb) HMODULE* lphModule,
    _In_ DWORD cb,
    _Out_ LPDWORD lpcbNeeded


    HANDLE hProcess,
    HMODULE* lphModule,
    DWORD cb,
    LPDWORD lpcbNeeded


Change Following:

    HANDLE Process,
    DWORD cb


    HANDLE Process,
    DWORD cb

Similarly Rename Following

GetMappedFileNameA to GetMappedFileNameAX, ,
DynamicLibrary.inc (LLVMSupport)  [ EnumProcessModules to EnumProcessModulesX] ,
Program.inc (LLVMSupport) [ GetProcessMemoryInfo to GetProcessMemoryInfoX]
KillTheDoctor.cpp (KillTheDoctor)
GetMappedFileNameA  to: GetMappedFileNameAX


Now Time Comes for Changes to Sourcecode Itself:
Place srw_locks.c inside llvm-cov /Source File

Due to Internal Catching of Microsoft VCC Platform we need to apply xp_obj.asm to whole project via MASM option  to eliminate following API:

EXTERN _RtlTryAcquireSRWLockShared@4 : PROC
EXTERN _RtlTryAcquireSRWLockExclusive@4 : PROC
EXTERN _RtlReleaseSRWLockExclusive@4 : PROC
EXTERN _RtlAcquireSRWLockExclusive@4 : PROC
EXTERN _RtlReleaseSRWLockShared@4 : PROC
EXTERN _RtlAcquireSRWLockShared@4 : PROC

EXTERN _InitOnceBeginInitializeX@16 : PROC
EXTERN _InitOnceCompleteX@12 : PROC

EXTERN _GetThreadGroupAffinityX : PROC
EXTERN _SetThreadGroupAffinityX : PROC

EXTERN _CompareStringOrdinal_SRW@20 : PROC

EXTERN _GetLargePageMinimum_SRW@0 : PROC


Changes to Windows 10 SDK for XP Compatibility: "processtopologyapi.h" and "sysinfoapi.h"

GetProcessGroupAffinity renamed to:

GetLogicalProcessorInformationEx renamed to


Changed from




This makes MSVC to search the api in reggetvaluew_emu.c which is placed in placed in LLVMSupport / Source Files

"processthreadsapi.h" is modified








                            _In_ DWORD dwFlags,// KNOWN_FOLDER_FLAG 
                            _In_opt_ HANDLE hToken,
                            _Outptr_ PWSTR *ppszPath); // free *ppszPath with CoTaskMemFree


    DWORD dwflags,
    HANDLE token,
    PWSTR* path

Changes to source: ShGetKnownFolderPath_Emu.c (placed in LLVMSupport / Source Files)

SetFileInformationByHandle_Emu (placed in LLVMSupport / Source Files)

    _In_ HANDLE hFile,
    _In_ FILE_INFO_BY_HANDLE_CLASS FileInformationClass,
    _In_reads_bytes_(dwBufferSize) LPVOID lpFileInformation,
    _In_ DWORD dwBufferSize

renamed to

    HANDLE hFile,
    FILE_INFO_BY_HANDLE_CLASS FileInformationClass,
    LPVOID lpFileInformation,
    DWORD dwBufferSize

Due to bugs in LLVM Source itself

    _In_ HANDLE hFile,
    _Out_writes_(cchFilePath) LPWSTR lpszFilePath,
    _In_ DWORD cchFilePath,
    _In_ DWORD dwFlags

renamed to

    HANDLE hFile,
    LPWSTR lpszFilePath,
    DWORD cchFilePath,
    DWORD dwFlags



Changes Made to LLVM Sources:

llvm file changed "Threading.inc" GetProcessGroupAffinity to GetProcessGroupAffinityX (LLVMSupport)
llvm file changed "Threading.inc" GetLogicalProcessorInformationEx to GetLogicalProcessorInformationExX (LLVMSupport)

llvm file Threading.inc GetThreadId rename to GetThreadIdX (LLVMSupport)

Rename Respective Function in file in Path.inc (LLVMSupport)

(loads llvmxp.dll)

change file in llvm (Path.inc) GetFinalPathNameByHandleWX (2 times)
DirectoryWatcher-windows.cpp GetFinalPathNameByHandleWX (2 times)


Repeated Information:
in files such as:
"llvm-ifs.exe" "llvm-objcopy.exe" "clang-linker-wrapper.exe"
have missing imports like the SRW locks missing or that GetLargePageMinimum function
srw_locks_Emu.c and xp_obj.asm have to be placed in
either the refence project or at that executables source files with MASM option clicked in in Project Properties.

With Following Comments :

#pragma comment(lib, "kernel32.lib")
#pragma comment(lib, "ntdll.lib")   


note microsofts remove of server 2003 and windows xp in STL (version higher then 16.7):

Once Binary are Compiled , You will face NT6 as default Sub System Version in Binary, Linker of MS is bastardized to kill Windows XP> Modern Mafia Linker needs Modern Solution

Here Patcher that can patch whole Binary inside a folder for Linker Subsytem Version [No need of doing anything Manually]

Patcher: https://www.mediafire.com/file/05pe1sc2rgjc81e/File_Patcher.zip/file


Special Thanks to @user57 for doing majority of heavy lifting.

here is final Binary https://www.file-upload.net/download-15128329/entirereleasefolder.zip.html


Biggest problem is now installer for Visual Studio 2010 and making LLVM default compiler of VS2010.

Community it is now your responsibility to help us now







Edited by Dibya
Link to comment
Share on other sites

  • 3 weeks later...
  • 3 weeks later...

LLVM/Clang Tool chain has been upgraded to 17.01 ,

Kindly check out the main post , Source will be uploaded with documentation for compilation

LLVM have their own Dragon Mascot


can anyone draw a mascot for this project? Similar to these guys





Link to comment
Share on other sites

I have been able to compile C++ 17 sample code with LLVM 16.0.5 and 17.0.1 in the VS2010 IDE.


After installing LLVM and selecting the LLVM v100 toolchain from the project properties, I had to do the following things to make it work:

-first, the VC++ 2010 and Windows 7 SDK headers were freaking out at the C++17 syntax. So I took the headers from VC++ 2022 as well as the Windows 11 SDK's UCRT headers and placed them in "Additional Include Directories".

-Then, I went to the LLVM section of project properties and added the following compiler options: ``-Wc++17-extensions `` and ``-fms-compatibility-version=19``. This enables support for C++17 and allows the use of the built-in types that the new headers expect.

-Linking is complicated. The LLD linker cannot be used due to various issues so we must use the VC++ 2010 linker. This works to an extent, but there will usually be missing functions that the linker is unable to resolve. I built libs containing various functions such as __std_terminate,and a delete operator, which should be placed in "Linker -> Input -> Additional Dependencies" (https://github.com/win32ss/win32ss.github.io/raw/main/images/msvcrt10_cpp17_x64.lib and https://github.com/win32ss/win32ss.github.io/raw/main/images/msvcrt10_cpp17_x86.lib).

-Furthermore, if you are using msvcrt*, the VC++ 2010-supplied msvcrt.lib has baked-in directives that block it from being used where _MSC_VER is not equal to 1600. Clang will make it 1900 when -fms-compatibility-version is set to 19. This means that the directives must be patched; by opening up msvrt.lib in a hex editor, searching for all instances of /FAILIFMISMATCH:"_MSC_VER=1600" and changing 1600 to 1900 (zeroing-out the whole string may also work).

*newer ucrt libs were attempted, but there were issues with the linker not recognizing CFG. This would require rebuilding the runtime to remove CFG references.

Link to comment
Share on other sites

when vc++ 2022 and windows 11 SDK is reached, and even win10 stuff isnt working anymore that means 

windtows xp passed to that win11 time in sence of compiler 

however why i have doubts if it was worth to spend the time for this project
according to dibya no one actually used it

it took many time to fix all of the problems

and also i lost many time related to the hevc encoder, by now (everybody wants something from me, however there is not that much space for a different code on such very big projects)

i really hope it was worth that

dibya had a different idea how this work, something "super simple" "something super fast", i always told him no it is not that simple to add all these 
codes, it are 173 projects and such, and we need more of compiles ect. 

still however i fully explainded how to add the code now, i think he should be able to add the code by himself

at least he brought the requied patience once he realized what has to be done

Link to comment
Share on other sites

Posted (edited)

@user57 My buddy here complaining about his team mate, well listen man i have patience issue , i guess 90% Gen Z suffers from that.

@win32 Next build i have to get LibC++ & LLD[Linker] work by hook or crook.I have idea how it can be done but have to be proven, CMAKE is quite finicky. It took me 8 hours remove errors from LLVM 17.01 and make it just compile without any changes.

Edited by Dibya
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.

  • Create New...