Hacker News new | past | comments | ask | show | jobs | submit login
ReactOS can finally build itself (twitter.com)
248 points by O_H_E on June 2, 2018 | hide | past | web | favorite | 78 comments

20 years and on version 0.4.8. No version number creep here :)

It did help that they've had very sporadic development until quite recently. For the longest time it was practically dead aside from a few developers.

Yup I wonder if they use any crazy processes to realize that ;)

Is anyone here using ReactOS? If so, for what purpose and how well has it served you?

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.

To what benefit, could you share?

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.

It’s free

Good question. I understand the motivation behind it and am impressed with the work done but can't imagine it being used as someone's primary os.

We use it on a Bitcoin ATM that converts spare pocket change to BTC (think Coinstar) in order to avoid licensing issues with Microsoft and Windows CE.

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.

Seems like a pretty reasonable use case. Thanks for sharing!

That is pretty interesting

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 feel like I should launch it in a VM and start using it for some of my Windows tasks just to see if I can. I wonder if it can run WebEx..

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.

Well, for that you just use WINE. ReactOS goes a lot further.

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

My greatest achievement was building ASIO (audio) driver client working with g++. At the time it was only possible with VC++.

Well, nowadays Visual Studio community edition is that native free tool.

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.

Hmmmm... if I could get Visual Studio 2015 on this then and Cygwin, it's quite likely I could build Libreoffice on it...

A hell of a lot less memory and CPU intensive than Windows 10 itself...

Well apparently Cygwin works on ReactOS: https://twitter.com/reactos/status/735141249775194112

LibreOffice is already working in ReactOS AFAIK

Sure, but can it be built on ReactOS?

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 
  > 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.
[0]: https://en.wikipedia.org/wiki/ReactOS

News to me. Thanks for clarifying. To quote Hunter S Thompson, "there is no way to describe the terror I felt." ;)

> News to me.

Suddenly I felt quite old.

I thought about putting a disclaimer, but I was like nah, they will figure it out :)

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

How is ReactOS architecturally different from Linux+WINE?

ReactOS doesn't use X and other middleware to help emulate high level APIs, it replaces them with replacements for Windows core libraries/APIs.


Is this a good thing?

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


Not true that it doesn't rely on a 3rd party operaring system; it just doesn't directly depend on a third party operating system.

Everything comes from somewhere, and this is a fundamental limit on computer security.


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

Good Thing™, or just a good thing?

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?

I never understood this sentiment.

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.

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

As a GPL/FSF/Stallman person: That's exactly it.

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!

The changes are available upstream, just not under the BSD.

That's not upstream. That's downstream to a (hypothetical) GPL fork, which is equivalent to the first downstairs GPL project from the first place.


GPL is about freedom of the source code and not people.

Not going to debate whether that makes sense with someone who's username is trolling and that just the start.

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

Why would it be fair to create a proprietary fork but not a copyleft fork?

It's certainly appreciated if you submit back code from your proprietary fork too.

Contributions are appreciated, but no one would expect you to donate the whole work "just to be fair".

There's no obligation to submit the work, if someone wants to patch in their implementation they can, but BSD doesn't obligate you to.

To be clear, the obligation on source code availability falls upon the person using (creative a derivative work out of) other GPL'd code.

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

Would someone please tell me what is so offensive about this question?

Its the product of a thousand flamewars, nobody is interested in seeing a big fight about it for the 999th time.

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.

Where is the subject matter for "disagreeing with sentiment"?

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"

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.

Old windows isos & virtual machine

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.

windows 3.11 dosent run well on any VM.

Really? I never had trouble with dosbox.

dosbox has lots of problems with windows 3.11 support, especially anything involving calls to realmode dos, or networking related.

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.

People are allowed to work on what they want, nobody cares that you think it is useless.

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.

The same argument could have been made to Linus while he “wasting time” making a clone of an existing operating system.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact