So they don't use LLMs to help code at all?

LLMs have likely seen the leaked Windows source code lets be honest...

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?

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.

> 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?

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.

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

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

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.

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.

> 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.

> 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.

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.

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.

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.

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 :)

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

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

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.

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?

Yes, I am asking why avoid Linux too?

What would be the point of avoiding linux?

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.

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

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?

That creates a loop hole. Take code, feed LLM and let it spew it again - voilà - you have perfectly legal code. Just fix bugs

"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.

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.

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...