How does Windows(/ReactOS if it is same) handles EXE loading of specific subsystem?
What are differences between CUI/GUI handling?
Not CRT main WinMain, but init of CreateProcess.
What's the role of csrss.exe process
Windows subsystem handlers
Moderator: Moderator Team
Re: Windows subsystem handlers
Here is a simplified overview of the Windows / ReactOS architecture:
After initialization, the NT kernel (ntoskrnl.exe) loads the Session Manager SubSystem process (SMSS.EXE) which then loads some subsystems. By default it loads the Windows subsystem, constituted by:
1- The Client-Server SubSystem process (CSRSS.EXE) (and its helper dll, csrsrv.dll), and the Windows GDI driver win32k.sys (handles all the graphics part).
2- Then CSRSS loads other dlls (basesrv.dll and winsrv.dll) which constitute the "Windows Subsystem" and are used by kernel32.dll etc...
On Windows NT 3 / 4 / 2000 / Xp / 2003 / Vista, the CSRSS hosts (amongst other little things) the console server (via winsrv.dll, which gives consoles to console applications) and the "terminal" window which appears when a Win32 CUI app starts (this functionality was moved in Windows 7+ into conhost.exe).
When you start a Win32 app (GUI or CUI), CreateProcess (inside kernel32.dll) is called, checks the subsystem of the application being launched (it reads its PE header for retrieving this value), does some signaling to CSRSS, and starts accordingly a subsystem: for a Win32 GUI app, nothing special is done, for a Win32 CUI app, there is a connection to the console server so that it can initialize the console subsystem for the application, display the "terminal" window, initialize the standard IO handles and so on..., for a POSIX app, there are calls to CSRSS which calls SMSS for loading the POSIX subsystem, for a OS/2 character-mode app, almost the same things are done... (the latest two subsystems, POSIX and OS/2, don't exist on ReactOS).
If you start a DOS or Win16 application, the CreateProcess function starts the NT Virtual DOS Machine (NTVDM) (some calls are done to basesrv.dll which store some initialization code, ntvdm.exe is loaded).
See Windows Internals 4th edition for further information
Code: Select all
Win32 User-mode applications
^
|
V
kernel32.dll ; advapi32.dll ; etc...
^
|
V
---------------------------------------------
Windows / ReactOS subsystem:
csrss.exe and csrsrv.dll ; basesrv.dll ; winsrv.dll
^
|
|
smss.exe
Native User-mode:
ntdll.dll
^
---------------------------|--------------------------------------------------
V
Kernel mode: hal.dll <--> ntoskrnl.exe ; drivers ; file-system drivers ; win32k.sys
^ ^
-------------------|------|---------------------------------------------------
V V
Hardware
1- The Client-Server SubSystem process (CSRSS.EXE) (and its helper dll, csrsrv.dll), and the Windows GDI driver win32k.sys (handles all the graphics part).
2- Then CSRSS loads other dlls (basesrv.dll and winsrv.dll) which constitute the "Windows Subsystem" and are used by kernel32.dll etc...
On Windows NT 3 / 4 / 2000 / Xp / 2003 / Vista, the CSRSS hosts (amongst other little things) the console server (via winsrv.dll, which gives consoles to console applications) and the "terminal" window which appears when a Win32 CUI app starts (this functionality was moved in Windows 7+ into conhost.exe).
When you start a Win32 app (GUI or CUI), CreateProcess (inside kernel32.dll) is called, checks the subsystem of the application being launched (it reads its PE header for retrieving this value), does some signaling to CSRSS, and starts accordingly a subsystem: for a Win32 GUI app, nothing special is done, for a Win32 CUI app, there is a connection to the console server so that it can initialize the console subsystem for the application, display the "terminal" window, initialize the standard IO handles and so on..., for a POSIX app, there are calls to CSRSS which calls SMSS for loading the POSIX subsystem, for a OS/2 character-mode app, almost the same things are done... (the latest two subsystems, POSIX and OS/2, don't exist on ReactOS).
If you start a DOS or Win16 application, the CreateProcess function starts the NT Virtual DOS Machine (NTVDM) (some calls are done to basesrv.dll which store some initialization code, ntvdm.exe is loaded).
See Windows Internals 4th edition for further information
-
- Posts: 31
- Joined: Wed Mar 18, 2009 7:53 am
Re: Windows subsystem handlers
The newest edition of that book is the 6th edition. (BTW, The 6th edition Includes the information of Windows 8, and the Windows 7 part first appears in the 5th edition. The 4th edition only contains Windows Vista and its predecessors.)hbelusca wrote:See Windows Internals 4th edition for further information
Re: Windows subsystem handlers
Exactly However I cited the 4th edition because it covers up to Windows Server 2003, which is the project's compatibility target. Some architecture changes appeared starting Windows Vista (and 7), that's why I didn't mention it.jihao1234567 wrote:The newest edition of that book is the 6th edition. (BTW, The 6th edition Includes the information of Windows 8, and the Windows 7 part first appears in the 5th edition. The 4th edition only contains Windows Vista and its predecessors.)hbelusca wrote:See Windows Internals 4th edition for further information
-
- Posts: 31
- Joined: Wed Mar 18, 2009 7:53 am
Re: Windows subsystem handlers
I just want to mention him/her that which edition includes Windows 7 information.hbelusca wrote:Exactly However I cited the 4th edition because it covers up to Windows Server 2003, which is the project's compatibility target. Some architecture changes appeared starting Windows Vista (and 7), that's why I didn't mention it.jihao1234567 wrote:The newest edition of that book is the 6th edition. (BTW, The 6th edition Includes the information of Windows 8, and the Windows 7 part first appears in the 5th edition. The 4th edition only contains Windows Vista and its predecessors.)hbelusca wrote:See Windows Internals 4th edition for further information
Who is online
Users browsing this forum: No registered users and 9 guests