Project Saphire Dragon: Port LLVM and Clang

[Dibya]

 

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 

 

 

Installation:

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 November 16, 2023 by Dibya

[DosFreak]

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?f=5&t=87617

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 May 20, 2022 by DosFreak

[Dibya]

Plan is to port  Clang and LLVM with LIBC++, not particularly anything to do with MinGW, MinGW is GCC.

LLVM produces fastest code.

 

[DosFreak]

https://colinfinck.de/posts/modern-visual-studio-meets-ancient-windows/
https://colinfinck.de/posts/targeting-25-years-of-windows-with-visual-studio-2019/
https://github.com/enlyze/EnlyzeWinCompatLib/tree/clang
This issue may allow 9x compatibility and appears to mention the functions mentioned at stackoverflow:
https://github.com/enlyze/EnlyzeWinCompatLib/issues/1

 

The below may or may not apply anymore but it's something I've been meenting to look into:
https://stackoverflow.com/questions/19516796/visual-studio-2012-win32-project-targeting-windows-2000/53548116#53548116

 

Edited May 22, 2022 by DosFreak
changes

[Dibya]

@DosFreak Thanks for pointing out , it is really interesting project, can be used to port many application.

[user57]

there is already a problem

1 function isnt found by visual studio 

RtlRaiseStatus

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

NTSYSAPI
VOID
NTAPI
RtlRaiseStatus(
    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 

VOID
NTAPI
RtlRaiseStatus(IN NTSTATUS Status)
{
    EXCEPTION_RECORD ExceptionRecord;

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

    RtlRaiseException(&ExceptionRecord);
    
}

 

 

 

Edited May 27, 2022 by user57

[Dibya]

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

BOOL
WINAPI
EnumProcessModules(
    _In_ HANDLE hProcess,
    _Out_writes_bytes_(cb) HMODULE* lphModule,
    _In_ DWORD cb,
    _Out_ LPDWORD lpcbNeeded
    );

to

BOOL
WINAPI
EnumProcessModulesX(
    HANDLE hProcess,
    HMODULE* lphModule,
    DWORD cb,
    LPDWORD lpcbNeeded
);

 

Change Following:

BOOL
WINAPI
GetProcessMemoryInfo(
    HANDLE Process,
    PPROCESS_MEMORY_COUNTERS ppsmemCounters,
    DWORD cb
    );

to

BOOL
WINAPI
GetProcessMemoryInfoX(
    HANDLE Process,
    PPROCESS_MEMORY_COUNTERS ppsmemCounters,
    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:
GetProcessGroupAffinityX

GetLogicalProcessorInformationEx renamed to
GetLogicalProcessorInformationExX

"winreg.h"

Changed from

WINADVAPI
LSTATUS
APIENTRY
RegGetValueW

to

LSTATUS WINAPI
RegGetValue

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

"processthreadsapi.h" is modified

from

WINBASEAPI
DWORD
WINAPI
GetThreadId

to

DWORD
WINAPI
GetThreadIdX

"ShlObj_Core.h"

from

 

/*
STDAPI SHGetKnownFolderPath(_In_ REFKNOWNFOLDERID rfid,
                            _In_ DWORD dwFlags,// KNOWN_FOLDER_FLAG 
                            _In_opt_ HANDLE hToken,
                            _Outptr_ PWSTR *ppszPath); // free *ppszPath with CoTaskMemFree
*/

to

__declspec(noinline)
HRESULT
WINAPI
SHGetKnownFolderPath(
    REFKNOWNFOLDERID rfid,
    DWORD dwflags,
    HANDLE token,
    PWSTR* path
);

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

SetFileInformationByHandle_Emu (placed in LLVMSupport / Source Files)

/*
WINBASEAPI
BOOL
WINAPI
SetFileInformationByHandle(
    _In_ HANDLE hFile,
    _In_ FILE_INFO_BY_HANDLE_CLASS FileInformationClass,
    _In_reads_bytes_(dwBufferSize) LPVOID lpFileInformation,
    _In_ DWORD dwBufferSize
    );
*/

renamed to

BOOL
WINAPI
SetFileInformationByHandleX(
    HANDLE hFile,
    FILE_INFO_BY_HANDLE_CLASS FileInformationClass,
    LPVOID lpFileInformation,
    DWORD dwBufferSize
);

Due to bugs in LLVM Source itself

"fileapi.h"
/*
WINBASEAPI
DWORD
WINAPI
GetFinalPathNameByHandleW(
    _In_ HANDLE hFile,
    _Out_writes_(cchFilePath) LPWSTR lpszFilePath,
    _In_ DWORD cchFilePath,
    _In_ DWORD dwFlags
    );
*/


renamed to

DWORD
WINAPI
GetFinalPathNameByHandleWX(
    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)
also:
C:\llvm-project\clang\lib\DirectoryWatcher\windows
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):
https://github.com/microsoft/STL/pull/1194/commits/faa3434d7e748fcfdc253ad2788a0e4fddfea105

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 September 29, 2023 by Dibya

[user57]

deleted

Edited June 15, 2023 by user57

[user57]

well here is the v16.0.5

https://www.file-upload.net/download-15158304/LLVM_XP_v16.zip.html

 

it contains also some screenshots

[Dibya]

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

 

 

[win32]

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.

[user57]

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
now

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

[Dibya]

@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 October 7, 2023 by Dibya

[RamonUn]

Wow, had not seen this topic before, I must give this a try, seems to be amazing...

 

[MWF]

i didn't know of this until now, but that's so cool project