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

My understanding is that NT is more of a hybrid kernel than a true microkernel. Is that still true or has it moved more towards a micro kernel in recent years? I remember reading an interesting article about the influence of Mach on NT, but that they ended up having to put a lot of stuff (including the Executive) into kernel space for performance.

It's hybrid indeed, but far more modular. The driver code is running in kernel mode to avoid costly switching from kernel to user mode and back. This imposed requirements on driver code quality as it is critical for the entire system, but it can be replaced (with another version) as a component. For a monolithic kernel like Linux changing a driver like the one for video card means recompiling the entire thing.

> For a monolithic kernel like Linux changing a driver like the one for video card means recompiling the entire thing.

Not necessarily, Linux has loadable kernel modules as well and most drivers are built that way and loaded on demand. The Nvidia proprietary drivers for instance are a loadable kernel module, though they are tied to a specific kernel version. BSD does basically the same thing.

There are somewhat more subtle differences: Not only are modules not tied to a particular kernel, they are also (to varying degrees) isolated against the rest of the kernel.

WDDM in particular can recover from a driver crash and restart hardware and driver (which you can trivially demonstrate on an AMD card by waiting for an hour or two…), while Linux (and Windows XP with its older driver model, and probably BSDs) will panic the entire kernel on problems like this.

Yeah, that's what I thought with NT, which is that drivers are much more isolated. If I understand it correctly drivers can still cause a kernel panic, but Microsoft requires that signed drivers pass a formal verification, which has greatly cut down on blue screens. I'm just an armchair observer though, so I'm not an expert.

I was always greatly impressed by Windows' recent ability to recover from something like a display driver crash with hardly a hiccup. That's pretty impressive voodoo.

AFAIK, Windows has a very defined model for display drivers (WDDM: https://en.wikipedia.org/wiki/Windows_Display_Driver_Model) so it should be a matter of implementing the WDDM specification + bugs.

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.

With its NTVDM, ReactOS can actually play DOS games out-of-the-box, which is something modern (64-bit) Windows releases can't do.

Even though ReactOS' current main architecture is 32-bit x86, I would hope that the NTVDM gets ported over to the 64-bit version, which would be quite awesome.

Something I rather enjoy about Wine is that it supports 16-, 32-, and 64-bit applications all from the same prefix. Quite a nice advantage over Windows :)

You can copy ntvdm.exe from reactos ro windows and start using it right now. Even in 64 bit system.

This doesn't work for me (Windows 7 x64). Am I supposed to do something else besides copying the file?

The OP says that it works on x64 too.

As a hardcore gamer, gamedev and old games lover, I am finding sadder and sadder that certain games are getting increasingly forgotten by everyone, and noone even remember they are in dire need of tools to make them work.

It is the games from Windows 98 and XP era, many used some combination of GDI and DDraw that doesn't work at all on new Windows versions, DDraw emulation is mostly broken, and pity you if the game used DDrawEx (it was to mix DDraw with D3D).

For example I am currently trying to figure a way to play SimCity 4 properly, the game is too demanding to run in an emulator, so some kind of native implementation is needed, but it also uses DDrawEx, that is very poorly supported in all OSes except Windows 98, ME and XP (it doesn't work in XP contemporary NTs either).

I think this is the kind of games the OP is happy ReactOS maybe will implement... because for DOS games, DosBox is more than enough already in most cases (there are some exceptions, like Noctis that is incredibly CPU-intensive and runs at 3 FPS in DosBox).

Get Linux, run Sim City 4 in WINE :) Apparently works very nicely in latest WINE versions:

https://appdb.winehq.org/objectManager.php?sClass=version&iI...

Even newer games can be tricky - try Assassin's Creed I and II on Windows 10 and you'll struggle.

Get WineD3D's DDraw.dll with the needed dependencies and it will run.

You could try running Windows 98 under VirtualBox.

Those old operating systems are quite a pain in VirtualBox. Qemu does a much better job, in this case. VirtualBox's emulated hardware is too new for some systems, and Win98/Win95 flood the CPU during idle time (because that's how things worked back then), causing the input processing from the VM to lag significantly.

Regardless though, this would legally require you to acquire a licensed copy of Windows 98, which will only become harder and harder down the road. Unless Microsoft decides to "free" all legacy software at some point.

ReactOS and WINE solve this problem in a different way, by providing open source solutions that everyone can use, copy and archive without cost or consequence.

I think you missed the part where I wrote that some games, like SimCity 4, need excessive processor performance to be emulated?

Or VirtualBox can sum several cores and simulate a single faster CPU?

Have you tried to use DosBox ? I was able to run DOS era games and applications just fine on Windows 7/8.1/10 with DosBox.

Not just on Windows. DOSBox works literally everywhere.

On Android, even. Pretty cool to be able to use a smartphone to replay the classics :) Of the various ports, I found this one to be most performant, stable and configurable: https://play.google.com/store/apps/details?id=com.fishstix.d...

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.

Please don't hijack scroll on web pages.

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.

I use the web to build applications and very much need to set scroll points and capture key input thank you very much.

I'd really rather you didn't do that, since it makes using the web as the web so annoying. I think we really need to fork the web and let "browsers" specialize in one direction while the "client/server application platforms" go another.

I’m using the page on Firefox, with a laptop (with touchpad) and it works perfectly normal – now I’m interested what I’m missing? What’s it like?

I'm using Firefox 44.0.2 on Linux with a mouse and it appears to be fine too...

The scrolling seems fine to me.

They're using kinetic/smooth scrolling, which is included in theme they're using from Okler. If you look in the JS, you'll see:

  Plugin Name: 	smoothScroll for jQuery.
  Written by: 	Okler Themes - (http://www.okler.net)

And here's a forum where a customer asks to disable it:

http://www.okler.net/forums/topic/disable-scrolling-effect/

Another offender:

https://www.astralgameservers.com/

Inertial/kinetic scrolling is incredibly frustrating when implemented in JS. On my Mac, sure, if I swipe my fingers and let go, I expect the OS to emulate a free-spinning scroll wheel. But when it's emulated in JS, there's no way for the code to know whether I lifted my fingers, so it defaults to making the page skid around uncontrollably, when I intend to quickly swipe - while keeping my fingers down at the end - to go to a precise offset in the page.

It's visually a cute a effect, but I have no idea how anyone thinks that it makes for anything other than an utterly infuriating user experience.

There's something non-standard going on with it for me. It snaps to certain sections at the bottom and I can't swipe to navigate back and forth like I usually do.

exizt88 is correct. I can't swipe to go back a page. And if I swipe up, the page seems to want to continue scrolling at the same speed, it feels different and not fluent.

I am using Windows 8, chrome, Microsoft mouse with scrollwheel.

The scrolling is absolutely broken, it is jumping around all over the place, and made the page impossible to read.

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.

It's free, it's open-source, it's Windows-like, and it can run Windows applications. It's very lightweight and has a live CD.

Those are all good of course, but how long before it is significantly better (faster, more compatible, easier) than e.g. doing the same with Wine? is it already?

It doesn't do the same thing. ReactOS is a full reimplementation, including the Windows kernel. You can boot your system with it. One of the main goals is to provide for the loading of Windows drivers. ReactOS and WINE share code for userspace to the extent possible.

I see. Is the reason it wants to use Windows drivers that it hopes to get better performance in comparison to Wine or VMs?

The hardware vendors used to pour more effort into the Windows drivers than into the other ones. (I think it's not about being unfair or against FSF ideology, it was just that the market so far was still heavily in the Windows' courtyard, so they were kind of forced to give in and have the other platforms only on lower priority.)

I would think a big reason is that the version of Windows that ReactOS is based on hasn't been supported in about a decade or more, and there are people who could be perfectly-well served by it.

Windows' biggest competitor in the past decade or more has always been the previous version of Windows. The early versions of NT were incredibly stable and did a great job while using 1/100th of the memory and disk space of what Windows requires now.

ReactOS uses some of WINE's code:

http://www.reactos.org/wiki/WINE

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

It's a binary-compatible Windows clone. If you don't need to run Win32 binaries, you probably don't want ReactOS.

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.

uh, Windows does support other architectures than x86: currently, it supports x86, x64, ARM and ARM64. (and as Windows Server 2008 R2 is still supported, the IA64 version is also still suppored)

Yeah, I know. But it will never support SPARC. Or anything other than the architectures you mention. Windows can still support these other architectures, I'd love to see it happen. ReactOS might be the way that it's made to occur.

Definitely. Microsoft doesn't see commercial value in supporting, eg, a SPARC version, especially when it won't run existing x86 apps. It'd be a huge lost cost in development just to make one.

ReactOS isn't driven by the same market forces. Anybody with enough determination can port it to SPARC and fly away :)

Windows NT 4 supported x86, MIPS, PowerPC, and Alpha. All but one were dropped with Windows 2000... and it wasn't until XP that non-x86 returned (initially IA-64, and x86_64 in three more years after initial release).

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.

Windows XP had 45 Millions lines of code, the Linux kernel has 20 Millions lines of code.

So it's pretty small. http://www.wikiwand.com/en/Source_lines_of_code#/Example

Does this run internet explorer? This would be interesting for Koreans wanting something easier than Windows but still needing online payments [0].

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

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.

Genuine question: is there a reason for the downloads to be hosted at source forge?

Two weeks ago the new owner of SourceForge terminated the controversial "DevShare" program. https://sourceforge.net/blog/sourceforge-acquisition-and-fut...

So it should be safe again.

Nah. Reputation is hard to build, but eeeeasy to destroy; saying "trust us that you can trust us again" doesn't magically revert it to previous version (at least a suspicion remains of "...until we have another Wonderful Idea at an indeterminate point in the future").

I wasn't aware of that, thanks for sharing.

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.

> (that is usually the problem, as SF has a bad habit of infect them with malware)

SF is under new ownership as of last week, and they've already removed the most problematic behavior. If you find malware you should let them know, as the new ownership seems much more on the ball.

There's nowhere else to easily host "large" binaries for free.

Seems like a legitimate case for BitTorrent? It's always my go-to download method for Linux ISOs.

Running a VPS / web server for an initial (web) seed isn't free - and then you're relying on popularity to keep the files available. I should check whether the Internet Archive will host things.

I've grabbed 5 year old tarballs off SourceForge before. I know there are 5+ year old torrents that still have peers but that's an exception to the rule.

10 years since the previous release ...

I'd really like to know how many people are actually using ReactOS for another purpose than testing or developing it.

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.

While usually I'd agree with your snarky comment, I am genuinely curious about this too. It's not some yetanother.js hacked together in a night but years (decades!) of man hours.

What's pushing them and stopping from giving up?

I've done similar projects myself. The thing that pushes people like us is that it's fun and challenging work! There really doesn't have to be anything else.

I believe the Russian Government has considered/is giving them support so that probably helps. Otherwise, a passion for the project and love of the craft most likely.

It's almost all a volunteer effort. They get the odd donation from time to time, and they had a crowdfunding campaign, but they really don't get that much money.

i think once you get a critical mass of developers, the shared enthusiasm for the project is motivation enough to keep it going.

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.

[1] https://blogs.technet.microsoft.com/windowsserver/2015/04/08...

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.

I really wish they had pointers to the source commits in their bug tracker. That would be fascinating :-)

Very interesting project. I'll make sure to test it when they release 1.0 :)

At this pace it'll be your grandchildren that will test it.

They're having a heated race with GNU Hurd to be the first on your grandson's desktop!

They can enjoy the 1.0 version of Dwarf Fortress while they're at it

Unlike GNU Hurd, most of the OS is actually working. Including GUI.

Except it seems to be progressing exponentially, not linearly.

2116: Year Of The ReactOS Desktop!

Always a little disappointed when I remember ReactOS does not mean React.js OS.

> ReactOS has been around for a lot longer than React.js.

It'll probably still be around long after React.js has faded into obscurity, too ;)