Project Saphire Dragon: Port LLVM and Clang

[Dibya]

Aim of this project is to port LLVM /Clang tool chain to XP/XPx64 and integrate with Visual Studio 2010, 

Newer VS2022 re-dist no more support  XP , it is essential to have a native compiler to compile for XP on XP.

@user57 and me are trying to get it compiled and facing some problem.

This thread is to discuss error we are facing , and to take some help and suggestion from members here.

Looking forward to your feedback.

[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 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 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 by user57