Submitted by The ReactOS team has pushed out version 0.3.9 of their Windows NT-compatible operating system. In case you’re new to OSAlert, the ReactOS project aims to create an operating system that’s compatible with the Windows Server 2003 kernel and Vista’s Win32. This new release brings a whole slew of improvements.
The most important changes are neatly summed up in the release announcement, but more detailed information can be found in the changelog.
- Reduced minimum memory requirement to 32Mb. In theory ReactOS can now be installed with 24Mb and run with only 20Mb
- A new, faster Hyperspace Mapping Interface has been implemented in the kernel resulting in a speed improvement of over 300%
- Security check improvements to the Object Manager in the kernel improves performance by 500%. Noticeable during large file/registry operations
- Various NDIS and AFD problems have been solved which increase compatibility with 3rd party NIC drivers and hardening of the network stack
- Preliminary support for sound via the new Kernel Streaming service. It’s now possible to use the ac97 driver via our new Port Class library to play sound bytes using winamp
- A great deal of work has been put into the command prompt to make it much more compatible. It’s now able to run very complex scripts, including our own Build Environment
- Many bugfixes to the kernel mode portion of the GDI resulting in much improved drawing engine across all bit depths
- Synchronization of most of the Wine usermode DLLs
You can get this new release from the download page.
It’s good to see there’s still steady progress, although I wonder whether they’ll ever catch up.
JAL
No they won’t, MS will always a be a moving target
But they will try and hopefully one day it will be ‘good enough’ for use in a production enviornment (its only hobby level atm)
ReactOS isn’t really chasing a moving target, the NT architecture has been relatively static for a long time. Yeah, improvements are made and new features are added but the architecture remains largely the same.
Backwards compatability is very important to Microsoft and it’s this backwards compatability that allows ReactOS its breathing space to get itself compatible.
http://www.osnews.com/thread?351945
Not to mention that they do not have to chase the Win32/user-space APIs themselves all that much, because Wine already do that.
I would add that, unlike other platforms, Microsoft is always assuring backward compatibility with previous versions (with a few exceptions). So Win32 target is good as start (though I think they moved from their original target – WindowsNT – to a newer one: Windows XP).
To me, the only real concern about this project is the whole legal platform: what would happen if they succeed in creating a WindowsXP clone? I hope they checked this before starting…
NT is behind XP, NT is the kernel they are targetting, you are getting mixed up.
They are targetting a newer NT kernel (the one around vista).
No, you got it wrong.
I wasn’t referring to kernel only. ReactOS original target was WindowsNT (as a whole, meaning as level of supported platform). Windows is way more than a kernel only.
I read somewhere (maybe here on OSAlert… can’t remember) that they were shifting their target platform from WindowsNT to WindowsXP, again as a target platform, not kernel only.
That was a good decision, to me: WindowsNT platform is too old to be meaningful and WindowsXP is very old as well. I guess they switched when they decided to use Wine as a compatibility layer but of course this is just a speculation by me…
Windows XP is Windows NT.
Windows Vista is Windows NT.
Windows 7 is Windows NT.
Again, NT kernel is not the same as Windows as a whole platform. While those systems share the same kernel (NT kernel, though they feature different versions of that kernel), targetting Windows XP IS NOT like targetting Windows 7 nor like targetting Windows NT.
Targetting Windows XP, for example, means targetting THAT kernel AND associated libraries (DirectX, COM, DCOM, MFC) in their versions featured on that platform.
For example, targetting WindowsXP means aiming to have DirectX-compatible libraries in place while targetting WindowsNT don’t need that (as far as I remember, WindowsNT had no DirectX implementation).
Again, NT kernel is not the same as Windows as a whole platform. While those systems share the same kernel (NT kernel, though they feature different versions of that kernel), targetting Windows XP IS NOT like targetting Windows 7 nor like targetting Windows NT.
Targetting Windows XP, for example, means targetting THAT kernel AND associated libraries (DirectX, COM, DCOM, MFC) in their versions featured on that platform.
Do remember that they can make the kernel target that of Win7 and still have user-space compatible with XP. Also, they can mix-and-match features, they can include all the necessary to be compliant with XP but they can in addition of that include features from Vista and Win7 as long as they can maintain XP compatibility.
In practice that would mean that all the XP software should run on ReactOS, but also some of the software meant for Vista/Win7 could run just fine thanks to having newer kernel features.
You’re getting confused there.
They moved from NT4 to 2000 to XP to Vista, but all 4 systems are still NT. It’s just NT opperating systems prior to 2000 was simply called NT n (where n is the version number)
I have a feeling with Windows 7 now getting a Windows XP VM that backwards compatibility is going to be less in the next release.
What about win64? Microsoft seems to have screwed up the jump to 64-bits quite badly, but there is no reason why wine and ReactOS can’t go 64-bit. That would be an actual plus compared to windows. It is very frustrating to see a 32-bit OS in times of 4GB-8GB becoming fairly common.
You must have a very broad definition of ‘wide spread’ given that casual observance shows that 1GB and 2GB being the more likely amount one see’s in low cost and mainstream computers respectively in retail computers (that I see in the big name stores).
…but a slow moving one. Microsoft Release rarely and you have to remember that the drivers in the main done by third parties, and the userspace by Wine
Adurbe posted…
Maybe, but is that Linux circa the mid ’90s when even as a hobby OS it was still increasingly being brought in to replace professional grade servers–or are we talking hobby OSes like Haiku or Syllable which require quite a bit more work to get use out of them? There is a difference…
–bornagainpenguin
its only hobby level atm
A hobby level ATM? That doesn’t seem like it would be very secure. Although, it may prove to be very financially beneficial even if it only fools half of the people.
No humor zone?
Good to see this! They’re making good, steady progress.
It’s interesting that “compatibility with Vista’s Win32” is one of the aims. I’m of the opinion that if ReactOS was just compatible with XP, then that would be good enough. ( I’m not convinced that Vista-compatibility gives much “value-add”, compared to being XP-compatible. )
But hey, if the devs are keen and willing to go past the XP-compatible level, then the best of luck to them!
What’s the difference from a technical standpoint, in the first place?
If they want to copy Vista, they’ll have to raise that number
I’m kidding. I wish them luck, and I hope it doesn’t take too much time until we can at least have a beta version. Can’t wait to see that
It looks like these guys have been doing a great job.
it will be really good when they can run the windowsxp shell ;p
It’s not an easy task to create a fully binary-compliant clone of an OS with closed sources. As such, good luck with the project and hopefully they’ll get to the point of it being stable and useable.
The sooner they reach the point where all my drivers and WoW works fine the sooner I can ditch XP and be free of proprietary OSes
I miss these obligatory comments that ask “What is the point of this project anyway? Why not just use the original?”
What a waste of resources. Windows future is all about .net not win32. One day Microsoft will deprecate Win32 as the platform API and that will be the end of ReactOS. They’d better implement Windows compatibility with Wine and Mono over a *nix kernel.
The day Microsoft deprecates Win32 (and its siblings), is the day that ReactOS will become incredibly relevant. Every now and then, I see a computer running some DOS-based COBOL system, or Delphi/Win98…Probably in ten years a lot of the actual Win32 apps will still be in use.
Not quite. They wouldn’t deprecate without including virtualpc and a free license of say Windows 2000.
what utter nonsense.
Windows will never see Win32 depricated. Losing Win32 will mean losing pretty much all Windows software, including .NET apps.
Microsoft will move to a new line of operating systems (see singularity) when the times comes to depricate it.
.NET relies on Win32 for everything. Without Win32 there would be no .NET
Your counterargument implies also the deprecation and loosing of all applications, so it doesn’t hold well. Microsoft *will* deprecate Win32 and implement .Net on top of another API (maybe Singularity kernel). And the product will still be called Windows something. So it’s no “utter nonsense” after all. Either way, ReactOS is screwed because it implements an OS which is doomed to die.
Just like Linux is because there are tons of other kernels with more technologically advanced features… oh wait.
Also, how is that having a second account to upvote your own comments going?
Edited 2009-04-27 16:12 UTC
I don’t have other account, I don’t need it. I don’t need votes, I can write and people will read. Besides, you see that my comments are all 1 or 2, so if I had more accounts I would be +5 or something.
Or is that you have multiple accounts and are voting me down so you can’t explain how I still get positive votes? It’s known as “others may share what I think” or “others feel that being voted down for expressing a concern is invalid as per OSAlert rules”. Whatever, very childish of yourself. If you came up with that is perhaps because you do that yourself.
Feel free to put as many negatives on me as you want, I don’t really care.
Edit: minor corrections. Spawning the upvoting bot!
Edited 2009-04-27 19:51 UTC
No man, .Net uses win 32 underneath, but it can act as a wrapper that abstracts win32 from the developer. Like how Mono can run on linux without wine. win 32 isn’t required as a back end. You would need to redo the CLR to work with what ever backend Api replaces win32, but then everything would work.
Take a look at the virtual machine win xp offering in windows 7. It may be the only way to run pure win32 apps in the future.
Nonsense, the OS will never be written in .NET, and performance demanding apps aren’t written in it. .NET is a poor candidate for applications that actually matter, it’s intended for rapid application development and nothing more.
Never say never man. Take a look at midori:
http://en.wikipedia.org/wiki/Midori_(operating_system)
What a waste of resources. Windows future is all about .net not win32. One day Microsoft will deprecate Win32 as the platform API and that will be the end of ReactOS.
First of all, all the base libraries are written using Win32. The mono runtime is ALSO Win32 code, and any of the base libraries used by it. If Microsoft dropped Win32 API altogether they’d be creating a whole new OS,
They’d better implement Windows compatibility with Wine and Mono over a *nix kernel.
Why so? What exactly makes a *nix kernel better than an NT kernel? Give some specifics, please, cos I have the feeling that you’re just saying stuff that you don’t know anything about.
Do you realize the kernel has nothing to do with Win32? Win32 is an API to the syscalls, and it sucks horribly. The kernel is fine, the API is not.
Do you realize the kernel has nothing to do with Win32? Win32 is an API to the syscalls, and it sucks horribly. The kernel is fine, the API is not.
Of course, but Mono IS built on top of Win32. If they deprecated Win32 they’d have to build Mono straight on top of the kernel, then they’d have to convert te shell, explorer, browser, all the libraries, misc utilities and all to Mono. That’d be more work than it’d take to just create a whole new OS!
Mono is not built on top of Win32. Mono was implemented as Linux alternative to .Net. If it was implemented on top of Win32 it wouldn’t run on Linux, right?
No. Mono already runs on *nix systems, no need to build on top of the kernel, except Windows specific parts. Those would have to be implemented, of course, on top of a *nix kernel facilities or services/libraries.
I don’t believe so.
What I meant with using a *nix kernel is not because it is inherently better, but because there are already plenty freely available. No need to implement your own kernel/OS. As Windows is constantly moving to .Net world, it would make more sense to implement only that compatilibity, not all of Win32 shit. Makes more sense in the end.
Mono is not built on top of Win32. Mono was implemented as Linux alternative to .Net. If it was implemented on top of Win32 it wouldn’t run on Linux, right?
Right, I am mixing Mono and .NET, I don’t use either so.. :/ The point still is that if there wered no Win32 libraries at all you’d STILL have to convert all the applications to .NET/Mono. Explorer, Internet Explorer, Shell, all the various .COM stuff and services and all. They are not .NET/Mono applications, they are built on top of Win32 libraries. You can check that yourself if you wish. Even in Win7 those are still all Win32 – dependant.
Now, who would be so sick as to even try to convert all that to .NET? Converting source code from one language to another is an enormous task, even worse if the application in question is a large one. And add to that that the original source is non-managed language and the new source would be for a managed language..
.NET is a framework, not a language. You would not need to ‘re-write’ the all of the above in a new language because CLR allows one to migrate to the .NET framework without having to go wholesale with C#. There is managed C/C++ which allows one to utilise their existing code base and with some modifications migrate. The code is compiled into CIL and then it is executable.
If speed is of great concern then you can use ‘Native image generator compilation’:
I don’t understand why you need to resort to using half truths when it comes to discussing Windows – and what is even worse when you make some glaringly obvious errors in your post, not out of miss types but flat out ignorance, you move to the goal posts, change the topic and launch a tirade from another direction.
Personally I don’t see win32 going anywhere given that Microsoft are still adding features to the win32 stack; Direct2D and DirectWrite being two new additions where as if they were focused solely on .NET, they would have continued focusing on WPF, fixing some issues, completely moved their widget/common control drawing over to WPF along with the UI of the whole operating system to it.
Win32 will keep hanging around because I simply don’t see Microsoft putting any effort in migrating their own code base over to a new framework even with CLR making the process alot easier. I’d like to see it, but I doubt it’ll happen anytime soon (or infact ever).
Given the fact that the .NET VM runs on top of the, wait for it, Win32 API, I fail to see how MS can deprecate the Win32 API without some type of C’ish user-to-kernel layer. (Let alone msvcrt and friends)
Granted, MS could always be stupid enough to shove the .NET VM (with the required libraries) into the kernel and create a new .NET base syscall interface, but at-least given my own experience, such an OS will redefine the terms bloated and slow.
– Gilboa
What about Singularity, the future Os from MS? The kernel, the drivers and the apps are all written in managed code.
Irrelevant.
If Singularity was anywhere near a production OS (after ~6 years) I would imagine that MS would have considered delaying Windows 7, and dropping the Windows NT kernel (w/ it’s Win32 API).
As they didn’t, I can only assume that Singularity is either -very- far from being production quality, or, most likely (considering past attempts of creating a Java based OS), Singularity’s basic design has is far too problematic to be see worthy.
– Gilboa