Post a Comment
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
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...
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 OSNews... 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...
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)
Not to mention that they do not have to chase the Win32/user-space APIs themselves all that much, because Wine already do that.
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 they will try and hopefully one day it will be 'good enough' for use in a production enviornment (its only hobby level atm)
...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
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'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 
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.
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
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.
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 OSNews 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.
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.
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..
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':
NGEN is intended to make the assembly execute faster by removing the JIT compilation process at runtime, but this does not always improve performance because some optimizations can be done only by a JIT compiler (i.e. if the JIT compiler knows that the code is already running with full trust, it can skip certain expensive security checks). Because of this fact, it makes sense to use NGEN only after benchmarking the application performance before and after it.
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
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





