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.
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.
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.
Of course not. You would be surprised how many developers don't even consider using an LLM in their workflow, myself included. Can't wait for this hype to end.
Firstly, neither OpenAI nor Anthropic is profitable, by a wide margin — investors are going to get impatient at some point.
Secondly, people that aren't enthusiastic about this whole thing are already experiencing something of an AI fatigue with all the AI features violently shoved into them by most software products they use. Being involuntarily subjected to slop in various online spaces can't be good either.
Thirdly, remember NFTs? So many people swore they were The Future™... until they weren't. But at least in that case it was much more obvious how stupid the whole idea is. The scale of the hype was also several orders of magnitude less.
Even if all major provides close down, it doesn't remove what's already out there. Glm / minimax / deepseek / gpt-oss may not be at the same level as current frontier, but you can download them and they're still very capable.
Crazy stupid ideas like cars with only touchscreens have still taken a decade to come in and then to get considered ill-advised even though anyone driving a car could tell how bad of an interface it is. We are still not fully out through the other side.
So while OpenAI or Anthropic are maybe not profitable today, they've got at least 5 years to figure it out. And there is already talk of inserting ads into the "chat", but hopefully that does not work!
But really, LLMs are useful (yes, sometimes only in appearance, but sometimes for real), and with that, there will continue to be investment into them until they are made profitable.
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.
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.
"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.
>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.
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)
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.
It certainly is, because I still don't see GNU/Linux desktops on sale, other than the short lived netbooks movement.
So normal people have stores with other people that they can talk to when they have problems, or just drag their computer into the store.
With Linux it is always the relative that happens to be around, or drive in on purpose, and had to manually install the <insert favourite distro> of the day.
And of course retail GNU/Linux machines that cost 1/4 of a cheap Apple Mac and yet have outsold them by revenue not number of units for nearly a decade now:
Yes this is absolutely happening. This is a real international market with sales in the hundreds of millions of units. This is not some tiny obscure niche that can be skipped over.
You are so eager to reply that you haven't even read the whole comment.
> So normal people have stores with other people that they can talk to when they have problems, or just drag their computer into the store.
Which of those online stores have a physical address for the normal people to do as per my comment?
Linux forums have enough complaints about those fairly prominent Linux-only vendors, even though they are suppose to control the whole stack.
And they also fall into each having their own <favourite distro>, the other part of the comment that you missed as well.
Normal people aren't using SteamDecks for their daily computing activities.
I use Linux in various forms since 1995, and yet I am tired from trying out such alternatives, the only things that makes me consider it again is breaking the dependency on US tech, and even that isn't really happening, given how much from Linux contributions are on the pockets from US Big Tech.
> 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.
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.
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.
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.
There's also another partial Win32 reimplementation in retrowin32, with the different goal of being a Windows emulator for the web, not for Linux or as alternate OS, at https://evmar.github.io/retrowin32/ It thus has an even more sparse path/fileapi.h implementation [2] than WINE and ReactOS. Written in Rust.
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.
I think using WINE over Linux has won as the option to consider if you want to run Windows applications on a non-Windows OS without loading Windows into a VM.
There is a growing list of software that which has discontinued support for Windows 10 on the latest versions (or the Server versions thereof). I'm not sure if your example of running a ~16 year old version of SQL Server on Server 2016 demonstrates.
To my original post - if you only need to run an old version of a software package, then an old version of Windows is fine. Just because something is old, it doesn't mean that it is not useful.
The system runs only one app and does not serve public internet content - it does not get any updates at all, only this one app is updated every few month.
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.
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.
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.
Interesting, I wasn't aware of the exFAT issues on MacOS. I can't remember exactly the last time I tried to use a USB drive like this, so it's possible that it might be further back than I thought and it was when NTFS didn't have write support out of the box for me on Linux.
Yes, interestingly I remember buying portable hard drives 20 years ago that were formatted as FAT or some variant (I don't remember which one exactly).
Last time I bought a portable hard drive it was formatted as NTFS.
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.
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.
"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.
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.
"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.
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".
"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.
> 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.
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.
> 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.
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!
Basically if you do the math, it means a whole generation got tired of being on the project and focused into something else, and there is no new blood to account for that.
The history of most FOSS projects after being running for a while.
I test ReactOS every now and then on a crappy 2011-ish laptop I bought from a thrift store a while ago to test one of my projects on Windows and Linux on real hardware.
Last time was about a month ago. It's still easier to list what works than what doesn't, but I like seeing progress. Ethernet works with some random Windows driver. The integrated GPU doesn't, but installing the driver doesn't make it bsod on startup any more, so that's an improvement. I've seen people have more success with discrete GPUs. Sound card doesn't work because it's too new.
The thing with these kinds of projects that target a vast existing library of software is that the progress feels slow for a long time, but at some point there's enough compatibility for people to try to use it for real, and this is when compatibility starts improving rapidly. I feel like ReactOS is close like never before to that point. I really want it to succeed.
How stable is it? A couple years ago I tried installing it in a VM, and my experience was it would BSOD in 15 minutes whenever I tried to do anything with it.
I tried ReactOS a little while ago, in some ways it's closer than it feels to being acceptable as a daily driver, in others it's quite far away.
I like the idea of there being more alternatives Operating Systems that aren't just a Linux distro. Operating Systems like Haiku and ReactOS I think are great for being a direction that isn't Linux. It's not that Linux is bad, but it's a slow moving change-resistant juggernaut that isn't going to be a place where innovation will thrive.
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.
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.
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.
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.
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)
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.
ReactOS has delt itself a massive blow by hiding so much of their progress.
The project has insisted on creating Windows Server 2003. Probably very little of the software you want to run works on Windows Server 2003. Certainly no modern web browser will.
There has been some movement in recent months though. They have a 64 bit version. They are implementing NT6 APIs. They are implementing UEFI. They are looking at WDDM drivers. The have synced with Wine 10.
If ReactOS can produce a version that can run a modern browser and maybe a half-way recent Office suite, I think a lot of people would change their mind about the potential.
If they can support modern GPU drivers, it is possible they could even gain some traction in that space. Lots of work to do but not impossible.
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.
>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.
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.
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.
i don't get this take. i've been on win11 since the closed "beta" (i think, it's been a real long time). i wrote guides on how to "fix" the most common and also tricky issues with the upgrade path from win10 to win11, as well as guides from 7/8 to winten.
however, i should note that i actually don't like windows 11 at all, but for different reasons. for the first two years or so, third party apps would crash to desktop if a folder had a literal "@"[0] in the name. That was patched on the "big patch" that a lot of people complained about, about 8-10 months ago.
Currently i have another issue, for brevity's sake, i'll just list these two. If i reboot, but don't log in, my computer will freeze. if i log in fast (within about 5 seconds of the login screen accepting input (enter, mouseclick, etc)), and get to the desktop, if i walk away, computer will freeze. My computer freezes (hard freeze, reset button/power button to fix) if it is idle. it's the silliest thing i've ever seen, surpassing even crashing with "@" in the directory name.
my fix? I run an idle game (nomad idle or idle pins) and that stops it from crashing forever. But once a month i wake up to a hard-locked computer because of an automatic update + reboot.
ugh.
[0] i think the newer windows terminal and/or the newer powershell API used to assume an "@" was something else, on powershell, it turns green and autofills stuff like "@Alias" and "@args". My assumption is they didn't sanitize it and let powershell hook everything when that's just silly. Windows 11 is silly.
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
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
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.
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 :)
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.)
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.
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.
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.
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.
I probably could be more clear about what I'm trying to convey. Tool A is written to manage mods for game B, and lots of mods for that game utilize library C. Tool A does not directly load or link to library C, but it does inspect the version of library C that currently exists alongside game B so that it can detect if mods depend on a newer version of it and notify the user that it needs to be updated.
I'm realizing now that I forgot an important detail in all of this: the metadata of the library existed as part of the metadata that the filesystem itself tracked rather than something in the contents of the file itself. This metadata doesn't seem to exist on Linux (which library C only supports if running via Proton rather than any native Linux version of the game). I could imagine it might be possible for this to be set as some sort of extended attribute on a Unix filesystem, but in practice it seems that the library will have this extended filesystem metadata when downloading the DLL onto a Windows machine (presumably with an NTFS filesystem) but not a Linux one.
> so that it can detect if mods depend on a newer version of it and notify the user that it needs to be updated.
The dynamic linker will literally tell you this, if you ask it.
> the metadata of the library existed as part of the metadata that the filesystem itself tracked rather than something in the contents of the file itself.
So does this metadata has anything to do with the file at all, or could I also attach it to e.g. an MP4 file? If that is the case than the difference is that the distributor for MS Windows did add the attribute and the distributor for GNU/Linux did not, it doesn't have anything to do with the platform.
EDIT:
> (which library C only supports if running via Proton rather than any native Linux version of the game
So library C isn't even an ELF shared object, but a PE/COFF DLL? Then that complaint makes even less sense.
I assume it's the ability to tag a .dll as version 0.0.0.1 or whatever (it shows up under the file name in Windows Explorer). I think company name is another one that Windows Explorer displays but there are probably a few other supported attributes as well.
Well, then the answer is that shared objects on GNU/Linux do not have a finite version, they just implement them. This is because they are expected to implement more than one version, so that you can just update the shared object, and it will still work with programs that expect to call the old ABI. You can however get the latest version. This is also what is in the filename. Note, that there are two versioning schemes: semver and libtool, they mean the same, but are notated differently. This version does not does not necessary equal the version of the project/package, APIs/ABIs can and do have their own version numbers.
I think this is just solving a different but related problem. Symbol versioning enables you to make observable changes to the behavior of some library like a libc while providing backwards compatibility by providing the old behaviors indefinitely. I've never gotten the impression that it is "prescribed" that shared objects on a Linux system don't have a specific/definite version, and I don't think that symbol versioning is necessarily appropriate for all programs, either-it just happens to be a mechanism used by glibc, and I don't think it is very common outside of glibc (could be wrong.)
On the other hand, the Windows NE/PE VERSIONINFO resource is mostly informational in nature. I think early on in the life of Windows, it was often used to determine whether or not the system library shipped by an installer was newer than the installed version, so that program installers could safely update the system libraries when necessary without accidentally overwriting new versions of things with older versions. That's just simply a problem that ELF shared objects don't try to solve, I reckon, because there aren't usually canonical binaries to install anyways, and the problem of distributing system libraries is usually left up to the OS vendor.
Actually though, there is another mechanism that Linux shared objects often use for versioning and ABI compatibility: the filename/soname. Where you might have a system library, libwacom.so.9.0.0, but then you also have symlinks to it from libwacom.so.9 and libwacom.so, and the soname is set to libwacom.so.9.
There is, of course, no specific reason why ELF binaries don't contain metadata, and you could certainly extend ELF to contain PE-style resources if you want. (I remember some attempts at this existed when I was still getting into Linux.) It may be considered "bad practice" to check the runtime version of a library or program before doing something, in many cases, but it is still relatively common practice; even though there's no standard way to do it, a lot of shared objects do export a library function that returns the runtime version number, like libpng's png_access_version_number. Since distributions patch libraries and maybe even use drop-in replacements, there is obviously no guarantee as to what this version number entails, but often it does entail a promise that the ABI should be compatible with the version that is returned. (There is obviously not necessarily a canonical "ABI" either, but in most cases if you are dealing with two completely incompatible system/compiler ABIs there isn't much that can be done anyways, so it's probably OK to ignore this case.)
So I think the most "standard" way to embed the "version" of a shared object on Linux is to export a symbol that either returns the version number or points to it, but there is no direct equivalent to the PE VERSIONINFO standard, which may be a pain when the version number would be useful for something, but the developers did not think to explicitly add it to the Linux port of their software, since it is often not used by the software itself.
But I personally wouldn't agree with the conclusion that "shared objects on GNU/Linux do not have a finite version" as a matter of course; I think the more conservative thing to say is that there is not necessarily a definite version, and there is not necessarily a "canonical" binary. In practice, though, if your copy of libSDL is an almost-unmodified build of the source tree at a given version 3.0.0, it is entirely reasonable to say that it is "definitely" libSDL 3.0.0, even though it may not refer to an exact byte-for-byte source tree or binary file.
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
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.
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.
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
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.
> 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.
how no?
> 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
and hows that going these days? still a nightmare? basic functionality introduced maybe 50 years ago now, and the linux world is still working out the kinks with GUIs, probably part of the reason TUIs are becoming popular.
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
Valve has already proven that one moderately-sized corporate contributor added to your moon-shot FOSS project can get you places. (And Valve isn't anywhere near in size for the FANG+ corps you listed)
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)
There's still a ton of critical, often custom-written (read: hard to replace), corporate Windows software out there that still needs to run. If Microsoft continues their further decline of Microsoft Windows releases then a free alternative starts to look more attractive. Linux+Wine is definitely a good option today but compatibility shims add complexity and not all shops run Linux or want to.
i just want to program my old motorola radios without having to deal with virtualbox windows 98 VMs, you know? one can transcribe "motorola radio" for "bosch end mill from 1993" or "thermoplastic former from 1999"
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"
Well if that's the case, then what you're arguing for is charity. That's fine, but the upthread topic has been about business case. If we're looking at it as charity and not a business investment, then it's a much different conversation. I'd certainly love if companies did things like this and would highly applaud it.
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.
I'll throw in a few of the billions I made when I read this paper by "Satoshi Nakamoto" in 2009 and decided to turn over my dozen SETI@home machines to mining his imaginary internet money.
I wanna sponsor 9front. Merge in whatever we can salvage from Inferno, make a 64-bit Dis runtime, and Inferno's version of Rio which is a lot more comprehensible.
I want a VM that can run diskless Linux microVMs so I can just run a Linux binary and have it open and display a GUI in a new Equis window.
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.
It is unfortunate it doesn't even run on SerenityOS anymore.
This does at least partially eliminate the appeal. e.g. SerenityOS has its own decoders for PNG, JPEG and other image formats and they are not bad, but the boring libpng, etc. were adopted instead.
It should be a net positive if not everybody uses the same implementations of everything.
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.
As owner from Red-Hat and Linux contributor since 1998, IBM isn't certainly blocked by choice, they also have Linux for the same architecture, which Aix customers could switch to and don't.
I mean, AIX essentially _does_ not exist unless you happen to work in an enterprise or are in a similar environment that has it. It's not something to easily get your hands on – esp. not "as a kid".
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.
working in it right now. and I can guarantee you anyone acting like linus better have made themselves indispensable because you wont last long lashing out like a 13 year old in emails to people. im still amazed he managed to convince a woman to like him
> it’s happened a small handful of times in the span of decades.
bit of an undersell... hes famous for it. people have left kernel dev because of it. difference between him and your typical product manager are the internet fanbois who treat him like a god. typical product managers have soft skills. typical product managers are beholden to things like polity, common courtesy etc.
I wouldn't invite Torvalds to a dinner party, but i think "supremely loathsome" is hyperbolic. He can spew vitriol and abuse at the drop of a hat, or did. Folks on here are kinda split on if "he's earned it" or "it's never ok" sort of thing.
yeah im just not that impressed with him to put up with that. same with rms. they only act like that because of the pedastal people have put them on. watch how far one lines tries to get his tongue up the other linuses backside.
seeing people give linus the credit for the kernel whilst ignoring the millions of man hours of other peoples time that made also went it (the majority of linux dev effort actually) reminds me of the numpties that think elon musk is literally knocking out rocket ship schematics and then having the spacex engineers rush off to implement his genius insight
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.
"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."
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?
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.
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.
"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.
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
"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.
All LLM have probably as they scrape github, and there are still to this day multiple Windows XP source code live on it (I won't give links but they are pretty easy to find). And I'd bet there is way more than just windows leaks on there...
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.
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?
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!
The new graphics driver stack they're touting (capable of running unmodified modern windows display drivers) along with support for x86_64 landing may result in increased interest in the project. They've already made a lot of progress with almost no resources as is. It's truly an impressive project.
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.
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.
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)
So they don't use LLMs to help code at all?
LLMs have likely seen the leaked Windows source code lets be honest...
Of course not. You would be surprised how many developers don't even consider using an LLM in their workflow, myself included. Can't wait for this hype to end.
from what i have experienced in the last couple of weeks, it is not going to. There is a new paradigm.
Oh it will.
Firstly, neither OpenAI nor Anthropic is profitable, by a wide margin — investors are going to get impatient at some point.
Secondly, people that aren't enthusiastic about this whole thing are already experiencing something of an AI fatigue with all the AI features violently shoved into them by most software products they use. Being involuntarily subjected to slop in various online spaces can't be good either.
Thirdly, remember NFTs? So many people swore they were The Future™... until they weren't. But at least in that case it was much more obvious how stupid the whole idea is. The scale of the hype was also several orders of magnitude less.
Even if all major provides close down, it doesn't remove what's already out there. Glm / minimax / deepseek / gpt-oss may not be at the same level as current frontier, but you can download them and they're still very capable.
Crazy stupid ideas like cars with only touchscreens have still taken a decade to come in and then to get considered ill-advised even though anyone driving a car could tell how bad of an interface it is. We are still not fully out through the other side.
So while OpenAI or Anthropic are maybe not profitable today, they've got at least 5 years to figure it out. And there is already talk of inserting ads into the "chat", but hopefully that does not work!
But really, LLMs are useful (yes, sometimes only in appearance, but sometimes for real), and with that, there will continue to be investment into them until they are made profitable.
My PC can give decent code recommendations locally, not relying on anything in the cloud.
Google can run the models profitable, thanks to their custom tpus. The rest? No idea
Google and Meta can both subsidize their AI divisions with their ad money.
That too, but I think someone said that Google AI cost is true costs. Unlike others.
Fascinating. Direct link to upstream source: https://bugs.winehq.org/show_bug.cgi?id=50464#c6
You are saying that ReactOS doesn't use clean room code? Source?
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.
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.
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.
It's common anti-ReactOS slander.
I keep seeing it pop up over the years. Never substantiated.
They posted their source for their claim (which is different than yours). Click and read it.
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?".
>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.
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)
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.
I would like to see many non technical people doing that, and then their experience trying to watch Netflix, Prime, HBO, YouTube,...
Linux experience is ok, when one knows UNIX and is technically skilled.
It certainly is, because I still don't see GNU/Linux desktops on sale, other than the short lived netbooks movement.
So normal people have stores with other people that they can talk to when they have problems, or just drag their computer into the store.
With Linux it is always the relative that happens to be around, or drive in on purpose, and had to manually install the <insert favourite distro> of the day.
> I still don't see GNU/Linux desktops on sale
Oh come on. Play fair. You are perhaps the single HN commentator whose input I most respect, because so many of your opinions overlap my own...
But that is not fair or right.
GNU/Linux desktops (and laptops) on sale:
https://itsfoss.com/get-linux-laptops/
Fairly prominent Linux-only hardware vendors doing R&D:
https://system76.com/
https://www.tuxedocomputers.com/en
A pure Linux-only consumer PC on mainstream sale:
https://store.steampowered.com/steamdeck
A compatible 3rd party machine of the same design:
https://www.lenovo.com/gb/en/p/handheld/legion-go-series/leg...
And of course retail GNU/Linux machines that cost 1/4 of a cheap Apple Mac and yet have outsold them by revenue not number of units for nearly a decade now:
https://www.google.com/chromebook/shop-chromebooks/
Yes this is absolutely happening. This is a real international market with sales in the hundreds of millions of units. This is not some tiny obscure niche that can be skipped over.
You can actually get a Thinkpad X1 Carbon with Linux on Lenovo US (and many other countries) pages: https://www.lenovo.com/us/en/configurator/cto/index.html?bun...
I am sure it even applies to laptops like T and P series too.
And Dell was the pioneer of the big makes with XPS 13 (and they still seem to do them: https://www.dell.com/en-us/shop/dell-laptops/xps-13-laptop/s...).
You are so eager to reply that you haven't even read the whole comment.
> So normal people have stores with other people that they can talk to when they have problems, or just drag their computer into the store.
Which of those online stores have a physical address for the normal people to do as per my comment?
Linux forums have enough complaints about those fairly prominent Linux-only vendors, even though they are suppose to control the whole stack.
And they also fall into each having their own <favourite distro>, the other part of the comment that you missed as well.
Normal people aren't using SteamDecks for their daily computing activities.
I use Linux in various forms since 1995, and yet I am tired from trying out such alternatives, the only things that makes me consider it again is breaking the dependency on US tech, and even that isn't really happening, given how much from Linux contributions are on the pockets from US Big Tech.
> 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.
May we have a link, please?
Just Finished => https://rodyne.com/?p=3524 - I guess I'm still in the honeymoon phase, as another poster so eloquently put it.
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...
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.
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.
There's also another partial Win32 reimplementation in retrowin32, with the different goal of being a Windows emulator for the web, not for Linux or as alternate OS, at https://evmar.github.io/retrowin32/ It thus has an even more sparse path/fileapi.h implementation [2] than WINE and ReactOS. Written in Rust.
[2] https://github.com/evmar/retrowin32/blob/main/win32/dll/kern...
Yes, exactly my point - thanks for elaborating on it.
Why not use Linux with WINE and that Chicago95 theme and call it a day?
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.
it causes you physical pain to say "NDIS", too?
I think using WINE over Linux has won as the option to consider if you want to run Windows applications on a non-Windows OS without loading Windows into a VM.
> 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?
> What "modern software support" do I lack here?
There is a growing list of software that which has discontinued support for Windows 10 on the latest versions (or the Server versions thereof). I'm not sure if your example of running a ~16 year old version of SQL Server on Server 2016 demonstrates.
To my original post - if you only need to run an old version of a software package, then an old version of Windows is fine. Just because something is old, it doesn't mean that it is not useful.
Software updates?
The system runs only one app and does not serve public internet content - it does not get any updates at all, only this one app is updated every few month.
We do not need updates here?
software only ever gets better
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.
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.
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.
Interesting, I wasn't aware of the exFAT issues on MacOS. I can't remember exactly the last time I tried to use a USB drive like this, so it's possible that it might be further back than I thought and it was when NTFS didn't have write support out of the box for me on Linux.
Yes, interestingly I remember buying portable hard drives 20 years ago that were formatted as FAT or some variant (I don't remember which one exactly).
Last time I bought a portable hard drive it was formatted as NTFS.
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.
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.
"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.
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.
"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.
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".
"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.
> 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.
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.
> 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.
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!
Basically if you do the math, it means a whole generation got tired of being on the project and focused into something else, and there is no new blood to account for that.
The history of most FOSS projects after being running for a while.
> 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!
I test ReactOS every now and then on a crappy 2011-ish laptop I bought from a thrift store a while ago to test one of my projects on Windows and Linux on real hardware.
Last time was about a month ago. It's still easier to list what works than what doesn't, but I like seeing progress. Ethernet works with some random Windows driver. The integrated GPU doesn't, but installing the driver doesn't make it bsod on startup any more, so that's an improvement. I've seen people have more success with discrete GPUs. Sound card doesn't work because it's too new.
The thing with these kinds of projects that target a vast existing library of software is that the progress feels slow for a long time, but at some point there's enough compatibility for people to try to use it for real, and this is when compatibility starts improving rapidly. I feel like ReactOS is close like never before to that point. I really want it to succeed.
How stable is it? A couple years ago I tried installing it in a VM, and my experience was it would BSOD in 15 minutes whenever I tried to do anything with it.
Still not nearly stable enough to be used as a daily driver, but it's been getting a lot better lately.
I tried ReactOS a little while ago, in some ways it's closer than it feels to being acceptable as a daily driver, in others it's quite far away.
I like the idea of there being more alternatives Operating Systems that aren't just a Linux distro. Operating Systems like Haiku and ReactOS I think are great for being a direction that isn't Linux. It's not that Linux is bad, but it's a slow moving change-resistant juggernaut that isn't going to be a place where innovation will thrive.
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.
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.
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
Great project, but let's just make this year the year of the Linux Desktop!
With significant progress for Linux on the desktop this year, I propose it’s time to move the goalposts:
Haiku has gazillions of modern software and got NVIDIA drivers recently. Things are looking pretty bright for Haiku.
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.
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.
Legacy of BeOS.
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.
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)
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.
ReactOS has delt itself a massive blow by hiding so much of their progress.
The project has insisted on creating Windows Server 2003. Probably very little of the software you want to run works on Windows Server 2003. Certainly no modern web browser will.
There has been some movement in recent months though. They have a 64 bit version. They are implementing NT6 APIs. They are implementing UEFI. They are looking at WDDM drivers. The have synced with Wine 10.
If ReactOS can produce a version that can run a modern browser and maybe a half-way recent Office suite, I think a lot of people would change their mind about the potential.
If they can support modern GPU drivers, it is possible they could even gain some traction in that space. Lots of work to do but not impossible.
I sometimes daydream about becoming a billionaire and bankrolling this project to completion. Would do the world so much good.
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.
>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.
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.
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.
i don't get this take. i've been on win11 since the closed "beta" (i think, it's been a real long time). i wrote guides on how to "fix" the most common and also tricky issues with the upgrade path from win10 to win11, as well as guides from 7/8 to winten.
I have no ads or any other nonsense on my computer. i can do an OBS screenshare on discord if you'd like to verify that. https://i.imgur.com/xldGfTc.png and also https://i.imgur.com/BkO4z9T.png to deflect that claim, too -> https://i.imgur.com/59hmp45.png
however, i should note that i actually don't like windows 11 at all, but for different reasons. for the first two years or so, third party apps would crash to desktop if a folder had a literal "@"[0] in the name. That was patched on the "big patch" that a lot of people complained about, about 8-10 months ago.
Currently i have another issue, for brevity's sake, i'll just list these two. If i reboot, but don't log in, my computer will freeze. if i log in fast (within about 5 seconds of the login screen accepting input (enter, mouseclick, etc)), and get to the desktop, if i walk away, computer will freeze. My computer freezes (hard freeze, reset button/power button to fix) if it is idle. it's the silliest thing i've ever seen, surpassing even crashing with "@" in the directory name.
my fix? I run an idle game (nomad idle or idle pins) and that stops it from crashing forever. But once a month i wake up to a hard-locked computer because of an automatic update + reboot.
ugh.
[0] i think the newer windows terminal and/or the newer powershell API used to assume an "@" was something else, on powershell, it turns green and autofills stuff like "@Alias" and "@args". My assumption is they didn't sanitize it and let powershell hook everything when that's just silly. Windows 11 is silly.
Do you have an ASUS motherboard?
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
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/
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.
> What you're suggesting is as if you could load Linux kernel modules into the FreeBSD kernel.
Afaik, you partially can.
It's far from "roughly compatible with NT", but the Linux kernel does accept changes to make supporting Windows applications more efficient.
example: ntsync
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 :)
You can already use binfmt_misc to instruct the kernel to execute PE binaries with Wine.
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.)
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.
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.
TBH the Wine loader and the Win32 subsystem for NT aren't that different design wise.
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.
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.
I probably could be more clear about what I'm trying to convey. Tool A is written to manage mods for game B, and lots of mods for that game utilize library C. Tool A does not directly load or link to library C, but it does inspect the version of library C that currently exists alongside game B so that it can detect if mods depend on a newer version of it and notify the user that it needs to be updated.
I'm realizing now that I forgot an important detail in all of this: the metadata of the library existed as part of the metadata that the filesystem itself tracked rather than something in the contents of the file itself. This metadata doesn't seem to exist on Linux (which library C only supports if running via Proton rather than any native Linux version of the game). I could imagine it might be possible for this to be set as some sort of extended attribute on a Unix filesystem, but in practice it seems that the library will have this extended filesystem metadata when downloading the DLL onto a Windows machine (presumably with an NTFS filesystem) but not a Linux one.
> so that it can detect if mods depend on a newer version of it and notify the user that it needs to be updated.
The dynamic linker will literally tell you this, if you ask it.
> the metadata of the library existed as part of the metadata that the filesystem itself tracked rather than something in the contents of the file itself.
So does this metadata has anything to do with the file at all, or could I also attach it to e.g. an MP4 file? If that is the case than the difference is that the distributor for MS Windows did add the attribute and the distributor for GNU/Linux did not, it doesn't have anything to do with the platform.
EDIT:
> (which library C only supports if running via Proton rather than any native Linux version of the game
So library C isn't even an ELF shared object, but a PE/COFF DLL? Then that complaint makes even less sense.
I assume it's the ability to tag a .dll as version 0.0.0.1 or whatever (it shows up under the file name in Windows Explorer). I think company name is another one that Windows Explorer displays but there are probably a few other supported attributes as well.
Well, then the answer is that shared objects on GNU/Linux do not have a finite version, they just implement them. This is because they are expected to implement more than one version, so that you can just update the shared object, and it will still work with programs that expect to call the old ABI. You can however get the latest version. This is also what is in the filename. Note, that there are two versioning schemes: semver and libtool, they mean the same, but are notated differently. This version does not does not necessary equal the version of the project/package, APIs/ABIs can and do have their own version numbers.
I think this is just solving a different but related problem. Symbol versioning enables you to make observable changes to the behavior of some library like a libc while providing backwards compatibility by providing the old behaviors indefinitely. I've never gotten the impression that it is "prescribed" that shared objects on a Linux system don't have a specific/definite version, and I don't think that symbol versioning is necessarily appropriate for all programs, either-it just happens to be a mechanism used by glibc, and I don't think it is very common outside of glibc (could be wrong.)
On the other hand, the Windows NE/PE VERSIONINFO resource is mostly informational in nature. I think early on in the life of Windows, it was often used to determine whether or not the system library shipped by an installer was newer than the installed version, so that program installers could safely update the system libraries when necessary without accidentally overwriting new versions of things with older versions. That's just simply a problem that ELF shared objects don't try to solve, I reckon, because there aren't usually canonical binaries to install anyways, and the problem of distributing system libraries is usually left up to the OS vendor.
Actually though, there is another mechanism that Linux shared objects often use for versioning and ABI compatibility: the filename/soname. Where you might have a system library, libwacom.so.9.0.0, but then you also have symlinks to it from libwacom.so.9 and libwacom.so, and the soname is set to libwacom.so.9.
There is, of course, no specific reason why ELF binaries don't contain metadata, and you could certainly extend ELF to contain PE-style resources if you want. (I remember some attempts at this existed when I was still getting into Linux.) It may be considered "bad practice" to check the runtime version of a library or program before doing something, in many cases, but it is still relatively common practice; even though there's no standard way to do it, a lot of shared objects do export a library function that returns the runtime version number, like libpng's png_access_version_number. Since distributions patch libraries and maybe even use drop-in replacements, there is obviously no guarantee as to what this version number entails, but often it does entail a promise that the ABI should be compatible with the version that is returned. (There is obviously not necessarily a canonical "ABI" either, but in most cases if you are dealing with two completely incompatible system/compiler ABIs there isn't much that can be done anyways, so it's probably OK to ignore this case.)
So I think the most "standard" way to embed the "version" of a shared object on Linux is to export a symbol that either returns the version number or points to it, but there is no direct equivalent to the PE VERSIONINFO standard, which may be a pain when the version number would be useful for something, but the developers did not think to explicitly add it to the Linux port of their software, since it is often not used by the software itself.
But I personally wouldn't agree with the conclusion that "shared objects on GNU/Linux do not have a finite version" as a matter of course; I think the more conservative thing to say is that there is not necessarily a definite version, and there is not necessarily a "canonical" binary. In practice, though, if your copy of libSDL is an almost-unmodified build of the source tree at a given version 3.0.0, it is entirely reasonable to say that it is "definitely" libSDL 3.0.0, even though it may not refer to an exact byte-for-byte source tree or binary file.
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
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.
As far as I can tell, the nearest thing to a stated goal or mission is on their “About” page:
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.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
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.
> 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.
how no?
> 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
and hows that going these days? still a nightmare? basic functionality introduced maybe 50 years ago now, and the linux world is still working out the kinks with GUIs, probably part of the reason TUIs are becoming popular.
> moved a long ways
for completeness, "backward" is "movement"
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
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
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.
Valve has already proven that one moderately-sized corporate contributor added to your moon-shot FOSS project can get you places. (And Valve isn't anywhere near in size for the FANG+ corps you listed)
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)
There's still a ton of critical, often custom-written (read: hard to replace), corporate Windows software out there that still needs to run. If Microsoft continues their further decline of Microsoft Windows releases then a free alternative starts to look more attractive. Linux+Wine is definitely a good option today but compatibility shims add complexity and not all shops run Linux or want to.
i just want to program my old motorola radios without having to deal with virtualbox windows 98 VMs, you know? one can transcribe "motorola radio" for "bosch end mill from 1993" or "thermoplastic former from 1999"
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"
Well if that's the case, then what you're arguing for is charity. That's fine, but the upthread topic has been about business case. If we're looking at it as charity and not a business investment, then it's a much different conversation. I'd certainly love if companies did things like this and would highly applaud it.
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.
Let's become billionaires together. You bankroll ReactOS and I'll bankroll HaikuOS.
And I'll join in and bankroll AROS.
Together, we could bankroll Minix3 as well.
Ooh! Can I join in?
I'll throw in a few of the billions I made when I read this paper by "Satoshi Nakamoto" in 2009 and decided to turn over my dozen SETI@home machines to mining his imaginary internet money.
I wanna sponsor 9front. Merge in whatever we can salvage from Inferno, make a 64-bit Dis runtime, and Inferno's version of Rio which is a lot more comprehensible.
I want a VM that can run diskless Linux microVMs so I can just run a Linux binary and have it open and display a GUI in a new Equis window.
Who wants to bankroll SerenityOS?
I don't think that one wants to be bankrolled. It'd go against its spirit.
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.
I am responding to you from Ladybird. It is indeed coming along quite well.
Interestingly, if you run https://html5test.co in Ladybird, you get a score of over 500. This is better than Firefox 60.
Ladybird has detached itself from SerenityOS[0].
It is unfortunate it doesn't even run on SerenityOS anymore.
This does at least partially eliminate the appeal. e.g. SerenityOS has its own decoders for PNG, JPEG and other image formats and they are not bad, but the boring libpng, etc. were adopted instead.
It should be a net positive if not everybody uses the same implementations of everything.
0. https://ladybird.org/posts/fork/
At this point, if I magically became filthy rich, I would invest in tools that facilitate migrating from Oracle to Postgresql, including Apex.
[flagged]
Why Torvalds?
I think he/she is talking about avoiding both Windows and Linux
Yes, I am asking why avoid Linux too?
Maybe the monoculture that many kids nowadays think UNIX === Linux?
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.
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.
But it’s not a monoculture because they’re wildly different applications of the technology.
It’s also not a culture at all because it’s a kernel.
FreeRTOS is an odd one in that set.
It also has good enough POSIX support.
> Aix
This is more a limitation on the architecture - virtually nobody has power arch hanging around to play on.
As owner from Red-Hat and Linux contributor since 1998, IBM isn't certainly blocked by choice, they also have Linux for the same architecture, which Aix customers could switch to and don't.
I mean, AIX essentially _does_ not exist unless you happen to work in an enterprise or are in a similar environment that has it. It's not something to easily get your hands on – esp. not "as a kid".
Ragebaiting/hater comment
not linux, specifically linus. its just a shame hes still attached to the kernel
Okay, so why avoid Torvalds? I am not sure what part of him you find objectionable.
What would be the point of avoiding linux?
[flagged]
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.
>Have you...worked in software before?
working in it right now. and I can guarantee you anyone acting like linus better have made themselves indispensable because you wont last long lashing out like a 13 year old in emails to people. im still amazed he managed to convince a woman to like him
I don’t think he regularly lashes out to people in emails, it’s happened a small handful of times in the span of decades.
And the difference between him and your typical product manager is his email chains are public.
> it’s happened a small handful of times in the span of decades.
bit of an undersell... hes famous for it. people have left kernel dev because of it. difference between him and your typical product manager are the internet fanbois who treat him like a god. typical product managers have soft skills. typical product managers are beholden to things like polity, common courtesy etc.
Janet Jackson is famous for her nipple being broadcast on the superbowl, doesn’t mean she does it every day.
https://youtu.be/bRwleoU5JMY
kinda sums up my point. respect is earnt, and certainly not acting how he does. so hes also a hypocrite.
This video is an ad for Okta. I think you have a copy/paste error.
yea i did. im away from pc now but it was his respect is earnt speech
I’m not familiar with the speech.
what about him is supremely loathable? that he doesn't code?
I wouldn't invite Torvalds to a dinner party, but i think "supremely loathsome" is hyperbolic. He can spew vitriol and abuse at the drop of a hat, or did. Folks on here are kinda split on if "he's earned it" or "it's never ok" sort of thing.
yeah im just not that impressed with him to put up with that. same with rms. they only act like that because of the pedastal people have put them on. watch how far one lines tries to get his tongue up the other linuses backside.
https://www.youtube.com/watch?v=mfv0V1SxbNA&t=248s&pp=ygUMbG...
seeing people give linus the credit for the kernel whilst ignoring the millions of man hours of other peoples time that made also went it (the majority of linux dev effort actually) reminds me of the numpties that think elon musk is literally knocking out rocket ship schematics and then having the spacex engineers rush off to implement his genius insight
[flagged]
What if the agents were trained by leaked Microsoft code?
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.
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?
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.
"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?
> "They're also committing a crime"
But Microsoft has the rights to the code, so they do not commit a crime by broadcasting it.
That creates a loop hole. Take code, feed LLM and let it spew it again - voilà - you have perfectly legal code. Just fix bugs
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.
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!
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.
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.
"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.
> that would be next-level irony
More like end of Copilot.
I would think claude code would help make a quick dent in boosting reactos capabilities. Curious what others think.
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
If they use Copilot it is probably fair game.
How do you steal open source code? It's open.
You violate the license (such as GPL)
Copyright licenses are not one word. They are written with intent, and usually at minimum that intent is to credit the original author.
"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.
All LLM have probably as they scrape github, and there are still to this day multiple Windows XP source code live on it (I won't give links but they are pretty easy to find). And I'd bet there is way more than just windows leaks on there...
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.
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?
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!
The new graphics driver stack they're touting (capable of running unmodified modern windows display drivers) along with support for x86_64 landing may result in increased interest in the project. They've already made a lot of progress with almost no resources as is. It's truly an impressive project.
I don't think Claude code (or any LLM) is adequate for any programming task, much less something highly technical like an OS project.
I think it would be an elephant in a china shop. ReactOS doesn’t come from React (JS Library)
A cleanroom trained LLM would be needed, no?
Nah, since the LLM is a copyright removal device: https://www.quippd.com/writing/2025/12/17/AIs-unpaid-debt-ho...
Multi Processor Support!!? Cutting edge stuff
Past certain level, it seemingly was cutting edge stuff, and has been mentioned as such in comics like this: https://xkcd.com/619/