ReactOS can finally build itself
twitter.com
twitter.com
What you’d need to run any Windows program is a way to parse the PE executable format, load it into memory, and emulate or simulate W32 api calls. I’m sure there are other steps but I can’t think of many more off the top of my head.
At work, the problem is different - even if ReactOS achieved 100% bug-for-bug compatibility with Windows 10, using it on client PCs would be too painful, because every time some application misbehaved, there would be that lingering doubt if the problem is with the application itself or with the OS. And if you called some software vendor's support hotline, the moment you let it slip that you are running something that is not Windows, they would start laughing and hang up on you.
There are scenarios where I would consider a Windows 10-compatible ReactOS at work - e.g. for reviving a PC where the "native" Windows version has gone out of support, and it only needs to run MS Office or Windows' RDP client, or a browser. But in the five years I have worked as Windows admin, this has happened so rarely I doubt it would matter a lot.
If the project got to the point where ISV's support hotlines did not care whether you are running MS Windows or ReactOS, ... that would change things in a big way.
Not that that should be the primary motivation for writing it, but surely the validation won't hurt! Projects like these are the most interesting ones for me to read!
This might be motivated by Windows licensing regime. Licensing for Windows VM instances used to be super-painful, so people would try hard to avoid it.
IIRC, to run a Windows VM you were required to acquire Windows Datacenter licenses for every node capable of running that VM (at least that's what we were told). If you have a fleet of hypervisor nodes running Linux workloads, the licensing cost calculated for a single Windows VM was absolutely ridiculous.
I guess things are less insane today and you can just get a license for the guest OS, no matter whether it's running virtualized or bare metal?
A side question: Can ReactOS build and run QT5? It would make building multi-build system / multi-programming language projects much much easier.
A hell of a lot less memory and CPU intensive than Windows 10 itself...
The software running in my car is still very much Windows dependent, but it'd be pretty interesting if I could run it on ReactOS instead.
For others for whom this is new, from wikipedia[0]:
ReactOS is a free and open-source operating system for x86/x64 personal computers
intended to be binary-compatible with computer programs and device drivers made
for Windows Server 2003.
Development began in 1996, as a Windows 95 clone project, and was continued as
ReactOS in 1998, with the incremental addition of features of later Windows versions.
ReactOS has been noted as a potential open-source drop-in replacement for Windows and
for its information on undocumented Windows APIs. As formerly stated on the official
website:
> The main goal of the ReactOS project is to provide an operating system which is
> binary compatible with Windows such that people accustomed to the familiar user
> interface of Windows would find using ReactOS straightforward. The ultimate goal of
> ReactOS is to allow you to remove Windows and install ReactOS without the end user
> noticing the change.
Suddenly I felt quite old.
ReactOS doesn't use X and other middleware to help emulate high level APIs, it replaces them with replacements for Windows core libraries/APIs.
Bootstrapping here means that a programmer can fetch the ReactOS source code, compile it, and run/deploy it without relying on any 3rd party operating system. In language that usually means that the compiler can compile an improved version of itself
Everything comes from somewhere, and this is a fundamental limit on computer security.
If you care about people giving changed code back to you, you use GPL. That's what it's for.
If you use BSD, you specifically say "I don't care what you do with the code". If you want forks to give code back, use GPL.
Wouldn't it therefore be polite and align with a position on developers getting changes back to make the changes available to upstream even though you're not legally obligated to?
I think it makes sense to do that upstreamable work upstream. Unless the interest in GPL-style is less about getting changes back and more about keeping your work out of any closed source products.
I can see how, if I were a big GPL/FSF/Stallman person, I'd like to ensure everything I derive will always have future derivations be open source, even if they came from BSD roots. In that philosophy, you're almost "upgrading" the license, where the BSD/MIT/Apache folks might view it as a "downgrade".
That said, I'll still usually try to contribute it back upstream under the original license; especially if I expect to be continuing to pull code from them. I think it's worth it to maintain good-will with the upstream devs, and to reduce my burden of maintaining the patches/merging new changes.
The authors of BSD-licensed code are clearly comfortable with people adapting the code for proprietary purposes without submitting their changes, so there shouldn't really be a problem with copyleft projects doing the same. And if the authors feel otherwise, they should use a copyleft license themselves (perhaps the LGPL in a situation like this).
shouldn't those developers submit a copy of the derivative work back to the BSD-licensed project as well, just to be fair?
Downvote could = "no, I don't agree"
While I understand that some would like to run Windows software without being attached to Microsoft, Linux exists. Linux is free and superior to Windows in many ways. For the few legacy programs that need to be run on Windows- JUST RUN IT ON WINDOWS. Then use the 20 years you just got backto develop something that protects user's data or helps developing countries or actually pushes the boundaries of the field instead of redoing an archaic platform on which no growth can occur.
Again, I'm not dissing the effort that any of these devs put into the project- it's extremely impressive. There simply exists no reason for this project to have procured the funding and man-hours that is has.
This works as long as you can get the version your application is compatible with and have hardware that version of windows can run on. At some point one of these will not be possible anymore and your choice will be either Wine or ReactOS.
Also what's the state of being able to directly pass through devices to VMs on Windows? I know you can do this with USB devices, but PCI etc? Even on Linux it might be a bit tricky.
I think ReactOS will be used on old computers and laptops to run old programs and games and probably to use some old peripherals where you need the driver compatibility.