I'm quite impressed that they can load graphics drivers now. Those generally seem to be arcane as heck, delving deeply into the internals of not just the applications they support (e.g. games), but the operating system itself.
Although I guess this is a more basic level, i.e. not using Nvidia drivers to run 3DMark...
Stable driver APIs (WDDM for graphics, IFS for in-kernel file systems, and others for other areas) are one of the big differences between NT's (micro-)kernel and Linux' (rather monolithic) kernel with no API commitment.
Of course, "stable" may vary. Microsoft introduced a new kernel graphics API with every OS after NT4 (XDDM, XPDM, WDDM 1.0, 1.1, 1.2, 1.3, 2.0; I wonder which ReactOS uses?) because of how significantly GPU capabilities changed over the years; while Linux changes its APIs more often than that, the changes are usually minimal enough that neither Nvidia nor AMD are complaining significantly about it. (The X¹¹ API, on the other hand…)
I've got a bunch of old games that I can no longer run on Windows 8/10. If they can get some of those running smoothly, ReactOS will see a surge in new users.
The longevity of this project is really impressive. I remember seeing it in the early days of Wine and thinking that it was a monumentally difficult challenge.
More importantly, please don't build web browsers that give nitwit web developers the option of hijacking scroll (or control keys!!) in the first place.
So I've heard the name ReactOS several times on here but never really been drawn in by the posts about it. Can someone explain why they would use it over Windows/their preferred Linux distro?
i ask out of curiosity not criticism. it seems like a cool project so I'm wondering it's benefits over existing OSes.
ReactOS is an open-source attempt to re-implement Windows. As far as I know, no one uses it in production. I know the ability to load Windows drivers has been one of their primary goals over something like WINE, which only addresses userspace (and which ReactOS leverages).
I've often thought there's a massive market for ReactOS in legacy support. There's so many platforms (ATMs, flight controllers, banking software) that use unsupported windows versions. Many of these platforms would pay an arm and a leg for ongoing support and security updates.
Excellent point. I'm contracting on a banking project currently, enhancing a C++ MFC fat client application that dates back to 1995. The client org - a UK bank - runs it on Windows XP.
Actually, I'm curious, but for slightly different reasons. Windows can still technically support other architectures than x86; if ReactOS is truly compatible (which it evidently is!) then I wonder how hard it would be for them to port the HAL layer to things like SPARC.
The project is neat, but they should not be proud of "9,000,000+ lines of code And growing!". Less is more. A security audit for example would be very slow already, given the number of lines.
Congratulations to the team :). Personally I'm really happy that someone is doing this work.. although I wish they would aim for baking in a per-app-sandbox-environment - in short order user empowerment is going to define successful computing projects (just look at the rise of Qubes OS and I bet this is still in its pre-viral state - if Apple get compromised by gov and are vocal about it then it will educate a generation of users about the importance of storing data safely!)
Kudos to the ReactOS team. I've tried the 0.3.x release about ten years ago and was a little disappointed. However, after a decade I've got a new perspective to appreciate their work.
I've kept several of my used laptops (Toshiba Satellite laptop, IBM Thinkpads, Lenovo Thinkpads, etc.) mainly for commemorative purpose. However, they can still boot and works fine with outdated OS's and extinct software. A potential very good use of them is to open my old archived documents, but I'd rather not to mess with these fragile machines.
When I checked my old archives, usually only plain texts and JPEG photos files are fine with current OS's and softwares. Nealy all my old software projects (mostly with Visual C++) no longer compile or run, or missing dependencies (DLLs, component libraries, tools, etc.). Even though I've backup most of the tools I used at that time, most of them would be a huge pain or impossible to reinstall correctly with right system dependencies.
Therefore I've come to think that the only meaningful archives are data with executables, i.e, documents with related spec, contemporary software and OS. In this aspect, a good Internet archive methodology should be like this: 1) data; 2) Fully installed and working software packages; 3) Running free OS such as Linux and ReactOS; 4) OS emulator on available hardware such as Virtualbox and KVM.
The importance of ReactOS here is that we will have a working OS on modern emulator or hardware for archiving purpose.
I'm omitting the hardware platform here, but it should be the other important aspect of archiving our knowledges.
It is an old state of things, but the data is not an executable installer (that is usually the problem, as SF has a bad habit of infect them with malware), it's a ISO image. For nightly (trunk) builds ReactOS uses its own servers, so I guess it's about the maximal bandwidth that may be of concern here especially when the new version are released, and SF may address exactly that.
Dude, this is _Hacker_ News. Who cares? This is cool!
Also: Their latest release was 0.3.17 in 2014, with the 0.4.0 release candidates coming out late last year. So it hasn't been 10 years between releases, but around 1.5 years.
ReactOs is still in alpha stage, so I don't think it's ready for everyday use. Also it has not been 10 years since the last release, it has been 10 years since the last mayor release.
Awesome, I'd love an updated (traditional) Windows 2k/XP GUI with windows and linux tools in it. :)
Interesting... I appreciate the faithful reproduction, but they've also copied the outright bad designs like the tiny environment variable window in the system control panel I always hated. ;)
Noticed they used a source-forge download instead of a torrent. :/
Yeah, and that tiny environment variable window lasted at least through Windows 7. You would think with 10s of thousands of developers, they could fix these kinds of things.
I wonder if ReactOS could target the same APIs as the upcoming Nano Server [1] in Windows Server 2016. They'd have to make it entirely 64-bit and implement some closed Microsoft protocols like WMI and DISM, but it could be a pretty cool drop-in replacement for any server apps that people decide to target to Nano Server.
On IRC the developers have mentioned (as wishful thinking) a minimal (i.e. a stripped-down) version, with only kernel, drivers, and a few other small miscellaneous parts over which dedicated applications could run. This would be something for embedded systems and other specialized machines (basically servers) unlike the all-encomprising common version of ReactOS. That having been said, it's important to understand that one of the reasons for nano is... well, OS size, which for a "normal" version got to tens of GBytes! Currently, ReactOS is (and I think that's a lot --) under 200 MB with all its bells and whistles.
I came in thinking this was something related to React Native (i.e open source OS for Android etc), but was pleasantly surprised to learn about this new OS, quite an achievement, seeing as they've been going on for 10 years.
[+] [-] mhd|10 years ago|reply
Although I guess this is a more basic level, i.e. not using Nvidia drivers to run 3DMark...
[+] [-] creshal|10 years ago|reply
Of course, "stable" may vary. Microsoft introduced a new kernel graphics API with every OS after NT4 (XDDM, XPDM, WDDM 1.0, 1.1, 1.2, 1.3, 2.0; I wonder which ReactOS uses?) because of how significantly GPU capabilities changed over the years; while Linux changes its APIs more often than that, the changes are usually minimal enough that neither Nvidia nor AMD are complaining significantly about it. (The X¹¹ API, on the other hand…)
[+] [-] m45t3r|10 years ago|reply
[+] [-] adam12|10 years ago|reply
[+] [-] mmastrac|10 years ago|reply
[+] [-] exizt88|10 years ago|reply
[+] [-] marssaxman|10 years ago|reply
[+] [-] kuschku|10 years ago|reply
[+] [-] adam12|10 years ago|reply
[+] [-] _uhtu|10 years ago|reply
i ask out of curiosity not criticism. it seems like a cool project so I'm wondering it's benefits over existing OSes.
[+] [-] TazeTSchnitzel|10 years ago|reply
[+] [-] cookiecaper|10 years ago|reply
[+] [-] pavlov|10 years ago|reply
[+] [-] pippy|10 years ago|reply
[+] [-] osullivj|10 years ago|reply
[+] [-] chris_wot|10 years ago|reply
[+] [-] andersonmvd|10 years ago|reply
[+] [-] exadeci|10 years ago|reply
So it's pretty small. http://www.wikiwand.com/en/Source_lines_of_code#/Example
[+] [-] eatonphil|10 years ago|reply
On a different topic, does this run any IIS software? Does anyone use this to run any servers?
[0] http://betanews.com/2015/04/03/south-korea-looking-to-scrap-...
[+] [-] dingdingdang|10 years ago|reply
[+] [-] donlzx|10 years ago|reply
I've kept several of my used laptops (Toshiba Satellite laptop, IBM Thinkpads, Lenovo Thinkpads, etc.) mainly for commemorative purpose. However, they can still boot and works fine with outdated OS's and extinct software. A potential very good use of them is to open my old archived documents, but I'd rather not to mess with these fragile machines.
When I checked my old archives, usually only plain texts and JPEG photos files are fine with current OS's and softwares. Nealy all my old software projects (mostly with Visual C++) no longer compile or run, or missing dependencies (DLLs, component libraries, tools, etc.). Even though I've backup most of the tools I used at that time, most of them would be a huge pain or impossible to reinstall correctly with right system dependencies.
Therefore I've come to think that the only meaningful archives are data with executables, i.e, documents with related spec, contemporary software and OS. In this aspect, a good Internet archive methodology should be like this: 1) data; 2) Fully installed and working software packages; 3) Running free OS such as Linux and ReactOS; 4) OS emulator on available hardware such as Virtualbox and KVM.
The importance of ReactOS here is that we will have a working OS on modern emulator or hardware for archiving purpose.
I'm omitting the hardware platform here, but it should be the other important aspect of archiving our knowledges.
[+] [-] arturhoo|10 years ago|reply
[+] [-] flxn|10 years ago|reply
So it should be safe again.
[+] [-] userulluipeste|10 years ago|reply
[+] [-] voltagex_|10 years ago|reply
[+] [-] flz|10 years ago|reply
I'd really like to know how many people are actually using ReactOS for another purpose than testing or developing it.
[+] [-] xenophonf|10 years ago|reply
Also: Their latest release was 0.3.17 in 2014, with the 0.4.0 release candidates coming out late last year. So it hasn't been 10 years between releases, but around 1.5 years.
[+] [-] ma2rten|10 years ago|reply
[+] [-] mixmastamyk|10 years ago|reply
Interesting... I appreciate the faithful reproduction, but they've also copied the outright bad designs like the tiny environment variable window in the system control panel I always hated. ;)
Noticed they used a source-forge download instead of a torrent. :/
[+] [-] ConceptJunkie|10 years ago|reply
[+] [-] rchowe|10 years ago|reply
[1] https://blogs.technet.microsoft.com/windowsserver/2015/04/08...
[+] [-] userulluipeste|10 years ago|reply
[+] [-] an4rchy|10 years ago|reply
[+] [-] chris_wot|10 years ago|reply
[+] [-] gosukiwi|10 years ago|reply
[+] [-] alexandre_m|10 years ago|reply
[+] [-] zackify|10 years ago|reply
[+] [-] ericmuyser|10 years ago|reply
[+] [-] chris_wot|10 years ago|reply
However... if there was a React.js OS, then I'd love to see ReactOS run on React.js OS. At that point, I'd love to see this run on ReactOS.