Menu ▾ ▴

#1577 Code::Blocks does not function on Windows XP

Undefined
open
nobody
Windows XP (3)
Bug_Report
2026-01-03
2025-12-17
T-640
No

Greetings!

I have ran into some difficulties when getting Code::Blocks to function on a Windows XP system, but fortunately have found a few workarounds and succeeded in making it work. Below are the issues that I have encountered, the workarounds applied and suggestions to fix the problem.

But first let me tell you that I appreciate that Code::Blocks is still capable of functioning on this operating system, despite all these years that have passed. It appears to be the last full-fledged actively maintained IDE capable of doing that. If this is not much of a burden, keeping the compatibility as long as you reasonably can is more than welcome!

Now on to the issues themselves (occurs on both the current 32-bit release and the nightly build version as of me writing this report):

1) The first one that I encountered were missing CRT libraries. Got this error:

This application has failed to start because api-ms-win-crt-convert-l1-1-0.dll was not found. Re-installing the application may fix this problem.

Not much of a problem of course, as all that needs to be done is getting a Visual C++ Redistributable package and installing it. But could you perhaps bundle it together with the installer, and deploy the C runtime automatically if this hasn't been done yet?

Apparently the last version compatible with Windows XP is one of the VS 2019 builds, in particular 14.28.29213.0, which can be downloaded from here:

x86
x64
ARM64

Found out about it on Github here (the link has vanished since then but fortunately The Internet Archive remembers).

The person who collected these links said that the aforementioned build was the last one to support this version of the operating system. You can see it if you scroll down the list.

2) After installing the C runtime the next error a ran into was this:

The procedure entry point K32GetModuleFileNameExA could not be located in the dynamic link library KERNEL32.dll

The workaround was to download the older versions of some of the Code::Blocks DLLs from here

In one of the newer versions of these DLLs the PSAPI_VERSION macro must have been set to 2, which makes it incompatible with Windows XP. Which results in the DLL looking for the GetModuleFileNameExA function in Kernel32.dll, while on Windows XP it is in Psapi.dll, as far as I understand. If it does not break Code::Blocks for the newer OS versions, could you set the PSAPI_VERSION back to 1 please? And in case this actually does break something compile two versions of a DLL that calls this function and determine which one to ship during the installation process?

3) At last I have managed to launch Code::Blocks but the joy was short-lived because the compiler refused to start, presenting me with the following error:

This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

The solution was to use the w64devkit distribution instead of the WinLibs one. It worked out of the box, all I needed to do was to replace the contents of the MinGW folder supplied by Code::Blocks installation with the files from the w64devkit release

And at last, it worked! It was quite amusing to observe the modern features like C++20 modules getting compiled on that system, while the last Visual Studio version capable of running on Windows XP doesn't even support std::thread!

Could you consider adding the w64devkit as an alternative option included in the installer?

The support for this operating system is explicitly stated in this project. Moreover, the author seems to be very open-minded regarding keeping the support for it, according to this discussion

Initially the project had not had support for Windows XP or the 32-bit architecture at all, but after giving it a try the author reconsidered and seems to be committed to continue supporting it. So this is not just a mere afterthought, but something that actually looks like a part of the project's long term vision.

Contrary the WinLibs used to support Windows XP but it was dropped later, and the author has no intention to bring it back, according to this disussion and this one

Both toolchains support the GCC version 15.2.0 at this time.

Discussion

  • ollydbg

    ollydbg - 2025-12-17

    Hi, good work!

    If you looked at this post: Re: The 06 December 2025 build (13761) is out. (forums.codeblocks.org)

    You can see Xaviou posted a Windows 32 bit version of C::B in every nightly build version. I'm not sure whether it works on Windows XP.

    It was really sad that a lot of compiler and packages were dropping the old Windows support. For example, the msys2 packages mainly drop the support for Windows7, because it is hard to maintain. See this post:

    Latest msys2/mingw64's gdb failed to start under Windows 7 and its solution

    You can see some other posts in the C::B's forum.

     

    • T-640

      T-640 - 2025-12-17

      Yea, I gave his build a try, but unfortunately it has the PSAPI_VERSION set to 2 as well.

      The current state of affairs is indeed looking quite sour. What makes things worse is that even the virtual machine support for the older operating systems as guests is degrading, at least when it comes down to VirtualBox and VMWare.

      But, if the fix turns out to be as simple as setting PSAPI_VERSION back to 1, incorporating the C runtime alongside that w64devkit, it would certainly be a sight for sore eyes!

      In case anyone else would want to test the compatibility with Windows XP in a virtual machine I could recommend the following versions of VirtualBox and VMware (both work more or less adequately on Windows 10 host):

      The VirtuaBox version 6.0.24, the last one to have 3D acceleration on Windows XP guest and apparently the last for Windows 7 to function as host. Without the 3D acceleration moving windows would look glitchy. Also beware that for Windows 10 version higher than home edition you might need to turn off the Hyper-V or the VM won't start at all, as far as I understand.

      As for VMware, I have settled down with the version 15.5.7. They say it's the last one to support Windows 7 as host, and I experienced crashes of VM with Windows XP guest on a higher VMWare version (unfortunately I don't remember which one in particular, 16 or 17, maybe even both of them).

      The public downloads for the older VMware versions appear to be inaccessible, but The Internet Archive comes to the rescue again. And this is the guest tools ISO image that works with Windows XP. Not sure if this is the last compatible guest tools version, maybe a few more may still work, but they have definitely dropped support since some newer version.

       

  • T-640

    T-640 - 2026-01-03

    Having a further look I came to conclusion that your code should be fine, the issue is with the Dr. Mingw library. The libraries exchndl.dll and mgwhelp.dll are the ones that must have been compiled with PSAPI_VERSION 2. Furthermore, the newer version of the Microsoft's dbghelp.dll library supplied in Dr. Mingw's newer releases is incompatible with Windows XP.

    Not to worry, however, as there is still a more or less elegant solution. You can supply both the older Dr. Mingw version and the newest one and determine which one to load at runtime. On Dr. Mingw project's page (github.com) they say that you don't have to link with their library and alternatively can load it via the LoadLibrary call:

    // Load the DLL
HMODULE hModule = LoadLibraryW(L"exchndl.dll");

if (hModule != NULL) {
    // Get the function pointer
    typedef void (*PFNEXCHNDLINIT)();
    PFNEXCHNDLINIT pfnExcHndlInit = (PFNEXCHNDLINIT)GetProcAddress(hModule, "ExcHndlInit");

    if (pfnExcHndlInit != NULL) {
        pfnExcHndlInit();
    } else {
        // Handle the error if GetProcAddress fails
        // Add your error handling code here
    }

    // Do not free the DLL module
} else {
    // Handle the error if LoadLibrary fails
}

    Which means that the following you can do:

    1) Move the exchndl.dll, mgwhelp.dll, dbghelp.dll, dbgcore.dll, symsrv.dll, and symsrv.yes to their own separate directory;

    2) Now you can supply both versions, name the directories something like DrMingw and DrMingw-WinXP;

    3) Quiery the Windows version. Refreshing my memory of WinAPI I came across this article. It lists three documented and one undocumented function to find the operating system's version.

    You shouldn't link to these functions, however, and access them via the GetProcAddress call as well. Because Microsoft in their infinite wisdom declared them deprecated saying they "may be altered or unavailable" in the future versions. Well, not a big problem I guess, if they remove them Code::Blocks will be able to detect that and proceed normally. Also apparently in the newer versions of Windows there are some oddities regarding the returned operating system version, but I believe just checking the major version for being 5 won't cause any trouble in this case.

    4) And once the operating system version is determined load the exchndl.dll from the respective folder via the LoadLibrary call.

    Ideally the author of Dr. Mingw could be asked to do the same trick for the GetModuleFileNameExA function, that is not to link to it but rather get it from either Kernel32.dll or Psapi.dll at runtime, depending on the operating system where the library is loaded at. That is the only function that Dependency Walker reported as missing on Windows XP for exchndl.dll and mgwhelp.dll.

    As for the Microsoft's dbghelp.dll library that comes Dr. Mingw, still an older version must be supplied for Windows XP. Trying to load the newer one results in the "The procedure entry point kernel32.ReleaseSRWLockExclusive could not be located in the dynamic link library api-ms-win-core-synch-l1-1-0.dll" error. As far as I understand that means that some function is missing in the MSVC CRT (or UCRT? I am getting confused trying to find out which is which).

    Regardless, the solution outlined above should do for now.

    The last Dr. Mingw version that supports Windows XP is apparently version 0.8.2, it can also be found in your own repository here. I found this information on your forum here reported by the user SiZiOUS.

     

Log in to post a comment.

MongoDB Logo MongoDB