Submitted by Three months after the previous release, the ReactOS Team has released version 0.3.8 of their Windows NT-compatible operating system. We have taken a short virtual look at this new release. In addition, the project will have a booth at the FOSDEM event in Brussels, Belgium on the 7th and 8th February. Several members of ReactOS Development Team along with the Project Coordinator will be attending. You can have a chance to test the live system, speak with developers, and get a closer look at their project.
The major changes of ReactOS 0.3.8 include:
- Various bugfixes and enhancements to Kernel core services (e.g. registry, system information routines, sync primitives like guarded mutex, IO support and other)
- An initiative has been started to fix the remaining unstable parts of the kernel: Memory Manager, caching code and filesystems driver APIs and other dependencies of Mm
- Introduction of a new Portable Structured Exception Handling mechanism (PSEH 2.0), which is much closer to the native compiler SEH syntax
- A few longstanding bugs are fixed (such as multipartition HDD support by LiveCD, Task Manager CPU graph)
- Various GDI drawing problems were fixed
- A minimal open source version of the KernelDebugger protocol has been implemented, allowing basic MS WinDbg functionality
- CRT and RTL library improvements
- A number of problems were fixed in base system drivers: NPFS, CDFS, FASTFAT, FS_REC, SCSIPORT
- Video driver improvements for better real hardware support
- Ongoing Win32-subsystem work
As always, the changelog for this release is rather huge. You can download the release from the website’s download page.
Rough, but promising
Giving ReactOS a go isn’t hard, as the team provides ready-made virtual machines for use in VMware or Qemu. I downloaded the new release for a quick test drive through VMware, and I was impressed with what I saw. The system boots very quickly, and apart from the use of the Tango icon set, it looks exactly like Windows Classic. There additions as well, of course, such as virtual desktop support.
ReactOS comes with an application called Download!, a sort of crude package manager that lists a number of Windows applications known to work with ReactOS. It can download and install them for you. Installing Firefox 2.x is a breeze this way, and seeing it all run so well is an odd experience.
Still, there are many rough edges. In my short use I experienced a few crashes, and a lot of screen remnants. The biggest problem, however, is the extremely unreliable and slow net connection; I’m not sure if I should blame Firefox, ReactOS, the WMware network driver, or VMware itself.
Still, ReactOS is an interesting project, and even though I find it highly unlikely it will ever reach its stated goal, that what they have already achieved is mind-blowing.
Who knows? In 10-15 years it might actually turn into a DOSBox equivalent of sorts. Never underestimate the FOSS as it has the tendency to keep going.
Edited 2009-02-05 14:40 UTC
Reactos will achieve their goals. Simply because after a certain point the win32 native APIs will load on reactos and they won’t have to write much more than kernel updates to keep it fresh. Wine’s a different bundle of trouble. It always has to keep tying things onto whatever linux provides. Reactos just has to perform the base windows functions and the kernel and the rest of the windows environment should hook in on top for low effort/free. Stuff like wrapping OpenGL isn’t really a problem on Reactos. Once the video card driver layer is implemented enough windows nvidia/ati drivers should just load and provide their own GL/DX implementations. Likewise the directx 9.0c runtime should install/run on reactos unlike wine where it doesn’t really install. There are wine directx dlls for providing directx. Wine has to reverse engineer every directx instruction and reimplement them on linux. Reactos gets to skip that work.
Edited 2009-02-05 14:51 UTC
They can only skip the work once they can handle the pre-compiled DirectX code.
As for now, they are using and contributing to Wine.
I thought they were recreating DirectX via <a href=”http://www.reactos.org/wiki/index.php/ReactX“>ReactX.
Wine actually has to actually implement every D3D and wrap that to an equivalent (enough) OpenGL call. For the harder stuff, they even have to implement shader compilers, and translators to go from D3D shaders to OpenGL shaders. Even worse, they have to re-implement the hacks and workarounds on a per game basis that nVidia and ATI have built into their proprietary drivers – never mind all the application specific hacks that may be in Windows itself.
Much of these problems would be solved in ReactOS by simply using the bits of code that come with the hardware drivers – and some of them even by running MS proprietary libraries (though that probably violates licenses, so I’m sure they will attempt to rewrite a lot of that anyway – like Direct X).
What I’d like to see, is a collaboration between the React OS guys, the Wine guys, and the Linux guys, so that we can get some of the windows code (like binary D3D driver support) into the Linux Kernel (modularize that part of the ReactOS kernel, add some glue code so it loads in Linux kernel, and we’re off), so that Wine could simply take advantage of what has already been implemented in the windows binary drivers and ReactOS (well, they are still a ways off, but still).
The Linux kernel guys have already stated that they would not be opposed to adding Win32 kernel calls into the Linux kernel. They’ve added calls from other kernels, and Linux itself is a reimplementation of an older proprietary standard (same as ReactOS, only further along), so it kinda makes sense. Linux kernel devs are a pragmatic bunch after all.
I believe what you propose is http://linux.insigma.com.cn/en/“>already with the Linux Unified Kernel project. That has some exciting potential. With Wine hooking into ReactOS’s API instead, we stand to see a lot of performance benefits.
Given the Linux kernel developers strong objection to -Linux- binary drivers, I don’t see it ever happening. At least not in the main-line tree.
– Gilboa
I haven’t read a Microsoft EULA for quite some time now, but I’m pretty sure they are limiting the scope of the license to Microsoft operating systems only. I recall something like that, quite early in the license text.
In other words, while the DirectX runtime may run under ReactOS it would be a license violation. I guess, the same holds true for other MS runtimes and libraries.
Does anybody know more about this?
Maybe when ReactOS will be quite stable, they decide “to break the chains” and develop their stuff but their own, no matter win32 compatibility or such kind of things.
I figure eventually someone will take the codebase and start exploring other evolutionary paths NT-like OSes could take. Who knows we may even end up with as many NT-ish distros as we see with Linux today
Does it run KDE 4.2 ??
Ultimatey a company will pick up ReactOS and start doing OEM installations with it. Hide the fact that the computer does not run Windows as much as possible and sell, sell, sell your machines. Kind of like the original Lindows business model.
In fact, its a matter of time and stability. Once the OS gets stable and can load all Windows XP drivers, run all the programs Windows run, you’ll see tons of people wanting to bundle it. I really think this project will see its glory day by the dead of XP.
There’s one thing I’m curious to see. What will be the reaction of hardware builders. Will they support it, or get enough pressure from Microsoft not to.
[EDIT]There one thing I’d like to see though, is a different memory allocator and task scheduler than Windows. If these gets exchangeable, this could be realy cool. I know MS has improved those, but I still hate to see my machine crawl under load under Windows while the machine is still responsive doing the same task under Linux! [/EDIT]
Edited 2009-02-05 15:50 UTC
I suspect that will be a very long time, indeed. By the time it does, loading XP drivers and running XP programs will likely be irrelevant. And if it is not, Microsoft will simply kill ReactOS through legal or other means. The phrase “squash like a bug” comes to mind.
I think you hit the nail on the head. I think they are setting themselves up for failure. Microsoft would never let this go commercial as that means it would be taking money away from them. You KNOW that ain’t gonna happen.
Didn’t Linux (and most of the rest of GNU) start off as a recreation of an older proprietary system?
Granted the older Unix standard did not move as quickly as the single vendor Microsoft has moved Windows, but I think the question is, can ReactOS (or Wine for that matter) catch up enough, within the EOL period for continued Windows XP use? XP isn’t going anywhere anytime soon, Windows 7 or not.
If they can achieve runtime compatibility with Windows XP, during the period where ISVs still feel the need to support it, then they have a shot. They do not need to achieve cutting edge compatibility with whatever the latest Windows code base is, just with whatever is still relevant enough that ISVs feel they must support. That’ll be Windows XP for a while yet to come.
Different situation. In 20 years, no one has ever done an acceptable job of running Windows apps on non-Windows OSes. And it has hardly been for lack of trying. OS/2? Wabi? Wine? others?
The list… and the failures… go on. Some even had legally licensed Windows code to work from.
Some of the various Unix flavors may have been proprietary. But the standards were more open. Whatever the reason, history clearly shows that Unix is easier to clone than Windows. And I would say that the root cause, in general terms, is that Microsoft *really* *really* wants it that way, despite any hand-waving they might do in front of various legal bodies.
Fifteen years ago, I might have felt differently. But today, in 2009, the evidence is in. And what it says is clear.
Edited 2009-02-05 17:56 UTC
Linux never had binary compatibility with any Unix variant as a goal – it was free to evolve in the best direction available given evolving technology. This allowed Linux to surpass Unix in some (not all) areas, and eventually (ironically) various Unix implementations began striving for Linux compatibility.
The goal of binary compatibility will ensure ReactOS is always… reacting… to Microsoft.
Once the OS is mature enough, however, a fork or two could provide interesting fodder for the OS grist mill, where perhaps “compatible enough, and sometimes better” will allow it to garner a measurable market share. Could be fun.
How can Microsoft stop people from collaborating and writing code?
Microsoft have been unable to do that with FOSS so far.
Just tie them up in patent proceedings; they don’t actually have to win to screw over a project, they just have to keep the thing dragging on long enough to eventually kill off any drink by the developers within the project by making it unaffordable to keep fighting. Basically an approach of wearing down the enemy.
Just tie them up in patent proceedings; they don’t actually have to win to screw over a project, they just have to keep the thing dragging on long enough to eventually kill off any drink by the developers within the project by making it unaffordable to keep fighting. Basically an approach of wearing down the enemy. [/q]
Wouldn’t work as intended.
FOSS would counter sue with patents of their own.
http://www.patentcommons.org/
http://www.openinventionnetwork.com/
http://en.wikipedia.org/wiki/Patent_retaliation#Patent_pools
If one is accused of violating a patent, the accusing party can get the court to stop everyone from using the product.
Everyone. Every single user can be required, by law, to stop using the product, until the patent suit is resolved.
http://en.wikipedia.org/wiki/Injunction#Common_reasons_for_restrain…
This applies as much for counter-accusations as it does for the original accusations.
This means that Microsoft could sue, and insist that everyone be made to stop using Linux … and FOSS could counter sue, and insist that everyone be made to stop using Windows!
Like wow … hey!
Guess who would be in the bigger world of hurt.
Although there is a temptation to reference such protections – at the same time I tend not to under estimate the enemy. Better to over estimate the strength of the enemy and develop and over kill in arsenal than under estimate and be sorry.
PS. Its interesting how within a space of 6 hours we have people trolling this website silencing peoples opinions through the moderation system. Typical of the ilk who reside on this website. Intellectual pigmies who can’t counter points so instead spit and curse at those who do.
There. I modded it back up, even before I read this post, because I completely agree with you. But this is one of the things that led to your demise the last time: the moderation system is what it is and it has been time tested by now. It is pointless to keep arguing about this any further.
I remember that most posters more or less came into a agreement that there might have been trolls moderating you down in the past but I don’t know if the OSAlert staff actually did anything about. Regardless, you should take these complaints to them. The forums are not the best place to do it and really: it is just not worth losing your temper about it.
Having said that, I’m glad to see you back. I may not agree with what you say all the time, but you indeed contribute a lot in the discussions that you take part in with often insightful comments and as such it is really good to see that you’re back. We already lost some other good posters along the years and it would be great if they could find some time to come back as well.
And Thom, you may want to check the logs or whatever you guys do to find out if Kaiwai’s posts are not being modded down arbitrarily by trolls. And sorry for the off-topic!
No investor in their right mind would ever go within ten feet of ReactOS for fear of being patent bombed out of existence.
Microsoft are not the inventors of “operating system”, nor even the inventors of “GUI”, or “desktop software”.
For help with understanding the problem of patents, and the “defenses” built up around them, and the concept of “mutually assured destruction” if Microsoft should ever venture to sue a FOSS project, I would suggest you google for the following terms: “Open Invention Network”, “Patent Commons”, “IBM Technical Disclosure Bulletin” and “Linux Foundation”.
http://www.linuxfoundation.org/en/Protect
They very much are the inventors of a large number of technologies and processes that ReactOS has no choice but to implement themselves. It doesn’t matter what you or I think about the actual patents that Microsoft hold: the fact is that they hold them, and can sue over them.
I’m well aware of them thanks, but not to be a kill-joy here: they will not come to the defence of a small investor and/or ReactOS if the big patents holders who are part of the OIN or Linux Foundation are not directly threatened. That’s the “nice” thing about patents: you can use them very selectively.
ReactOS has very little to protect itself from Microsoft other than the continued goodwill of Microsoft themselves and being low enough to pass under their radar. Any serious push to commercialise ReactOS would be a direct threat to Microsofts core revenue and would unleash all hell.
Edited 2009-02-06 12:28 UTC
>I’m not sure if I should blame Firefox, ReactOS, the WMware network driver, or VMware itself.
Neither Firefox, VMware’s driver ot VMware itself. Guess what – it’s ReactOS.
They are moving forward and somebody already said the truth – eventually they’ll get to a point where many native DLLs load and work wonderfully, so reimplementing them in a free form will be second-hand priority. We’re still looking for functionality.
Is react os based in the usa. Im sure others will fork react os an it be under different names.
The Netherlands Denmark do they have laws on software stuff.
Lets say reactos.com shuts down im sure they will be several other web sites that will have reactos it will be named different.
As long as reactos stays in beta ms will simply ignore it. Staying in beta might be reactos best bet.
Im surprised ms did not go after freedos.
For the record, the whole reason FreeDOS exists is because MS decided to drop their efforts for their own MS-DOS in favor of Windows. Besides, there are other DOSes, and MS hasn’t killed them all off (DR-DOS, PTS-DOS, ROM-DOS, RxDOS, etc) despite a few nits. I guess because it’s not illegal to clone an API.
Besides, if you don’t clone the API, all your old apps die, and current Windows has no support for OS/2 and little support for DOS. Plus, x86-64 kills any 16-bit stuff (DOS or Win) except via virtualization, emulation, etc. (DOSBox, DOSEMU, VirtualBox, QEMU, BOCHS, etc). So it gets bleaker by the day. Compatibility ain’t what it used to be.
Actually, as long as you are doing a clean room clone, nothing stops you from cloning Windows.
-However-, if MS has a patent on say, clicking on an icon called start to show the application list (and MS most likely have a lot of brain-dead patents), ReactOS is doomed…
– Gilboa
From what I’ve heard it’s not very clean room development. They look at the Windows binaries and basically derive the original source code from the assembler code.
That’s basically just stealing other people’s code.
That is the accusation that made them stop development look for offending code and remove any code that was close to offending. One the plus side in this huge code review React dev’s squashed bugs and bad code.
A. I’d guess that you never tried to to debug anything meaningful in assembly. Hint: Trying to reverse engineer kernel32.dll by looking at the assembly dump is useless. (Especially given the fact that Win32 is fairly documented.)
B. AINAL, but at least according to the law in my country, the ReactOS can take you to court for your accusations, and unless you have a solid proof that your wild accusations are correct, they’ll win.
– Gilboa
It is fairly easy to reconstruct something similar to the original source code. There are even tools that do it for you.
You seem a bit touchy on the subject, so I’m not going to take the flame bait and respond to arguments about the law in your country.
[quote]It is fairly easy to reconstruct something similar to the original source code. There are even tools that do it for you.[/quote]
My experience seem to suggest other wise.
[quote]You seem a bit touchy on the subject, so I’m not going to take the flame bait and respond to arguments about the law in your country.[/quote]
Funny that you mention flame-bait, especially given your previous comment. I’d venture and guess that the term FUD doesn’t really ring a bell on your end, right?
– Gilboa
Edited 2009-02-06 23:32 UTC
React OS has annual code reviews that involve microsoft certified contractors to ensure that no IP infringment is occuring.
Since Microsoft is actively indirectly a part of the code review process this gives ReactOS some level of legal ground to stand on.
React is 100% legal OS that can run windows applications. It also follows the origional NT security model with common sense applied where necessary. Microsoft botched things when they decided to start automating things, for the sake of automation.
Edited 2009-02-05 20:47 UTC
In my opinion, the work these guys are doing is simply amazing!
Great Job!
Is it possible to run MS SQL server on top of ReactOS ? Vista and 7 are too bulky for VM, and Windows server is too expensive.