I'm saddened a little bit to see stuff like theming has been built. I was hoping that ReactOS would stick with the Windows 2000 look and feel. I also think that with the limited resources they have, the project team would be better focusing on improving compatibility, over shiny desktop effects.
That said... I firmly believe there is a place for ReactOS. Eventually, XP will fail to run on new hardware, and when that happens a lot of great software will die also. Having ReactOS around means we can continually target new hardware, but still remain XP compatible.
Personally, I view software like I do books. We can read books written 100s of years ago, but we struggle to run 10 year old software. This has to change, else we'll endlessly repeat ourselves rewriting the same programs over and over again.
Maybe the people who did the theming stuff aren't the ones that would working on compatibility issues.
Thats usually the case in company driven projects but not necessarily in community driven open source projects.
If you would be the project lead and a person comes to you and tells you that he would like to create a newer modern theme. If you tell him/her no and that he/she should work on something completely different i wouldn't be surprised if you would never see him/her again.
I think virtual machines are the best way to keep old software around. I have one for 32 bit stuff that's over 15 years old and making something of a comeback.
Personally I'd be more interested in ReactOS as a way to run current software without microsoft, as I think they have really started behaving unacceptably with windows 10.
>I think virtual machines are the best way to keep old software around.
You're not wrong. However I think that the appeal of ReactOS (in part, and if it was more stable) is that it's currently updated and (in theory) can be secured against modern threats; so you'd be able to put it on a network -which would be masochistic to do with Server 2003 at this point.
I could also be modified to run modern Firefox, chrome, etc which 2003 cannot.
>In short I would say both (or rather, all three) have their place.
I agree with you, and I think that using WINE on Linux probably gives you more options than using ReactOS.
But in terms of what is appealing about Reactos is that (in theory) you'd have the option of modifying it, and it being (again -in theory) compatible with 2k3 server so that putting it on a networked vm could be an option.
I can't think of a use case for it, and I'm not sure that there's a compelling amount of ~17 year old hardware needing drivers -but it still has it's appeal (IMO).
But by and large you are right -most of the time it's better to either use a supported windows version or to use WINE on Linux.
> else we'll endlessly repeat ourselves rewriting the same programs over and over again
Doing this is ok. We are also rewriting the same books all over again. Knowledge is forgotten and reinvented and rediscovered. You see this in computer science and programming all the time, but also in other fields. Rather than the programs themselves, preserving the concepts and learnings is much more important. Don’t get me wrong, I think vintage computing is great, but we shouldn’t necessarily solve todays problems with it.
Knowledge being lost and reinvented is a bug, not a feature. Some lessons have been paid-for in blood (like the Therac 25, if you're looking at software development). There is value in understanding how things work and what knowledge came from specific lessons, but starting over again simply invites making the same mistakes all over. I wish we could aspire to be better than that.
No because most knowledge is tacit in nature. Things needs to be practised to be really understood. We're not living in the matrix where you can upload knowledge into your brain, you need to actually practise something to understand how it works.
Not to mention that all knowledge is contextual and dependent on its environment. Doing the same things over again in a different environment may yield different results, old failures, through tiny changes may turn out to actually work now. That's what makes constant experimentation and repetition necessary to rebuilt robust systems.
that's why markets are more effective than central planning, and why evolution is the most robust mechanism on earth. Having twenty companies build the same product is more wasteful than having one committee do it, but only competition, incremental change, and reinvention really are able to explore the entire space.
Isn't this kind of like wishing that we could apply the lessons of the fallen Roman Republic to present-day America?
It has the same problems: the historical context is imperfect and very tedious to understand (for those who even try). Reinventing the wheel is always easier, cognitively (perhaps while being vaguely cognizant of how there was a Roman Republic that fell to dictatorship that then fractured into hundreds of apocalyptic Christian fiefdoms and how there was an incident with this thing called Therac-25 [and maybe crystallizing that cognizance in proper government standards for medical software]).
Also, since the bottleneck is brain bandwidth, it's not helpful that old code is written in old languages which were formulated in a time where the most salient bottleneck was memory/processing speed.
I wish we'd just try to do better. It won't be perfect, and it'll probably never even be good. The worldview that espouses an inevitable loss of the products of human toil fills me with crushing sadness. Why bother doing anything then?
The equation is different with video games, but I generally agree with you on everything else. There isn't much value in using Word Perfect 5.1 today beyond historical preservation.
My mother edited four or five academic books on Word Perfect 5.1, and the easiest way to generate offset copy for them would be to boot it up and print them again on an HP LaserJet 4000, just like last time.
These will most likely never see another printing, granted. But generalizing across all books published this way, I'm sure this situation will actually arise in the future.
I think I wasn't very clear in my comment. I think that for things like Word Perfect 5.1, the better solution for longevity would be new open source software that recreates it's functionality in a non-hardware dependent manner. Your mother being able to open Word Perfect files in LibreOffice and print them out with the correct formatting on a modern printer would be easier (and more useful) than relying on the original hardware and software.
> Eventually, XP will fail to run on new hardware, and when that happens a lot of great software will die also. Having ReactOS around means we can continually target new hardware, but still remain XP compatible.
Unless you're talking about running it on a computer that's not networked, it's already impossible to run XP safely. But Windows is really good about backwards compatibility--what XP software is there that doesn't run on Windows 10?
agreed that most software can be made to run, but not all of them. The other issue is drivers, old drivers won't work on Windows 10 but will on reactOS
As an avid collector of vintage hardware and one who runs a YouTube channel dedicated to teaching people about how the hardware works, and how to actually use it, I can say confidently that yes, we definitely struggle.
There are a great number of games that cannot be played by most 16-bit and 8-bit console emulators. The Famicon disk system, for instance, is a real struggle to get working right.
90s machines are dying off rapidly, and hardware is becoming very very scarce. Much DOS software, for instance, requires very specific hardware timing and behaviors that is either not known about or still emulated wrongly. Worse, some emulations simply don't exist or are very difficult to get working (see also 3DFX Voodoo3 8-bit paletted textures).
2010 machines are next on the chopping block. Though tose systems may be easier to deal with hardware wise, emulation will still be a challenge.
It's really saddening if you've been following the project for years. They had some good progress back when the Russian government got interested in ReactOS, but lately they seem to just be doing webdev stuff not directly related to improving ReactOS.
To the ReactOS devs: what's the deal with the last couple years of GSOC projects? Why is there little to no work going on to improve compatibilty?
ReactOS dev here. As of today, compatibility is primarily hampered by the fact that many applications don't run under Windows XP anymore.
We don't want to change the entire OS target to something newer than NT 5.2 (XP/Server 2003) at this point. Let's better stabilize on one target than chasing a moving target forever.
This is why a versioning system is being implemented right now to allow applications targeting NT 6.x to use newer DLLs/APIs not available under Windows XP.
Check e.g. this recent PR from a few days ago for details: https://github.com/reactos/reactos/pull/3239
>To the ReactOS devs: what's the deal with the last couple years of GSOC projects? Why is there little to no work going on to improve compatibilty?
Why are you asking this here in the HN comments section? Maybe communicate directly to them through a means of contact on their page. Why "grill" them on their progress? Maybe go invest in the project yourself.
This just comes off as lazy criticisms. It's not like GSOC is your money, nor does Google "make it rain" with their stipend.
it's not just a matter of software, but also being compatible with drivers. Some old equipment that requires a specific window xp software but also a driver that doesn't work on current versions of windows.
The lack of commercial purpose of ReactOS (and Wine) and it's primary goal of interoperability, plus the fact that it doesn't really damage the value of the original Windows platform, means it's probably a very easy case of fair use.
Android isn't fair use, is a massive commercial endeavour, and has obliterated the value of mobile Java, while breaking interoperability with Java. Oracle winning the case will not be kind to stolen platforms by tech giants.
Oracle purchased Java (and MySQL) 2 years after Google made Android a huge success, specifically for litigation purposes.
It's not like Oracle designed Java, and then Google stole it. Java was supposed to be open. It was designed for this intent. Oracle bought it to destroy everything Java was supposed to be, and to prey on anyone who used Java for what it was designed to do.
One could also claim the opposite: Android has massively boosted the Java ecosystem and given it new life. So many people are learning Oracle's language now thanks to Android.
Oracle will enforce a ruling in their favor globally, but fair use doesn't exist globally.
Also it will make API patentable, and that's a very bad thing.
Just think of OpenOffice und MySQL vs. LibreOffice and MariaDB.
Oracle killed Java and now they still want money.
Next step compatibility to the JVM is a copyright violation.
That's not true though the reality is even worse. Patents have a limited term of 20 years.
If they win this case it is based on copyright law which has significantly longer terms. Currently that's valid until 70 years after the death of the content creator.
Not necessarily. It might be problematic for ReactOS to try to market their software commercially, but not for someone downloading it to use it commercially. (The latter of which is governed solely by ReactOS' own license, which takes no issue with that.)
The first thing to understand about fair use is that it applies to copyright infringement, so first, someone has to complain about the infringement and then you utilize fair use as a defense. And second, that fair use has some guidelines/rules to test whether or not fair use should apply, but they are open to some interpretation.
So it wouldn't be "illegal" to commercialize ReactOS... but it'd probably make it a lot harder for ReactOS to use fair use as a shield going forward, because it would weaken their case on one of the pillars of the fair use test.
Reverse engineering for interoperability is protected with no routes to contest if done with a clean room reimplementation. If you physically own the item and are using it you are even more protected (think fixing your own tractor).
Unfortunately I think some lower courts have some messed up decisions or companies are trying to bully others with threats of suit. For example, some medical coding systems have copyrighted codes that are claimed to require a license and you can not install a system to cooperate with these. Except... this has already been decided, and you can.
The state of the market today isn't the point: It obliterated mobile Java when Google infringed. Your question actually reinforces Oracle's claim that they were irreparably harmed by Google's infringement; there's no way to undo what has been done, and substantial damage compensation is necessary.
https://en.wikipedia.org/wiki/Fair_use#U.S._fair_use_factors is a really good read for the basic understanding of how fair use should be applied. Factor four is what we're discussing here, which the Supreme Court labeled the "most important" factor.
I don't mean "if you take away Android today would Java succeed on mobile?", I mean "if you retrospectively imagine Android never existed at all (or used a different language), how does Java do?"
My position is that it doesn't really change things all that much, with losses by Android probably mostly picked up by Apple or Symbian or webOS or Windows Phone but the trajectory to smartphones and away from J2ME stuff largely the same. The sense of how much Android actually "mattered" in this sense goes right to the "effect on the market" prong.
As for the broader case, both the copyrightability and fair use claims have been presented to the Supreme Court here. The temptation from the outside looking in is to think/hope/dread that the court will just resolve these questions once and for all, but they often prefer to resolve cases on narrower grounds, where available. Google spent a lot of time arguing for, and would be perfectly fine with, a simple remand based on the Federal Circuit's standard of review of the jury's fair use verdict.
Like you said fair use applies to copyrights. The question in the google case is if the API can actually be copywritten.
Assuming google did a perfect cleanroom implementation of parts of Java and they lose this case then it can be assumed that cleanroom implementations offer no protection against copyright claims.
A lot of non-commercial projects get shot down by companies for copyright infringements. Being non-commercial won't protect you either.
There would be no Java on smartphone with Windows Phone and Apple. Java ME was not much even before Android, Symbian overshadowed it. Mobile developers were predisposed "What? Java? Ah, Java SE, maybe ok then"
You don't need fair use for something that isn't copyright worthy like an API.
It's like claiming you copied a book if the chapter headlines are identical.
> You don't need fair use for something that isn't copyright worthy like an API.
This is true. However, bear in mind, Google argued that 1. APIs weren't copyrightable and 2. that if they were, their usage was fair. In this ten year court nightmare, they've lost fair use and of course, are likely about to lose on copyrightability.
If the Supreme Court rules for Oracle, Android is copyright-infringing, it's already failed on the fair use claim. But most non-commercial projects would still have a fairly compelling case for fair use.
Note that your "copied a book" analogy is poor for a bunch of reasons: Chapter headlines... are copyrightable. (Though the "amount of work copied" is a fair use pillar, so it's possible to lift chapter headlines fairly.) And it fails to account for the functional nature of APIs which is under debate for copyrightability.
> If the Supreme Court rules for Oracle, Android is copyright-infringing
You mean was copyright-infringing. Harmony was dropped years ago, and Android has been rebased onto Oracle's own anointed, conflict-free codebase.
And you dodged the previous question where the commenter was asking for an honest assessment of mobile Java. You responded to a question that wasn't answered by talking about being unable to undo the past—which only makes sense if they had been pressing you for an answer to what would happen if Google called it a wrap on Android today, but that wasn't the question. Which brings us to another thing.
People who complain about Google's use of the Java APIs can't seem to get their arguments straight. That includes Gosling + the subset of the Sun/Oracle fan club who sat on the stand during trial + and the perennial commenters who parrot the same talking points on Hacker News. They (you) all complain about Android ripping off Java (to the tune of a multi-billion dollar copyright infringement lawsuit), but invariably the argument comes around to the real thing that's bothering them and which they try to wrap up in a bunch of claims about infringement—and what's actually got everyone (besides the money grubbers) fuming is the intentional incompatibility—in other words, that Android didn't copy enough! You wanna try squaring that circle? Which brings us to another another thing.
Android today is now based on the "proper" codebase, as mentioned above. How? Because it's open source. And it's been open source the whole time. It uses a different open source license, but it's open source nonetheless. Which means no one actually ever needed to get Sun or Oracle's permission to do anything. All the incompatibilities of Android? There's nothing that keeps the same breaking changes from being made in our hypothetical world where Android used the blessed license instead of the one from their preferred implementation. That difference does not suddenly force the hand of Google—or anyone—to keep dragging around Oracle/Sun's failed attempt at a mobile platform and maintaining compatibility with it.* It's GPL. Modifications are allowed. So reset from the beginning, bypass the Harmony detour, and everything still plays out exactly the same. Sun's platform still starts off where it was the whole time, in the gutter, and in that vacuum, Android becomes a thing, with incompatible APIs and all. And Oracle's infringement angle now disappears completely. Even if you're deluded enough to tell yourself that the platform Sun cooked up had a real shot (it didn't) before Google "obliterated" them, the market looks the same as it does today in favor of Android. So how much of those imaginary losses are actually the result of any infringement? I'll fill in the blank: the answer is none.
In practice I don't see too many companies going full on litigious towards small players or end users- especially not Microsoft as many of their moves as of late hinge on interoperability. But it'd be certainly a worry as it'd be very much weaponized when it comes to big companies against each other, which of course will affect the end user one way or another.
We don't know. There are several substantiative questions of law and both parties' inability to give the court a clear picture of what an API is may result in the case not actually being decided.
There's two questions up in the air with the case:
1. Whether or not you can claim copyright over the name of a function plus the combination of it's input types (an "API").
2. Whether or not copying APIs can constitute fair use in the context of building a new platform using an existing language.
The first one is likely the case generally; you can claim ownership over "structure, sequence, and organization" just as well as Flame can claim ownership over a descending minor ostanato with a specific timbre. Imagine if Microsoft decided to do an end run around the GPL by copying all of Linux's header files and just writing new implementations. (Wait, isn't that how we got BSD?) This is sort of like the computer science equivalent of tracing over someone else's art, and we probably should have some protection to prevent that.
However, Java's APIs aren't just internal implementation details. They were made public to other developers specifically so that they would write programs that used them. Google argues that this makes them "methods of operation", which can't be copyrighted. If Microsoft makes Microsoft Excel accept macros from LibreOffice Calc by copying their menu bar shortcuts, that isn't protected and Microsoft is free to do that. (This has been adjudicated in court back in the 80s and is relevant precedent for the SCOTUS case.)
The fair use question is a fallback argument if the court rules that copyright ownership applies to API declarations. This requires application of a four-factors test. Notably, Google argued that Android needed to be compatible with Java APIs, and that such activities should be fair use. Oracle counters that Android's implementation of those APIs were out of date and incompatible, so that fair use shouldn't apply.
This also means that the Google/Oracle case might be ruled so narrowly that it doesn't affect WINE or ReactOS, or it could allow one and prohibit the other. After all, WINE is very narrowly focused on making Windows programs run on Linux, while ReactOS is trying to replace Windows entirely. One of the four fair use factors is the "market usurpation factor": what happens to the market for licenses if we allow people to do this under fair use and not pay for a license. If Win32 declarations can be considered copyrighted, then we could run into a situation where WINE using them to run Windows apps on Linux is NOT usurpation, but ReactOS using them to rewrite Windows IS.
Not to mention GNU was made in the same way as ReactOS, but against UNIX rather than Windows. I have no idea if the people who own the corpse of the people who bought out Novell would be able to assert a copyright claim, though, as most UNIX APIs were standardized under POSIX. Android also largely doesn't use those APIs (just the Linux kernel itself) and they'd be ironically safe from an SCO-style attack in this scenario.
Full disclosure: I am one of the developers of Ruffle (Free Software WASM/Rust Flash Player reimplementation) and I'm extremely paranoid of the project getting shut down by Adobe or HARMAN (the latter bought Adobe AIR). Ergo, I very much have material interest in the outcome of this case.
Right, but nobody is asserting an implied license claim (as far as I'm aware). The complaint is whether or not any API declaration bears copyright, and if so, whether or not you can make a fair use of such a declaration. They aren't arguing whether or not publishing said declarations implies copyright permission to use them. Granted, that would probably give the Supreme Court an easy out on this decision without having to throw out a lot of caselaw that seems to hint towards API copyright or suddenly reassign ownership of half the world's operating systems code to a handful of defunct holding companies.
API is mechanism, honestly I do not understand all that fuss.
Another API implementation is compatibility layer for authors who heavily invested in the platform. They are the reason platform is successful. Car dealerships investment is protected.
Intel asserted this right against Zilog (names, etc.) with Zilog settling by changing the names of all Z80 instructions and registers. Binary compatible but source requires translation.
Huh. The 8086 did the exact opposite: your ASM source was A-OK but they changed all the opcodes around so you had to reassemble your program. It's why CP/M was completely incompatible with the 8086 and (arguably) why Microsoft was able to edge out Digital Research on IBM PCs.
I know ReactOS has a different purpose and they aim to do a clone of Win32 API and kernel but if you feel nostalgic about Windows look and feel and wonder how a UNIX-kernel windows could be there's serenityos[0]
For readers unfamiliar with the project: it's been in alpha for 24 years, although it now targets Server 2003/XP instead of Win95 which it originally did in 1996.
My goal is to get Avid Pro Tools 7 working on bare metal ROS. Partially successful attempts thus far: install is going smoothly, but the software doesn't launch. I get the nostalgic Blue Screen of Death and usually end up re-installing the entire OS. I assume it is a driver issue since PT of that era (2007-ish) requires a dedicated audio interface (the Mbox).
But I need PT a few times a year, so I'll keep trying.
I can also state that compared to version 0.4.7 (the first one I tried, iirc), the current non-nightly build 0.4.13 ran way more smoothly for me, at least on the GUI side. Issues with mouse stalling are gone, etc.
The "EPIC WIN!" threads on the ROS forum [1, 2] are fun to follow. Based on that, the OS seems to be quite usable for a range of cases.
I also liked the "What's the point?" threads [3, 4]. My respect to the developers for taking the time and patience to explain.
All in all, I keep hoping and installing new versions. I like how clean the system feels -- or, maybe this is the case with many systems when you don't bother to add Internet connectivity. Without wifi, every OS feels quiet and calm.
True, I haven't filled a report yet; will look into this next time, probably when ROS 0.4.14 is released.
Pro Tools, at least in its early versions, tends to show its moods even on a well-tuned Windows system. So I was almost sure that it won't run in ROS out of the box. I was actually surprised to see it installing so smoothly. My guess is that the driver for the audio interface (Mbox 2) needs some attention.
Every time I’ve tried it, it falls apart within minutes of using it. You’d think after 20 years of development it might be somewhat stable but I guess not.
IMO, the is a monumental underestimation of the man-hours put into make Windows as compatible as it is, even ignoring the fact that Microsoft's engineers are/were highly skilled.
I like the ReactOS idea, but I think it will take decades to be compatible enough - and I'm even talking about enough.
If the objective was to run obsolete software, I personally had to distribute resources, I'd just do assign them to Wine. It's surely much more productive to make software compatible on a per-case basis, rather than writing a whole operating system with the objective of being compatible.
But I'm not disappointed in ReactOS because it's not fully compatible. I'm disappointed because it's not stable.
(Or was, last time I tried a couple of years ago.)
I think they should go for rock solid stable first.
Then people could build on it. It's perfect for embedded, Point-of-Sale etc where the vendor want to keep their codebase untouched but hop off the Microsoft bandwagon.
> I like the ReactOS idea, but I think it will take decades to be compatible enough - and I'm even talking about enough.
It has been under development for decades. That is more than twice the time it took to develop Windows 95. I've tried ReactOS a few times over the years, and it has never worked for me.
I know of two specific examples of ReactOS code that as of a couple years ago were identical with Windows code. There are likely other instances pointing to a non-clean-room implementation.
We've banned this account - it's not ok to mimic someone else's username like that, but it's especially not ok to add sockpuppet accounts to a thread you're already in. Doing that will get your main account banned as well, so please don't do that again.
not really a fair comparison, windows 95 had the advantage of not having to be developed from the ground up to retain perfect binary compatibility with blindows 95
If they ever get to the point of enabling audio folks to run windows audio apps with a low-latency pre-emptible kernel, they'll get big adoption in that world. Right not it's ridiculous how crappy the options are for low latency given how fast our machines are.
Does anyone try to shift audio mixing to the GPU and use the audio output of HDMI? I don't know if modern GPUs can take buffers and move them to the audio buffer without going out and back in through PCIe but it seems plausible.
Even if that was possible (no idea), I don't know that it would help. Graphics processing works on GPUs because it's a massively parallel task. With audio, increasing buffer sizes for more parallel processing will inherently increase latency. And if you're not dealing with massive buffers, then you're just shipping data over to the GPU for no good reason.
The point is more that data could be closer to where it is going to be used instead of needing the cpu to move it around at precise times. If audio is on the GPU before it is mixed, then only the mixing/filter values would need to be sent to the GPU. Maybe this would take some sort of programmable scheduling on the GPU though.
I'm not sure, but that's a different issue. The latency problem with everything except linux is we can't tell the OS to elevate our audio apps priority above the rest of the kernel, so operating system calls randomly happen and jump in front of the audio callback, hosing latency. I used to get 0.7ms latency on linux with the CPU at over 90%!!! I'm lucky to get 7ms on OSX with the CPU at 30-40%ms, sigh. It sucks so bad, it's like being allowed to use 1/4 of your computer power for real time audio. Even Windows 98 was better, you could tweak it pretty well. If you put your audio latency down to 2-3ms nowadays you can use very little of your CPU without under-runs. :-/
Well I'm no OS dev, so I will happily defer. But I was under the impression that this would not change the fact that a host audio app is running under user-space and can be pre-empted anytime? The way most pro-audio apps work is they have a callback they run once per audio vector size to fill a buffer of samples for the next buffer to pass to the audio subsystem. So if this gets knocked down the priority list, you get problems. Man I'd love to see any developments to improve that though, on an OS level we've been stalled for 20 FREAKING YEARS now. :-/
Doesn't work like this. HDMI is a separate device; also, in a thread somewhere Paul Davis of Ardour fame explains how exactly infeasible it is. (And you won't be able to do "real time" on a GPU anyway if it's not graphics.)
There's also more to audio than mixing (simple mixing was done on G3/G4, come on), when you take all the effects and filters, so to offload that reasonably you'd need an audio card with, say, an FPGA.
> Doesn't work like this. HDMI is a separate device; also, in a thread somewhere Paul Davis of Ardour fame explains how exactly infeasible it is. (And you won't be able to do "real time" on a GPU anyway if it's not graphics.)
Why? HDMI comes from the graphics card with video and audio.
Also I'm pretty sure a graphics card can handle audio effects in real time. 44k samples per second per channel is going to take a lot less than running complex shaders on 240 million pixels per second.
I've always had some admiration for ReactOS, but I also find it a bit baffling. It's been in development for so long, and it doesn't appear to be particularly stable. Granted, it's a difficult project, but I also struggle to see a valid use case for it. Why would I want to use this when I can use WINE or a virtual machine? And if it's aiming to emulate windows xp, surely this use-case gets less and less relevant over time?
Then again, the fact that it exists just makes me feel good in ways I don't completely understand.
There was an interesting talk a while ago about using ReactOS to teach low level Windows internals to Microsoft personnel. I can’t find it right now, unfortunately.
It seems like it's more for learning and hacking than it is for actually using. At least, that's the appeal to me.
I'd love to see it advance far enough that one could drop in the open source code from Microsoft in it and run it. I doubt that'll happen any time in the next 20 years, however ...
This looks cool, how can I get involved helping with this project? I'm a full stack web app developer but I've never worked on an OS before (I'm self-taught). I don't really know where to start.
My suggestion would be to download the build environment[1], read how to build it[2], try it out in a virtual machine (eg virtualbox) and then work with their jira[3].
For the moment, yes it will be a better combo, with much greater hardware support and compatibility with Windows applications/games.
ReactOS is still in alpha, it's a very unfinished operating system. On the plus side, there's a lot of low-hanging fruits to attack if you want to work on a operating system, especially if the Windows NT design intrigues you.
ReactOS is most useful for stuff that needs kernel level compatibility or comparable things. For most userland things I'd expect Wine to be smoother overall experience for now.
It's perfectly fine if this is effectively ' we did it to prove we could ' thing. I've heard of React OS before and it's been in development for such a long time.
> There is currently no other operating system that implements the kernel architecture design of MS Windows NT™ so if you are unhappy with the direction or goal of Windows there is little real alternative. ReactOS was started as a “clone” of Windows NT to alleviate this situation. To demonstrate the concept of o/s cloning, GNU/Linux is the best for comparison here: Linux was started as a “clone” of Minix and Unix, eventually going on to be a Unix replacement.
...
> Linux+Wine is never going to be a complete replacement for a full Windows system. It's not only because of Linux (despite some user-friendly Linux distributions out there) and not only because many users might find a transition to Linux/BSD difficult but it is largely due to design and implementation decisions of Linux and Wine architectures which prevent 100% compatibility.
I think ReactOS is mainly being used by hobbyists, and I doubt Microsoft would want to sue hobbyists. Little commercial or financial gain, lots of bad press.
The situation is a little bit comparable to Hercules, the IBM mainframe emulator (although not quite the same – Hercules is of course a hardware emulator, ReactOS is an operating system clone). You can use Hercules to run z/OS, but not legally, IBM only licenses z/OS to run on IBM's own hardware, or authorised proprietary emulators that cost $$$$. Thankfully though, IBM doesn't appear interested in suing hobbyists – IBM treats the hobbyist community as if they don't exist. But, try building a business on Hercules, as the company TurboHercules SAS did, and IBM's lawyers will start sending nasty letters to you.
How does this work with different versions of Windows? I know a few apps that are broken on Windows 7+ and it would be nice to have a modern OS that can run older Windows apps without having to have that actual OS in a VM.
How would recent leak of Windows XP source code help these guys? Would they be able to use some of it for reverse engineering and then create their own solutions?
Well, leaked proprietary code is not open source. Just having a peek at the leaked code would create bias for the dev, which would eventually harm the project. Noone contributing to ReactOS should take a glance at the leaked code. So the leaks hurts both MS and ReactOS, simultaneously.
That said... I firmly believe there is a place for ReactOS. Eventually, XP will fail to run on new hardware, and when that happens a lot of great software will die also. Having ReactOS around means we can continually target new hardware, but still remain XP compatible.
Personally, I view software like I do books. We can read books written 100s of years ago, but we struggle to run 10 year old software. This has to change, else we'll endlessly repeat ourselves rewriting the same programs over and over again.