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.