I definitely admire their moxie, but I have to say that it surprises me that the developers keep on working on this project year-after-year.
There was a time many years ago when I was hopeful that ReactOS would end up providing us with an open version of windows to help break their stranglehold. But considering the ways the industry has changed since the project launched in 1998, I just don't think there is much demand for an operating system like this anymore.
I would have lost motivation for this project a decade ago, but I still wish the devs the best of luck.
I don't think you're looking at the project the right way.
Think about it like FreeDOS. FreeDOS facilitates running DOS software on modern hardware, and by its open nature, it can continue to evolve and make DOS software runnable on the next generation of hardware.
Think about 10, 15, 20 years from now, and all that software written for XP. That is where ReactOS comes in. A sustainable, maintainable platform for running XP-era software on hardware systems yet to come.
At least, that's how I see the project, as someone who is neither involved nor a close follower of it.
The thing is that the WINE project currently does and will continue to provide the userspace logic to allow this. ReactOS is a heavy user of WINE, and differentiates itself in that they are recreating the most basic components of Windows, including the kernel in hopes of getting a binary-compatible driver layer.
Long-term compatibility will be provided by the WINE project. ReactOS is only necessary if you need to run Windows-specific drivers, and I don't see that being useful in 10, 15, or 20 years. We have other systems that can provide kernels, driver, and other low-level interfaces (like a basic shell) and depend on WINE in userspace to preserve compatibility.
If you'll need XP-era software in the future, you'll just run it inside a Win XP VM. Same for DOS software. Same for any software who will outlive its initial host (open-source or not) and will not be very simple to tweak and recompile (even if you could tweak and recompile it, you might choose to just run a damn VM anyway out of pure laziness or for cost/time savings...)
I think a Win XP VM could solve most people's needs, but personally I think it's fantastic that we will have several different solutions such as ReactOS, Wine, and VMs. Eventually you will run into something that won't work on your preferred solution.
It's also nice that they work on different levels. Wine let you run an legacy app on your regular OS, while a VM would give you the entire operating system to fiddle with.
That's where something like ReactOS fits in. Right now you can legally use a DOS VM running, say, FreeDOS (or an emulator, like DOSBox). There's no freely-available Windows XP equivalent. Sure, sure-- you can run Windows XP illegally w/ a volume license product key (to skirt product activation w/o modifying the product) but that's not a solution that "works" in many cases. It's technically very easy to run a Windows XP VM-- it's very challenging, legally.
Good point - but seems better to me to run a single specific, non-free app (which may or may not depend on the manufacturer's servers to function), than to add another non-free dependency to it (i.e. XP), which definitely _does_ require manufacturer's permission (i.e. activation servers) to function normally.
Why is that a good thing for the world? Serious question. Why should we enable businesses that don't want to develop modern software? Doesn't this hold back the world in terms of productivity and software quality?
Because the already-done software (e.g. XP) has serious issues; namely, even if you have obtained it legally, you can't legally install and run it without the manufacturer's explicit consent (activation servers will go down some time after EOL - after that, you can either go illegal and crack your copy, or you can't use it at all). In other words, it's timebombed. (Note that I'm not passing judgement on this - just stating the existence of such condition.)
For a home user, this is a non-issue (as "meh, just get a new OS" is also an option, due to commodity hardware); for an organization, this is big trouble (as neither "so we'll use the OS illegally, whatever" or "so we'll throw away the equipment we now can't use" is an option).
Which is something which might happen, or perhaps not, and is entirely under MS's control and discretion.
IMNSHO, this is a very unlikely scenario - the (misguided) reaction of the general public would be something like "oh look, XP had its antipiracy protection disabled by MS, which means it's now free to use; who needs Win8 anyway?" I can't imagine MS essentially undermining one of its core cash cows (Windows) anytime in the near future, especially as the "meh, just get a new computer with new Windows" line has proven effective in most cases. Also, as I have yet to see this to happen to any deprecated and truly obsolete MS product (Altair BASIC? MS-DOS? Windows 3.11?), I don't see that happening to a product which is anything but disused.
It is easy for me to imagine them doing it, if they wait enough time, that most new hardware has no XP drivers anymore, and most programs/games depend on higher versions of windows APIs, the general public will not care about the then obsolete XP, just like they do not care about DOS, or Windows 3.11 and so on.
I agree that this is an act of kindness, that can not be depended on and it is entirely under MS control when/if it will happen.
Haven't we learned a fair amount since the days of XP-specific software? I've never seen an enterprise XP application that was "done." Only shipped. Don't we have better platforms now that make it easier to write responsive and stable software?
I think ReactOS' niche is situations where replacing some legacy system would be massively expensive but for some reason you can't (or do not want to) run legacy version of Windows. It might be a small niche, but even small niches should be catered.
I'm quite amazed at the negativity and derision on this thread.
We are hackers. We do things not because they're good for business, and not because we want to be pragmatists with every decision. We don't create startups because we're Harvard MBAs (apologies to Harvard business majors), we create startups because we change the world (or try our best to, anyhow).
It's disheartening and a little saddening that after the amount of delight I had that one of my favorite open-source projects reached #1 on the homepage, discussion about how people have lost motivation for a system fully compatible with Win32 APIs ensues.
Yes, it's slow. Yes, it's laggy. Yes, it crashed on me when I tried to install any applications depending on libgtk2.0. Yes, now my VirtualBox image is corrupted and won't boot anymore. But as I started testing it seriously for the first time ever 6 hours ago, it was undoubtedly a magical experience. I was able to install Audacity, FreeBasic IDE, Notepad++, the Windows version of Firefox, 7-zip, and Bloodshed's Dev-C++. I tried to install X-Chat 2, but it would not run, and segfaulted every time I tried to. Pidgin crashed the entire system and rendered it unusable.
That unsupported GTK apps brought down the system is irrelevant, however. Installing this many Win32 applications without any hitches on an OS kernel and graphic environment developed from scratch is an incredible feat for an open-source project with very limited time and funding.
Those of you that say that this is no way forward and that more resources should be given to Wine are completely misunderstanding the purpose of this project. The purpose is to develop a completely integrated Win32 compatible system with a similar look and feel so that it can function as a drop-in replacement for Windows NT. This is far easier to get going and give to a prior Windows userbase than installing Linux, and then Wine, and trying to run NT executables with Wine is. It also benefits greatly from being a fully integrated system, which Wine is not -- applications share none of the integrated L&F and the syscalls are translated JIT, so you still feel like you're running an application on a system it wasn't designed to run on.
Some may say running a hypervisor like VirtualBox or VMWare in a seamless environment is the solution, but even that is not. First of all, you have slightly more performance overhead compared to Wine, and you still have to pay for Windows, thus rendering the entire point of a project such as Wine or ReactOS obsolete.
So yes, it's a laggy and crashy piece of work in progress, but it's come a hell of a long way since 2006 when ars reviewed it.
Words cannot express how much of an impact this OS would have had if the amount of time and resources dedicated to Linux, which is yet another UNIX clone in an age where 4-year CS majors do UNIX clones as assignments, were dedicated to ReactOS. Where might Microsoft be now if that had happened?
In essence: this is not a project to be ignored, spat on, or buried far too soon. This is a growing project with growing potential, so let's be hackers for just a moment now and help build the open future. Building an open Web, open operating systems, open energy, and when possible, an open government -- is in reach.
Let's build the future and help this little project out.
>Words cannot express how much of an impact this OS would have had if the amount of time and resources dedicated to Linux, which is yet another UNIX clone in an age where 4-year CS majors do UNIX clones as assignments, were dedicated to ReactOS.
The difference is that UNIX was designed by AT&T Bell Labs and largely standardized with POSIX. Whereas Windows was designed by the people who brought you kernel mode printer drivers and the Blue Screen of Death and a working implementation requires such gems as having to intentionally reproduce undocumented historical bugs because legacy applications rely on them.
WINE makes sense because it's transitional. It allows you to switch to a better operating system without having to abandon all vestiges of legacy software at once. It's software you like to exist but you still hope to never have to use.
Which is why a full Windows clone is silly. It's not transitional. Windows was designed by a committee in a hurry. There are plenty of good reasons not to want it completely regardless of the license it's distributed under.
> the people who brought you kernel mode printer drivers and the Blue Screen of Death
the scenarios that result in errors are totally different from the error scenarios in linux. most of the crashes in windows systems are the results of non-MSFT developers who wanted to insert code into the kernel. these kinds of errors happen on linux too, if you use binary nvidia drivers and/or vmware.
> requires such gems as having to intentionally reproduce undocumented historical bugs because legacy applications rely on them.
the "compatibility layer" is actually far more nuanced than this, and only turns on the old and bad behavior if it recognizes that it's being used by an application that requires the old and bad behavior.
> Windows was designed by a committee in a hurry.
NT was designed by the team that did VMS in a 3-month retreat to Hawaii. the design they created has lasted with very minor modifications for the last twenty years. can linux say the same?
>the scenarios that result in errors are totally different from the error scenarios in linux.
Not really. It's more like the Windows problems are a superset of the Linux problems. Most kernel panics are a result of bugs in drivers which happens just the same on Windows. Then you have all the ones based on Microsoft laziness, like getting the INACCESSIBLE_BOOT_DEVICE BSOD instead of the OS trying to load some more drivers if your disk controller died and you replaced it with a different model. And then you have the fallout of Microsoft's attempts to fix legacy software rampaging through kernel memory, which means all the legacy code that used to do that (including the ones that did something useful instead of causing a BSOD) will now just crash the application and break the legacy software, because Microsoft couldn't be bothered to get it right the first time.
> most of the crashes in windows systems are the results of non-MSFT developers who wanted to insert code into the kernel.
The difference is that Unix-like operating systems have always discouraged that behavior so it happens a lot less often (and is a lot more suspicious), and if you have something that legitimately needs to go into the Linux kernel then it generally gets merged into the main tree. But not until you fix what problems the kernel maintainers identify, and then it gets maintained by the people who know what they're doing.
> the "compatibility layer" is actually far more nuanced than this
Sounds unnecessarily complicated and undesirable.
> NT was designed by the team that did VMS in a 3-month retreat to Hawaii.
NT was never the problem. That's like saying ReactOS will be good because it's designed by smart people. The "design" is already cribbed by what came before it and the box it now has to live in, which was set out by DOS and Windows 95. Microsoft now has to live with that legacy, why should the rest of us?
> NT was designed by the team that did VMS in a 3-month retreat to Hawaii. the design they created has lasted with very minor modifications for the last twenty years. can linux say the same?
It's not necessarily a good design just because it has lasted for 20 years. It might just be that it's too expensive to change any of it. Although I should probably say that I'm not informed enough to judge
> Words cannot express how much of an impact this OS would have had if the amount of time and resources dedicated to Linux, which is yet another UNIX clone in an age where 4-year CS majors do UNIX clones as assignments, were dedicated to ReactOS. Where might Microsoft be now if that had happened?
MS does offer some of the NT kernel source under an academic license precisely for this purpose . I'm not sure if it's a response to ReactOS (does anyone know?).
AFAIK, React OS doesn't use any of Microsoft's trademarks, and they've come out of a pretty long, hard and deep audit to ensure that there wasn't any Windows code in the system.
The only recourse (other than a bullshit groundless lawsuit) that Microsoft has it to produce a better product. And considering that MS are ahead in terms of customers, API users, and paid developers... I'm pretty sure they'll remain on top for quite some times to come...
Microsoft steals ReactOS developers to become Windows kernel developers. The last two editions of Windows Internals list Alex Ionescu as co-author. Alex Ionescu was the lead ReactOS developer before Mark Russinovich stole him.
But the fatal flaw could be its monolithic nature. Linux is just a kernel. Unix, by nature, is more easily broken down into a loose collection of components that can more or less stand on their own. NT was created as a monolith by one company with tremendous resources, and it doesn't easily break down into smaller pieces. It either all works or it all doesn't. So this project seems to have a much bigger scope than Linux; it's more like Linux+GNU+X11+KDE+Wine+... all rolled into one. Unless they've figured out how to drop in chunks of NT itself and have it work. So I wish it luck, but it sounds daunting...
Yes, the project's target is, at least at beginning, a full-fledged Windows binary-compatible OS, a "monolith". Yet, when it will reach a stable version, there isn't really any obstacle, given the fact that it is an open-source project, in forking it. The ReactOS team has to provide everything now, but when others around will start providing better alternatives for the OS' components, the team might retreat in doing only what they do better, which I suppose is the NT core.
If you refereed to the NT kernel to be a monolith, then it actually is a hybrid. Other than kernel-integrated UI, its NT core is micro-kernel by design.
"The emulation subsystem which implements the Windows personality is called the Client/Server Runtime Subsystem (csrss.exe). On versions of NT prior to 4.0, this subsystem process also contained the window manager, graphics device interface and graphics device drivers. For performance reasons, however, in version 4.0 and later, these modules (which are often implemented in user mode even on monolithic systems, especially those designed without internal graphics support) run as a kernel-mode subsystem."
First yes, monolithic kernels aren't any harder than microkernels, they are actually easier. That was the main reason for Linus' choice when redesigning the Minix microkernel into monolithic Linux.
Second, yes again - UI was integrated due to performance improvement. Earlier versions of NT had microkernel architecture.
Third - well, this is a philosophical question. There are a lot of different people involved in ReactOS and I guess each of them have slightly different reasons for their involvement. "Critical mass" might be unavoidable though, considering the offering. For now Windows 2003 is targeted due to its simpler kernel architecture (NT 5.2) compared to later versions. After that will be achieved, well... we'll see.
First, ReactOS actually targets (at least for now) Windows 2003, not Windows XP. Second, you may provide a clue on the metric by which an OS is measured when you say "it's just way behind any other OS".
At least ReactOS isn't likely to incite a religious flamewar: LosethOS, the creator of TempleOS, pushes his religion on you. Ignore him: don't feed the trolls.
I _like_ it that operating system news is posted on HN. Operating systems take _forever_ to get anywhere, unless you're a multi-billion-dollar company with armies of grunts working on it.
Their goals actually are not that outdated: a non-trivial number of Fortune 500 companies continue to need Windows XP, but Microsoft is giving them the finger. Whether ReactOS can step up and fill in that need or not, wouldn't an entrepreneur want to know that this is possible?
Slightly off topic for this post, but since it is mentioned here: there is one part of that link which may appear slightly misleading without context. A twitter feed is mentioned, which ended up consisting of posts such as "and then God said", followed by some gibberish. This is actually a reference to a feature in one of his programs (a game I think) which allows one to "talk to God". When you press the button, it simply randomly spits out words. On Reddit, the author asks people repeatedly to tell him what God said to them. He's referring to this feature in his OS and obviously finds entertainment in hearing what words his program came up with for other people. This is reminiscent of fortune cookies. Strange behaviour perhaps, but not so nonsensical when placed in its context. As other people have pointed out, illness or not, this guy has managed to succeed at something highly nontrivial which most people will never do, at the pinnacle of Maslow's hierarchy of needs, namely "Pursue inner talent; creativity; fulfillment". And whether or not some of his writings may be unintelligible, his code certainly passes a strict syntactic check. I mention this here because I have met individuals with the same illness who have not managed to achieve even the bottom level of Maslow's pyramid. So it really is a credit to him that he has achieved so highly despite his illness.
FWIW, LosethOS pushes his religion on you as much as the crazy guy on the corner with a "the end is near" sign does. Half of his content seems to be generated by a Markov chain. I also suspect plenty of people here may be intrigued with the "brilliant but insane" aspect he seems to show.
He's not just trolling, that's for sure. Often he posts a mix of real content, with nonsensical God quotes in the middle of it. And he doesn't even bother about the hellban, he just keeps posting in the same accounts and has been for years.
Did you look at his site? There is stuff on there just as crazy as the stuff he posts here. The simpler explanation is that he is genuinely not well, not that somebody is pretending to be him and faking it.
He himself has admitted he's schizophrenic. You'll also notice that he continues to post on Hacker News, despite being hellbanned, and seemingly knowing that he's hellbanned. if you read said comments, it's difficult to believe they stem from a strange sense of humour.
The fun thing about this is that it is allowing diving directly into an approximate implementation of the API, without having to locate the specific Old New Thing post or other such article on an obscure function.
I've seen some great write-ups were people have done just this when investigating bugs and strange behaviours, it's rather cool!
Successful software lasts decades. Yeah, that accounting system might run on rickety Windows XP and developed on PowerBuilder 0.2 but it sustains a multi million dollar operations without a hitch.
There are tons of happy software running on old operating systems. It takes years to depreciate your software assets. It makes no sense to keep redeveloping all your software just because Ember 2.0 and Node.js (asm.js) are out.
I have kept half an eye on ReactOS for a number of years. I think it has potential when it gets to the point where it starts having Distros like Linux. I have installed Windows often enough to know how much work it is to turn a Stock windows machine into something tolerable. Things like Ninight try to serve that need as best as possible but being able to spin it into an actual distro would mean you could potentially make a Windows that was truly targeted to what users wanted intead of pushing Microsoft's technology du jour.
The goal of creating an open sourced version of Windows has always intrigued me. But I can't help but wonder if the time would be better spent working on WINE itself which at least works a whole lot better but needs more resources than trying to build a new operating system mimicking Windows.
I believe this project has been around since 1998/1999 and I admire their determination. But if you want Windows, just use Windows. What I and many other Linux users have been wanting for years is a way to run basic Windows applications within Linux.
Wine bridges this gap somewhat and for many apps it works well. My dream is to see Adobe CS6 running on Linux flawlessly to the point people can ditch Windows completely.
One of the very nicest things about the ReactOS project is their build chain -- you can download one project and have a very nice toolchain for building open source software targeting the windows platform, with very little fuss.
Consider the pain of getting a functional Cygwin system able to target non-GNU libraries.
Also, it's just plain fun to use the ReactOS desktop to look at your own desktop looking back at ReactOS ... and drag the ReactOS window down so it does the whole infinite mirror thing.
All we need is the Win32 subsystem, I see little use for other parts of the project. The two major pushed besides Windows compatibility are hardware drivers that aren't supported on Linux and supposed performance gains by removing a layer of abstraction. The later is rarely an issue and it can be solved at a later time.
The driver thing is absurd because unless the OS is 100% identical, they will not be compatible causing random crashes. Imagine how unstable your system will be if you are running a driver that wasn't tested on your system? I don't want buggy drivers form 2003 on my computer! If this was my requirement I would install Windows XP.
This project has the functionality of a wrapper for Wine, why not just wrap Wine into something more useful like a Linux?
Win32 is the ugliest part of Windows, to me. I like seeing the lower level "native" NT bits being re-implemented. (I think NT itself is a pretty elegant OS. I'd love to see a "distribution" of NT with a POSIX personality and no Win32.)
Oddly enough, as someone who was fluent in SoftICE, I almost cringed when NT surpassed Win32. I love Windows 7 now...the interface is second to none and I don't have to reinstall the OS every 3 months, but sometimes I miss the days where if a program didn't do what I wanted, I could have it grovelling at my feet within 30 minutes.
This was great for either sniffing out serial numbers or getting unlimited health in games. I know there are good NT debuggers around nowadays, but nothing really beats loading in at ring0 on Win32 =].
This is weird statement. The Win32 subsystem is what most people encounter as Windows and unless you try hard your software will target that. The Native API includes calls like throwing a bluescreen and halting OS execution.
> The driver thing is absurd because unless the OS is 100% identical, they will not be compatible causing random crashes. Imagine how unstable your system will be if you are running a driver that wasn't tested on your system? I don't want buggy drivers form 2003 on my computer! If this was my requirement I would install Windows XP.
How I see it, it's not really intended for general purpose use. Instead imagine a situation where you have some very expensive equipment connected to a PC and the only drivers available for that equipment are for Win2k. Then imagine that old PC breaking down and the replacement isn't compatible with Win2k. But you could plop in ReactOS and continue using that equipment with Win2k driver. And because it's open-source you can just kludge it until that proprietary driver works just like you want.