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.
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.
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.
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.
it is hardly anything-friendly to toss a working, expensive instrument because you can't buy a computer that will run ancient-OS-whatever anymore, or they EOL'd the OS and you can't get patches, etc.
there isn't enough diversity/competition/whatever in the market to shop for instruments on the basis of software quality. sadly.
This is a huge pet peeve of mine. Most equipment is "Windows based" today
It is "ok" if it's fully built-in, still vulnerable to network/USB exploits, though.
The main issue is when it's a USB/PCI device, and then you have to provide the computer to run it, and of course, there's probably not going to be support for the next versions.
This is usually equipment costing 5 to 6 digits
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).
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.
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.
There's little other creative or "intellectual property" that becomes non-functional after only ten years. Compared to, say, movies or photography.
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.
 I still love Linux, don't worry. :)
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?
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
How long does it take to design an OS, once you've already done one, and there are others to use as reference?
I don't think there was ever a similar moment in the history of Linux, because Linus copped the design of UNIX, and he states this freely and matter-of-factly.
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?
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?).
 : http://www.microsoft.com/education/facultyconnection/article...
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...
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 UI kernel integration intrigues me. Apparently it was done for performance reasons. If it improves performance, then that would be a legitimate reason to do it.
I guess the project is aiming to hit some critical mass where it attracts more developers and becomes self-sustaining. But does that point change with each release of Windows?
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.
Care to elaborate on the kernel-integrated UI. That seems like a weird place to break from a micro-kernel 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."
Aleksey Bragin, ReactOS Project Coordinator
But, if it were very popular how would MS respond? I'm pretty sure they wouldn't ignore it.
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 might have done ReactOS favor given the poor reception that Windows 8 has gotten. An open source OS that was a Windows 7 work-alike might see a broad market from OEMs.
This isn't a Windows-7 workalike. It's an XP "lookalike", and a poor one at that. Not dogging the project, 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?
Deploying a completely new codebase and opening yourself up to a frightening array of bugs is not really an acceptable risk, sadly.
I do enjoy the OS postings too. I hope to see more interesting info on the BeOS ports like Haiku on here too. I also loved that I could finally mess around with RiscOS and Plan9 on a raspberry pi.
But it's down now. I can't find a cache of it because I'm on mobile.
It makes me exceedingly happy to know that things like this exist in the world.
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.
ReactOS is amazing.
I've seen some great write-ups were people have done just this when investigating bugs and strange behaviours, it's rather cool!
A VM is not magic, it's emulating real hardware under there - a PIIX4 IDE controller by the look of the settings. You may have better luck picking another option in Settings under Storage.
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.
I would love to browse through the code easily - as I am sure many others would.
I think that would likely increase the likelihood that people participate.
Would it be possible to build a react OS based system that supported running Win32/64 based applications in an isolated environment on Windows or POSIX?
For instance, running a CSRSS and all child processes with a binary Registry.
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.
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?
More time on Wine and less time on this.
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 =].
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.
Microsoft puts a ton of work into keeping backwards compatibility. You can watch the YouTube Video of someone upgrading through every Windows version (well, most?). OS X users have to figure out if they need that Intel or PPC binary, or maybe just the larger universal one and call it a day. Then there's not being able to run any of their older PPC-only apps once Apple removed Rosetta from OS X.
This hasn't been an issue for years. Since Rosetta was killed off in 2011 you really don't see any UB/PPC apps around.
> OS X users have to figure out if they need that Intel or PPC binary, or maybe just the larger universal one and call it a day.
Whoa, how is life in 2006?
>Then there's not being able to run any of their older PPC-only apps once Apple removed Rosetta from OS X.
I would like an example of the app that you absolutely want to run.
> Microsoft puts a ton of work into keeping backwards compatibility.
Usually MS fails at it. Upgrading to win 8 made me furious because apps stopped working. I still remember time when I had to dual-boot win 98 and xp in order to play pre-xp games.
The only case I have ever come across of an OS X app that depends on rosetta is one of my clients upgrading to a retina MacBook Pro 15" when she ran a decade old, macro heavy, film production bidding spreadsheet in Office X. Got Snow Leopard in a VM for her and she's on her merry way.
Fun read: http://blogs.msdn.com/b/oldnewthing/archive/2003/12/23/45481...
Old versions of Photoshop. Lots of stuff. I'm so glad that practically zero businesses run Macs because Apple really does suck at backwards compatibility- and as a business programmer, I'm just glad that I don't have to deal with all that. Maybe that's why businesses don't really use them? It probably has more to do with the hardware lock-in though honestly.
Making old business software run on current Windows is a breeze. My parents even ran their old DOS accounting package on Windows for their small business - all the way up through Windows XP and then they retired altogether.