[ros-dev] FreeWin95

[Alex Ionescu]

Emanuele Aliberti wrote:

> Hi Gunnar Dalsnes,
>
>> I dont understand what this "fight" is about. Could you and Alex 
>> elaborate? I would take part in this discussion too, if i only knew 
>> what it is about;-)
>>
>> G.
>>
>> Emanuele Aliberti wrote:
>>
>>> I just want to warn you are going to build FreeWin95 with WDM support.
>>>
>
> There is no "fight". Just a "disagreement with some design choices", 
> as correctly Jason said. Probably a vote will eventually close it. 
> But, as you too ask for, a technical discussion is required, 
> presenting arguments pro and contra.

I view this as a "misunderstanding with some design choices", if not 
even a "misunderstanding of NT Subsystem design".

>
> The design choice, in short, is the rôle of the "Client/Server Runtime 
> SubSystem" (CSR=CSRSS.EXE+CSRSRV.DLL) in the design of the "O.S. 
> Personality" code, that is the emulation code that manages processes 
> of the same operating system in user mode, making them belive to run 
> on the emulated O.S.

The Client/Server Runtime SubSystem, which is unfortunately incorrectly 
named by Microsoft, is actually the Win32 Personality. It manages Win32 
processes in user-mode, and allows them to access kernel features which 
would pollute the native-mode ntdll.dll, would they have been included 
there. Only Win32 processes use csrss and registration is done in 
kernel32. Console windows, another Win32-ism also use csrss. Because NT 
was designed with a set of universal native APIs, this was necessary so 
that routines useful to only one personality wouldn't be exported as 
native APIs. For example, fork() is a POSIX-only API, not Windows 32. 
Therefore, it was not included in ntdll.dll, even though the kernel 
supports it. Instead, it's used by the POSIX subsystem. The same goes 
for Console windows and their APIs, which are usable only in Win32. 
Access to the video hardware is done in kernel-mode, but the functions 
are called through CSRSS.

Now, CSRSS is in a way a Client/Server Subsystem, because it's merely a 
4KB host to CSR Servers, which implement parts of the Win32 behaviour. 
The 3 servers currently used are: basesrv.dll, which handles SxS (Side 
by Side assemblies, a Windows XP feature), VDM (16-bit emulation) and 
stuff like Process/Thread creation, winsrv.dll, which handles some 
graphical things and windowmessage-related functionality (such as 
hardware event dispatching) plus all the Console code (winsrv is 
internally split into 2 CSR Servers). I think a big problem here is that 
ea believes that CSRSS is the place where you would add a POSIX 
subsystem. This isn't the case. CSRSS is reserved for Win32 CSR Servers.

Now, let's move on...what actually loads CSRSS? This is called SMSS, the 
Session Manager SubSystem. The Session Manager handles all the 
subsystems that are installed on an NT Machine. By default, this means 
CSRSS, the Win32 subsystem. If you install SFU 3.5, or are using Windows 
Server 2003 R2, you will also get psxss.exe. On older Windows, you can 
also have os2ss.exe. These are the POSIX and OS/2 subsystems. They have 
nothing to do with CSR at all, and they are actually, in themselves, 
CSRSSes for their own subsystems. This is the naming mistake I was 
talking about; Microsoft should have named csrss as w32ss.exe.

So, SMSS is the first process that will load, and it will then load the 
subsystems, say csrss psxss and os2ss. These subsystems will then load 
server dlls which expose functionality that can be called from user-mode 
processes.

As I'm writing this, my Win2K3 machine is running posix grep and working 
perfectly. It's not touchign CSRSS at all, nor should it have to. CSRSS 
is a win32 subsystem.

>
> Think about it like the program run by the Architect in Matrix: when 
> you double click on Microsoft Word's icon and the process is created, 
> it happily belives to run under Windows, it can see the familiar 
> libraries, it can call CreateFile and get back a reasonable file. In 
> fact, CreateFile calls NtCreateFile and so on. Microsoft Word lives in 
> a fake World. ;)
>
> The two opposite directions the CSR can turn for are:
> - be a process totally bound to the Windows personality

Which it's -supposed- to be. CSR is W32SS.

> - be a general purpose process, a facility for any kind of personality

Other personalities don't need CSR! They have PSX and OS2 and VMS and etc...

>
> More on demand.
>
Another issue which ea has brought up is that NT is somehow to 
"connected" to Win32. I beg to differ. I've spent a week working on a 
sample native application. It currently can display running processes, 
drivers, create a new process and create/delete/list files. Here are 
some screenshots:

http://members.tripod.com/WinAlOS/rtlcli.png
http://members.tripod.com/WinAlOS/rtlcli2.png
http://members.tripod.com/WinAlOS/rtlcli3.png

Note that there is no CSR, no win32k.sys loaded. NT is running in its 
rawest form. You need less then 16MB of memory (notice that the 
processes are using <1MB, the rest is up to the drivers, which you can 
disable) and about the same amount of diskspace. This works perfectly in 
Windows 2003 without any need to "separate win32".

Best regards,
Alex Ionescu