ReactOS is an effort to re-create the WindowsNT platform, in an open source sense (GPL). The team works towards source compatibility with NT’s applications and drivers by re-creating the Microsoft APIs. More developers are always welcomed in the project, but there is already a number of them working for the last 3 years, splitted into several teams. Jason Filby, head developer of ReactOS, answers to a series of questions regarding the project.1. What is the difference, technically-speaking, between ReactOS and PetrOS? Both OSes try to use the WinNT4 OS model and drivers.
Jason Filby: On the PetrOS home page it says that PetrOS is going to be compatible
with MS-DOS and Windows 95 (FAQ section). So is PetrOS really looking
at NT driver and application compatibility? It looks as though they
are more or less supporting a Win32 API level of compatiblity at
best.
Aside from this, an important difference between the two projects is
that PetrOS is commercial software while ReactOS is Open Source under
the GNU General Public License.
2. Why don’t you try to be compatible with XP or Win2k, which are younger OSes than NT4 and will support newer hardware?
Jason Filby: Windows XP and Win2k are systems that have been built on NT 4 —
they’re upgrades. This means that most of what we’ve done is
compatible with the newer OSs. There are no big changes to the APIs
from what we’ve seen, mostly just additions. When we’re coding, we’re
looking at what the new OSs have that we can add. Officially, we say
we’re going for NT 4 compatibility because there’s much more
information out there compared to the newer OSs.
3. What is the status of ReactOS today? Is there a GUI for the OS already being developed and how is the driver support progressing?
Jason Filby: At the moment we have no GUI for ReactOS. We are still busy
constructing the GDI which will provide APIs to support a GUI. The
GDI has some good basic functionality at the moment, but there’s
still a lot to be done.
Networking support is also something that’s seen as important, but
we’re still far from having adequate support in this area.
Driver processing is looking good. We can’t load NT drivers just yet,
but we are nearing this point. The registry has come a long way, but
that also needs a lot of work.
4. When trying to mimic or be compatible with another OS, in order to be compatible in source level (and even more in binary level) you may have to implement even the bugs of that OS. Does ReactOS implement the bugs of NT4 too, or are you trying to find workarounds for the problems?
Jason Filby: We haven’t found this to be a problem yet. Still, it’s bound to
happen and we’ve discussed what we’ll do: provide files that are
compatible even if they’re buggy and files that do what they should
how they should. Then the users can choose what they want.
5. What are the immediate plans for the ReactOS development teams? What are the teams are working on at the moment?
Jason Filby: Right now documentation is a big issue, including tutorials and
references. More on the development side, we’re trying to iron out
bugs and make what we have relatively stable and complete. This
includes major work on the kernel and system libraries. The GDI and
networking do receive attention, but not at the same priority. We do
plan to step up work on the GDI in the immediate future, however.
6. OpenBeOS is a new community driven OS effort to try to be source, and if possible binary compatible, with the abandoned by Be, Inc., BeOS. What would you advise these developers, as their effort is very similar to ReactOS one as you already have 5 years of experience of building an OS based on another OS?
Jason Filby: They should minimize discussion on design. If you’re trying to be
compatible with another OS with regards to architecture, this can
remove a lot of this discussion. Even then, they should always
remember that discussion and coding must be balanced.
Too many OS projects fail because they’re too busy:
– discussing design (this IS necessary, but make sure discussions get
resolved and don’t drag on forever)
– going off-topic by trying to reinvent the wheel — revolutionary
GUI, revolutionary filesystem… (cool projects are fun, but if your
OS doesn’t even boot.. why?)
– setting up websites and teams, repeat every few months (this
happens a lot in projects where everyone is afraid to write code)
In the end they have nothing because nobody ever got round to coding
anything. Without code people will eventually get disillusioned and
leave. Don’t make this mistake!
I also recommend that they look at what the most common applications
need and focus on that. Don’t spend months trying to implement APIs
that are hardly used.
7. What are the biggest obstacles and technical problems you encounter on ReactOS?
Jason Filby: One of the biggest problems right now is the process of getting new
developers up to speed. That’s why we’re looking at putting much more
effort into the documentation.
Another huge problem is time. Seeing as we’re all volunteers working
on this project, sometimes development seems really quiet while other
times its a hive of activity. People have other commitments and
things going on in their lives. This is a point that Peter Tattam
made to me about commercial software, that you get to spend the bulk
of your time on the project. But if we did that, how would we be
different from Microsoft?
Technically, it can be really hard to try and keep compatibility
going with APIs that aren’t very well documented. It can also be very
difficult to understand some of the more complex APIs.
8. Which GUI Toolkit are you using for ReactOS? Something written from scratch, or something like QT or Qube?
Jason Filby: There has been a lot of discussion on the list about this recently.
We’re leaning towards writing something from scratch, though. This is
because a lot of the shells out there for Windows take advantage of
some APIs that can actually be considered part of the GUI…. but you
know Windows, the lines are always blurred between the window
manager, the shell, the browser… I could go on.
9. Does ReactOS support SMP?
Jason Filby: Yes, ReactOS does support SMP, but its very basic at this point.
10. How is the performance of ReactOS when compared to WinNT4?
Jason Filby: At this stage its very difficult to say. We haven’t tried to do any
tests because competing with NT through performance is a very low
priority at the moment. Right now we’re just focusing on getting
everything working.
These inteviews about OSes that are still in their early stages are great
They are a ton of fun to read.
I’m curious… why don’t these guys just help out with the WINE project? Why reinvent the wheel?
See that they have a blue.sys in their kernel binary tree. Now I don’t have to pay $$ to see a blue screen.
What the hell this team doing? Does anybody _really_ need something like this? When ReactOS 1.0 Release will be ready Microsoft will already make Windows 3000, or something like this… It’s simply stupid… It will be really better to help, for example, WINE project…
I have search for these kind of Open Source OS’s and I must say, ReactOS is the best I’ve seen. When you read the mailing lists, these guys know what they are doing and there is a lot of commitment by the developers who do it in their free time.
They have come a long way and it isn’t just a project that’s stuck or abandoned it’s constantly under development, I like it! 😉
Great work Jason and Co.!
ReactOS’s MAIN goal is total binary -and- driver compatability.
Wine emulates the Windows API. This is a critical part of emulating Windows applications. However it does not emulate Windows itself. It does not, for example, make it possible to run your Windows 2000 nVidia geforce3 driver on Linux.
Wine is designed to be totally compatible. So far, Windows 2000 and XP are really just minor ‘icing’ on Windows NT. Once ReactOS is complete with NT4 compatability, adding on to build up to the latest OS will be -easy-!
Some files of Wine are pure Win32 code (I don’t know how much). Those files can/will be used in ReactOS.
——–
There’s also OWP (Open Windows Project – http://www.owpcentral.com) which has quite the same goal. I don’t understand, why ReactOS and OWP don’t team up.
The OWP project maintainer seems more interrested in being the project manager of an open source OS than writing a usable OS. The ReactOS team has asked the OWP team to merge, but the OWP team seem to don’t care at all.
This is what the OWP team has come up with in a year:
ftp://ftp.owpcentral.com/Kernel/owp-kernel16-alpha4-12272000.zip
They have spent more time redesigning their website than actually writing an OS.
I can understand doing this for the fun factor, after all complex programming does give you a buzz, but it seems a waste of time, nobody is going to use it.
Why not get involved with some of the other cool projects out there that are trying to do something new, AtheOS springs to mind, or maybe OpenBeOS.
Just my 2 pence.
I wish them good luck. Coz’ they gonna NEED it!
doing something that some could see as pointless…
or commenting on it being pointless?
This must be the best OS for the future, if they make it.
NOT a Microsoft product but hopefully compatible to most of the Windows software.
Based on Open Software and not emulated environment.
Due to the legacy of NT architectur, multiprocessor support and better multitasking and memory handling than Win9X.
If they also add X11 grapics support then they also have all the Linux source compatible software available.
Perfect for the gaming community with Windows games.
This must be better then Linux, I’m waiting for ReactOS.
Why dont all the other groups join ReactOS development.
Well, I don’t know if this project will work. Some years ago I have never touched or used a UNIX platform. But now that I have a LINUX platform I like it. But some people don’t like UNIX because they say is too difficult to learn,
So they prefer to stick with Windows. I’m trying to educate the people about the new Windows XP (That actually is a trap). But hey what we gonna do if Microsoft discontinue Windows 98/Me/2000. I would be very difficult to people like me that my job is selling new computers.
Well, I wish the best for ReactOS. But I sincerely I will stick with Linux.
Just some comments on what Jason said about minimizing discussion on design, and history of the project. I am one of the original 2-3 founders of the ReactOS project (long before Jason got involved I believe). It was originally called FreeWin95, and the idea came from Yannick Majoros (I cant spell his last name). After he left the project, we changed project leaders, and underwent a name change to WOS (Windows Operating System). When Jason became leader (he is a great leader,
, we were Co-Leader’s for a while, but since he did more work anyway because of my lack of technical knowledge in the low level stuff, I let him take over all leadership responsbilities, and became Beta Testing Team Coord.), anyway, we opened up discussion for a new name. I dubbed it ReactOS, because it was our reaction to Microsoft’s monopoly, bleh bleh bleh….
Anyway, I just wanted to second Jason’s comment that you need to minimize design discussion. This is why 99.9% of OS projects NEVER go anywhere. Freedows, which started around the same time as ReactOS(FreeWin95), never went anyone because of this. In fact, I think they split into two OS projects, and are still in discussion stage. I was a leader in that project for a while, before I realized it was going no where, and spent many long hours on the phone with Freedows founder Reece, from canada (the prodigy kid who was in College at age 14 or something
). If you want to go somewhere, you need to start coding from the beginning, and not spend years talking about design. It even took ReactOS a while to learn this, and any major progress didnt happen until we decided it was time to code and talk about design along the way (roughly before Jason took over the helm, when Brian was running it things started to get done).
If find ReactOS very interesting.
Wine plus ReactOS is more than the sum of the two.
Sounds crazy, or like some linux zealots dream. However just as there are open source rivals to Microsoft there are corperations who have been working to dethrone them. I’ve heard of a GUI OS called aurora out of Japan. From what I have heard about its features it will destroy Microsoft with thier own method. Useless eyecandy and nifty features, like a AI assistent. You could tell it “Send finished work to jeff” and it finds what you where working on, checks the email address DB, finds the jeff you work with and sends. Mind you this AI program is represented by a human figure onscreen. Keep in mind this is somewhat vaporware as I have never seen a development version. Just the promise that it is comming, and America will be unable to compete.
So my question becomes this, what more will you do above and beyond NT 4.0, 2000 or whatever version Microsoft it pushing out the door today, to top international offerings? Or is this beyond the scope for the next few years?
Simple. ReactOS is a kernel based on the NT design philosphy.
NT’s actual design is not bad. Much as people might complain about Microsoft, their programmers are actually fairly intellegent. I suggest you get the book ‘Showstopper’, about NT’s original development.
That said, ReactOS is based on NT design, planned to be NT and Windows compatible. This is mostly due to the large amount of Software available for Windows. It will be GPL’ed, and open to just as much hacking and the like as Linux is.
That said, it’s hardware support will be fantastic due to the ability to support NT/2000/XP drivers… and it could be expanded with a BSD/SkyOS style Linux emulation layer and god knows what else
But remember, it’s still early.
Comparing Petros & Reactos.
They are not too similar. We have decided to not go for binary driver compatibility because it would lock us in too tightly to the way MS does things in the kernel. The OS would likely be hamstrung as a result, or we might lose our flexibility at least. We do use PE executable format for all system components though. There has been some discussion about driver compatibility recently in our forums and I’ve had to be firm in our direction regarding this. Jason is right in saying that we’re mainly interested in the upper level win32 compatibility. We also have our native API which can be coded against. It makes for smaller memory footprints for executables so the alternative API could be useful in embedded environments. We want to explore the multiple API direction with API’s customized to specific purposes.
Jason talks about us being able to dedicate more resources to a project when it is commercial. Overall, I would say this is true as I have more resources to call upon, especially ones like legal and other administrative resources. That doesn’t mean to say that I don’t get busy with other things too though. I have a life outside of software and I also have a company to run which can consume precious time.
The other advantage is that I don’t need to contend with developer design discussions which have slowed down other OS projects. I suspect you will find that the most rapidly developing OSes are ones where there is a single developer who does most of the coding and doesn’t bother with discussions of design and stuff. I personally am not afraid to try something out quickly to see if it works & am quite happy to throw away code that is obsoleted as a result. Some sections of petros have seen significant change over the past year or so because the way it was done before was inappropriate to future directions. We’ve been criticized for the lack of progress on a GUI. That’s because, like Jason, I’ve been putting the hard work into fundamentals of the OS. A stable and powerful OS is much more important than a pretty GUI and the GUI is more likely to develop faster when I don’t have to contend with OS bugs.
In my study years, we talked of several ways to approach a software project, and there were several models around at the time. There was the “army of ants” approach used by very large corporations – it was very inefficient because productivity dropped as you added more & more members to the project. Conversely, there was another approach called the “super programmer” model. This was where a single programmer was responsible for building the entire project (or large autonomous subsection). I heard tell that the Burroughs (now Unisys) B6000 series mainframe operating systems were designed and built by 3 super programmers. This model I believe still works today, and is especially true of OS development. I believe an OS is one of the more complex of programming tasks because fundamentally you are trying to create an abstract well defined user layer on top of a typically badly defined, poorly documented and often buggy hardware structure. This demands that all team members have an intimate knowledge of every section of the kernel, and how it intereacts with the hardware. Building a team that has such characteristics is a hard task, and that’s typically why you end up with projects of one, or a project that has one key developer.
The other issue I’d lke to raise, and I think it’s worthy of a feature interview is that of WINE. Now I would love to see WINE reach it’s sweet spot, but I believe that it’s crippled by having to use other APIs like X and the native OS API calls. If they could build a graphics subsystem directly into WINE and do a lot more of the basic API stuff closer to the kernel, it would be a big winner. My educated guess is that the way Windows does things as opposed to the way unix does things also is a large factor in performance and compatibility.
I’ve been asked to help with the WINE project several times, and also asked why we don’t use WINE instead of doing our own GUI. The answer to the latter is that I would probably spend as much time writing glue code from WINE to the PetrOS API as I would by writing the GUI directly. The answer to the former is that very likely the licensing models of WINE and PetrOS are a bit incompatible for our requirements, and the risks of GPL code leaking could cause us a lot of grief. The prudent choice for us is to at least get our our GUI working and work from there. I would love to research WINE to determine how feasibile it would be to port a version to PetrOS, but the time we’d spend just doing the study is not something I’m prepared to risk. Because of this, I only have a basic knowledge of WINE and how it works – please excuse my ignorance if I have got things wrong.
To those more knowledgeable about WINE I ask, can WINE be improved to remove its dependence on X and Unix. If that happened, my guess is that performance and compatibility would improved and we (and others) would be much more interested in using it.
Peter