ReactOS, the project to create a Windows NT-compatible operating system, has published another news update with some interesting news items. The legal position of the ReactOS Foundation has been strengthened, and now has a VeriSign certificate that might help other open source projects as well, the new ATA driver is more or less complete, and there’s some progress in the area of video drivers.
The ReactOS Foundation is the organisation which owns the ReactOS trademarks and logos, and which handles the legal maters around the project. Some good news around the foundation lately: “ReactOS” is now a registered trademark, owned by the foundation, which means they now have a stronger legal position in cases where the ReactOS name is abused. In addition, they now have a digital codesigning certificate from VeriSign, allowing them to sign their releases and preventing fake ones.
There’s another major benefit to having such a certificate: as most of you will know, 64bit versions of Windows requires signed drivers, and the ReactOS project think they can help open source projects. “The Foundation is considering setting up a system where projects can apply to have their code signed with the Foundation’s certificate, thus working around that particular issue,” the project states, “Of course we’d be vetting the code for any issues and any code submitted must conform to the rules they would have followed had they applied for a certificate themselves, but this will at least save them some money along the way.”
The UniATA driver is now ready to replace the older SATA driver, enabling better support for ATA controllers. VirtualBOX used to choke on the UniATA driver, but this bug has been temporarily fixed – a definitive fix still needs to be made, since the current one causes a performance penalty (it just disables DMA). “In the future, we’ll of course want to actually fix this as not having DMA imposes a performance hit,” they explain, “In the mean time, the major blockers with UniATA are now gone and it has been switched over as the default ATA driver for ReactOS.”
There’s also been some testing in the video driver department, but it’s still mostly with old hardware such as Matrox’ G100/G400, the ATI Rage II+, and the S3 Trio 64V. “The good news however is that it seems the XP drivers seem to be more reliable than the Windows 2000 drivers, meaning the current kernel side that interfaces with the drivers behaves more like XP. The drivers also provide 2D hardware acceleration,” they state, “The bad news is that currently there is still no 3D hardware acceleration. That is going to take a good deal more work on the ReactOS side before we get those benefits.”
I imagine that these guys from ReactOS are very intelligent.
Why are they wasting their time doing this project? Really, this is not going anywhere. By the time they have a consumer ready version, Windows will be in #15 or whatever name Microsoft finds for it.
Just drop it. It is useless. No one, except a couple dozens hobbiest will ever try it.
Do some work on some meaningful project and use your talents for something that will really make a difference in software engineer and design.
I beg to differ….
I can see at least three valid reasons for ReactOS to keep going (and this is from a Linux-using and occasional BSD-using weenie…
)
a) Playing Windows games. At present, if you want to play those but don’t want to buy Windows, the options are Wine (running on Linux/*BSD) or ReactOS. Wine has the inside running at present, but ReactOS can still get to a good-enough state to run games.
b) As a security testbed, to see if it is possible to create a Windows-like OS that can be hardened against worms and viruses. If it were possible to port pf to ReactOS then that would be a good start.
c) (Eventually) – as an XP replacement. Ok, I agree that this is likely to be quite a way down the track (I’d guess at least 18 months to 2 years). However, given the progress that the ReactOS devs have made so far, it’s possible.
– obsidian
Yup, Linux is currently my default OS, which means Windows XP is my gaming OS. If ReactOS could run games in the future, I might use it.
I, for one, would like very much a Windows compatible OS that I don’t have to pay money for. Windows XP will still be relevant 5 years from now, and I think the React OS team will produce something stable in this time frame.
I beg to differ too.
Linux with Reactos in Vmware or Virtualbox so you can run Windows stuff looks like a very promising option.
It easy: because they can! They want to do this, they have time to this, they have skills and most importantly, if they succeed to make something that works well, it will become a big news! I cannot wait this day.
Ridiculous comment. Of course it is a useful project. It *does* take time, but it’s a project that many people will use in a few years, because it’s a clone of the *most popular* operating system around. What I suggest is take a few Linux developers, have them learn about Win32 and give the Reactos team a hand until it reaches the stable version, then resume work on Linux (if still interested). Now, *that* would be useful, and many more people would benefit from the collaboration and could use a Windows replacement that works for them.
I don’t understand the relationship between Linux and Reactos here, why not suggest BSD developers down tools and work on Reactos?
I personally don’t use Windows and have no requirement for a Windows clone, so your suggestion seems utter madness to me.
Oh now wait a minute, your were joking in your post right?
Because both people who work on Reactos and Linux are system developers and they can learn any system to work on improving it.
Could be too!
You aren’t representative of the majority of people. Most people use Windows, so a Windows clone is useful to more people than a Unix clone.
Nope. Just pragmatic.
The core architecture of the Linux operating system is fundamentally different to that of Reactos, and would take some time to get up to speed.
I agree that any system developer should have no problem learning a new system, but where is the incentive for a Linux system developer to do this?
I never said I was a representative of the majority of people, and like many others you are using the context of a desktop market share.
Nope, you are being pragmatic where it benefits Reactos.
i too have taken a few linux developers and put them to work, chopping trees and mining gold.
i will send them to finish ReactOS, maybe later
I imagine you will be flamed to death for this comment…
Here’s a healthy dose of skepticism:
1) Wine has been in development for 16 years. It is useful. It works, but not very well. How much better can we expect ReactOS (which shares a lot of code with Wine anyway) to do? Can ReactOS work better than Linux + Wine? Is kernel compatibility (vs API) the real issue?
2) In my experience, projects either come up with something you can “almost” use within 1-2 years or they never do. Examples: Linux (went from 0.01 to v1.0 within a couple of years), FreeDOS. Contra-examples: Hurd, SkyOS, Haiku etc.
3) ReactOS has been in development for 11 years.
How do you know Haiku will never release a working, usable version 1.0?
The reason operating systems take a long time to reach 1.0 is because operating system development is not magic.
The NT design is very strong and the fundementals haven’t changed since the days of cutler.
Unless Microsoft drop the NT architecture, then reactos will always be relevant.
The inner workings of Windows 7 aren’t all that different from windows XP. Once reactos has a stable base the extra work to get Vista/win7 only software to work will include adding any new API’s (some of which reactos already supports) and adding support for the new driver model.
So, the moving target reactos is chasing isn’t moving quite as fast as people believe.
On the contrary, Microsoft dropping NT would make ReactOS more relevant than ever. There will be vital code written for NT running for decades to come. Once ReactOS becomes the only windows 2000/XP compatible OS with drivers for the latest hardware and with regular updates it will take off in a massive way.
Agreed. We still have NT4 boxes in production. A working ReactOS would give us another option (one under active development) next time the racks get short or space (or audited).
Fundamentals haven’t change – you need to look at where they verred off course in 4.0 for the sake of speed as a prime example of what happens when management start to get involved with things they know nothing about or make decisions that are dogmatically driven based on ‘market research’ rather than the right course of action based on a long term perspective.
Maybe they do it because they like the idea of having windows drivers installed instead of sitting in linux forums asking all day .
Furthermore i like to add that Linux would kick ass if some cool asm-hacker would remake the mlinux kernel so that it ran all kinds of windows inf/dll drivers and strenghten directx support.
But until that eggheads realize that we’ll keep run games on windows or torture ourselves in winex and give linux shit about how some of our hardware don’t work.
I imagine it would be useful in a developing country like mine where the vast majority who want to use computers cannot afford even the cheapest Windows license but would like to use Win32 applications. I for one have tried an older beta and will try the latest beta again along with some applcations to see if I can deploy it on retired PCs here.
Why would there be any confusion as to an “authentic” react OS build? Do other open source programs sign their releases? Or do they anticipate it being a problem due to its Windows-esque behavior?
It’s likely something to do with the way Windows handles code signing – the certificates used to sign code have to be issued by a commercial CSA. In order to be compatible with Windows, ReactOS would have to use the same root certificates.
That said, I’m not sure why they’d be implementing that right now. Nor can I work out why they don;t just create their own root certificate, and sign the releases using that.
I don’t understand why ReactOS would need code signing for their drivers. Maybe I don’t want them? Solution follows
//if (check_driver_is_signed(driver))
//{
enable_driver(driver);
//}
//Am I missed something?
Perhaps this might be interesting to know, that ReactOS Foundation is already giving a hand with its VeriSign certificate to at least one another open source project, – DiskCryptor (http://diskcryptor.net/index.php/DiskCryptor_en). Maybe there others as well, but that’s one that I know of.
I’m just waiting and waiting until they got some usable version (i.e 3D acceleration and network), so I could dump Vista and become free…
Unfortunately ReactOS is the only viable option to a Windows (TM) user, since Linux is a useless crap and FreeBSD has even a worse position on the desktop.
No one will free us without losing all Windows-based SW except ReactOS… if they only could find an investor so they’d accelerate their progress… oh well…
I’ve -1 Trolled you because of the tone of your post and the following facts you were grossly inaccurate about:
* Linux already has 3D accelleration and network drivers (so it can already run many Windows games better than ReactOS)
* ReactOS already has ethernet network drivers – not tried wireless, but then I find even Windows to be buggy with WiFi with many cards. So I’m really not quite sure what you’re on about when you mention ReactOS’s lack of “network”.
* Ignoring games for a moment: Given ReactOS is BASED on a *nix app (WINE), it’s safe to say that Linux/BSD runs not that much less Windows apps (via WINE) than ReactOS does. So there already are workable alternatives to Windows (not that I want to discurrage this project either mind).
* and finally: Millions of people world wide already use Linux/BSD as their desktop OS (including myself). So clearly it is a viable desktop OS.
Sure, Linux/BSD maybe a different way of working to what you’re used to (package managers and different software suites as opposed to randomly downloaded untrusted EXEs and running Microsoft branded bloatware), but to argue that these differences make Linux/BSD useless is pure ignorance and trolling.
* Linux already has 3D accelleration and network drivers (so it can already run many Windows games better than ReactOS)
At the moment, yes, but I suspect that when ReactOS gets 3D acceleration working it’ll be a better alternative for gaming than Linux. Atleast I get subpar performance with WINE, and usually crashes or other issues. None of the games I want to play are playable under Linux on my machine. Atleast on ReactOS you wouldn’t need to translate Direct3D to OpenGL which should lead to better performance and you could use Windows-native graphics drivers which usually support more functionality than the open-source ones.
In the future there could be a package or wizard in Linux distros that will create a partition and bootloader option for ReactOS. There are many options for integrating ReactOS into Linux. After everything is installed into the partition the user could launch ReactOS using KVM (Kernel Virtual Management) if the user wanted to run programs that don’t require much complicated video or special things. If the user wanted a full on Windows experience then the user could reboot and choose ReactOS as boot loader option. Then once in this pure Windows environment the user could have access to the Linux filesystem and possibly load up Linux in a virtual environment. Perhaps a special driver would be needed for the ReactOS to Linux integration. That driver or configuration could be pre-installed or pre-integrated by the Linux distro.
So what I’m thinking is that when running the Ubuntu package manager or whatever you check the ReactOS box and then click Apply. ReactOS is downloaded from Ubuntu Repos and when it is done a dialog comes down asking you to configure some options and levels of integration. When you finish you have a super sweet Windows environment that is integrated in two directions in all kinds of cool ways.
Hell ya this would be sweet. Maybe we could have something like this is 4 years? What do you guys think?
Sounds good actually, but it’d require modifications to application menus, or an additional panel application to get some integration with virtual OS. It sure would be nice to have a few new menu entries whenever the VM was running: configure, browse disk, copy to/from clip board (even better would be to automatize that), synchronize calendar/mail/address book/etc.
Maybe some of these things could be done with a small TCP/IP server/client between the two OSs? Perhaps the same program code source could run on either OS depending which way you were virtualizing?
Then in the Windows software Add/Remove menu there would be a program called “Ubuntu Integration”.
Keep the dream alive people!
Maybe some of these things could be done with a small TCP/IP server/client between the two OSs? Perhaps the same program code source could run on either OS depending which way you were virtualizing?
Then in the Windows software Add/Remove menu there would be a program called “Ubuntu Integration”.
Sure, it’d be very easy to implement such functionality, you just need someone to actually do it. We have access to the ReactOS sources and all so there is nothing stopping us from having two-way integration. Too bad I don’t know a single thing about Win32 programming, otherwise I’d probably try something myself