Dibya Posted May 19 Share Posted May 19 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. Link to comment Share on other sites More sharing options...
DosFreak Posted May 20 Share Posted May 20 (edited) 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 Link to comment Share on other sites More sharing options...
Dibya Posted May 20 Author Share Posted May 20 Plan is to port Clang and LLVM with LIBC++, not particularly anything to do with MinGW, MinGW is GCC. LLVM produces fastest code. Link to comment Share on other sites More sharing options...
DosFreak Posted May 22 Share Posted May 22 (edited) 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 1 Link to comment Share on other sites More sharing options...
Dibya Posted May 22 Author Share Posted May 22 @DosFreak Thanks for pointing out , it is really interesting project, can be used to port many application. Link to comment Share on other sites More sharing options...
user57 Posted May 27 Share Posted May 27 (edited) 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 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now