The ReactOS Team is pleased to announce the release of version 0.4.13. As with prior releases, keywords are noted representing the release itself and highlighting key improvements. In this particular case, the 0.4.13 version shows the results of significant hard work to bring improvements to the USB stack, further development on the Xbox port boot process, an Explorer File Search for the Shell module, as well as many other changes.
There’s also new work on accessibility features, and the 64 bit version has seen considerable improvements, too.
Congrats!
It seems like they are still a long way away from stability. Last month Linus Tech Tips did a bit on ReactOS and it shows just how understable the OS still is: https://www.youtube.com/watch?v=U6d7E1uKSmg
It would be one thing if it were stable and feature incomplete, but this seems like a mess, and matches my experience of a decade ago
Michael MJD also did a video about ReactOS.
https://youtu.be/k2o_1ld2bzQ
So here is my buglist for just this video:
Breaks multiboot, although it had changes that should make multibooting working properly
Doesn’t support Vesa 800×600 but needs VGA 640×480
(Doesn’t support NTFS???)
Hangs during shutdown and required restarting entirely
Keeps finding the same hardware and hangs during driver detection
So simply doesn’t work on real hardware
During a serie of simple file copy the available memory keeps dropping (filecaching makes no sense in this situation)
So currently ReactOS is only good to run virtualised and has lower software support and stability than any other Windows or Linux+Wine
ReactOS is a great hobby project, but the idea that they will ever make anything that will have a substantial marketshare or that will influence the software world is a pipe dream.
Just enjoy ReactOS for what it is: A great idea and way to waste some time on a geeky hobby
It is much more stable than it was… *much* as as long as you aren’t attempting to run software developed very late in XP SP3s life like say… firefox 52 then it mostly works.
I think the main problem they have at this point is it is still an uniprocessor OS, which XP was *always* a multi processor aware OS and designed as such… I even ran XP on a dual P2 from 1997 for awhile, not an ideal machine for it but it worked.
Amazingly it is also very ram efficient, it will boot with 56MB in a VM, and booted with more like 256MB it might have more like 50MB resident at the desktop… granted you can’t do much with only 64MB as swap doesn’t work well but it’s very close to what you would expect from XP. It does have a few issues that XP doesn’t have such as memory reclamation not working quite right in some software like FireFox (try downloading a several GB file and ram use will creep up probably due to file cache or something but it goes right back down if you pause downloads, last I checked it doens’t break if you download a file larger than memory anymore something is just still wierd with file cache or something).
Indeed. There were undoubtedly significant changes under the hood, but the user experience in essence hasn’t changed in a long time. Now, when you look at the reactos team at https://github.com/orgs/reactos/people you see how incredibly small it is, and of those 18 people only a handful seem to actively contribute. I really wonder what keeps them going. It can’t be the ambition of eventually releasing a usable product, because that seems quite unrealistic. It is probably the same as with projects such as Citizendium or GNU Hurd, just when you think that it is finally over, they pop up again…
Well from a UX standpoint nobody wants it to change, it has reached feature parity with XP in several areas like the task bar volume control and the search functionality is getting there.
Certainly nobody wants it to become the hodgepodge mess than windows 10 is. Even if it can run most windows 10 apps down the road I think the UI will continue to remain the same, themable but much like the classic UI of windows.
I think adding the search functionality to the taskbar from classic shell would make sense as this is acutally a real improvement, while keeping the menu from basically windows 95 for those that favor spacial layouts.
There are some things about the user experience that most definitely need to change, first of all the awful instability. With ReactOS, the BSOD is never far away. It quickly happens that your system is rendered unbootable and there is no easy fix short of wiping the partition and reinstalling.
Second, you want to be able to install the OS on real hardware, not just in VirtualBox. Most of my attempts to do so reproducibly fail, even though I don’t own new hardware. I am talking HW like a dated Fujitsu esprimo desktop computer and a Dell Latitude E6420, dated 2013. This I haven’t seen changing in many years.
One of the big selling points for Reactos over WINE is that you would be able to install and use proprietary drivers. This, in my experience more often than not fails.
And of course, you should offer at least basic security. A system installed on FAT with no user separation in place is a nightmare in terms of data security.
That’s what I mean by “user experience”, not so much the design of the interface.
“system stability” isn’t really a “User experience” component. Everyone wants a stable system, and it pretty much core to any product ever released. Remember that ME bombed because it was an unstable and clunky mess, not because it’s UI was particularly bad.
However, system stability in ReactOS is a much harder goal to achieve. Most of the instability is caused by either non-existant or incomplete API/ABI implementation. Since ReactOS is cloning a very complex proprietary OS from reverse engineering and public documentation, it’s a bloody miracle it’s as stable and Windows-compatible as it is.
Whilst stability is ReactOS’s main flaw, i think it’s giving them a great disservice to criticize the project just because it’s buggy. It is buggy, and it will get more buggy before it gets better. No-one is expecting you to migrate from Windows to ReactOS yet, and that day is many years into the future yet. However, it’s reassuring to know that a project exists with the goal of eventually replacing proprietary Windows.
@yahya While you have some point. However, your ignorance is showing, BTRFS has basically replaced FAT for ReactOS at this point and is a modern file system, more so even than NTFS which is getting very long in the tooth.
You can install on real hardware, There is a video on this very thread of someone doing it… you just have to have compatible hardware, you can’t expect a team of 20 to match MS’s team of at least hundreds testing hardware compatibility on machines that can’t even be bought new anymore. If you have hardware known not to work… stop expecting it to ever work and hunt hardware that does.
Your best bet is to with with plain jane hardware not a laptop. For vintage hardware a 440BX chipset is the what most emulators are emulating and you can get somewhat performant CPUs on there (for win98- early XP era). There are even people that have even gotten it working on Ryzen + x570… with a little fidding.
@cb88
I had ReactOS running on real hardware many many moons ago. It ran quite well on a PII Dell i had kicking around.
The experience wasn’t much different to running it in a VM. It crashed a lot and was barely usable, and not all the hardware worked on it.
This was a long time ago mind you, back in the 0.3 days of ReactOS
I won’t ever migrate from Windows for the simple reason that I don’t use it. Have been a Linux user since 2001. I understand that the reactos devs are a tiny bunch and I don’t blame them. Of course there are reasons why ReactOS is still in alpha state. But none of these reasons is likely to disappear in the future. So the idea that ROS will at some point in the future become a viable Windows replacement is like the belief in Jesus’ second coming. The likelihood is that it will fade into oblivion at some point in the future, but this might take a while just as with other undead projects such as citizendium and GNU Hurd
Are you kidding? *I* would love for the ux to change. I love windows 10 UX. Its the best one Microsoft has ever done.
But as said down thread, the ux is a dumb thing to focus on as the stability is terrible. I would use it with the current ux, if it were possible to do so. Sadly it is not. The LTT video rings true of all the times I’ve tried reactos. Building an operating system as complex as windows is not easily done with a volunteer army. Its basically a miracle that we have anything as good as linux is on the desktop now.
Bill Shooter of Bul,
Obviously we all have different opinions. If I could cherry pick some improvements (like task manager), I would gladly take those, but on the whole I really feel like microsoft threw away the book on UI best practices. Now rather than uniformity and standard controls for things like titlebars, scrollbars, menus, etc, you’ve got programs that are hard to identify, hard to use, interfaces that are harder to discover, and a decrease in information density apparently in a bid to satisfy touchscreen users.
In some ways it was a lot like ubuntu’s unity, you either liked it or you didn’t, haha.
Yeah, I haven’t used it recently, but it does seam that stability and compatibility with the latest software is the biggest holdup.
In a way, it’s easier to have an independent project where you make the rules. Consider that virtually no software developers nor hardware manufactures are routinely testing against reactos. With windows, due to it’s dominance, microsoft is able to put the onus on 3rd parties to achieve compatibility. For example, when a commercial product that we work on broke under windows 10, ultimately we, the 3rd party developers, spent our money and time to fix the incompatibility and not microsoft. This is a huge perk that microsoft gets for free as the defacto-monopoly. Even when windows is buggy or microsoft otherwise does a poor job of supporting an application. 3rd party developers will use their own resources to work out the problems.
Now here comes reactos, they onus is 100% on the reactos team to fix everything. If either software or hardware doesn’t work, it’s reactos’s responsibility to debug it. The reactos project is judged not on how faithfully it implements the win32s/specs, but based on how closely it mimics the exact behavior of microsoft’s binary code. It’s a subtle, yet important distinction. Maybe a work around or undocumented quirk was used on windows, and now the reactos team has to support those workarounds using it’s own time and resources.
This is why reactos struggles to keep up and I think it would be easier for them to create an independent desktop, but as a clone the whole point is to be compatible with windows.
cb88,
I agree. Heck, if reactos would have been truly production ready, microsoft would undoubtedly have lost many customers (both corporate and home users) who weren’t really sold on the direction of windows after windows 7.
Microsoft is rather fortunate that reactos is in a perpetual alpha state. On the other hand, reactos has been very fortunate microsoft hasn’t unleashed the lawyers, I don’t believe reactos would have the resources to fight a prolonged lawsuit. Everything about copyrightable APIs is bad and only hurts innovation, but realistically now that there’s a legal precedent for API copyrights from federal courts, it’s hard to see how a clone like reactos is not clearly guilty of it. It’s one of those areas where moral and legal arguments diverge quite dramatically.
This is apropos of nothing, but here goes. I just did simultaneous Qemu boots of ReactOS and Haiku live images.
System spec: AMD64X2, 2GHz, running Slackware-current. So, with X running, there’s no lack of running processes to throw a Qemu instance onto another processor (i.e. lots of RAM thrashing). And, for extra kicks, I ran both of the Qemu instances under “nice” parameters.
The ReactOS had a boot menu prompt, which required human input. I delayed launching the Haiku image by 4 seconds, to give some balance, hopefully within 2 seconds, to the images actually booting.
Basic observation: the first question asked by both OS’s was language. Haiku was definitely the first to ask.
Once I waited for ReactOS to catch up, I hit Enter quickly, on both Qemu machines, to see which one would be the first to accept “normal desktop” input. And ReactOS won that race to the finish. Within 30 seconds, ReactOS was able to respond to a Ctrl-Esc sequence, and pop up the Start menu. Over a minute later, the Haiku desktop finally started to show up with clickable items, although the desktop wasn’t yet fully formed.
Yes, there might be a difference in their performances, if I grabbed a 64-bit image for one, and 32-bit for the other. As I understand, Qemu studies emulated code, then transforms it into directly executable stuff. As the two Qemu instances proceed, their performance differences should become less and less, on any supported platform.
So here are my two distilled observations:
1. Haiku responds quickly, asking the user a question framed in a BeOS-centric GUI. That sets up the anticipation of something yummy to come, and the user will wait for it.
2. ReactOS shows a familiar “still working” progress bar for a while, something that many Windows users/admins are accustomed to. But once the user answers the question about language, ReactOS gets right to work setting up the desktop interface, icons and all, including UI responsiveness.
The ReactOS testers already know the Windows interface. The Haiku testers are yearning for the look and feel of BeOS. I think both of them, in their own way(s), will find some satisfaction.
I just want WINE for Haiku.
I haven’t tried reactos in a long time and I don’t think I’ve ever tried haiku, but regarding emulation and virtualization, qemu supports both. It depends how it’s launched and what modules are loaded prior to launching. Are you using a qemu front end?
Software emulation can be very slow. If you’re launching qemu manually at the command line, you should specify -enable-kvm with the modules loaded. Debian and I believe ubuntu have a “kvm” helper utility in the qemu-kvm package that does this automatically.
Congrats! I always love testing out new versions.