ReactOS Archive
The ReactOS project is working on a new graphical installer to replace the older, text-mode one. In the first blog post about this effort, from December 2023, developer hbelusca details their work on setupapi, the module that enables “reading and processing INF files, moving/copying files from an installation source media to a target, supporting also extraction from compressed .CAB cabinet files”, as well as device installation functions. The second post dives into partitioning during installation, which involves a lot of very delicate work, from partitioning to installing the bootloader, and from copying files to modifying the registry. On top of that, this needs a GUI, and preferably one that’s better and more versatile than the well-known blue text-mode setup we all know from old versions of Windows. The new GUI presents more options, allows for bootloader settings, and, of course, partitioning in a non-destructive way before committing. In addition, while the blue text-mode setup can only go forward, the new GUI is bidirectional. The third and final post dives into testing all this work and fixing bugs. The post goes into great detail describing a number of bugs and their fixes, and is well worth a read, too.
The ReactOS project has published another newsletter filled with news about their progress, and two things stand out. First, there’s now initial support for booting using UEFI. Work has been underway since the beginning of the year to transition FreeLoader, our default bootloader for ReactOS, to support UEFI on x86 and AMD64, as well as ARM32 and ARM64. Hermès has been developing a system for passing the UEFI framebuffer information in a fashion that allows Windows XP to run on UEFI systems, while Justin Miller (TheDarkFire) has been developing the UEFI freeloader build. On top of supporting booting ReactOS, other features are being built such as EFI chainloading and a bootmgfw-compatible build of FreeLoader. These features would add boot management capabilities and allow modern Windows systems to bootstrap our favorite bootloader. Second, and this is a big one: work has been done to add initial support for running Windows applications targeting newer systems than Windows Server 2003. Up until now, ReactOS was limited to running Windows applications targeting NT 5.2 found in Server 2003, but now work is being done to support appications targeting NT 6.0 and newer, as found in Windows Vista and newer. A group made up of Timo Kreuzer, Justin Miller, and other developers and contributors alike are developing the necessary APIs for compatibility with modern programs. While Timo is still working on implementing a dynamic versioning system for DLLs (#3239) that allows exporting of routines to applications depending on their compatibility settings, he has added the option for ReactOS bot builders to compile builds with NT6 exports which makes it possible to experiment with NT6+ application compatibility. There are also various improvements to the shell and debugger, but a new release is still a ways away, so unless you want to dive into unstable builds, there’s no way to test any of this just yet. Still, hose are some massive projects being undertaken, and makes ReactOS a bit more prepared for the future.
After several months of (public) work, ReactOS can now use UEFI boot. But that’s the major changes planned for this PR. As of the state of this PR UEFI boot will operate as long as you have a serial port you should be able to test it. Some more boot fixes will come down the road but this covers 85% of devices we’ve ran into. In fact, they’ve even made it possible for ReactOS to boot on the Steam Deck, which is surely a neat trick. I’m sure once this has been polished up a bit more – if that’s even necessary – it will make its way to the next ReactOS release.
The last ReactOS release is already twp years old, and there seemingly hasn’t been any news since. Of course, the project has not stalled, and in a newsletter the project details the progress that’s been made since 2021. In the last year and during the beginning of 2023, the ReactOS developers and contributors alike are working on many parts of the project, the top focused area being the kernel. Other areas that aren’t kernel-related are the applications, specifically our Paint and Notepad programs, the Input Method Editor (IME) as well as other stuff such as the ReactOS testing infrastructure. There’s steady progress on the x86-64 port, improvements to the Security Subsystem, and more.
ReactOS as the open-source project striving for binary compatibility with Windows applications/drivers is still working away in 2022 on symmetric multi-processing (SMP) support. Proper SMP/multi-core support is obviously critical for today’s hardware or even anything in the past roughly two decades… It’s also been a pain point for ReactOS, but fortunately the situation is improving. We’re still looking at very early code that’s not even merged yet, but once it has – this would be a massive leap forward for the project.
The ReactOS Team is pleased to announce the release of version 0.4.14. As with every other release, we’re regularly noting improvements and updates to keep you in touch with what is being done in ReactOS. In this release, improvements range from FreeLoader fixes, Shell features, kernel fixes, NetKVM VirtIO bringup, further work on the Xbox port and support for NEC PC-9800. A steady stream of improvements, and there’s more already implemented in the nightly builds that’s not in this release.
The latest ReactOS newsletter has been published. Timo Kreuzer (tkreuzer) worked hard on various parts of the kernel and HAL, fixing issues here and there. Structured Exception Handling (SEH) support for the amd64 architecture was finished, various bugs around the kernel are fixed. A major issue with interrupt handling in HAL was also fixed in May, which finally allowed a semi-stable boot in a virtual environment. There’s also work being done on support for multiple monitors, improved support for SMP, and more.
Despite all the turbulence, it has been quite a productive year for ReactOS. Many bugs and instabilities were resolved, many more have been introduced. This year we hired two kernel developers full-time, this happened for the first time in the project’s history. The post highlights some of the changes which may be interesting to the community. This post is a good overview of the progress the ReactOS project has made this past year. One of the major achievements this year is that ReactOS can now use Windows’ own NTFS driver, which is pretty amazing.
During the upcoming months, Jérôme is going to overhaul the Mm (Memory Manager) and Cc (Cache Controller) components of the kernel. Both of them are core parts of the operating system, which are involved in every memory request and file operation. Improving them is expected to have a substantial effect on the overall stability and performance of ReactOS. Always nice to see small projects gather the funds to hire a developer to do work.
During his contract with ReactOS Deutschland e.V., Victor will primarily work on the storage stack, a long neglected piece of ReactOS. He plans to finally turn scsiport into a Plug & Play aware driver and fix kernel Plug & Play bugs in the process, thereby improving USB storage support and compatibility to Windows storage drivers. If time permits, stretch goals include continuing his previous work on integrating Google’s Kernel Address Sanitizers into ReactOS and fixing booting with our APIC-enabled HAL. It’s always good to see such a small and alternative operating system project hire a developer, even if only for a short time.
The ReactOS Build Environment (RosBE), our curated set of compilers and build tools, has just received a major upgrade. After more than 7 years of using the same and now ancient GCC 4.7.2, ReactOS is finally going to be built with the help of a modern compiler (GCC 8.4.0). Among other things, the new version better detects programming mistakes like improperly sized buffers, and comes with improved error messages to pinpoint such mistakes to the corresponding position in code. It also adds support for the latest C and C++ standards, marking a first step towards the introduction of modern C++ concepts into ReactOS. That is one hell of an upgrade, and a much-needed one by the looks of it.
The ReactOS Team is pleased to announce the release of version 0.4.13. As with prior releases, keywords are noted representing the release itself and highlighting key improvements. In this particular case, the 0.4.13 version shows the results of significant hard work to bring improvements to the USB stack, further development on the Xbox port boot process, an Explorer File Search for the Shell module, as well as many other changes. There’s also new work on accessibility features, and the 64 bit version has seen considerable improvements, too.
The ReactOS team is pleased to announce the release of version 0.4.12. As always a multitude of improvements have been made to all parts of the OS, though userland components saw special emphasis this time around. A lot of work has gone into filesystem support, with the ultimate goal being the ability to run Microsoft’s filesystem drivers – a goal the project has not yet achieved. PXE booting has been fixed as well, and window snapping has been added, among many other things.
Some pretty bold claims by a Microsoft kernel engineer who works on the Windows kernel regarding ReactOS, the open source operating system that aims to be compatible with Windows. Axel Rietschin, kernel engineer at Microsoft, has claimed that ReactOS, an open source operating system intended to be binary-compatible with Windows, is “a ripoff of the Windows Research Kernel that Microsoft licensed to universities.” He says that “internal data structures and internal functions, not exported anywhere and not part of the public symbols, have the exact same names as they appear in the Research Kernel.” In his recent post, he presents further arguments against ReactOS being a “clean room” implementation done without reference to the source code. “Macros names, parameters, etc. never appears in the compiled code. It is … almost surely impossible that a clean-room reimplementation ends up using macros for the same things, let alone macros with the same or similar names.” Reitschin does add he is no lawyer, but these claims do raise a number of serious concerns and questions about the ReactOS project. These claims alone will probably ensure no serious commercial entity will ever want to associate itself with ReactOS, and it will be interesting to see if these claims will ever lead to something more serious than mere words.
The headline feature for 0.4.10 would have to be ReactOS' ability to now boot from a BTRFS formatted drive. The work enabling this was part of this year's Google Summer of Code with student developer Victor Perevertkin. While the actual filesystem driver itself is from the WinBtrfs project by Mark Harmstone, much of Victor's work was in filling out the bits and pieces of ReactOS that the driver expected to interact with. The filesystem stack in ReactOS is arguably one of the less mature components by simple dint of there being so few open source NT filesystem drivers to test against. Those that the project uses internally have all gone through enough iterations that gaps in ReactOS are worked around. WinBtrfs on the other hand came with no such baggage to its history and instead made full use of the documented NT filesystem driver API.
Seems like another solid release. While ReactOS always feels a bit like chasing an unobtainable goal, I'm still incredibly impressed by their work, and at this point, it does seem like it can serve quite a few basic needs through running actual Win32 applications.
Another step of progress.
The ReactOS Project is pleased to announce the release of version 0.4.9, the latest in our accelerated cadence targeting a release every three months.
While a consequence of this faster cycle might mean fewer headliner changes, much of the visible effort nowadays comes in the form of quality-of-life improvements in how ReactOS functions. At the same time work continues on the underlying systems which provide more subtle improvements such as greater system stability and general consistency.
The biggest new "feature" is something we already talked about: ReactOS is now self-hosting.
ReactOS has unveiled its Google Summer of Code project, undertaken by Victor Perevertki.
My project is both simple and complicated. I want to add to ReactOS an option to install on and boot from BTRFS partitions. There are a few little things left to implement this:
- BTRFS support in bootloader.
- Fixes in cache controller and memory manager in order to boot with WinBtrfs driver. It is getting better every week, but right now used only with fastfat driver for FAT32.
My primary goal for this internship is implement BTRFS support in FreeLdr - our bootloader.
Another great GSoC project to keep an eye on.
Now, ReactOS can fully build ReactOS, even with the USB stack. Be it a LiveCD or a BootCD! And just because we can, here LiveCD is mounted in ReactOS to show it. Thanks FreeBSD for your qsort implementation.
The building ReactOS wiki page has been updated with the new information. A pretty major milestone for any operating system!
ReactOS 0.4.8 has been released, and its biggest new feature is experimental support for NT6+ applications.
With software specifically leaving NT5 behind, ReactOS is expanding its target to support NT6+ (Vista, Windows 8, Windows 10) software. Colin, Giannis and Mark are creating the needed logic in NTDLL and LDR for this purpose. Giannis has finished the side-by-side support and the implicit activation context, Colin has changed Kernel32 to accept software made for NT6+, and Mark keeps working on the shim compatibility layer. Although in a really greenish and experimental state, the new additions in 0.4.8 should start helping several software pieces created for Vista and upwards to start working in ReactOS. Microsoft coined the term backwards compatibility, ReactOS the forward compatibility one.
There's tons of other improvements, as well.
Submitted by 
Submitted by