The idea is simple: Linux isn’t always the best non-Windows operating system. Windows is excellent and unbeatable for quite a few people and tasks. But neither is perfect. Almost exactly 10 years ago, a team began to search for a fix. In 1996, Linux was unusable for anyone but the most technologically ‘gifted’ and Windows 95 wasn’t anywhere near as complex as Windows today.
Originally called FreeWin95, the project had a decent idea, but terribly organized, implemented, and coded. Two years later, the dos-clone kernel was dumped, and the real project began. It was called ReactOS, and this time it was for real.
ReactOS is a 100% Open Source (mostly GPL) rewrite of the Windows Kernel. At its heart, ReactOS is an initiative to create an open-source project that is fully compatible with the all Windows NT-based drivers, applications, and services.
ReactOS is a project intended to bring together the power of open-source, the usability of Microsoft’s Windows, and most importantly the immense driver and application database available to Windows users into one operating system that can distributed free of charge and licensed at will. ReactOS is a true community-driven initiative to make a better operating system, and it strikes at the heart of the corporate OS world by appealing directly to the users of Windows, theoretically providing the very things that Microsoft advertises Windows as being excellent for – without the price tag and with greater flexibility.
But ReactOS is much more than just a GPL Windows-Clone. Rather, ReactOS takes the Windows code a step further by stripping it down to the bare minimum – leaving a kernel that is (supposedly) fast, light, clean, and powerful with a more stable user interface with greater flexibility where implementation is concerned.
This review of ReactOS will not revolve as much around usability, stability, or features as much as it does on the core concept and the development cycle. You can see NeoSmart Technologies’ ReactOS Screenshot Tour for a quick look at what there is to see.
At heart, any operating system is no more powerful or useful than its kernel allows it to be. The ReactOS kernel is the most integral part of the entire project, and it is a testimony to years of dedicated clean room design, with years of reverse engineering and code-from-scratch going to work.
The ‘goal’ for ReactOS’ final kernel is to be the Windows kernel, but with new source. This at once poses a great challenge and with it though a rather large inhibition. When a kernel for any OS is designed, generally the entire thing is completed to a limited extent, then one bit at a time, the code is perfected and the features are finished. But when you set off with a goal to mimic the features of an existing kernel and provide complete cross-compatibility, you have a problem.
ReactOS’ biggest goal, the ability to run any native Windows application on a ReactOS kernel without any loss of functionality or experience, is solely dependant on just how much of the respective kernel code has been completed. As such, ReactOS isn’t designed according to traditional means.
At the moment, ReactOS development seems to involve coding the kernel section-by-section, one stack at a time. Until a ‘section’ of the kernel is practically feature-complete & fully compatible, the rest of the kernel will, in a word, suffer. Obviously there are different teams focus on the various components of the ROS kernel, but nevertheless, it poses a serious problem for the OS as a whole until all sections are complete.
What this means for users is that a program that uses just the supported sections of code (heavily or lightly) may work great, but the rest of the Operating System will lack quite a lot of functionality, and often crashes when trying to do something that hasn’t been fully coded.
Following the Windows model, ReactOS uses a monolithic kernel (technically it’s a ‘hybrid kernel’ but that’s marketing BS. A hybrid kernel is either a microkernel or monolithic kernel under a different name). There is no need to get into yet another µkernel vs. monolithic kernel debate here, it will suffice to say that even with its monolithic kernel, the ROS core is the fastest we have seen to date, compared to Linux, Windows, and far out-performs Macintosh’s (“hybrid”) microkernel architecture.
The kernel borrows quite a lot of code from the WINE project, and implements it rather nicely. The ROS source code is well-written and not as confusing as many other lesser projects – and from there we were able to see how the WINE code was implemented and improved, and it all looks great.
ReactOS looks a lot like Windows 2000. It has (more or less) the same theme, but with better looking icons and cursors taken from Linux. But obviously that’s not all what goes into a user interface. As far as the core UI model goes, ReactOS attempts to mimic all the finer points of the Windows UI, doing a fairly good job for the most part.
As already mentioned, it looks reminiscent of Windows 2000, but it behaves a lot like it too. On boot it starts up with ROS desktop which shares the exact same functionality. It has a start menu and context menus exactly the same way Windows does – no surprises there.
We hinted earlier that ReactOS wouldn’t be graded according to our normal Operating System review scale, instead ReactOS is being scored based on the rubric it provided. In particular, ReactOS’ goal is to look and act just like Windows, and as far as that is concerned it has done a good job. ReactOS has context menus exactly where you would expect them to be, with the same exact options as those on Windows – just not all of them have anything on them yet.
Using ReactOS was a breeze, and once it’s complete we believe a normal non-geek user would be very hard-pressed to realize that it’s not Windows (“I can’t believe it’s not butter!” comes to mind). At most, the ReactOS scheme & layout is a heavily simplified and skinned version of Windows 2000’s superb layout (which was unduly bloated in Windows XP, then mutilated and buried with Vista). It provides a familiar haven for Windows users, and perfectly copies both the layout and design of Windows.
The ReactOS interface does have some differences from the standard Windows 2000 look – and they’re good signs that have implications that run quite deep. In several places the ReactOS developers have elected to make minor changes to the UI, such as changing the default font from a serif to sans-serif font, adding a button to do a function here and there, and over-all cleaning up the display.
What this means is that the ROS developers refuse to be entirely limited by what’s already there in Windows, and are willing to (even if to a very minor extent) improvise and innovate on their own. It means that ReactOS could very possibly be more than just a Windows-clone – it could actually be a 100% Windows-Compatible operating system with quite a bit more on the side to offer. It’s to early to tell now, but the user interface does seem to be heading in the right direction.
The TCP/IP stack is one of the most incomplete sections of ReactOS, seeing as most traditional applications are far from being network-aware, it seems that the ROS developers decided to (for now) only do the core requirements as needed to surf the internet and download a couple of files.
The TCP/IP stack where implemented is very inefficient, and could do with a large amount of tweaking, but all that comes later. Unfortunately, it can’t handle much of a load, and times out on the simplest of requests. ReactOS’ road-map for 1.0 contains a complete networking stack that theoretically includes support for both server- and client-side networking such as the establishing ad-hoc (workgroup) connections and joining a Windows Server 2003 domain.
From the ROS project community site and what we’ve seen in the source code, ReactOS’ network code is coming along fine, all it needs is more time and a bit more effort, but it hasn’t been hurried through nor improperly done – it will work soon enough.
At the moment ReactOS ships with only one browser: IBrowser, the ReactOS Internet Browser. It features code even more decrepit than that of IE5 or even IE4, but it seems that IBrowser is only there as proof of concept. The start menu offers a link to download and install Firefox, but the first 4 times we used it the connection would break or the data would be corrupt.
It turns out IBrowser has decent FTP capabilities, and we were able to FTP into local application FTP repository, and grab Bon Echo and Firefox 1.5 to the desktop. Firefox 1.5 installed great, and it starts up OK. As previously mentioned though, TCP communications are terribly slow and unreliable, taking several tries to get a webpage to load, and although we’re on broadband, it was no faster than 1 kbps at its fastest.
On the whole, ReactOS’ has a nice game-plan for the networking section, it just hasn’t kicked in yet. Once a stable release with a better networking stack is implemented you can be sure we’ll revisit our review and tell you what’s changed, but for now, steer clear of networking.
Seeing as ReactOS’ biggest sales point is complete and unlimited non-emulated support without emulation for all PC-compatible software, it only makes sense that it gets a section of its own. This is ReactOS’ biggest challenge.
For any other operating system, the software developers write the software to match the OS – any improper code or lack of functionality is entirely the developers’ fault. But with ReactOS, the tables are turned. ReactOS developers have the programs and they have to make them work.
The ReactOS kernel borrows heavily from the WINE project, and both projects have a very close & symbiotic relationship, borrowing and improving on one-another’s code to achieve true Windows compatibility. Wine is not an emulator. It isn’t. It’s a compatibility layer. Applications will run at full speed under WINE, and require nothing else.
Basically the compatibility layer used in ReactOS and the WINE project ‘intercepts’ calls to certain low-level operating system functions, and replaces them with its own calls that are compatible with the operating system and accomplish whatever it is that was supposed to natively. Technically speaking, any programs that run on Linux with WINE should run just as well on ReactOS, however there are quite a few exceptions.
But ReactOS is a lot more than Linux that looks like Windows and was compiled with WINE in the kernel. ReactOS is WINE. Since early 2006, WINE now runs a large percentage of standard Windows programs under fairly stable circumstances, including Microsoft Office, most productivity applications/suites, and several games. As of the time this article was published, ReactOS maintains ‘CompDB,’ its database of verified working programs on ReactOS.
Besides the standard programs run under the same context as WINE on Linux, ReactOS goes even further by aiming complete compatibility with Windows drivers and services. Most simple drivers will install without a hitch on ReactOS; including LAN network drivers, AC ’97 audio drivers, mice, keyboards, and more. Basically any drivers that come in a single INF file and don’t rely on accompanying services or applications to run seem to work great, with minimal trouble.
At the moment it seems that ReactOS’ biggest obstacle is the cross-compatibility with Windows. As an operating system it is moving along great and at a decent pace, covering ground well and reliably. But much of its compatibility relies on the WINE project – meaning that both projects will float or sink together. Unfortunately, development, milestones, and general success in the WINE project isn’t often, and it has a very long way to go before it can reach anywhere near the amount of compatibility required for ReactOS to reach beta stage.
ReactOS is a brilliant idea at heart, and it has come a long way in the past couple of years. It is integral for there to be more than one choice for alternate operating systems, since Windows isn’t the best and Linux isn’t for everyone.
In a sense, ReactOS isn’t an alternate operating system, it’s Windows under another name and brand new source code to match, but at the end of the day, ReactOS is big proof that Linux and Windows aren’t the only choices for desktop PCs, and that there is always room for more innovation. All it takes is a bit of effort.
What’s ironic is that ReactOS is now taking the same path the technological community hoped Windows 2000 would. When Microsoft released Windows 2000, it truly was a break-through operating system, and brought desktop computing to a whole new level. At the end of its run and before the release of Windows XP, the technological community expected another version of Windows that would keep the speed and lightness of Windows 2000, but add touch-ups to the layout, provide better and more powerful system management tools, and provide a better overall experience.
At the moment, ReactOS is not to be considered an operating system in its own right. As explained, the development cycle of ReactOS doesn’t allow for it to be used properly until all development is more-or-less complete. As such, it’s hard for anyone to use it as a real alternative operating system just yet, making it even difficult to review it under the same circumstances and conditions as any other operating system would be reviewed; but where development is strong ReactOS is doing great.
Windows XP may not have been that operating system, but ReactOS is poised to steal that light if it can get it’s compatibility layer fixed and it’s development times cut down enough so that it isn’t released along with Duke Nukem Forever. We wish the ReactOS team the best of luck, look forward to new features and greater compatibility in releases to come.