Remix.run Logo
30 Years of ReactOS(reactos.org)
164 points by Mark_Jansen 10 hours ago | 80 comments
mixmastamyk 8 minutes ago | parent | next [-]

I’ve been playing around with this for decades and it has been a pretty toy façade until recently. But the last time I found a package manager GUI and installed Python, and to my surprise it worked! Was gobsmacked it took this long but real progress is being made.

ch_123 an hour ago | parent | prev | next [-]

I would like to see ReactOS succeed for various reasons, mainly philosophical. On the other hand, for practical real-world use cases, it has to compete with several alternative solutions:

1. Just use Windows 11. Yes, it sucks and MS occasionally breaks stuff - but at least hardware and software vendors will develop their code against Win 11 and test it. In other words, you have the highest likelihood that your computer will work as expected with contemporary Windows applications and drivers.

2. Use an older version of Windows. If you want to use old hardware or software, odds are you will get the best experience with whatever version of Windows they were developed/tested against. You have to accept the lack of support for modern software, and you will need to take appropriate security measures such as not connecting it to the internet - but at the same time, it's unlikely that your Windows 98 retro gaming rig is your only computer, so that's probably an acceptable tradeoff.

3. Run WINE on top of Linux (or some other mature open source operating system). This might not be a good solution for the average person, but ticks the box for people who feel strongly pro-open source, or anti-Microsoft. Since Windows compatibility is dictated by Windows' libraries and frameworks and not the kernel, compatibility is likely to be comparable to ReactOS.

I am not saying that this covers every possible use case for ReactOS, but I would posit it covers enough that the majority of people who might contribute or invest into ReactOS will instead pick one of the above options and invest their time and energy elsewhere.

afavour an hour ago | parent [-]

IIRC ReactOS uses and contributes heavily to WINE. So in many ways your #3 isn't far from using ReactOS, and if done correctly it'll be friendlier for the average person than Linux itself.

spijdar 6 minutes ago | parent | next [-]

This isn't really my arena, but I did happen to recently compare the implementation of ReactOS's RTL (Run Time Library) path routines [0] with Wine's implementation [1].

ReactOS covers a lot more of the Windows API than Wine does (3x the line count and defines a lot more routines like 'RtlDoesFileExists_UstrEx'). Now, this is not supposed to be a public API and should only be used by Windows internally, as I understand it.

But it is an example of where ReactOS covers a lot more API than Wine does or probably ever will, by design. To whom (if anyone) this matters, I'm not sure.

[0] https://github.com/reactos/reactos/blob/master/sdk/lib/rtl/p...

[1] https://github.com/wine-mirror/wine/blob/master/dlls/ntdll/p...

ch_123 an hour ago | parent | prev [-]

Yes, exactly my point - thanks for elaborating on it.

hypercube33 11 minutes ago | parent [-]

Why not use Linux with WINE and that Chicago95 theme and call it a day?

_fat_santa 2 hours ago | parent | prev | next [-]

I look at ReactOS largely as an exercise in engineering and there's really nothing wrong it with it being just that. Personally I think projects like Wine/Proton have made far more in-roads in being able to run Windows software on non-Windows systems but I still have to give props to the developers of ReactOS for sticking with it for 30 freaking years.

ACS_Solver an hour ago | parent | next [-]

Yes. The unique point of ReactOS is driver compatibility. Wine is pretty great for Win32 API, Proton completes it with excellent D3D support through DXVK, and with these projects a lot of Windows userspace can run fine on Linux. Wine doesn't do anything for driver compatibility, which is where ReactOS was supposed to fill in, running any driver written for Windows 2000 or XP.

But by now, as I also wrote in the other thread on this, ReactOS should be seen as something more like GNU Hurd. An exercise in kernel development and reverse engineering, a project that clearly requires a high level of technical skill, but long past the window of opportunity for actual adoption. If Hurd had been usable by say 1995, when Linux just got started on portability, it would have had a chance. If ReactOS had been usable ten years ago, it would also have had a chance at adoption, but now it's firmly in the "purely for engineering" space.

tracker1 an hour ago | parent [-]

While I think better Linux integration and improving WINE is probably better time spend... I do think there's some opportunity for ReactOS, but I feel it would have to at LEAST get to pretty complete Windows 7 compatibility (without bug fixes since)... that seems to be the last Windows version people remember relatively fondly by most and a point before they really split-brained a lot of the configuration and settings.

With the contempt of a lot of the Win10/11 features, there's some chance it could see adoption, if that's an actual goal. But the effort is huge, and would need to be sufficient for wide desktop installs much sooner than later.

I think a couple of the Linux + WINE UI options where the underlying OS is linux, and Wine is the UI/Desktop layer on top (not too disimilar from DOS/Win9x) might also gain some traction... not to mention distros that smooth the use of WINE out for new users.

Worth mentioning a lot of WINE is reused in ReactOS, so that effort is still useful and not fully duplicated.

ACS_Solver an hour ago | parent [-]

> I do think there's some opportunity for ReactOS, but I feel it would have to at LEAST get to pretty complete Windows 7 compatibility

That's not going to happen in any way that matters. If ReactOS ever reaches Win7 compatibility, that would be at a time when Win7 is long forgotten.

The project has had a target of Windows 2000 compatibility, later changed to XP (which is a relatively minor upgrade kernel wise). Now as of 2026, ReactOS has limited USB 2.0 support and wholly lacks critical XP-level support like Wifi, NTFS or multicore CPUs. Development on the project has never been fast but somewhere around 2018 it dropped even more, just looking at the commit history there's now half the activity of a decade ago. So at current rates, it's another 5+ years away from beta level support of NT 5.0.

ReactOS actually reaching decent Win2K/XP compatibility is a long shot but still possible. Upgrading to Win7 compatibility before Win7 itself is three plus decades old, no.

genewitch an hour ago | parent [-]

maybe posts like this will move the needle. If i could withstand OS programming (or debugging, or...) I'd probably work on reactOS. I did self-host it, which i didn't expect to work, so at least i know the toolchain works!

f311a an hour ago | parent | prev [-]

> Wine/Proton have made far more in-roads in being able to run Windows

Yeah, they can even run modern games, which ReactOS can't. It can't even run on modern hardware properly.

It's a nice project, though. Good progress for a hobby project, and it's still going after 30 years!

rubymamis 3 hours ago | parent | prev | next [-]

Great project, but let's just make this year the year of the Linux Desktop!

xattt 2 hours ago | parent [-]

With significant progress for Linux on the desktop this year, I propose it’s time to move the goalposts:

    - 2027, the year of ReactOS
    - 2028, the year of Haiku
    - 2029, the year of TempleOS
bitigchi an hour ago | parent | next [-]

Haiku has gazillions of modern software and got NVIDIA drivers recently. Things are looking pretty bright for Haiku.

tracker1 an hour ago | parent [-]

I like Haiku tech... to not too fond of the window chrome amd ux style myself... It's like every window has a pan-handle.

bitigchi an hour ago | parent | next [-]

With Haiku I like that I can use the computer without having to resort to dark mode like the other operating systems. The other systems are just too bright, while Haiku interface is warm and on-point.

memsom an hour ago | parent | prev [-]

Legacy of BeOS.

tracker1 34 minutes ago | parent [-]

I get that... I didn't like it in BeOS either... It just feels off, the more time spent on more recent alternatives (Windows, Mac, Linux+Cosmic/Gnome/Kde...). Similarly, trying to use OS/2's desktop also feels more and more alien as the years pass.

I mean, I get trying something different and/or sticking to a legacy, but there's also being usable to today's users.

ofrzeta 2 hours ago | parent | prev [-]

I get the joke, but Haiku could indeed have its year because it's the only one of these OSs that has Firefox running. Do you need anything else? (ok, some hardware support would be nice, I guess)

superdisk 4 hours ago | parent | prev | next [-]

I sometimes daydream about becoming a billionaire and bankrolling this project to completion. Would do the world so much good.

sho_hn 4 hours ago | parent | next [-]

I still think Windows app compat for Linux (i.e. as Wine does and Valve productized with a gaming focus) is the better solution since it offers a true upgrade path out.

I realize ReactOS has a potentially wider useful scope (I think device driver compat is part of what they're attempting to do, so it'd offer a solution to keeping niche HW running) but I think it's just a smaller audience.

mghackerlady 4 hours ago | parent | next [-]

Has anyone thought about making the linux kernel roughly compatible with NT? Like how FreeBSD is compatible with Linux? I know it'd definitely be harder as NT is proprietary but syscalls (in my very uninformed opinion) seem all that difficult to implement, even without a userland

augusto-moura 3 hours ago | parent | next [-]

At what level do you mean that? Kernel level? Driver level?

Wine[1] is the de facto compatibility layer with NT executables. Driver compatibility is too complex and obscure to worth the while. Often information is undocumented or hard to get.

There are a few implementations of windows behaviors at kernel level for a few subsystems features, ntsync, samba, ntfs, etc. they can be used by wine to improve compatibility or performance

[1]: https://www.winehq.org/

treyd 3 hours ago | parent | prev | next [-]

FreeBSD is not "compatible with Linux", it provides a way to run Linux applications under a Linux-like syscall environment. What you're suggesting is as if you could load Linux kernel modules into the FreeBSD kernel.

The issue with NT is the driver ecosystem. You'd have to reimplement a lot of under-documented NT behavior for NT drivers to behave themselves, and making that work within the Linux kernel would require major architectural changes. The userland is also where a lot of magic happens for application compatibility.

bryanlarsen 2 hours ago | parent | prev | next [-]

It's far from "roughly compatible with NT", but the Linux kernel does accept changes to make supporting Windows applications more efficient.

example: ntsync

jchw 3 hours ago | parent | prev [-]

Me as a kid thought this would be a great idea, and started implementing a PE binfmt. I actually did make a rudimentary PE binfmt, though it started to occur to me how different Windows and Linux really were as I progressed.

For example, with ELF/UNIX, the basic ELF binfmt is barely any more complex than what you'd probably expect the a.out binfmt to be: it maps sections into memory and then executes. Dynamic linking isn't implemented; instead, similar to the interpreter of a shell script, an ELF binary can have an interpreter (PT_INTERP) which is loaded in lieu of the actual binary. This way, the PT_INTERP can be set to the well-known path of the dynamic linker of your libc, which itself is a static ELF binary. It is executed with the appropriate arguments loaded onto the stack and the dynamic linker starts loading the actual binary and its dependencies.

Windows is totally different here. I mean, as far as I know, the dynamic linker is still in userland, known as the Windows Loader. However, the barrier between the userland and kernel land is not stable for Windows NT. Syscall numbers can change during major updates. And, sometimes, implementation details are split between the kernel and userland. Now, in order to be able to contribute to Wine and other projects, I've had to be very careful how I discover how Windows internals works, often by reading other's writings and doing careful black box analysis (for some of this I have work I can show to show how I figured it out.) But for example, the PEB/TIB structures that store information about processes/threads seems to be something that both the userland and kernel components both read and modify. For dynamic linking in particular, there are some linked lists in the PEB that store the modules loaded into the process, and I believe these are used by both the Windows loader and the kernel in some cases.

The Windows NT kernel also just takes on a lot more responsibilities. For example, input. I can literally identify some of the syscalls that go into input handling and observe how they change behavior depending on the last result of PeekMessage. The kernel also appears to be the part of the system that handles event coalescing and priority. It's nothing absurd (the Wine project has already figured out how a lot of this works) but it is a Huge difference from Linux where there's no concept of "messages" and probably shouldn't be.

So the equivalent of the Windows NT kernel services would often be more appropriate to put in userland on Linux anyways, and Wine already does that.

It would still be interesting to attempt to get a Windows XP userland to boot directly on a Linux kernel, but I don't think you'd ever end up with anything that could ever be upstreamed :)

Maybe we should do the PE binfmt though. I am no longer a fan of ELF with it's symbol conflicts and whatnot. Let's make Linux PE-based so we can finally get icons for binaries without needing to append a filesystem to the end of it :)

direwolf20 3 hours ago | parent [-]

You can already use binfmt_misc to instruct the kernel to execute PE binaries with Wine.

jchw 2 hours ago | parent [-]

I mean something a bit different. I mean using PE binaries to store Linux programs, no Wine loader.

Of course, this is a little silly. It would require massively rethinking many aspects of the Linux userland, like the libc design. However, I honestly would be OK with this future. I don't really care that much for ELF or its consequences, and there are PE32+ binaries all over the place anyways, so may as well embrace it. Linux itself is often a PE32+ binary, for the sake of EFI stub/UKI.

(You could also implement this with binfmt_misc, sure, but then you'd still need at least an ELF binary for the init binary and/or a loader.)

(edit: But like I said, it's a little silly. It breaks all kinds of shit. Symbol interposition stops working. The libdl API breaks. You can't LD_PRELOAD. The libpthread trick to make errno a thread local breaks. Etc, etc.)

direwolf20 an hour ago | parent [-]

Wine has no problem loading Linux programs in PE format. It doesn't enforce that you actually call any Windows functions and it doesn't stop you making Linux system calls directly.

jchw 31 minutes ago | parent [-]

Well yes, but you'd be spawning a wineserver and running wineboot and all kinds of baggage on top, all for the very simple task of mapping and executing a PE binary, and of course you would still wind up needing ELF... for the Wine loader and all of the dependencies that it has (like a libc, though you could maybe use a statically-linked musl or something to try to minimize it.)

Meanwhile the actual process of loading a PE binary is relatively trivial. It's trivial enough that it has been implemented numerous times in different forms by many people. Hell, I've done it numerous times myself, once for game hacking and once in pure Go[1] as a stubborn workaround for another problem.

Importing an entire Wine install, or even putting the effort into stripping Wine down for this purpose, seems silly.

But I suppose the entire premise is a little silly to begin with, so I guess it's not that unreasonable, it's just not what I am imagining. I'm imagining a Linux userland with simply no ELF at all.

[1]: https://github.com/jchv/go-winloader - though it doesn't do linking recursively, since for this particular problem simply calling LoadLibrary is good enough.

snvzz 4 hours ago | parent | prev [-]

>it'd offer a solution to keeping niche HW running

Preservation. It ensures WinNT survives as a platform even if Microsoft abandons it, which some would argue the present state of Win11 counts as doing.

ch_123 2 hours ago | parent | next [-]

If MS abandons WinNT, then people will likely continue to use the existing versions of Windows which are out there for any existing software (just as people continue to use MS-DOS and Win 9x for old games and software).

As for new software - I think it's open to debate just how much new Win32 software will be created after a hypothetical abandonment by Microsoft of Windows.

godzillabrennus 4 hours ago | parent | prev [-]

Windows 11 is the enshitification late stage advertisement economy product that no one asked for, and everyone in the C Suite at Microsoft is excited about. Probably the only thing they are more excited for is yet another terrible branding decision.

drzaiusx11 4 hours ago | parent | prev | next [-]

I wonder if any corporations that could benefit from this project could help bankroll it (of which I assume there are many.)

Wish they had a sponsorship listing on their GH page... I poked around and couldn't find one

freedomben 2 hours ago | parent | next [-]

I suspect this would be a very risky proposition for them. The expense would be enormous, so it would either need to be a player with such huge economies of scale to make it work, or it would have to be a collection of businesses that in aggregate could make it economically feasible. I would suspect in most cases, it would be a lot cheaper to just port your software to modern Linux than to try to get react OS over the line. And that's before considering that a lot of the large players will be in contract situations with Microsoft that likely directly prevent this sort of thing

genewitch 19 minutes ago | parent [-]

apple, nvidia, microsoft, google, facebook, amazon, broadcom(!!!!), TSMC(!), and tesla all have way more than a trillion dollars.

>$1,000,000,000,000.00

They could give this project $10,000,000 per year for a decade and not notice. we're talking "slap on the wrist fine" levels of money here.

zamadatix 2 hours ago | parent | prev [-]

There's a sponsorship section but it just links to the donate page rather than a corporate focused sponsorship program. It seems most of the corporate activity in this space is around userspace compatibility rather than NT kernel compatibility, like CrossOver or Valve driving Wine and other codebases in that regard.

Cthulhu_ 4 hours ago | parent | prev | next [-]

Is money the issue for this project, or finding the right people?

Or another point of view, if you put a lot of money into it, it becomes a commercial endeavour - would it still be for a good cause?

More armchair internet commenter devil's advocate discussion starters than any opinions of mine to be honest. But, there's a lot of projects that would benefit from no-strings-attached donations.

velcrovan 3 hours ago | parent [-]

As far as I can tell, the nearest thing to a stated goal or mission is on their “About” page:

    Our main features are:

    * ReactOS is able to run Windows software
    * ReactOS is able to run Windows drivers
    * ReactOS looks-like Windows
    * ReactOS is free and open source
Building a replica of an old OS is a fun project, but if there was a purpose for it besides having an "is able to" replica, it would attract more people.
squeefers 2 hours ago | parent [-]

in the real world, most people use windows. most software that those people use is written for windows. if it can run windows exes out of the box, whilst not phoning home to microsoft, it becomes an attractive proposition. i want to get off windows but i dont want the headache of linux; to me its the only hope

doublerabbit 4 hours ago | parent | prev [-]

Let's become billionaires together. You bankroll ReactOS and I'll bankroll HaikuOS.

snvzz 4 hours ago | parent [-]

And I'll join in and bankroll AROS.

Together, we could bankroll Minix3 as well.

LoganDark 4 hours ago | parent [-]

Who wants to bankroll SerenityOS?

snvzz 4 hours ago | parent [-]

I don't think that one wants to be bankrolled. It'd go against its spirit.

ipunchghosts 3 hours ago | parent | prev | next [-]

I would think claude code would help make a quick dent in boosting reactos capabilities. Curious what others think.

Oxodao 3 hours ago | parent | next [-]

I would rather not. While it is already highly questionable to use it normally because it steals opensource code, but let's give it a pass for this thought experiment, it probably scrapped the multiple git repository of Windows leaked source code. In which case it would ABSOLUTELY undermine the project's ability to say it's a clean room implementation

DustinBrett 2 hours ago | parent [-]

How do you steal open source code? It's open.

Dwedit 2 hours ago | parent | next [-]

You violate the license (such as GPL)

davisr an hour ago | parent | prev [-]

Copyright licenses are not one word. They are written with intent, and usually at minimum that intent is to credit the original author.

jeroenhd 2 hours ago | parent | prev | next [-]

Various versions of Windows have had their source code leaked out in part or almost whole. If Claude produces an exact copy, like LLMs used to do with the fast inverse square root from Doom, Microsoft would have good reason to sue and it'd be on the project to prove that the copyright violation was done by a bot (which makes it legal now).

With the project essentially implementing the entire API method by method, the chances of LLMs repeating some of the leaked source code would be tremendous.

A one-directional fork of ReactOS might be able to make some fast progress for a few people who desperately need certain programs to work, but I don't think the project will benefit from LLMs.

DustinBrett 2 hours ago | parent | prev | next [-]

I think it's not ready yet but I agree that eventually it will be. The 40th anniversary of ReactOS might have some substantial features. This is the decade of ReactOS!

sermah 2 hours ago | parent | prev | next [-]

I think it would be an elephant in a china shop. ReactOS doesn’t come from React (JS Library)

bluedino 2 hours ago | parent | prev [-]

A cleanroom trained LLM would be needed, no?

yoasif_ an hour ago | parent [-]

Nah, since the LLM is a copyright removal device: https://www.quippd.com/writing/2025/12/17/AIs-unpaid-debt-ho...

computersuck 4 hours ago | parent | prev | next [-]

Multi Processor Support!!? Cutting edge stuff

sshb 3 hours ago | parent | prev | next [-]

Feel like such projects would benefit tremendously from agentic coding

luismedel 3 hours ago | parent [-]

What if the agents were trained by leaked Microsoft code?

jeroenhd 2 hours ago | parent [-]

With the way the courts seem to judge LLM outputs, I don't think that's an issue as long as it's provable that the code was shat out by an LLM.

Of course Microsoft could still claim that someone used a leaked Windows build as the source so any LLM use would be a ticking time bomb.

Kwpolska an hour ago | parent [-]

Is this defense even viable if the Windows XP source code has been leaked and openly shared online, and you can find many copies of it on GitHub?

jeroenhd an hour ago | parent [-]

There's definitely irony in that Microsoft's GitHub is hosting the leaked source code (which probably got sucked into Copilot and every other AI under the sun as a result).

However, I don't think copyright lawyers will care. "They're also committing a crime" doesn't mean you're free to do what you want. That applies especially in ReactOS vs MS, because if ReactOS succeeds, it will compete directly with Microsoft.

DustinBrett 2 hours ago | parent | prev | next [-]

At some point AI might get good enough to write whatever is missing from that thing. Seems like they have the ability to wait it out.

zamadatix 2 hours ago | parent | next [-]

Maybe, maybe not, but one thing is for certain: you can't seem to escape conversation about AI regardless which post you open on HN!

treesknees an hour ago | parent | prev [-]

ReactOS requires all contributors to affirm that legally they have not used or seen any leaked Windows source code. This is to avoid any hints of copyright violation. While AI may be capable of writing a new driver or fixing bugs, a developer using AI can’t affirm that the model hasn’t seen/trained on any leaked source code. So AI submissions would very likely be denied.

squeefers 3 hours ago | parent | prev [-]

anything that gets away from microsoft, and more importantly linus torvalds, is a good thing

satvikpendem 3 hours ago | parent [-]

Why Torvalds?

augusto-moura 3 hours ago | parent | next [-]

I think he/she is talking about avoiding both Windows and Linux

satvikpendem 3 hours ago | parent | next [-]

Yes, I am asking why avoid Linux too?

pjmlp 2 hours ago | parent | next [-]

Maybe the monoculture that many kids nowadays think UNIX === Linux?

dangus 2 hours ago | parent [-]

I don't think the kids these days know that UNIX exists.

UNIX is also basically irrelevant unless you are talking about macOS technically being UNIX, so I agree with the kids.

The idea that Linux is a monoculture is also hilarious to me. That umbrella includes things like RHEL, SteamOS, Bazzite, Android, Chromebooks, Gnome, KDE, dwm, i3, your robot vacuum, car infotainment systems..."Linux" is the exact opposite of a monoculture.

pjmlp 2 hours ago | parent [-]

All powered by the Linux kernel, the very meaning of monoculture.

Also it isn't as if BSD, FreeRTOS, Aix, INTEGRITY, SmartOS, Illumos, QNX,... don't exist.

6c696e7578 27 minutes ago | parent | next [-]

> Aix

This is more a limitation on the architecture - virtually nobody has power arch hanging around to play on.

vardump 39 minutes ago | parent | prev [-]

FreeRTOS is an odd one in that set.

squeefers 2 hours ago | parent | prev | next [-]

not linux, specifically linus. its just a shame hes still attached to the kernel

satvikpendem 2 hours ago | parent [-]

Okay, so why avoid Torvalds? I am not sure what part of him you find objectionable.

augusto-moura 2 hours ago | parent | prev [-]

Ragebaiting/hater comment

millerm 3 hours ago | parent | prev [-]

What would be the point of avoiding linux?

squeefers 2 hours ago | parent | prev [-]

as a person, hes supremely loathable. hes long since stopped coding and now hes just gobshiting. im not saying you have to stop admiring him

dangus 2 hours ago | parent | next [-]

Have you...worked in software before?

His skills are applied to being essentially the product manager of the Linux kernel, just like any other senior engineer of his age and experience.

It's better that he not write code because he can have greater impact steering the direction of the kernel and reviewing others' work.

I'm also not sure why you don't like the guy on such a personal level. He only made Linux and git because he didn't have an alternative that worked for him. What did he ever do to you?

I watched the video of him hanging out with Linus from Linux Tech Tips and I thought he seemed like a relatively personable guy. Maybe he's somewhat opinionated on technology and wrote an angry email or two but certainly not a bad person.

jccalhoun an hour ago | parent | prev [-]

what about him is supremely loathable? that he doesn't code?