A few years ago i used it for automated builds. The GUI bits were (and i think still are, at least last time i checked it a couple of months ago) broken, but the command-line works fine and for automated builds it worked perfectly.
Running Windows builds and tests where Wine didn't work but ReactOS did?
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?
Familiarity, mainly. The tools i used were Windows binaries and i knew how to set them up under Windows (although it took a couple of tries under ReactOS due to GUI freezes, etc, but this was in a VM image that i'd later reuse as a sort-of blank state for each build - note BTW that this was like 6-7 years ago), whereas at the time i felt a bit skittish using Windows development tools under Wine.
Are you using existing ATM software that was written for Windows, or was this custom development (i.e., did you choose ReactOS over Windows, or over e.g. Linux)?
The hardware drivers for the coin counting ATM machine were provided as precompiled WinNT/CE drivers by the vendor without sources and using ReactOS was easier than reverse engineering them all.
A wrote up about this would almost certainly make the front page of HN.
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!
That's really cool and IMO a great use case for ReactOS. Sounds like a neat project. Did everything just work out of the box? If so that's pretty impressive on the part of ReactOS.
At home, I would not consider it because it is a Windows clone, and I have certain, strongly-held views on Windows. ;-)
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.
I would assume you can run WebEx because ReactOS says they have 100% binary compatibility with Windows.
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.
I don't use it, but I do have an installation on an older computer around here and I occasionally browse through the source code because what these guys managed to build is really damn impressive.
Tried it on one of my old netbooks, unfortunately it can't install from USB anymore at the moment. (I do have an old celeron 500 laptop too but it can't read CD-R)
I respect people that build large C++ software on Windows with "native" free tools. The last time for me was around 8 years ago on Vista and I had no fun - except for the sick pleasure of working on challenges. I was porting a Linux server software to Windows using free software. Going another 10 years back, I think it took me a year to compile my C++ Hello World on Windows... :D (At some point I happily found the freeware compiler from Borland.)
You don't actually need to install the bloated mess that is Visual Studio for Microsoft's C++ compiler. You can download the Build Tools separately.
You can also use Cygwin/Mingw compilers (gcc, clang) as well. Plenty of alternatives these days.
Genuinely great to hear! Congrats to every single person involved for reaching this milestone. I expect a lot more quality of life improvements to trickle down as more people opt into using it exclusively.
A side question: Can ReactOS build and run QT5? It would make building multi-build system / multi-programming language projects much much easier.
Does it work with .NET Framework 4.6.2 yet? I saw suggests you could download and install 4.5 from Microsoft and run it on ReactOS, but I think later versions tend to be more closesly built into the OS 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.
First thought when I saw "React" and "OS" together was "surely that can't be what it sounds like it might be."
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.
Every time someone puts a link to ReactOS this is always commented on, and then they get a shock when they realise that ReactOS is decades older than the Javascript React. :-)
Sure, this is called bootstrapping. It's a pretty significant milestone for operating system/programming language/or any project that serve as a platform.
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
It relies directly on itself. The dependency is recursive, and I'll grant that it needs an origin somewhere - but the same can be said for linux built on linux (and yet we do not).
So when a GPL2-licensed project takes code from a BSD-licensed project and makes a derivative work based on that, shouldn't those developers submit a copy of the derivative work back to the BSD-licensed project as well, just to be fair?
Yes, but if you've chosen GPL, it suggests you care that open source project's ability to get changes back. And code can only cross the barrier between BSD and GPL in one direction.
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.
It depends on your reasoning around the GPL and using it. It gets into the whole "permissive" vs "restrictive" debate and how people in both camps flip those terms around.
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.
BSD doesn't view downstream GPL as a downgrade. BSD philosophy is that they don't care about how consumers use the software. If BSD philosophy cared about downstream licensing, they would be GPL philosophy!
> GPL is about freedom of the source code and not people.
Not quite: GPL is about freedom of the End User to modify their software. BSD does not insist on that freedom, and from my POV, it's about freedom of the Software Author to (re-) license upstream libraries as they wish.
I don't see why, GPL doesn't require you to submit your modified GPL code back to the project, it only requires you to make the code available to others. All GPL cares about is keeping the code available and if a GPL project uses some code from a BSD-licensed project, it also makes that BSD-licensed code available as part of the GPL project (of course the entire project is now GPL, but in theory if you can rip out the BSD code without any GPL bits or modifications, you can use it under the BSD license).
That is simply not practical for anything except toy projects due to the complexity it adds, and is rarely necessary anyway. The most common case is a GPL project importing BSD licensed code with minimal adaptions, e.g. just enough to integrate the code.
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).
It doesn't appear flagged, just downvoted. Some people use downvotes to express disagreement. Without it being flagged to death, I would not assume it is offensive. I would only assume some people don't agree.
I asked a question. Where is the subject matter for "disagreeing with sentiment"? It's not like I asked an RTFM question; I'm curious if, like in the case of the story in question, when code is taken from a BSD-licensed project, if derivative work is made from it if the coders also contribute those changes back to the BSD-licensed project since there is no legal way for them to get the derivatives otherwise.
I'd like to bring up a point about ReactOS that I never see. Why does this exist? Obviously the teams behind this are incredibly talented, but will it ever be worth it to use a blatant copy of Windows that just doesn't work as well? These developers could have spent the last 20 years working on something that actually moves the free software movement forward, instead of wasting time on a pipe dream with no practical motives.
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.
It is highly useful to be able to see the source code of the platform you are developing against, for research/reference purposes. Obviously that's not possible for Windows developers, but ReactOS at least provides an example of how a compatible implementation might do things.
> For the few legacy programs that need to be run on Windows- JUST RUN IT ON WINDOWS.
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.
The performance of that wouldn't be too good. Also wouldn't work if older hardware includes an older PC.
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.
What do you think about DOSBox and FreeDOS ? people are using those projects, same as Wine.
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.
So all hospitals should just run old winxp on their crt/mrt and other vital hardware? ReactOS has a use case and it's saving all of us money. In healthcare and in production for cnc machines and the like.
