[HN Gopher] 30 Years of ReactOS
___________________________________________________________________
30 Years of ReactOS
Author : Mark_Jansen
Score : 226 points
Date : 2026-01-22 08:03 UTC (14 hours ago)
(HTM) web link (reactos.org)
(TXT) w3m dump (reactos.org)
| superdisk wrote:
| I sometimes daydream about becoming a billionaire and bankrolling
| this project to completion. Would do the world so much good.
| drzaiusx11 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| freedomben wrote:
| but why would any of those companies want to use ReactOS?
| They already build on top of Linux, except maybe
| Microsoft, but certainly Microsoft wouldn't want to fund
| ReactOS...
|
| If I were an executive at those places and somebody
| proposed ReactOS to replace our foundation, I'd assume
| they were joking/trolling and would laugh (and genuinely
| find it funny)
| genewitch wrote:
| who said they need to _use_ reactOS or "replace their
| foundation", which is a term i cannot parse, i don't
| think anyone wants to use this as a server platform (that
| was my default assumption of that phrase.)
|
| this is "we have a market cap of 61,271,506 times the
| median household income in the USA, we can afford to peel
| off 1/500,000th (0.0002%) of our market cap per year to
| make this project _awesome_ because we like this project
| and want to see it grow "
| zamadatix wrote:
| 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.
| sho_hn wrote:
| 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.
| snvzz wrote:
| >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.
| godzillabrennus wrote:
| 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.
| ch_123 wrote:
| 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.
| mghackerlady wrote:
| 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
| jchw wrote:
| 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 wrote:
| You can already use binfmt_misc to instruct the kernel to
| execute PE binaries with Wine.
| jchw wrote:
| 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 wrote:
| 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 wrote:
| 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.
| saghm wrote:
| I recently learned that Windows binaries contain metadata
| for what version they are (among other things,
| presumably). I was discussing in-progress work on making
| a mod manager for a popular game work on Linux with the
| author of the tool, and they mentioned that one of the
| things that surprised them was not being able to rely on
| inspection of a native library used by most mods to
| determine what version they had installed on Linux like
| they could on Windows. It had never occurred to them that
| this wasn't a first-class feature of Linux binary
| formats, and I was equally surprised to find out that it
| was a thing on Windows given that I haven't regularly
| used Windows since before I really had much of a concept
| of what "metadata in a binary format" would even mean.
| 1718627440 wrote:
| Are you talking about the "Linux version" it targets or
| the version of the library? If its the latter, then it is
| the case, that versioning works per symbol instead of per
| library, so that a newer library can still contain the
| old symbols. If you want the latest version a library
| implements, you could search all symbols and look for the
| newest symbol version.
|
| If you want it the other way around you could look at the
| newest symbol the library wants.
| treyd wrote:
| 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.
| BoredomIsFun wrote:
| > What you're suggesting is as if you could load Linux
| kernel modules into the FreeBSD kernel.
|
| Afaik, you partially can.
| augusto-moura wrote:
| 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/
| bryanlarsen wrote:
| It's far from "roughly compatible with NT", but the Linux
| kernel does accept changes to make supporting Windows
| applications more efficient.
|
| example: ntsync
| dmitrygr wrote:
| That would require (among many other things) a stable
| driver API -- one of the things NT gets right and linux is
| wrong on. Linus has been quite clear that he does not see
| things this way. So ... not going to happen
| doublerabbit wrote:
| Let's become billionaires together. You bankroll ReactOS and
| I'll bankroll HaikuOS.
| snvzz wrote:
| And I'll join in and bankroll AROS.
|
| Together, we could bankroll Minix3 as well.
| LoganDark wrote:
| Who wants to bankroll SerenityOS?
| snvzz wrote:
| I don't think that one wants to be bankrolled. It'd go
| against its spirit.
| drnick1 wrote:
| Ladybird has quite a few corporate sponsors now and is
| progressing quite well. I built and tested the latest
| sources over the winter break and it sort of works
| already. I posted on HN from it.
| Cthulhu_ wrote:
| 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 wrote:
| 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 wrote:
| 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
| velcrovan wrote:
| Sure, but Windows has moved a long ways since the version
| that they're attempting to replicate. And again, their
| bar for success "is able to run Windows programs" is not
| actually high enough to achieve a practical Windows
| replacement, even if going back to Windows 95 is all we
| wanted.
|
| It's interesting you mention Linux being a headache -- it
| is, but there is an order of magnitude more people
| working full-time on _just_ the Linux desktop experience
| than have ever even tried running ReactOS. That ratio
| would have to flip before the latter has a hope of being
| a useful Windows replacement. We're much more likely to
| see Wine able to run 100% of Windows before ReactOS gets
| there.
| forinti wrote:
| At this point, if I magically became filthy rich, I would
| invest in tools that facilitate migrating from Oracle to
| Postgresql, including Apex.
| computersuck wrote:
| Multi Processor Support!!? Cutting edge stuff
| userulluipeste wrote:
| Past certain level, it seemingly was cutting edge stuff, and
| has been mentioned as such in comics like this:
| https://xkcd.com/619/
| ipunchghosts wrote:
| I would think claude code would help make a quick dent in
| boosting reactos capabilities. Curious what others think.
| Oxodao wrote:
| 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 wrote:
| How do you steal open source code? It's open.
| Dwedit wrote:
| You violate the license (such as GPL)
| davisr wrote:
| Copyright licenses are not one word. They are written with
| intent, and usually at minimum that intent is to credit the
| original author.
| userulluipeste wrote:
| _" 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"_
|
| If an LLM model has been fed leaked code, then that is a
| general problem for that model and for its use for anything.
| Singling out its use for an open-source project and
| denouncing that as a potential problem while otherwise
| keeping quiet about it just makes no sense. Just take legal
| action against the model if there's anything plausible to
| warrant that, don't weaponize it against open-source
| projects.
| timeon wrote:
| If they use Copilot it is probably fair game.
| jeroenhd wrote:
| 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.
| userulluipeste wrote:
| Well, it's not Claude, it's GitHub Copilot (which happens to
| be owned by none other than... guess who):
| https://github.com/reactos/reactos/pull/8516
|
| But, if any such model got fed with leaked code, then how is
| this a specific open-source project's problem and not of all
| projects (either open-source or private) that got to ever use
| that model?
|
| Then, (having thought this just now) how can an argument
| relying on (legally) undisclosed information be used against
| anything public? Isn't the onus on the party having the
| undisclosed information to prove that it preceded the public
| one? How can that precedence be trusted by an independent
| judging party if the undisclosed information (source-code and
| systems managing that source code) is and always has been in
| the hands of the accusing (thus biased) party?
| sermah wrote:
| I think it would be an elephant in a china shop. ReactOS
| doesn't come from React (JS Library)
| DustinBrett wrote:
| 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!
| bluedino wrote:
| A cleanroom trained LLM would be needed, no?
| yoasif_ wrote:
| Nah, since the LLM is a copyright removal device:
| https://www.quippd.com/writing/2025/12/17/AIs-unpaid-debt-
| ho...
| bigstrat2003 wrote:
| I don't think Claude code (or any LLM) is adequate for any
| programming task, much less something highly technical like an
| OS project.
| sshb wrote:
| Feel like such projects would benefit tremendously from agentic
| coding
| luismedel wrote:
| What if the agents were trained by leaked Microsoft code?
| jeroenhd wrote:
| 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 wrote:
| 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 wrote:
| 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.
| 1718627440 wrote:
| > "They're also committing a crime"
|
| But Microsoft has the rights to the code, so they do not
| commit a crime by broadcasting it.
| userulluipeste wrote:
| _" 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."_
|
| And ReactOS uses GitHub Copilot:
| https://github.com/reactos/reactos/pull/8516
|
| There's also such thing as being responsible (for an
| outcome), which in case of litigation means being
| culpable. Microsoft here is the sole actor that has any
| control on the GitHub Copilot, on what it was fed with,
| and thus - on its output (which would be the base of
| their accusation if they sue). How do you imagine such a
| case could be made to look like it would have any legal
| standing?
| p0w3n3d wrote:
| That creates a loop hole. Take code, feed LLM and let it
| spew it again - voila - you have perfectly legal code. Just
| fix bugs
| rubymamis wrote:
| Great project, but let's just make this year the year of the
| Linux Desktop!
| xattt wrote:
| 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
| ofrzeta wrote:
| 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)
| bitigchi wrote:
| Haiku has gazillions of modern software and got NVIDIA
| drivers recently. Things are looking pretty bright for Haiku.
| tracker1 wrote:
| 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 wrote:
| 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 wrote:
| Legacy of BeOS.
| tracker1 wrote:
| 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.
| DustinBrett wrote:
| 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 wrote:
| 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 wrote:
| 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.
| HanClinto wrote:
| Oh? Because Copilot might have trained on code it shouldn't
| have?
|
| Assuming a ReactOS developer used Microsoft / Github Copilot
| to work on this codebase, then if Microsoft attempts to sue
| (themselves?) over their own Copilot tool injecting their own
| copyrighted code into a user's codebase, then that would be
| next-level irony right there.
|
| I would chip in my $100 to fund whatever side of that legal
| battle is necessary just so I could see that case be argued
| in court.
| timeon wrote:
| > that would be next-level irony
|
| More like end of Copilot.
| userulluipeste wrote:
| _" Assuming a ReactOS developer used Microsoft / Github
| Copilot to work on this codebase"_
|
| No need to assume. It's a certainty:
| https://github.com/reactos/reactos/pull/8516
|
| _" if Microsoft attempts to sue (themselves?) over their
| own Copilot tool injecting their own copyrighted code into
| a user's codebase"_
|
| Such an attempt can't make sense, given that the model used
| by ReactOS is in Microsoft's control and thus Microsoft
| alone is the one responsible for the model's behavior. They
| won't sue, thus much is clear.
| _fat_santa wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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!
| userulluipeste wrote:
| _" 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."_
|
| I understand your angle, or rather the attempt of fitting
| them in the same picture, somehow. However, the differences
| between them far surpass the similarities. There was no
| meaningful user-base for Unix/Hurd so to speak of compared to
| NT kernel. There's no real basis to assert the "kernel
| development" argument for both, as one was indeed a research
| project whereas the other one is just clean room engineering
| march towards replicating an existing kernel. What ReactOS
| needs to succeed is to become more stable and complete (on
| the whole, not just the kernel). Once it will be able to do
| that, covering the later Windows capabilities will be just a
| nice-to-have thing. Considering all the criticism that
| current version of Windows receives, switching to a stable
| and functional ReactOS, at least for individual use, becomes
| a no-brainer. Comparatively, there's nothing similar that
| Hurd kernel can do to get to where Linux is now.
| saghm wrote:
| > There was no meaningful user-base for Unix/Hurd so to
| speak of compared to NT kernel.
|
| Sure, but that userbase also already has a way of using the
| NT kernel: Windows. The point is that both Hurd and ReactOS
| are trying to solve an interesting technical problem but
| lack any real reason to use rather than their alternatives
| that solve enough of the practical problems for most users.
| ACS_Solver wrote:
| I'd still consider them more similar than not.
|
| Hurd was not a research project initially. It was a project
| to develop an actual, usable kernel for the GNU system, and
| it was supposed to be a free, copyleft replacement for the
| Unix kernel. ReactOS was similarly a project to make a
| usable and useful NT-compatible kernel, also as a free and
| copyleft replacement.
|
| The key difference is that Hurd was not beholden to a
| particular architecture, it was free to do most things its
| own way as long as POSIX compatibility was achieved.
| ReactOS is more rigid in that it aims for compatibility
| with the NT implementation, including bugs, quirks and all,
| instead of a standard.
|
| Both are long irrelevant to their original goals. Hurd
| because Linux is the dominant free Unix-like kernel (with
| the BSD kernel a distant second), ReactOS because the
| kernel it targets became a retrocomputing thing before
| ReactOS could reach a beta stage. And in the case of
| ReactOS, the secondary "whole system" goal is also
| irrelevant now because dozens of modern Linux distributions
| provide a better desktop experience than Windows 2000.
| Hell, Haiku is a better desktop experience.
| userulluipeste wrote:
| _" And in the case of ReactOS, the secondary <<whole
| system>> goal is also irrelevant now because dozens of
| modern Linux distributions provide a better desktop
| experience than Windows 2000. Hell, Haiku is a better
| desktop experience."_
|
| Yet, there are still too many desktop users that, despite
| the wishful thinking or blaming, still haven't switched
| to neither Linux, nor Haiku. No mater how good Haiku or
| Linux distributions are, their incompatibility with the
| existing Windows simply disqualifies them as options for
| those desktop users. I bet we'll see people switching to
| ReactOS when it will get just stable enough, yet long
| before it will get as polished as either Haiku or any
| given quality Linux distribution.
| ACS_Solver wrote:
| No, people will never be switching to ReactOS. For some
| of the same reasons they don't switch to Linux, but
| stronger.
|
| ReactOS aims to be a system that runs Windows software
| and looks like Windows. But, it runs software that's
| compatible with WinXP (because they target the 5.1
| kernel) and it looks like Windows 2000 because that's the
| look they're trying to recreate. Plenty of modern
| software people want to run doesn't run on XP. Steam
| doesn't run on XP. A perfectly working ReactOS would
| already be incompatible with what current Windows users
| expect.
|
| UI wise there is the same issue. Someone used to Windows
| 10 or 11 would find a transition to Windows 2000 more
| jarring than to say Linux Mint. ReactOS is no longer a
| "get the UI you know" proposition, it's now "get the UI
| of a system from twenty five years ago, if you even used
| it then".
| userulluipeste wrote:
| _" UI wise there is the same issue. Someone used to
| Windows 10 or 11 would find a transition to Windows 2000
| more jarring than to say Linux Mint. ReactOS is no longer
| a <<get the UI you know>> proposition, it's now <<get the
| UI of a system from twenty five years ago, if you even
| used it then>>." "A perfectly working ReactOS would
| already be incompatible with what current Windows users
| expect."_
|
| That look and feel is the easy part. That can be
| addressed if it's really an issue. The hard part is the
| compatibility (that is given by many still missing parts)
| and stability (the still defective parts). The targeted
| kernel matters, of course, but that is not set in stone.
| In fact, there is Windows Vista+ functionality added and
| written about, here:
| https://reactos.org/blogs/investigating-wddm although
| doing it properly would mean rewriting the kernel,
| bumping it to NT version 6.0
|
| I'm sure there will indeed be many users that will find
| various ReactOS aspects jarring for as long as there are
| still defects, lack of polish, or dysfunction on
| application and kernel (drivers) level. However,
| considering the vast pool of Windows desktop users, it's
| reasonable to expect ReactOS to cover the limited needs
| for enough users at some point, which should turn
| attention into testing, polish, and funding to address
| anything still lacking, which then should further feed
| the adoption and improvement loop.
|
| _" No, people will never be switching to ReactOS. For
| some of the same reasons they don't switch to Linux, but
| stronger."_
|
| To me, this makes sense maybe for corporate world. The
| reasons that made them stick with Windows has less to do
| with familiarity or with application compatibility (given
| the fact that a lot of corporate infrastructure is in web
| applications). Yes, there must be something else that
| governs corporate decisions, something to do with the way
| corporations function, and that will most likely prevent
| a switch to ReactOS just as it did to Linux based
| distributions. But, this is exactly why I intentionally
| specified "for individual use" when I said _" switching
| to a stable and functional ReactOS, at least for
| individual use, becomes a no-brainer"_. For individual
| use, the reason that prevented people to switch to Linux
| is well known, and ReactOS's reason to be was aimed
| exactly at that.
| f311a wrote:
| > 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!
| ch_123 wrote:
| 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 wrote:
| 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.
| ch_123 wrote:
| Yes, exactly my point - thanks for elaborating on it.
| hypercube33 wrote:
| Why not use Linux with WINE and that Chicago95 theme and
| call it a day?
| ch_123 wrote:
| That's (part of) my point. A project like ReactOS which
| clones Windows down to the kernel level solves for a very
| small set of practical use cases which are not covered by
| real Windows, or Linux+WINE.
|
| It's worth noting that 30 years ago, there was a definite
| advantage to an open source operating system which could
| reuse proprietary Windows drivers - even Linux had a
| mechanism for using Windows drivers for certain types of
| hardware. Nowadays, Linux provides excellent support for
| modern PC hardware with little to no tinkering required
| in most cases. I have seen many cases where Linux
| provided full support out-of-the-box for a computer,
| whereas Windows required drivers to be downloaded and
| installed.
| spijdar wrote:
| 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/rt
| l/p...
|
| [1] https://github.com/wine-
| mirror/wine/blob/master/dlls/ntdll/p...
| ch_123 wrote:
| That's an interesting data point. I wonder if there is a
| hard technical reason why that logic could not be added to
| WINE, or if the WINE maintainers made a decision not to
| implement similar functionality.
| tadfisher wrote:
| There is not a hard technical reason, just different
| goals. WINE is a compatibility layer to run Windows apps,
| and thus most improvements end up fixing an issue with a
| particular Windows application. It turns out that most
| Windows applications are somewhat well-behaved and
| restrict themselves to calling public win32 APIs and
| public DLL functions, so implementing 100% coverage of
| internal APIs wouldn't accomplish much beyond exposing
| the project to accusations of copyright infringement.
|
| IIRC, there is also US court precedent (maybe _Sony v.
| Connectix_?) that protects the practice of reverse-
| engineering external hardware /software systems that
| programs use in order to facilitate compatibility. WINE
| risks losing this protection if they stray outside of
| APIs known to be used (or are otherwise required) by
| applications.
| badsectoracula wrote:
| No, the Wine developers refuse to accept contributions from
| ReactOS developers or even people who have _seen_ ReactOS
| code[0]. So any improvements go one way only.
|
| [0] https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-
| Guide... (last "Don't" entry)
| kwanbix wrote:
| You are saying that ReactOS doesn't use clean room code?
| Source?
| snovymgodym wrote:
| I believe the integrity of ReactOS's clean room reverse
| engineering has been called into question in the past
| when it was found that there were some header or code
| files with sections that matched leaked Windows Server
| 2003 code or something like that. Can't recall for sure
| though.
| userulluipeste wrote:
| The article mentions this:
|
| _" In January 2006, concerns grew about contributors
| having access to leaked Windows source code and possibly
| using this leaked source code in their contributions. In
| response, Steven Edwards strengthened the project's
| intellectual property policy and the project made the
| difficult decision to audit the existing source code and
| temporarily freeze contributions."_
|
| The allegations have been taken seriously and since then
| the procedure for accepting contributions include
| measures to prevent such further events from occurring.
| If you or anyone else happen to have any plausible
| suspicion, then please report it to the ReactOS team,
| otherwise keeping alive this kind of vague and uncertain
| connection between some Windows code leakage and ReactOS
| fits the very definition of FUD: https://en.wikipedia.org
| /wiki/Fear,_uncertainty,_and_doubt Please stop.
| zen928 wrote:
| They posted their source for their claim (which is
| different than yours). Click and read it.
| card_zero wrote:
| I read it, and "not appropriate for Wine" was a non-
| answer, so I followed the footnote link and got to the
| same discussion:
|
| https://bugs.winehq.org/show_bug.cgi?id=50464#c6
|
| Which isn't really a discussion, it just ends with the
| same question "why not?".
| badsectoracula wrote:
| I'm saying nothing, i posted the link of the Wine
| developers claim for why not accepting contributions by
| ReactOS developers since the post i replied to wrote that
| ReactOS contributed to Wine.
| snvzz wrote:
| It's common anti-ReactOS slander.
|
| I keep seeing it pop up over the years. Never
| substantiated.
| SirMaster wrote:
| So they don't use LLMs to help code at all?
|
| LLMs have likely seen the leaked Windows source code lets
| be honest...
| boznz wrote:
| >it'll be friendlier for the average person than Linux
| itself.
|
| I think the myth that Windows is easier needs to die. The
| builds targeted at Windows users are very easy to use; You
| would likely go into the Command Prompt as much as you would
| with Windows, and the "average person" spends more time on
| their non-windows phone than they do in Windows.
|
| I am a 30+ years Windows developer, who thought he would
| never move, but who migrated literally a week ago, the
| migration was surprisingly painless and the new system feels
| much more friendly, and surprisingly, more stable. I wrote it
| up on my blog, and was going to follow it up with another
| post about all the annoyances in my first full week, but they
| were so petty I didn't bother.
| johnisgood wrote:
| I agree. One can just install Linux Mint or Fedora or
| anything and then Linux is just as friendly to use. You got
| a desktop, you can use your mouse to start up the browser,
| install applications with a mouse click, and so forth. You
| could do without opening up the terminal. Functionally the
| same as using Windows.
| maybewhenthesun wrote:
| You are still in the honeymoon phase. I see a lot of those
| blogpost in the last months.
|
| In a few weeks you will bump into something that isn't
| simple and friendly and you will _curse_ that stupid linux.
| Something that trivially works in windows and is impossible
| or insanely hard in linux. That is often the time people go
| back. Old habits die hard.
|
| But still you are 100% right. Windows is _not_ easier. I
| know because I went from dos to linux and only occasionally
| dabbled in windows. And I have exactly the same sort of
| trouble as soon as I try to do something non trivial in
| windows. Including bumping into stuff that _should_ be
| trivial but suddenly is impossible or insanely hard.
|
| For years I have seen people say that windows is easier,
| while actually windows is just more familiar.
|
| My (completely non computer savvy) parents and in-laws are
| on ubuntu/mint since 2009 and it was the best decision ever
| to switch them over. And they don't understand why people
| say linux is hard either (though my father in law still
| calls it 'Ubantu Linox' for some reason :-P )
|
| At the start I had a small doubt if I should push them to
| macOS (OSX at the time) as then apple's fanatical
| dedication to userfriendlyness paid off. But I decided
| against it because I didn't feel like paying apple prices
| for my own hardware and it seemed ill advised to manage
| their systems while not using it myself. I'm very glad
| about that because apple has gone downhill immensely since
| ~2009 (imo)
| thisislife2 wrote:
| Sigh, I hate to agree with you. On a slight tangent, I was
| exploring what file system I could use safely with different
| OSes, so that I could keep my personal data on it and access
| (or add to it) from other OSes, and incredibly NTFS is the only
| feature rich _cross-platform_ filesystem that works reliably on
| all the major OSes! None of the open source solutions - ZFS,
| Btrfs, Ext etc. work reliably on other OSes (many solutions to
| make them cross-platform or still in beta, for years now). It
| 's the _Windows effect_ - open source developers are putting so
| much effort into supporting windows tech because of it 's
| popularity, that unknowingly they are also helping it make even
| more entrenched, to the detriment of better open source
| solutions.
| saghm wrote:
| Last time I looked at this, I think I determined that exFAT
| also had reasonable support for Windows, Linux, and MacOS? I
| guess it might not be "feature rich", but it's at least
| suitable for a USB drive or something. This also isn't a
| counterpoint to your argument that Windows tech is better
| supported given its origins, but it might be useful for some
| people depending on their intended use.
| thisislife2 wrote:
| That's a good tip, and I do use exFat on some pendrives.
| But due to the lack of journaling, and its buggy
| performance on macOS (
| https://www.linkedin.com/pulse/exfat-file-system-save-
| henk-s... ) I wouldn't recommend it for long-term use on
| any fixed drives with data you care about. My research lead
| me to conclude that NTFS implementations are the least
| buggiest non-native file systems on Linux and macOS.
| KellyCriterion wrote:
| > accept the lack of support for modern software
|
| Running MS SQL 2008 R2 and MS Server 2016 in production here.
|
| What "modern software support" do I lack here?
| Gud wrote:
| Software updates?
| mixmastamyk wrote:
| I've been playing around with this for decades and it has been a
| pretty toy facade 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.
| neocron wrote:
| Aah, ReactOS, my hope from the era of windows xp. After 30 yrs
| it's still another 30 yrs from completion, kinda like nuclear
| fusion reactors
| phendrenad2 wrote:
| ReactOS is an amazing achievement, for what it is. Building a
| house is much easier than building _exactly the same house_
| without being able to even peek at the original blueprints, or
| take input from anyone who has.
|
| To that point I hope that more people study ReactOS and get a
| sense for the Microsoft/IBM philosophy of doing a desktop
| operating system (which is completely different from the
| Linux/Unix way). I hope we someday see new operating system
| projects that use these learnings.
| accrual wrote:
| Congrats on 30 years of development, ReactOS team! What a lovely
| walk through the storied history of the project.
|
| I wonder how well it runs on XP-era hardware, Thinkpads, etc. I
| have several for running period games and software, but it'd be
| super cool to run ReactOS instead and be able to hack on the OS.
___________________________________________________________________
(page generated 2026-01-22 23:01 UTC)