Submitted by The ReactOS project aims to be an open source Windows NT-compatible operating system which can run Windows applications and utilise Windows drivers. Obviously, this is quite a daunting task, and as such, progress has been relatively slow. As a result, project coordinator and kernel developer Aleksey Bragin has proposed a rather drastic solution.
Aleksey Bragin announced his new plan on the ReactOS mailing list. He detailed that while ReactOS has achieved a number of great things (audio support, the bootloader can boot Windows, some Windows binary drivers work, networking improves by the day, the kernel evolves), the operating system is still lacking in what he calls “usability”.
“For a user it’s important that a web-browser loads websites, instant messenger client connects and works, [Microsoft/Open] Office shows documents, email client gets new messages,” Bragin explains, “This bare usability is what’s still missing, and if it continues to be like this, I am afraid our project won’t be of much use in another 10 years.”
The problem, according to Bragin, is the Win32 subsystem in ReactOS. Over the years, it has become this monstrous thing that takes far too many people and hours to manage, let alone develop, leading to the situation where despite 30+ people working on it for the past 10 years, there’s still no “satisfactory result”; applications which do not have problems with Win32 “[can] be counted on one hand”, bugs remain in the bugzilla for years, and in the end, few parts of ROS’ Win32 subsystem actually correspond to that of Windows XP (the rest being ROS-specific or Wine code).
The solution is ARWINSS, which reuses as much Wine code as possible. The architecture of ARWINSS looks like this:
- USER32.DLL and GDI32.DLL are nearly unchanged Wine source code
- WINENT.DRV – a custom, ReactOS-specific user/gdi driver for fast graphics and windowing operations
- WIN32K.SYS – low-level graphics support, user server implementation, minimal Win32 support for the kernel
- WINEX11.DRV – an optional user/gdi driver allowing to use remote X Server instead of a local display
Observant readers may be asking themselves: what happened to the X server? ARWINSS has a solution for that, too. “Wine implements a special layer of abstraction, called user/gdi driver, which abstracts all X11 specific details in a standalone library,” Bragin explains, “ARWINSS implements its own fast user/gdi driver.”
ARWINSS has many advantages, not in the least the fact that it would bring Wine’s level of application support to ReactOS: 13495 applications from the Win database, as well as a theoretical number of applications Wine can’t run due to hardware issues. On top of that, a lot of people are working on Wine – especially compared to the number of people working on ReactOS.
He also put his money where his mouth is: he produced a working version in two months (!), which already works on ReactOS and Windows, and can be checked out of svn today. In addition, ARWINSS would also automatically fix a huge amount of bugs.
With ARWINSS, the future looks bright, according to Bragin. It would streamline development, allowing developers to focus on other parts of ReactOS, while also paving the way for lots of other new features, such as printing support, compositing, and a terminal server. Better yet, it could push ReactOS into beta stage.
The future looks bright indeed, if Bragin is to be believed, and he has called upon ReactOS’ developers to aid in developing ARWINSS further. “With your help we can take ReactOS to the place it deserves, reaching end users in a good shape and still growing,” he says, “Let’s look to the future, it will pay us back.”
Wine basically converts Win32 into Linux system calls, but I didn’t see Linux in the architectural diagram. I am guessing though there has to be a Linux kernel underneath it all.
So what this amounts to is that emulating the internals of the modern Win32 OS is a lost cause. Whereas emulating the Win 32 API on top of another OS (Linux) is a proven approach that supports something like 13k windows apps.
The only problem I can see is that you lose driver support. You can’t just install your win32 drivers for your hardware in ReactOS and expect it to work.
Linux? Where did you get that idea from? Did you read the article?
Thanks for bringing this interesting development to our attention Thom. I have to admit that in my ignorance I assumed that ReactOS was already using the WINE code in this manner.
Hopefully this will kick start a new era of ReactOS usability.
I admit I also thought that was the case; from the sound of the presentation it seems like they were using some old wine code and not as extensively as they are now suggesting.
(Disclaimer: this is how I understand the situation, I might be wrong;) )
They already use lots of current Wine code, e.g. for most of their user-mode stuff. So they don’t write their own versions of common dialogs, COM components, etc., as this would be a lot of duplicated effort. Instead they import the Wine code, and they do this quite often.
What Aleksey writes about is win32k, which is the kernel mode part of Win32. This is currently written by the ReactOS guys, using some Wine code, but mainly focused on Windows compatibility. Sadly it takes an insane amount of work, and that’s why Aleksey proposed a ‘shortcut’, which would be significantly different from the Windows architecture, but which would give a system that’s usable now and that can profit from the improvements made upstream (i.e. Wine’s win32k).
Thanks for the clarification, there, I was confused too.
If I can ask a second, stupid question: what parts of the Win32 API run are kernel-mode? I thought the NT kernel/Win32 architecture design featured a small kernel, with layers built on top of it (in user mode) to generate the system interface that user applications see; basically, I thought that, by design, the Win32 interface was implemented in libraries and didn’t penetrate down into the NT kernel itself?
The microkernel architecture was used in NT 3.1-3.51, but in NT 4 some performance critical components were moved to kernel-mode (although not into the NT kernel itself, which is a separate module). AFAIK this is when Win32k was born. This move resulted in a big performance improvement, but also in less clean design and some security risks (win32k has been exploited to elevate privileges).
I’m not sure what exactly goes to win32k, but at least some of the usermode GDI functions are thin wrappers that just call their kernel mode counterparts.
I find that to be… interesting. I remember reading some time ago that someone had added a similar facility to the Linux kernel — the ability to take a user-mode process and promote it to kernel mode. The main use, I think, was to speed up system services like X, by reducing the number of times that it had to call into the kernel (as calling into the kernel from outside is apparently quite expensive). I think that a consensus was formed, tho, that promoting random userspace daemons – even if they where known, trusted and system-critical – into kernel space was a really, really terrible idea, for exactly that reason: an X bug become then becomes a kernel bug, and an X exploit becomes a kernel exploit. It’s interesting that Microsoft apparently ran into the same problem, thought of the same solution… but opted for raw performance over potential security and stability costs.
Yes, I read the article, where did you make it clear that this would be running on top of a ReactOS kernel?
So this is a “Lets just use Wine as the Linux folks are already doing it and lets focus in our Windows compatible kernel.”
The only benefit I see from this is that there will be an open source Windows compatible kernel (ReactOS kernel) where you will be able to run the Windows drivers and apps through Wine.
But Linux is already a stable platform to run Windows apps (through Wine) and the Linux drivers work just fine.
Edited 2010-01-18 20:01 UTC
Do articles about water tell you water is wet?
Do I seriously have to start adding into articles about about alternative operating systems “This does not use the Linux kernel”? Is that what we’ve come to?
Yikes! You sound a little tense, there, Thom.
I’d be a little perturbed myself. joshv is either trolling badly, or is genuinely missing the most obvious content in the article. It wouldn’t hurt him to visit the ReactOS site to read about the fundamentals of the project, let alone the OSNews blurb.
I think you’re getting a little confused there.
ReactOS is a complete OS from the ground up. The problem Aleksey Bragin mentioned was specifically with ReactOS’s implementation of it’s Win32 calls.
So what Aleksey Bragin is suggesting is by using WINEs Win32 code (baring in mind that WINE has a larger and more complete development) in place of the existing ReactOS Win32 so you have WINEs app compatibility.
So it doesn’t really matter what kernel is running as this is purely user space tools.
(case in point being the numerous non-Linux kernel systems that WINEs been ported to: from *BSD and Solaris ports to ‘Crossover’ for the Mac).
AFAIK drivers wouldn’t use Win32. Win32 isn’t generally used that low-level. It’s more a graphical toolkit with knobs on.
That said – it’s been a while since I’ve used Win32 so I maybe forgetting some details.
However Aleksey Bragin seems to hint that drivers were a non-issue:
Ok, so this is a port of the Wine Win32 user land to run on top of the ReactOS kernel? Correct? If so, I have to admit I pretty much thought that’s what ReactOS was already.
Yeah… Me too. My guess is that when they decided they weren’t going to do this back in 99 or so, wine wasn’t nearly as complete as it is now. So it wasn’t obvious that they should focus on leveraging the wine source as heavily, instead of writing one more in tune with their development goals.
Same here…
WINE and ReactOS shared code and developers, but ReactOS was never really a port of WINE.
There’s much much more to Windows than Win32 and NT kernel – just like there is more to ReactOS than it’s Win32 calls and it’s kernel.
However, up until today, I must admit I thought ReactOS had heavier influences from WINE too.
Edited 2010-01-18 22:27 UTC
A simplification that should make things more understandable:
ReactOS is a re-implementation of the Windows NT kernel, and the Windows NT userland, with the hopes of having a Windows-compatible OS, without any Windows code being used.
WINE is a re-implementation of the Windows userland (the win32 APIs) that allows Windows applications to run on non-Windows OSes.
The ReactOS project has decided to use WINE as their userland leading to: Windows applications running on top of WINE running on top of the ReactOS kernel.
I guess my confusion was that I thought ReactOS was basically already doing what this announcement proposes to implement. But I guess they’d started out with their own Win32 user land and hacked in Wine code on an ad hoc basis.
But this brings up the question – why not go further? What’s the benefit of having your own custom NT-like kernel if the Wine Win32 API runs just fine on top of the Linux kernel? I guess you couldn’t run Windows drivers for your hardware – but if, as the announcement states, all anybody cares about is apps – who cares? And doesn’t their windows driver model implementation pretty much suck anyways?
Perhaps this will just allow them to focus on hardware driver support and kernel tweaking, and leave the userland stuff mostly to Wine.
Actually, people do care about drivers for their weird-ass legacy hardware that the manufacturer went out of business 5 years ago, and there’s not enough demand for porting the drivers to Linux.
And, I was under the impression that the Linux driver interfaces weren’t stable (by stable, I mean not changing, and I don’t mean not crashing.)
Exactly so: I think a large part of the expected pay-off is being able to use all those existing, well-supported Windows drivers, and having hardware support on the same level as Windows.
I think the designers also have a few (possibly legitimate) gripes with the way POSIX-OS’s do things: at least, that’s what I recall their FAQ saying. So, “fixing many of people’s gripes about Linux” may also be something of a goal.
There’s more to an OS than the kernel and toolkits.
You only have to look at the number of Linux distros that behave differently despite all running a Linux kernel and all having QT/GTK+ installed.
<rant>
Quite frankly I’m getting a touch sick of everyone heralding Linux as the saviour to all FOSS. I mean, one minute people are complaining about a Windows monopoly and the next they’re trying to create a Linux one in the FOSS world.
The reason I love ReactOS is because it’s different from every other open source OS.
So surely this merits more praise than those that just repackage Linux with a blue GNOME desktop instead of a green one and then try to pass it off as a whole new OS?
</rant>
1. Create a problem that doesn’t exist (i.e. the need for a Windows clone).
2. Find a sucky solution that somehow, kind of works after using lots of duct tape (i.e. ReactOS).
3. Let the project die a slow death (they’re still working on that).
There are too many clowns today who do Open Source just for the sake of Open Source.
Edited 2010-01-18 17:17 UTC
are you calling “clowns” to people that are far smarter than you?
could you please enlighten us and telling us what are the wonderful things you created?
at least, are you a great developer of commercial software able to bash the work of open source developers showing your superior work?
come on man, if you do not like the way they work, respect them because of the work they do.
Edited 2010-01-18 18:54 UTC
Ah! Well, here’s the thing: I don’t need to have created anything to criticize something. It’s always the cheapest cop-out, especially in the world of Open Source, that random people suddenly ask for your developer credentials as soon as you criticize an Open Source project. Most software is made for *users*, and if some Open Source sissy can’t take criticism, he should stay out of the kitchen.
I’m not. And I don’t have to be one. Because I didn’t in any way criticize the *quality* of ReactOS.
Oh, you got that wrong. I disrespect them precisely because of their work. It’s redundant. It’s irrelevant. If I want Windows, I buy Windows. A fully function-complete clone of even XP/2003 is IMO a sweet, fleeting dream.
Sure, every Open Source developer is free to work on whatever she wants. But given the fact that Open Source on the whole misses good developers, it’s more of a disservice to the community to dabble in meaningless pet projects.
Feel free to disagree with me, though.
In truth, I think that most people took issue with your belligerent and offensive tone. No one likes to be called (or to see their champions called) “clowns”.
But you’ve got an interesting point from an engineering or even a political/economic perspective, that given that true programming talent and skill is a limited resource, why should it be put toward a project that will never really achieve its goal? I think that this view is too narrow, however, and in research there’s always so-called “wasted” effort. ReactOS should be treated as a research project, and I suspect that its main usefulness will come from the knowledge gained among its participants. Who knows how Aleksey Bragin will use his findings to change the world in the years to come?
I disagree. You don’t have to be happy with some application or open source “product”; it is possible than you do not like it because it does not fulfills your needs, it has a lot of bugs, it has no the quality you are used to, etc… But, if you have no the skills to do something better than the thing you are criticizing, I suppose you should at least respect the people that made it and be constructive to help them to improve their stuff instead of bashing it.
I also disagre on this point with you.
I am a software developer and though I do code for Linux and Mac, I respect A LOT the Win32 API and, thus, to their developers too.
I like Java a lot, but that thing does not mean that I do not respect to the .NET framework architects.
In brief, you don’t have to like anything you don’t want to, but everything turns around respect to others’ work.
It’s true, exclaiming your disgust at a product does not hinge on your ability to make a product of your own. You’re free to not like the product, and it doesn’t take a chef to tell you that the food’s bad. But proudly touting your ignorance on a subject without first asking of the subject’s relevance is a mug’s game.
An OSS project attempting to replicate Windows will have a lot of advantages if successful:
1. An open operating system that has a built-in compatibility with most hardware created today. You take any other OS: Haiku, BSD, SkyOS, even Linux still, and the chance for many of those OSs to grow is very remote considering it’s all tailored for hardware that at best has only basic functionality with that operating system. Few write drivers for an operating system possessing less than 1% of the market, and I doubt they’re going to start.
2. This project will assist many other projects meant to replicate one part or another of Windows compatibility. Given the sheer volume of closed APIs they have, if one can find a way to openly replicate them, then other OSs can also implement a compatibility layer that will open up a cornicopia of programs to them and certainly go a long way to level the playing field, forcing MS to work harder on their OS in order to compete.
3. As windows does progress, it tends to can a lot of it’s compatibility with older programs. DOS, Win 3.1, Windows 95, right on up to Windows XP all have access to programs that Windows 7 and Vista are no longer able to run properly. Sure, it’s all well and good to tell someone to stick to their OS if they’re in need of a certain program, but without support that OS will lose functionality in enough places where it will eventually become unfeasible to use that OS for any other reason than to execute a specific program.
You flippantly characterize this project as some sort of deluded fever dream, but even if the OS never reaches 1 on 1 functionality with the latest Windows OS(which, let’s face it, it probably won’t until MS gets lazy again), the very act of the project accomplishes enough to make it a worthy endeavor. Continue using your commercial Windows. It’s fine that you do, there are certainly enough programs on there to justify doing so. But to boldly state that the project has no value without actually asking anyone if there’s something you missed(and clearly there is) is irresponsible at best and gloriously, obnoxiously ignorant at worst.
Nobody “needed” a clone of UNIX either, but we have several.
Hmm, can anyone confirm whether this comment broke/set the record for downvotes?
The truth hurts.
I’m still trying to wrap my brain around what the ReactOS team’s idea of “success” is. Windows, in its various flavors, is a good enough Windows, so why even go that direction? Improving on it (“a better Windows than Windows”) just makes it less compatible so again, what would be the point? They can’t possibly put as many resources into it as Microsoft does so they will always be behind. I truly commend their efforts, I just don’t understand what their desired end result is in the grand scheme of things. It is unlikely that many developers will target ReactOS specifically as a platform.
I think the switch to WINE for the Win32 layer is likely the best move they can make from a resource perspective. In the end, most users doesn’t really care HOW the compatibility is attained, they just want it there, easy to manage, and fast enough to make more sense than dual booting another OS. If the WINE group and the ReactOS group gain from combined efforts then everybody wins.
I still can’t help but feeling that ReactOS would have made a lot more sense 10 years ago and is pretty much irrelevant today.
They used to say the same about Linux in ~1993.
But thanks for words of support!
Edited 2010-01-18 17:37 UTC
Except that Linux wasn’t trying to be a better Windows… Better OS maybe, but not a clone+1.
It was trying to be better than UNIX (obviously), which commercial flavors were prevailing back then. Noone really could believe that some enthuasist-made OS kernel could become mainstream in future. And I’m sure people were saying “who needs Linux? We have major commercial UNIX implementations, supported by hundreds of skilled people and companies with good reputation.”.
Linux was fairly mature as a hobbyist OS before it was trying to be a ‘better’ anything. Its original ambitions were modest: a better hobbyist Unix than Minix. Soon, it became the de facto kernel for the GNU operating system, placing it firmly in the centre of Free and Open Source software development, and it started taking off.
Commercial Unix was a rip though and mostly RISC only.
Commercial windows is a rip too, and mostly x86 only.
The difference with unix, is that unix is much simpler and better documented…
Windows on the other hand is intentionally extremely complex and its inner working poorly documented, to make it difficult for third parties to create clones.
Hehe…sounds like one of my old classmates when the teacher would ask him why his code was so convoluted….
“Yeah…well…I meant that” he’d say with a straight face.
No-one believed him either
Actually, Linux is not made by someone, it is actually GNU. Stallmans vision decades ago. Linus stepped in and placed his kernel into GNU. Without the collective efforts of the GNU team, Linux would not have happened.
You make it sound like Linus developed GNU/Linux. But no, it was only his kernel. Someone builds the whole car except the engine, and is constructing the engine – when some teenager steps in and puts his shitty engine inside. Then that teenager gets all credit: “he constructed the car”? I dont get it.
As several people say, Linux is bloated and unstable. Some would say it is quite shitty compared to a real OS.
Actually I think it makes more sense today than ever.
As Windows is an OS with an ever increasing footprint and support for legacy versions are being dropped – it might prove useful to have a compact system that will run the old Win32 apps reliably when you just need something simple because a 10+ year old business critical application was never upgraded to run on newer OSs.
(eg I keep hearing horror stories about offices with a stray Win95 desktop because they need software xyz which didn’t support XP).
Nobody can expect Microsoft to maintain complete backwards compatibility (some argue that their attempts at such is half the problem with Windows of present) nor to keep supporting old OSs indefinitely because a lazy developer / cheapskate company never thought about future-proofing.
So the answer might turn out to be ReactOS.
Closer to home, I’ve found another use for this OS. I’m currently playing around to see how viable it is as a virtual server for a Windows only application.
I’m doing this partly to be bloody minded (I can so I will), and partly because I don’t want to pay for a Windows license just to run one application when I know it already runs perfectly under WINE.
But, what does ReactOS offer that WINE (or the like) cannot solve? Or virtualization for that matter? Run XP/2000/98/95 in a VM and your problem is solved, for the most part.
Again, I am not trying to convince anyone that ReactOS should not be made, I just don’t think it will ever be a platform of choice for development of Windows applications. So that makes me ask the question of “Why?”. It’s the relevance question. I understand full well the motivation for making something for the challenge of it, but if the end result is for others to use it then there has to be a reason to draw them in.
On a side note, people still running 15 year old unsupported software on a 15 year old unsupported operating system probably need to consider their costs in maintaining that system versus rewriting it for a more current architecture. Why fix it if it isn’t broken? Because sometimes it costs more to keep it unbroken that it does to replace it, especially over time. Not to mention that replacing it may have other benefits that could never be reaped from the old software.
Virtualization requires a valid license for the OS (including 98 and 95, they are not vaporware).
Wine is a compatibility layer, not an OS.
Agreed, but there are many free operating systems on which you can run WINE. So I believe my question still stands.
Imagine a small and minimalist OS which is there just to run Wine. I don’t want to install full linux distro just to run wine. In addition, linux + wine are two different things and Wine is not well integrated with Linux.
Nice small well integrated system which sole purpose is to support hardware, run Wine and provide acceptable user experience is all I need with out myriad of config files and ReactOS with its seemless Wine layer is a perfect solution.
Edited 2010-01-19 19:13 UTC
Not really because other OSs don’t have the full Windows-clone environment.
You can slap a Windows theme on a Linux distro running WINE, but that doesn’t make it behave anything like Windows.
So what these guys are setting out is much much more than just coding an OS that runs a few Windows apps on an open source kernel.
Because you still need a licence for Windows if you virtualize it and WINE isn’t an OS.
The whole point of ReactOS is it’s a Windows clone and can run Windows apps.
So drawing developers in is a moot point as they’re already there (in a manner of speaking)
I agree with you but the problem is many people can’t look past the now.
To fix something that’s not currently a problem (ie the “it’s working at the moment so why should I care?” mentality than many budget holders have) costs money now. So some managers would rather wait until the proverbial sh*t hits the fan before investing into a solution to fix something that might never happen (despite how likely that it will happen).
I think it’s mostly just to give people interested in understanding more about the guts of NT/Windows something to poke around in. This is probably why the project is tacitly condoned by Microsoft* — it’s unlikely to actually cut into their revenue in any significant way, and having more alpha geeks interested in Windows is a benefit to them.
* The lead developers of ReactOS co-authored (with Mark Russinovich) the latest edition of the official book on Windows internals published by MS Press.
There’s some effort underway to run Wine on Windows:
http://wiki.winehq.org/WineOnWindows
Wine on Windows and ARWINSS share the same plan – use the Wine’s userland stuff on top of the ReactOS/WinNT kernel and drivers without needing NT kernel emulation.
I am surprised this wasn’t the ReactOS plan from the very beginning.
Yes, I researched all possible options and tried to contact people who was interested, but that seemed to have been totally abandoned. You’re right, Arwinss hs actually almost the same goals, and could be used same way.
Better late than never
ReactOS is a waste of time, people should just improve on Linux/Wine.
I say this is a waste of time because clearly, ReactOS is not going anywhere, they don’t have enough manpower and Linux architecture is much better than NT anyway.
Linux is also much more mature and has lots of people contributing to it every day, the same could be said with Wine, Linux/Wine also have support from companies, etc.
Don’t get me wrong, I don’t think ReactOS is a bad project or anything, but I don’t see them going anywhere unless they get serious and start to get support from companies, or full time paid developers working on it every day.
I think it would be wise to just work on improving Wine rather than wasting time on a big project like ReactOS that requires much more manpower than what they currently have, ReactOS is clearly not going anywhere, and by the time they get somewhere, it will be too late already because Windows will be 1000 years ahead.
Working on improving Wine and running Wine on top of unix-like OS’es is a much better idea IMHO.
Edited 2010-01-18 17:53 UTC
ReactOS is a waste of time, people should just improve Linux/WINE
Linux is a waste of time, people should just improve BSD
BSD is a waste of time, people should just improve Unix
Unix is a waste of time, people should just improve VMS
(Let me guess, you use some flavor of Linux and find developers volunteering there time for non-Linux related projects downright offensive right?)
And, the reasons for a win32 native alternative are probably just as valid today as when they motivated the starting of the ReactOS project. It’d be nice to be able to buy an OS from someone other than Microsoft just because one has to run some win32 app.
No, I am not an extremist like that, I do support other projects other than Linux, I also use BSD, and Windows when I have to. I am open to use whatever software in order to get done with the work, I use the best tool for the job and am neutral when it comes to software.
I really wish the best for ReactOS, and I hope they succeed, I would love to see a free implementation of Windows, and I would love if they work closely with the Wine team, I know having a free implementation of Windows will benefit everyone, I am just saying that they have very big envisions and goals and not enough man power. There is nothing wrong with that, but I’m afraid that if that continues to be the case, by the time they reach to the 1.0 stage, with the current man power they have, it will take a lot of time for them and it will be too late already because Windows will be much more ahead.
I hope I’m wrong though, and I hope they get more man power and succeed with their project.
Sure, that would be great
.
Edited 2010-01-18 18:29 UTC
Well, IIRC, 1.0 is when they’re 100% compatible with NTOSKRNL 5.2 and 100% compatible with the current version of NT’s userland.
My prediction is that 1.0 may never come, simply due to NT’s userland being a moving target, but they might get something reasonably compatible.
I think you are way off the mark here. While you could argue for most things that double effort is wasted effort (to which I wouldn’t light-heartedly sign up to re. your examples), all these projects you mentioned have actually produced some quality, usable code.
But with ReactOS, the waste really lies in that it has never gone anywhere – if I am not doing it great unjustice. I feel like having deja-vus for like a decade… everytime ReactOS gets a mention, I get the impression they got like 98% to go still. That’s the difference, others may be wasteful, but they are getting somewhere nonetheless. Not that I care – just saying…
I accept I am doing ReactOS injustice if you were to tell me that actually, it will be as complete and usable as, say Ubuntu, within the next 2-3 years. Or else, yes, it is a waste of time that has been going on for a very long time. People can tinker with it, fine… only, maybe there comes the day where ReactOS news items are about as useful as Duke Nukem ones
Nuke’m for ever has yet to produce a playable alpha or beta yet. ReactOS current images are available for install, liveCD and prepackaged VMs.
My grief was really with the minimal thought one-liner suggesting that developers put there time elsewhere because the comment poster feels that the project is not moving ahead fast enough. It’s a project I check up on about as frequently as the news articles about it hit the pages but I don’t feel the personal justification to demand where developers spend there leisure time. Even if it’s only increased the involved developer’s understanding of win32 back end, that’s a benefit.
It’s much like the people who think that “Linux” (ignorantly meaning everything that happens to use the kernel) needs to be consolidated into a single master distribution before it will ever gain desktop retail success. They look at market share as if it somehow indicates more than the quality of one’s marketing and sales teams. They assume that any distribution based on the kernel should be focusing on that one person’s primary interest of retail measurements. As if the distributions and developers have some obligation owed to that one individual.
Prooflink please, or it didn’t happen.
Well, the NT Kernel isn’t that bad, in fact in terms of used concepts it comes quite close to Linux.
The whole operating system is a different beast. Linux has much better separation between user and administrator, simply because Windows has to evolve out of a single-user environment as it tries to be as backwards compatible as possible.
Linux, on the other hand, was multi-user from the very early days on, and if need should arise, backwards compatibility can be broken (it didn’t break since 2.4.0, but that just shows good foresight by the developers).
Microsoft may one day be forced to provide built-in virtual machine technology, to be able to get rid of 2 decades of cruft they now have to maintain in the operating system.
So was Windows NT.
Exactly… the real problem back then was so few Windows applications were “multi-user ready”.
This info you put up shows me you don’t have a good grasp on windows NT. I suggest you learn more on windows NT based operating systems before saying anything else on them from now on. NT grew out of a mutiple user enviroment from the get go. Now alot of windows users and programmers coming from win 9x\3.1 going to 2k\xp have grown out of a single user enviroment unaware of how NT works, ACLS, multiusers, etc.
Edited 2010-01-18 21:00 UTC
NT had ACLs from the beginning, Linux did not. Your point being?
Well, here is a place you could start:
http://www.top500.org/stats/list/34/osfam
You could look at the OS that the worlds fastest (and most expensive) computers use … here are the Top 3:
http://www.top500.org/system/10184
(Linux)
http://www.top500.org/system/10377
(Linux)
http://www.top500.org/system/10185
(here’s a surprise … its Linux again).
Then, you could go here:
http://en.wikipedia.org/wiki/List_of_Linux_computers
and find a significantly longer list than just Windows on x86 and x86_64 desktops and servers.
And how does it make it a better architecture?
I’ve always liked the NT architecture, so an open source version of it is a good thing, provided that they can actually get it working better than they have so far. If it takes porting Wine to their NT kernel clone to get things working, then I’m all for doing so.
NT alone is meaningless (and I would still want a proper *nix with inodes, etc etc). It is Windows that is on top that people want. Sure there is the NT drivers, but I see that a being a right old mess compared with open drivers in the Linux trunk. The closed drivers and stable driver api world really does seam to be beginning to crumble. It’s just not a good way of doing things.
http://lxr.linux.no/linux+v2.6.32/Documentation/stable_api_nonsense…
I beleive that they could go one step further and use a real-ukernel for their system. Not a hybrid one, in order to share work. OkL4 is a possible/maintained solution.
I just downloaded the PDF to read… but the basic idea in the post sounds good to me. I am sure he/they will have some fine ideas to commit back to the WINE project as well.
I haven’t evaluated the state yet, but http://en.wikipedia.org/wiki/Linux_Unified_Kernel is also a good idea.
You think?
Closed drivers are bad enough. Mainly because no one else can fix or improve them.
But closed drivers from another platform? That forces a stable api in the kernel, which is as bad or worse.
http://lxr.linux.no/linux+v2.6.32/Documentation/stable_api_nonsense…
No, both projects are crazy. Wine on top of a free Linux is the best long term hope for being able to run Windows apps on something other than Windows. But you can bet MS will fight it every step of the way (extend, extinguish).
http://www.theregister.co.uk/1999/07/18/analysis_how_ms_used/
History of this almost happening before with Win32.
http://tuxdeluxe.org/node/296
MS and standards
http://lxr.linux.no/linux+v2.6.32/Documentation/stable_api_nonsense…
Why stable driver API are bad
Does ReactOS have a more complete Win32 and Direct3D implementation than the newest Wine and Crossover releases?
How complete is Windows driver ABI support? For example, could someone install video drivers designed for Windows XP and play Modern Warfare 2 on ReactOS like you can with Wine on Linux?
Supporting Windows drivers is neat, but only if it really works. Linux has drivers for devices across multiple architectures–although some are half-baked. However, Linux can directly use some Windows network device drivers using NDISWrapper.
I was post a quick one-liner about “can directly use” followed bu “with Ndiswrapper” but I’d rather help clarify.
– If you are using the driver inside a wrapper then the OS kernel is not using the driver directly. The wrapper is translating between the Windows driver and host OS.
– With Ndiswrapper specifically, one should get basic NIC functions from the Windows driver however it may not provide more advanced functions beyond the basic connection (no packet injection or other fun).
– How easily you’ll be configuring the driver inside ndiswrapper inside the OS driver framework depends on the distribution. Mandriva manages it well including a “would you like to use a Windows driver for your NIC” during the installation wizard.
The solution to all of this is convincing NIC (and other hardware manufacturers) that drivers and/or driver interface specs are part of public documentation that increases there potential customer base. If they want to make utilities closed source and “value add” bits of the hardware product then fine but closed drivers from a vendor deciding what limited OS I can run there hardware under is madness. I’ve yet to hear a rational reason that drivers or driver interface specs should be hidden away like they are. (Broadcom, your “but people will change the power output” excuse doesn’t fly either.)
I’m very eager to have something that can replace Windows for me all together. I just hope that what ever choices they end up making, that this project doesn’t become any more bloated than XP as far as size and resource abuse goes.
Also I’m hoping that it will allow you to remove parts of the OS that you’ll never use, which is another option Microsloth never gave us.
Lastly I just hope for good compatibility, and a pleasant experience when using media related apps.
So far what I’ve seen has been impressive, though I wonder what became of the XBOX port?
Edited 2010-01-19 03:05 UTC
I’ve glanced at the PDF. Arwinss will base its Win32 subsystem on Wine’s. That is an obvious advantage but I still don’t think it will help the project much.
Wine still isn’t anywhere near perfect, although its excellent considering that the project is attempting to implement some 70,000 Win32 APIs, many with incomplete or no documentation. Wine may have support for most applications but the level of support varies greatly from poor to perfect.
The most troubling factor for the project is the fact that Windows will always be a better Windows than a clone and 95% of manufactured PCs already have it installed.
Wine is buggy and far from perfect, but the ReactOS userspace DLLs are apparently even worse, thus they’re trying to go from the proverbial fire into the frying pan that is Wine.
But Wine isn’t necessarily that far: 70000 APIs sounds like a lot, but 90% applications together use maybe 10% of those.
I’ve never seen the point. You are always going to be chasing MS tail lights. If you start to succeed at all, they start to deliberately make it harder. (Extend, extinguish). This goes for Wine too. Wine isn’t the first of its type either, there was Wise before it, http://www.theregister.co.uk/1999/07/18/analysis_how_ms_used/
I have a love/hate thing about Wine.
On the positive note Wine seems to be able to run some old Windows apps (well games) that modern real Windows can’t. I’ve even read of talk of porting Wine to Windows because of this. The cheek of that delights me.
Also on the positive note when I run up against lack of documentation in Win32/COM, I can look at the Wine source and cross my fingers the other Win32 implementations do the same. The Wine source is clear and well written C.
Also on the positive note, Wine means people can play Windows games (and that does seem where much of the work goes), which aids peoples leaving Windows.
Also on the positive note, Wine can be used to quickly port apps to being cross platform.
But that leads on to a negative note, I don’t like Win32. I want Win32 dead. If people want cross platform apps, write cross platform apps. Writing Windows apps and porting them is not a good way of doing things.
Also on a negative note, I don’t like Win32. I want Win32 dead. Most of the time there is only one implementation of Win32, so bugs go hidden until the app is run on another Win32 implementation (WOW64 as well as Wine). The phrase of matching “bug for bug” isn’t for nothing.
Trying to do a Wine for the whole OS? What’s the point? Use Linux and Wine. Closed drivers are bad anyway (for many reasons, not just who can fix/improve them, but forces a stable kernel API, which is also bad), but closed Windows drivers on another platform? Very bad idea. Same goes for Linux Unified Kernel.
Open drivers, in the kernel trunk please. Then anyone can improve or fix them, and if the driver API can be improved, it can be improved without legacy mess. If old Windows apps must be run during transition, run them via wrappers or virtual machines.
I know many will disagree with all this, but if I make one person think about something they haven’t before, I’m happy. Years ago, I would have disagreed too.
For all of you asking why. It is simple.
In the United States (and probably elsewhere) there is an ice cream chain called Baskin-Robbins which has 31 or 32 flavors of ice cream.
People want choices. YOUR choice of “ice-cream” is not necessarily THEIR choice of “ice-cream”.
“But their choice isn’t popular enough. It should be discarded.”
Let’s turn it around. What if YOUR choice wasn’t “popular enough” and should be discarded. How would you feel then?
31 or 32 choices of operating systems is/are not too many as long as there are people to create and maintain them. If you don’t like this attitude, please stop going to a site called, “OSNews” because it is all about News about Operating Systems.
It’s not News about Operating Systems that only you care about. It’s about ALL the operating systems that ANYONE cares about.
Again. If you don’t like it, don’t come back anymore. If you do like it, keep coming back and join in with any group that you have anything POSITIVE to contribute.
Thanks. Now you can return back to your regularly scheduled programming.
Yes…..but, this isn’t a different flavor ice-cream, it’s a copy of an existing flavor. But more than that, this ice-cream has to be compatible with the other flavor of ice-cream because it needs to run the same programs and drivers, etc etc, as that is the point in its existence. Worse the existing flavor is a moving target, a law until itself, and the new flavor must try and keep up with big jumps without knowing what’s going to happen in advance. Even worse the existing flavor has a long history of deliberately destroying compatibility. Ok moved away from ice-creams, but I think I’ve made my point. Not saying it shouldn’t be reported, it is interesting (I love Plan9 as a concept, but don’t try and use it), but I am saying I think it’s doomed to fail.
A copy? You mean like any posix/linux-like operating system that came after UNIX? That turned out rather well, I think.
But I do agree with you that the project has a rough road ahead and it might even be impassable.