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 3 hours ago | parent | next [-]

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)

▲

SirMaster an hour ago | parent | next [-]

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

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

▲

kwanbix 2 hours ago | parent | prev [-]

You are saying that ReactOS doesn't use clean room code? Source?

▲

snovymgodym 2 hours ago | parent | next [-]

I believe the integrity of ReactOS's clean room reverse engineering has been called into question in the past when it was found that there were some header or code files with sections that matched leaked Windows Server 2003 code or something like that. Can't recall for sure though.

	▲	userulluipeste 18 minutes ago \| parent [-]
		The article mentions this: "In January 2006, concerns grew about contributors having access to leaked Windows source code and possibly using this leaked source code in their contributions. In response, Steven Edwards strengthened the project’s intellectual property policy and the project made the difficult decision to audit the existing source code and temporarily freeze contributions." The allegations have been taken seriously and since then the procedure for accepting contributions include measures to prevent such further events from occurring. If you or anyone else happen to have any plausible suspicion, then please report it to the ReactOS team, otherwise keeping alive this kind of vague and uncertain connection between some Windows code leakage and ReactOS fits the very definition of FUD: https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt Please stop.

▲

zen928 an hour ago | parent | prev [-]

They posted their source for their claim (which is different than yours). Click and read it.

	▲	card_zero an hour ago \| parent [-]
		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?".

▲

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

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

	▲	maybewhenthesun an hour ago \| parent \| next [-]
		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)
	▲	johnisgood an hour ago \| parent \| prev [-]
		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.

▲

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

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

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

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

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

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

▲

ch_123 4 hours ago | parent [-]

That's an interesting data point. I wonder if there is a hard technical reason why that logic could not be added to WINE, or if the WINE maintainers made a decision not to implement similar functionality.

	▲	tadfisher 3 hours ago \| parent [-]
		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.

▲

ch_123 4 hours ago | parent | prev [-]

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

▲

hypercube33 4 hours ago | parent [-]

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

	▲	ch_123 4 hours ago \| parent [-]
		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.