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.
The Kernel
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.
The Interface
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.
Networking
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.
Compatibility
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.
Conclusion
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.
Just out of curiosity, have you tried running it on actual hardware, or just within an emulator? I’ve been playing around with it since around 0.2.3, and I’ve actually found it to be pretty usable on my DeskPro EP (PIII-650, 64MB) considering that it’s still in the very early phases of development.
Anyway, probably entirely off-topic, but figured I may as well mention anyway 😉
Both.
VMware Workstation for the most part, but when we did the driver tests we loaded it on several computers (new and old). This is seriously the fastest OS we’ve ever seen.
Smile, you’re on Slashdot 😀
http://it.slashdot.org/article.pl?sid=06/07/13/1423245
Great review, two thumbs up 🙂
“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 even Macintosh?s own (?hybrid?) microkernel.”
My opinion that a hybrid kernel is a viable and technically decent concept aside, isn’t one of the main drawbacks of the microkernel the severe performance penalty induced by the excessive message passing and context switching? Your statement is basically equivalent to saying “Even despite its huge V8 engine, this car is quite fast.”…
Awaiting your reply,
Tore Bekkedal
Thanks alot for your review. I’ve never heard of ReactOS before and find this whole thing very fascinating. Excellent review!
Hey Matt, it was our pleasure!
That’s the only problem with these ‘alternate OSes,’ by nature, no one has heard of them for the most part 🙂
@Tore: That bit about Mac OS X is a typographical error and has been tended to – not sure how that got past our editors, but yeah, µkernels are definitely far slower than monolithic kernels. Thanks for the heads-up.
On page two of ReactOS Reviewed
s/defendant/dependant/
Don’t contradict yourself too badly, you only stated that it’s the fastest OS with the slowest TCP/IP stack in the industry… I wish you had something to contribute to readers, but I couldn’t find it.
If you want to see what speed is all about you got to check AROS @:
http://www.aros.org/download.php
In about 19Mb you got an OS you can play aroun either trough Qemu/Vmware or burning the ISO
ReactOS doesn0t stand a chance (speed wise that is 😉
:$
Choose either stable or nightly build, it’s the fastest OS alive 😀
@Swoolley:
Read page 2 again, it explains a lot about the kernel architecture and design and why it’s good in some places and terrible in others. But it’s fast 😀
Numbers please: how much memory does it take compared to NT2/W2k/XP on with the same application? What about benchmarks? What percentage of WIN32 API is implemented? How fast does it boot? How fast is disk IO? Graphics (2D)? CPU intensive tasks?
Hello Eractos,
Unfortunately every benchmarking utility we tried either wouldn’t install or would BSOD – the OS simply isn’t ready for this.
On the first page, we note that this review of ReactOS will not be comprable to that of any other OS, simply because of the development model and still-alpha stage production.
As far as the WIN32 API goes, I don’t think anyone has the hard numbers, but feel free to check the WINE site for info – it’s the same rewritten core.
Check out their website… They have all the numbers you need…
I was hoping for a more in-depth review, but I liked it. the speed claims of the kernel sounds fishy when you say you weren’t able to benchmark. likewise, like someone else said, current memory usage would be a good pointer as to how much it will eventually use.
@pixie:
the main reason for Aros speed is that it lacks memory protection (just like the good old AmigaOS), I’ve had enough ‘Guru Meditations’ in my life thank you very much.
Hello DownLow,
If you would post or email about what you would have liked to see we’ll definitely take that into account for future reviews or maybe even touch this one up.
However, if it’s the numbers you’re looking for, we’re not doing that for ReactOS. We feel it would be excessively unfair to subject ReactOS to numbers and statistics it isn’t ready for. Suffice to say, ReactOS is unstable and not yet compatible. But it’s on it’s way.
We probably will do a review on Aros soon enough, but like DownLow mentions, it doesn’t put any weight on the memory. That may be great for embedded devices and operating systems, but for desktop platforms it just won’t cut it. ReactOS however uses the same memory settings and configurations as Windows – just a bit more wisely with far-lighter code.
My only question is, why do you always say “we” when referring to your site. As far as I can tell, you are the only person that does anything for this site at all. Do you have multiple personalities or something like that where you can say “we” and actually have it referring to multiple persons, or what is going on. If there are actually more people associated and “working” for your site or company, whatever you want to call it, then why don’t they post anything? If there really are others at this site, can they crawl out of the woodwork and at least introduce themselves or something as seeing “we” everywhere but never seeing more than just one person over and over and over seems really dumb
We actually do have a review team, you’re welcome to join if you are intersted.
Most reviews are written by one person, but the research is a team effort. We’re changing the structuring at NeoSmart Technologies, so you should be seeing more and more of our wonderful team 🙂
Hopefully, all reviewers and editors would use the journalistic “we” when referring to the perspective of the writer in the body of an article. As referred to above, the author is usually presenting the collected work of research assistants, librarians/archivists, reporters, investigators, type-setters (site managers?), editors, et al. to produce each article. Also, the views therein, except as specifically excepted, are generally accepted as representing those of the journalistic entity as a whole.
I do not know how this applies to bloggers, or whether one should distinguish between those bloggers retained and endorsed by the site versus those who freelance periapetetically (sp?). My belief is if we strive for the higher standard, any errors will be more kindly regarded and hopefully more gently corrected.
Thank you for your attention.
LJH “Tigerdown”
just tried it…very disappointed. it is incredibly unstable, so much so it is not usable.
example: installed firefox, tried to download and save a zip to desktop. 1st attempt seemed not to save a file, second attempt led to BSOD!!!
i don’t see what the difficulty is here. all they need to do is build the kernel and ensure usermode ntdll.dll has 100% compatibility with windows. Then you could use MS binaries for all other system dll that are effectively wrappers around ntdll.dll (excluding sockets).
Wow, MS binaries, wow. How about even reusing ntdll.dll from Windows? 😉
Tibbar, if they used MS binaries, they were cheating.
hi,
can i know few specs in brief about reactOS.
1) system structure- simple,layered,microkernel..
2)Process Management – single/multitask..
3) type of process – process, thread…etc
4) allocation – fixed,segmentation, paging..
5) page replacement – LRU, FIFO..
6) Addressing
tq
[quote comment=”3249″]
Wow, MS binaries, wow. How about even reusing ntdll.dll from Windows? 😉
Tibbar, if they used MS binaries, they were cheating.[/quote]
Not also that, it’d be illegal.
10 years and still in alpha, sheesh 🙁
That has to be a record!, LOL
Bad ass!!! ReactOS rules. I can’t wait until it’s done!
Unfortunately, “ReactOS” is not a really marketable name. The project should reconsider the name and allow a period of one to two years for a title transition.
Don’t make it sound geeky. Including OS in the name of the project is usually a bad idea.
Make it roll off the tongue, or use a more common word like “windows”
I like ReactOS, and I think that the idea is interesting, but a few lessons in marketing have also taught me a few things.
One of the posters above asks why ReactOS does not make use of Windows binaries, followed by a reply which suggests this would be cheating. However, this idea makes a lot of sense.
I have often wondered why the project did not start by basing itself on actual MS Windows, then replacing the DLL’s one by one. After all, many if not most people who would like to eventually use ReactOS have a legitimate copy of Windows. Successive REACTOS releases could have been installed on top of Windows, each release replacing more of the proprietary code each time with open source code.
In the meantime, there would always be a fully functional (barring bugs) Windows system on the PC.
Perhaps its possible that the teams decision to make use of WINE has meant that low level compativility with Windows has had to be sacrificed, and has prevented this incremental development concept.
One issue that strikes me is the inevitable blending of Open SOurce with proprietary code. After all the main point of cloning Windows is that the OS will be able to run Windows apps. But most Windows applications are proprietary, and a significant propertion of those are Microsoft applications cush as Office, IE, Media Player, etc.
Is ReactOS intending to produce open source clones of the applications too ? I would guess not. I am not sure of what benefit it will be to run Firefox on REACTOS rather than run it on Liinux.
So one must ask just what is the benefit of being able to run expensive proprietary programs on a free OS, when nearly all PC’s come supplied with an OS (Windows) that runs these applications?
Of course there are some GPL’d applications for Windows – so this part certainly makes sense.
To me the most appealing aspect of ReactOS versus Linux would be that you can use Windows drivers for your hardware. However, this advantage is becoming less of an issue as Linux now often has more up to date hardware support than Windows anyway.
Of course I have no objection in prinicple to the guys cloning Windows – why not if they want to. But I still think Linux has more of a future.
Perhaps a project could be started that allows Linux to use Windows drivers?
yeah and what about viruses…..will they come with a gpl?
It’s certainly promising. What I’d really like to see is a small fast Windows with DirectX or OpenGL for a power-gaming rig or Media Center (Windows MCE and Vista certainly aren’t it, that’s for sure.) I agree that Linux is an excellent OS and certainly works well in some applications. But the reality is that most vendors create for Windows first and Linux second or third (if at all).
I’m not sure that the real value of alternative OS’s is simply cost. It’s also about control, removal of proprietary bloatware and performance. Again, all things that Linux brings to the table, but Linux doesn’t address he current “windows-centric” state of the market.
I think that a lot of the promise here is along the lines of Linux. There was a lot of open development in the Unix world. But the real commercial push came when there was an open source kernel that gained popularity. With that, all of the various development streams started to converge and we didn’t have a bunch of disconnected tool development for proprietary OSs (conceptually). We’re still in that disconnected tools stage with Windows. But I seriously think that a good stable Kernel may do for Windows what Linux did for Unix. With the Linux convergence, we gained an entire open environment that comes in a variety of flavours and can be customized by anyone willing to take 10 minutes to learn how to use a package management tool. I’d certainly like to see that in Windows one day.
Can’t they just make a version that works??? What is all the fuss about, when you can’t even use it as effectively as MS XP or something?
bleh
Good Luck and more blessings to the ReactOS team! May it rain millions of dollars on your efforts, and may the big names to back you.
There is a serious need for a Windows compatible operating system that is fast and limits itself to operating the system.
There is too much crud, WMP, IE, DRM, etc., built into Windows that for the most common computer applications–corporate desktops–Windows just doesn’t really work anymore.
Add to that the complexity of licensing, and there will be millions, if not billions of potential users of ReactOS.
I’ve been watching this project for a while now and you guys are doing quite well.
It’s far from complete and you have alot of problems to iron out, but I admire your prowess.
I have to say that to compete with Linux is a tall order, since you can run alot of Windows software on it already as you well know from the Wine project.
Just to make the point: Linux is compatible with an immense amount of hardware and software and is happily competing for the top spot with Vista as you will see in alot of blogs on Vista vs Linux.
Linux is compatible with more hardware than XP since you will usually have to install 3rd party drivers into XP whereas they will be already in the Linux kernel.
I would advise against attempting to compete for Linux users since, like me, Linux users use it because of the wealth of differences with Windows.
Principly the security aspect which is due the to inherent bad design of Windows, which you will be copying.
Also Windows to me represents dumbing down the potential of computing in general.
Still, good luck and I look forward to 0.4.
Graham.
Fascinating! A complete clone of the Windows OS, only to be better! I’m a Linux convert, but I am excited by the idea of running commercial Windows programs on a free, open-source OS. I mean seriously, someone ought to have done it already, after all the virus fiasco with XP and now the ridiculously expensive and unbelievably resource-hogging Vista.
I applaud the developers for making such bold, ambitious goals. Keep it up man!
stolennomenclature, there’s no need to run lots of proprietary Windows software on it. There are good, functional equivalents to a lot of MS software–with one major exception being the operating system itself.
Office – OpenOffice, AbiWord (both work stably in Windows now)
Internet Explorer – Firefox (arguably better anyway)
Media Player – VLC
Windows’ (laughably bad) built-in CD burner – CDBurnerXP Pro
nice very nice 🙂
I have tried it on a real machine but it was a pain in the neck to install (the install disk doesn’t work. neither does the live cd) first i had to convert the virtual hard disk to raw format then copy the partition over with parted. it doesnt like my usb mouse or serial mice though
hi, i like you review of reactos, maybe its time to do another review,a lot of things have improved in the last 12 months.
I am really interested in ReactOS and look forward to possibly replacing Windows XP with it on my computers some day. However, I am somewhat skeptical about whether it can achieve 100% compatibility with Windows applications.
For one thing, I’ve heard that the Windows API is not totally documented, and in some cases, the documentation may be incorrect, which happens sometimes when the code is updated but the documentation is not. I seem to remember reading that this is a problem for the Wine developers. Also, I’ve heard that there may be special “hidden” APIs within Windows that Microsoft uses for their own apps to make them run faster or work better with Windows than another company’s app. That was one of the arguments I heard back when the antitrust case against Microsoft was in full swing.
Another problem is the fact that the ReactOS team will always be a little behind in keeping up with the changes that Microsoft puts out in their service packs, patches, etc.. If Microsoft makes any significant additions to Windows with their service packs, the ReactOS team would have to take some time to release the equivalent changes in ReactOS.
I am excited about ReactOS though. It looks like it has come along fairly well, and it would be nice to have a GPL alternative to Windows so that if I build my own PC, I won’t have to spend an arm and a leg on an OS to install on it. If I had more experience with OS development, I might even join the ReactOS team and contribute to it.
This is the perfect time to be working on a clone of Windows. When Windows XP is frozen at SP2 and Windows Vista sinks like a stone… OK ReactOS has been a work in progress for a while 🙂 But Rome wasn’t built in a day 🙂
Problem is reverse engineering the entire Windows OS would frankly drive me insane…
I presume most of the people posting crap about ReactOS couldn’t even reverse engineer ONE PROPRIETARY Windows hardware device driver… You bunch of brainless lameos… The OS is at the alpha stage and there isn’t hundreds of paid programmers working on it like M$…
Imagine having a decent OS for gaming on that wouldn’t get kicked off on-line servers for not being the ‘correct’ Windows. Or an OS that supported Windows drivers that Linux doesn’t (a lot from what I keep finding when I try to install the latest distros – bloody hardware/chipset manufacturers)… An OS that fixes real bugs rather than constantly have security fixes released (bullshit)
ReactOS team rock on!!
Bob Wya
Its funny, a few years ago I remember being mocked for mentioning something like this, rewriting windows to make it more efficient, etc, look what happened. Its somewhere on slash dot, I’ll have to look
Well, they’ll probably still poke fun at it on Slashdot anyway – if it’s not Linux, it’s not worthy 😛
But all joking aside, ReactOS has actually been “in the works” since the early 90s – it’s only recently getting the attention it deserves.
It’s really unfortunate that it’s been in development for so long. Being in alpha for 11 years is one of those stigmas that’s going to haunt ReactOS. It’s a remarkable achievement. But it’s really a shame that some corporate monolith didn’t jump on board to throw some cash and resources at it. There could have been a ton of money in consulting, support and enterprise licensing while promoting a “free” alternative for the masses.
Just out of curiosity, is ReactOS going to jump on the Vista bandwagon and try to build the Vista kernel changes? (UMDF, ASLR, all of the UAC and session 0 isolation, etc.) I don’t know that anything would be lost by ignoring the changes, apart from compatibility. But I’m just curious how ReactOS is going to position itself now that Microsoft is getting more aggressive and scheduling more frequent kernel-level changes.
Finally, is there anyone looking at ReactOS as a thin/thick-client OS? With desktop virtualization becoming a hot topic in the enterprise, I would think that a sleek fast OS that could run a VNC or RDP client would be pretty well received. If it could stream and run Softgrid or Thinstall images as well, it would certainly be in a good place. Since Microsoft’s VECD licensing is so restrictive (ie: expensive as hell for large mixed deployments), there’s a pretty nice niche there that could be exploited. Add ReactOS on a bootable CF card to an old desktop and get a brand new high-speed thin-client with ultra-low maintenance costs. Linux and Wine has been a popular alternative, but it’s certainly higher maintenance and a larger footprint. Plus it has the “Linux Geek” stigma in the enterprise. A lot of executives roll their eyes and groan whenever you mention Linux because of the wild promises that they’ve been hearing for years. ReactOS would be something “new” without any of the baggage. It would be a pretty nice coup to see ReactOS as an embedded OS in a client appliance.
Well, that certainly is an interesting idea.
But look at it like this: if you’re going to be using it to run virtualized operating systems, why all the bother with MS-compatibilties in the first place? After all, a highly stripped-down Linux distribution with VMware or Xen installed will do the same thing.
However, running Windows-based (probably built for Windows Embedded) thin-clients… that sounds like an idea that could be expanded on!
I don’t know about the Vista compatibility, but I’ll certainly do my best to find out and post back 🙂
>But look at it like this: if you’re going to be using it to run virtualized operating systems, why all the bother with MS-compatibilties in the first place? After all, a highly stripped-down Linux distribution with VMware or Xen installed will do the same thing.
Politics mostly. A “Windows compatible” operating system is an easier sell than “Switch to Linux”.
VMWare and Xen are certainly viable options for some situations. But the footprint and hardware requirements are relatively large. If you can run Windows in VMWare, you can certainly run it natively right on the client.
If an app virtualization client like Thinstall or Softgrid could be made to work, you could package up your existing Windows apps so that there’s no loss in functionality at the client. You’d reduce your IT support costs since the apps are all isolated in packages, centralized on a server and there’s no issue with people farting around with configurations locally. You also do away with a lot of compatibility and integration testing since the packages are somewhat isolated from the client OS and each other. The advantage over a VMWare solution is that you aren’t packaging the entire OS and operating environment with each app. Only the bare minimum to run the app is included and ReactOS continues to provides the core services. You can do the same with Linux, Wine and a lot of brute-force, but it’s multiple layers of emulation and abstraction where something like ReactOS would be a single layer (or maybe 2).
As for the embedded options, I just realized that I have a few “appliances” that I’ve built using Win2K. (It’s faster than WinXP and recovers better from brute force power on/off situations) I’ll have to see if ReactOS would be a viable replacement. I could also see ReactOS as a viable option where WindowsCE is being used today.
Maybe I just look at it differently than the dissenters. I don’t see the future of it as a replacement for gamers or power users. The real power and viability is where you need core Windows compatibility, speed and a small footprint. The geek running 64-bit with 8GB of RAM, dual-SLI and a 1TB disk array to speed up level loads isn’t going to be the beneficiary. Someone in a call center that runs one app or a Windows-based cash register in Walmart or the guy running a dedicate MAME system on a Centrino with 256MB of RAM are far more likely candidates.
It’s pretty exciting and I hope that the recent attention gets ReactOS some funding and supporters. There’s a lot of potential. I just hope that the timing is right to really exploit it.
reactOS always just gives me a Blue screen when I try to emulate it in VirtualPC or VirtualBox
The Qemu emulation works, and I’m waaay to cheap to buy VMWare
Well, both VirtualBox and VirtualPC aren’t the “optimal” virtualization softwares. The only one’s I’d dare recommend would be VMware (Workstation – which is paid; and Server – which is *free*) and Parallels *only if* you have a good reason not to use VMware.
I’ve actually used this before on one of my spare machines, booted into 64mb of ram where most other OS’s failed to do so. The absolute best feature of this OS is not the open source, free, ect. but that it is so much more damn efficient. Kind of makes me wonder why the microsoft corporation doesnt notice public unrest and try to develop a more effecient and STABLE OS instead of slapping us with something like Vista. I made a point of using vista for about a month, i found that not only did everything become slower and lag, but that i was getting hit left and right by viruses. Luckily i thought enough to install nod32. Linux ftw.
if only im the only one using this computer, i would install it ASAP. ^^ unfortunately, my comp is shared with my rather computer-illiterate sister, leaving me with windows to help her out with her favorite windows commercial apps.
damn… ^^
thank you grub bootloader keeping winxp.. ^^
Well pitched review, all questions asked in the comments section pretty much appear in the ReactOS FAQ section & introduction…
Most users (esp. notebook users) will benefit from the faster speed and lighter-weight rewrites. The idea of combining the ReactOS kernel & dlls ontop of a windows install is legally/security-wise you’d need 2 windows licences for 2 installs on the same machine as the hybrid would probably be too unstable to use as your main OS. There is the issue of windows core file protection. I suppose nlite gets around this so it is possible. The main problem is they can’t do anything (else) to give MS reason to attack them. I believe if ReactOS is ever completed (hmm?!) microsoft will attempt to out-date the project by releasing a new OS/windows version that will run legacy win apps / hardware slower than newer hardware / apps. The new hardware / apps won’t run on older windows version (much like the leap from 98′ to NT/2000/XP/Vista). The chances of this happening before completion is very high…BUT WHO CARES? If reactos can beat MS to it, or complete quick enough so hardware manufacturers support ReactOS instead of the new MS Condos then MS would be dead in the water…Once ReactOS is written keeping the kernel uptodate with MS Windows & CPU improvements will be possible at the current development rate…