The OS/2 subsystem is being developed to enable NT-like systems (like WinNT and ReactOS) to run 32-Bit OS/2 applications natively. With this it shall provide binary compatiblility on x86-Based systems. It is intended to port the ROS/2 also to other platforms supported by ReactOS / NT. It is planned to provide source code compatibility on these platforms. Yeeahh, OS/2 for PowerPC is in sight.
ROS/2 consists of the following components:
Up to now just a fragment of DOSCALLS.DLL exists. The biggest problem are the os2 API headers which are (C) by IBM. So help is still welcome.
It is not intended to support 16-bit OS/2 applications. This would make the system inconsistent and produce much more work that use. But there is still one issue: Current textmode applications are either 16-bit or use thunking to call the 16-bit APIs. These 32-Bit thunking applications have to be supported. We are still thinking how to accomplish that.
It is planned to replace the current MOU- KBD- MSG- and VIO- subsystems with the Unicode Console API. This is also the foundation for other platforms we want to provide source code compatibility with. So nearly every 32-Bit processor can be supported. It sould even be possible to implement a 64-bit OS/2 API.
To understand the architecture of ReactOS or WinNT read a book from the "Inside
Windows NT"-series. The architecture of ROS/2 is like every normal subsystem.
When OS2SS.EXE starts, it creates an object directory named os2 and therein
it creates a port object with the name Os2API. A port is something like a socket.
Two programs can comunicate with each other via a port. The port Os2API provides
the LPC API of the OS2SS.EXE - the actual subsystem.
Every OS/2 program that is loaded, is linked with DOSCALLS.DLL and NTDLL.DLL - the interface to the NT-kernel. Since DOSCALLS is implemented using NTDLL.DLL, every OS/2 app has it in its adress space. Many functions in DOSCALLS.DLL are implemented by just wrapping NTDLL.DLL functions. Some functions however need assistance by the subsystem. For this reason the app makes an LPC to OS2SS.EXE. LPC means local procedure call and it is a very fast version of RPC. Together with the first application also OS2.EXE starts up. OS2.EXE runs in the win32 subsystem with the security of the current user. OS2.EXE is used to gather keyboard and mouse input and to show console windows and PM-windows of all OS/2 programms of the current user. In order to accomplish this OS2.EXE creates a port object in the os2 object directory named Os2Interact. OS/2 applications have a connection to OS2.EXE, too. OS2SS.EXE and OS2.EXE also talk to each other. An OS/2 application then makes LPCs either to OS2.EXE directly or if required via OS2SS.EXE.