If you’re still running old versions of Windows from Windows 2000 and up, either for restrocomputing purposes or because you need to keep an old piece of software running, you’ve most likely heard of Legacy Update. This tool allows you to keep Windows Update running on Windows versions no longer supported by the service, and has basically become a must-have for anyone still playing around with older Windows versions.
The project released a fairly major update today.
Legacy Update 1.12 features a significant rewrite of our ActiveX control, and a handful of other bug fixes.
The rewrite allows us to more easily work on the project, and ensures we can continue providing stable releases for the foreseeable future, despite Microsoft recently breaking the Windows XP-compatible compiler included with Visual Studio 2022.
↫ Legacy Update 1.12 release notes
The project switched sway from compiling with Visual C++ 2008 (and 2010, and 2017, and 2022…), which Microsoft recently broke, and now uses an open-source MinGW/GCC toolchain. This has cut the size of the binary in half, which is impressive considering it was already smaller than 1MB. This new version also adds a three-minute timer before performing any required restarts, and speeds up the installation of the slowest type of updates (.NET Frameworks) considerably.
I wonder if ReactOS can use it.
Seems pointless. Using Microsoft’s clunky update system from 2000 would be silly in a currently maintained OS in 2025.
It doesn’t really work because ReactOS isn’t any one version of Windows these days. It usually pretends to be Server 2003, but has APIs from modern versions like Windows 7 and 10. Also its version of Internet Explorer is very unfinished and can’t run ActiveX controls.
Thom Holwerda,
People and maybe even some devs don’t realize that microsoft are engineering planned obsolesce into visual studio updates. Meaning they deliberately break the backwards compatibility for new compiled binaries even with software that is otherwise compatible.. Visual studio also has DRM and time bombs that stops the software from running locally if it doesn’t manage to phone home often enough. So whenever it’s my call, I opt to use MingGW compiler instead. which doesn’t have these antifeatures built in.
I sense some tinfoil hat enthusiasm. There is no such thing injected into binaries, even when standard libraries are statically linked in. Anything like this would have been found and understood decades ago. There’s no need for Microsoft to backdoor third-party code anyway – they own and can push updates to the OS it runs on!
Visual Studio 2022 provided a legacy Visual C++ 2017 toolchain (v14.1) that produces binaries that run on XP SP2+, and this has worked fine since VS2015 when they first created the “for XP” branch of the VC++ toolchain. An update to VS2022 broke this back in March or so, and Microsoft discontinued it rather than fix it. March 2025 is well past when it should have been removed (2019-2020 at the latest), it’s hard to blame them for not continuing to officially support an old toolchain for an old OS. We could have gotten the job done by moving to VS2017, or finding a copy of the .msi’s from before it broke, but I wanted to try switching to MinGW for a handful of reasons, particularly smaller binary sizes, and so we can produce nightly builds that work on Windows 2000 RTM onwards from GitHub Actions CI (rather than only XP SP2+).
kirb,
It is what happens when you allow visual studio to update your project.
If you link to the legacy DLLs, then I agree legacy DLLs will continue to work on older operating systems. But I don’t think all developers understand that by letting MS VS perform updates by default they’re inadvertently enabling microsoft to break the 3rd party software on older versions of windows even though no incompatibility exists in the software itself.
Part of the issue is the way MS engineered it. Rather than “check if feature set exists”, they engineered it as “check if windows version >=”. This is very similar to another notorious “feature detection verses browser version detection” problem, where causing compatibility issues by checking for browser versions instead of features is widely considered bad practice.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Browser_detection_using_the_user_agent
Microsoft’s approach is worse for backwards compatibility, but better for planned obsolesce, so it’s logical why MS would go with it.
I have no objections and I’m happy to hear MinGW works for you. It’s been useful for me too. I used it with FLTK to produce very lightweight executables. Years ago I even used MinGW to build windows drivers.
If you are still running Windows 2000 and Windows XP on anything not airgapped, you are being thick.
If you are relying on a a jury-rigged solution to deliver these patches to your devices that should not be internet facing, you are being obtuse.
If you have to run legacy applications, run them in VMs on isolated subnets behind a damned proxy.