“Welcome to Issue 7 of the ReactOS Weekly Newsletter, as persistant as a Jehovah’s Witness. This week, I’ll be taking a look at the NDK used by the ReactOS developers, covering WINE 0.9.2, and detailing the latest SVN activity.”
“Welcome to Issue 7 of the ReactOS Weekly Newsletter, as persistant as a Jehovah’s Witness. This week, I’ll be taking a look at the NDK used by the ReactOS developers, covering WINE 0.9.2, and detailing the latest SVN activity.”
I seriously doubt few if any businesses will bother with ReactOS until it has good support. And even then they may not bother. I hate to say it but at this point Windows is probably the cheapest to use. Doesn’t take a rocket scientist to do updates/repairs on it.
Oh and yeah – we are kinda persistent aren’t we.
It’s still pre-alpha. I don’t see the point in shooting it down already because businesses won’t use it…
Erm, so a 0.2.x OS isn’t ready to replace something from the Microsoft behemoth? Did anyone expect otherwise? I can’t see the point of your post 🙂
As for repairs, this is an area in which ReactOS could shine in a few years, when it’s more fleshed-out and stable. Instead of being at the mercy of Microsoft to have OS-level bugs fixed, you could contract someone else out to do it — possibly cheaper and almost certainly faster.
Something tells me this project will eventually get slapped with a huge reverse engineering lawsuit at the hands of MS.
True, this is a risk…
But didn’t a similar thing happen a while back?
I seem to remember that’s how we have FreeBSD – wasn’t FreeBSD essentially reverse engineered (without really copying any code) from BSD?
If this is the case, then would this previous case perhaps set a precedent?
Todd
“I seem to remember that’s how we have FreeBSD – wasn’t FreeBSD essentially reverse engineered (without really copying any code) from BSD?”
Not really. FreeBSD *is* BSD code, based on the 4.4 BSD Lite distribution of BSD. What’s missing these days is the original AT&T UNIX code that was there.
I wonder if anyone is looking at porting Mono to ReactOS, although perhaps “integrating” is a better term.
Assuming they achieve good compatibility with at least Windows 98se, whose to say they won’t simply be able to direct people to the download page for Microsoft’s .net runtime environment.
“Assuming they achieve good compatibility with at least Windows 98se, whose to say they won’t simply be able to direct people to the download page for Microsoft’s .net runtime environment.”
If they only achieve compatibility with 98se…..
They can take the whole project and toss it straight out the “window”.
“If they only achieve compatibility with 98se…..
They can take the whole project and toss it straight out the “window”.”
They’ll achieve more, but even just becomming fully compatible with 98se means that a lot of software including most of today’s games will work. 98se support is actually quite a lot.
What’s the point of writing a whole replacement OS and then giving up and using MS .NET?
Mono is just as good for all practical purposes.
Why giving up? MS.NET is based on win32, if there’s no win32 api, .NET won’t work. So really, I don’t understand why people think .NET will replace the Windows APIs. It won’t, it’s just an addition.
I think you missed my point.
For god’s sake that think is not able to work properly yet and you want to put mono on top of it?????
Yes. They already have openoffice and other complex stuff running. Mono is just another application. The system is there to be used.
IIRC, that was on the agenda for later on down the road. Besides, if the core ReactOS implementation becomes robust enough, the Microsoft .Net Framework would run “out of the box” on ReactOS.
OK, but what about us ABMers?
Then there’s also Sharpdevelop instead of VS express . . .
at some stage of development in reactos everything that works in win should work in ros, too.
so there’s no need in “porting” things to it;
just use ms .net or the win version of mono or whatever you want….
ReactOS isn’t reverse engineered. It’s a clean room implementation.
What we are doing is no different than what Linus Torvalds did.
There are sutuations where reverse engneering isn’t illigal anyway.
There is a policy at ReactOS that if something does need to be dissasembled, the person who does the dissasembly documents their findings and another developer will use that documentation to reimplement the functionality.
Instead of simply trying to duplicate the entire Windows base OS, why not improve on it a bit? For example, instead of implementing the GUI using the old Win32 APIs, the project might want to try writing it entirely using Mono (and better integrate the OS with .NET itself).
Businesses (and hackers) will probably only seriously consider ReactOS if it provides some interesting features or improvements as opposed to Windows.
The single biggest improvement over windows will be low cost. I’ll bet lots of people will use it for this feature alone.
You want to use Winapi for compatibility.
Thats the only real advantage of using React.
It gives people a real alternative to playing games/applications without windows.
Other OS’ should include REACT OS for dual booting.
Wanna play a game ? Boot React.
Edited 2005-12-04 19:56
I would use it to play games.
Why reboot into React? React uses the WINE codebase for its WIN API so it will not be any more compatable then WINE on Linux or whatever other kernel.
“If they only achieve compatibility with 98se…..
They can take the whole project and toss it straight out the “window”.”
ReactOS isn’t aiming for compatability with ’98. It’s based in the NT5 arcitecture, which means 2k, XP, 2003
“Why reboot into React? React uses the WINE codebase for its WIN API so it will not be any more compatable then WINE on Linux or whatever other kernel.”
This is not true. For starters, not all libraries come from Wine. Secondly, many applications rely on communucation under the win32 API, which is something Wine do not offer. Thus there are some programs Wine will never be able to run. ReactOS won’t have this problem.
There will also be full DirectX support, which is only simulated via D3D under Wine.
Also, when was the last time you installed your Plug an Play hardware with a Window driver under Wine?
There are many many things ReactOS will be able to do that Wine won’t. This isn’t a competition though, Wine and ReactOS have very different goals, and are not targeting the same market.
People, the microsft way to do the software is: “do it in the easyest way , speed ? forget it the hardware will be updated”
The reactos in this alpha-alpha, compiled using the slow machine gcc 3.42.
And thiss all this its use less memory, boot faster and to demostrate their potencial, one delevoper stop one day optimizin the DIB engine of windows, and CABOOOM, it become 10 x Faster than the Windows Xp.
Imagine a final version, compiled with a Intel COmpiler ?
That is kinda unfair–
The reactos DIB rewrite outperformed the XP DIB routines by about 3X, in ONE, VERY OPTIMISED test.
Personally, what I find to be the “big features”, are the min requirements.
Currently:
486
32mb RAM
50mb HDD
VESA compliant video
AT/PS2 keyboard
Serial/PS2 mouse
Considering that ReactOS tests this configuration as the base compatability level, and strictly enforces the 32mb memory requirement threshold, this should really take off in some parts of the world where really cutting edge tech simply isnt affordable or available.
Throw in “Free as in speech” and “Free as in beer”, and you end up with a very workable solution for such areas.
For corporate entities, the ability to use really old HW at a useable level for simple workstation use would greatly improve appeal as well— rather than having to have a forced HW upgrade every 2-3 years to keep up with MS’s new windows & office releases, It may be pushed back to 5-6 years, or maybe more. Further, if there is a particular feature that the corporate entity needs really badly, it doesnt have to petition MS for the feature anymore– The full sourcecode is available, and they can brew up the feature in house.
As for MS slapping reactos with a big lawsuit, I dont see how they could do so. ReactOS’s codebase contains no closed source code. API implementations are based on trial/error behavior of apps running in ROS VS on windows, and from heavy digging through the MSDN website where many public APIs are described sufficiently to be reimplemented.
I eagerly await a more mature ReactOS to do speed trials against, with various windows versions.
Also, why does everyone hate the windows GUI so much?