A lot of media outlets and, generally, people in the tech community, have approached the subject of ARWINSS, a new development for the ReactOS free and open-source Windows compatible operating system. There have been speculations that it will boost application compatibility instantly, that the developers will do away with their code and start fresh using Wine code, or that it will require and X Server to work.In the ReactOS Newsletter, Issue 68, developer Z98 took the time to clear up on this issue. First and foremost, he makes it clear that this new development doesn't mean that they're chucking out all their code and switching to the Wine implementation. Also, the win32 subsystem is something that makes sure your applications will work, and that the functions they call in the kernel or the other libraries will be handled correctly.
Even if ARWINSS, the Wine-based win32 implementation, looks like a very good replacement for the current system that ReactOS uses, it isn't a drop-in replacement. Since Wine is designed to work more or less like a middleware between the applications and the different components of a typical open-source operating system, it relies on an X Server being present and various system calls are passed on to the Linux or BSD kernel. From this layered design, the code that would be usable in ReactOS sits only on the upper layers. Because of this, the current win32 implementation and ARWINSS will be developed in parallel, and the system that will prove to be superior in the long run will be adopted.
It might be argued that an X Server wouldn't be such a bad idea after all, but that falls down to a single problem: performance. ReactOS doesn't aim to be only application-compatible to Windows, it is also designed so that existing native drivers would work. This raises a major problem: an application would first make a call to the win32 subsystem, which would translate it to an X call, which in turn would have to be able to interface with the kernel and the video drivers that are in place. To make matters worse, the X Server is traditionally a user mode application, and the video driver resides in kernel mode, further slowing down the system. That's why the ARWINSS code makes use of winent, a driver wrote specifically to make the link between ARWINSS and the kernel's video components.
Overall, only time will tell if this ReactOS development will be a good choice, or if it will be shelved as something that appeared to be a good idea, but didn't pay for itself programming-wise. For the more in-depth look, read Issue 68 of the ReactOS Newsletter.
Even if ARWINSS, the Wine-based win32 implementation, looks like a very good replacement for the current system that ReactOS uses, it isn't a drop-in replacement. Since Wine is designed to work more or less like a middleware between the applications and the different components of a typical open-source operating system, it relies on an X Server being present and various system calls are passed on to the Linux or BSD kernel. From this layered design, the code that would be usable in ReactOS sits only on the upper layers. Because of this, the current win32 implementation and ARWINSS will be developed in parallel, and the system that will prove to be superior in the long run will be adopted.
It might be argued that an X Server wouldn't be such a bad idea after all, but that falls down to a single problem: performance. ReactOS doesn't aim to be only application-compatible to Windows, it is also designed so that existing native drivers would work. This raises a major problem: an application would first make a call to the win32 subsystem, which would translate it to an X call, which in turn would have to be able to interface with the kernel and the video drivers that are in place. To make matters worse, the X Server is traditionally a user mode application, and the video driver resides in kernel mode, further slowing down the system. That's why the ARWINSS code makes use of winent, a driver wrote specifically to make the link between ARWINSS and the kernel's video components.
Overall, only time will tell if this ReactOS development will be a good choice, or if it will be shelved as something that appeared to be a good idea, but didn't pay for itself programming-wise. For the more in-depth look, read Issue 68 of the ReactOS Newsletter.
No comments:
Post a Comment