[ch_123]

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

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

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

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

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

[afavour]

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.

[badsectoracula]

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)

[boznz]

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

[spijdar]

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

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

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

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

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

[ch_123]

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

[pkphilip]

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.

[KellyCriterion]

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

[ch_123]

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

[Gud]

Software updates?

[thisislife2]

Sigh, I hate to agree with you. On a slight tangent, I was exploring what file system I could use safely with different OSes, so that I could keep my personal data on it and access (or add to it) from other OSes, and incredibly NTFS is the only feature rich cross-platform filesystem that works reliably on all the major OSes! None of the open source solutions - ZFS, Btrfs, Ext etc. work reliably on other OSes (many solutions to make them cross-platform or still in beta, for years now). It's the Windows effect - open source developers are putting so much effort into supporting windows tech because of it's popularity, that unknowingly they are also helping it make even more entrenched, to the detriment of better open source solutions.

[saghm]

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.

[jamesfinlayson]

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.