Graphic subsystem “dead on the core”

What is commonly called “graphics in the kernel” usually refers to win32k. Win32k.sys is the core part of the graphics subsystem. It is loaded by the user process smss.exe during the initialization process of all other subsystems. The path to the executable image for the “kmode” subsystem is registered here:


How does this happen?


')
Here (on the stack trace at the bottom of the screenshot) you can clearly see that the win32k process initiates the smss user-mode process (which also initializes the paging files, the registry, environment variables, saves a memory dump, if it was a bugcheck before, through wininit it runs service) control manager and local security authority subsystem, creates a session logon, etc.), and one of the first things that win32k itself does is “building connections” with the kernel. And here's why: win32k is at a higher level than the kernel, so the kernel cannot have a dependency (by “dependency” in this case is understood the classic “reason to change”) from the concrete implementation win32k, but both the kernel and win32k can safe to depend on the interface. Such an interface is the KWIN32_CALLOUTS_FPNS structure and the function for registering a specific implementation of this interface in the kernel is PsEstablishWin32Callouts.

In addition, win32k registers several types of objects (in particular, Desktop and WindowStation) through general-purpose interfaces provided by the Object Manager.

Thus, the kernel has NO dependencies on win32k. Moreover, before NT4, all user / gdi APIs were processed in csrss and, of course, slowed down. Starting with NT4, the user / gdi primitive part was moved to the kernel to improve performance.

In general, win32k can be completely removed, you can replace your own nuclear part, and you can implement everything completely in user mode (using, for example, ioctls to communicate with the kernel), but this will slow down. The only reason this is not done is because it is not needed. You can write differently - yes, it’s much better to write - hardly. Well, rewriting for the sake of rewriting is not the best idea.

Practice - the criterion of truth or "MinWin on the knee"

To avoid misunderstandings, I want to immediately say: what I will do is not MinWin . This is no longer because the real MinWin contains a minimal set of user-mode binaries, but I’m going to demonstrate a fully loaded kernel (another difference is that MinWin contains a minimal set of drivers, but my set of drivers doesn’t change compared to normal booting ) without user mode at all (ok, one process and one dll there is still there, but you have to show the user that something is happening though). An additional reason for reflection may be the fact that the real MinWin appeared in connection with the work on the “stratification” of the code of Windows 7, the same thing that I will do in principle is possible on XP and even on NT3.51

So, if you thoughtfully read what is written in the previous section, you can guess that we need to replace smss with one that does not initialize the subsystems, but still remains more or less interactive. smss.exe is a normal native process (approximately, a native application is an application that links only with ntdll.dll and uses only the Native API for work). Fortunately for me, Alex Ionescu - the former chief developer of ReactOS - has already written a similar application in the framework of the (long closed) tinykrnl project. This application does not build under amd64, does not build on the last WDK, has several bugs, but generally works. The following image can be opened by the archiver - it contains the sources and the compiled amd64 binary of a small native.exe application:


I ask you to forgive me, but I can not lay out the finished image because it is illegal, so I post the code that can compile the vhd image from the installation image.
The following code can be executed ONLY on Win7. Save it somewhere in the temporary directory under the name, for example minwin.ps1, put install.wim next to it (located in the \ sources directory) from the Windows 7 installation disc (this is important - only the NLS files needed for this localization are copied) save the native.exe file from the image attached above to this directory, go to this very directory in the elevated console and do the following:

powershell -executionpolicy bypass .\minwin.ps1 

To be short:
1. Next to the same directory should be the following files: minwin.ps1, install.wim and native.exe
2. Run minwin.ps1 only after changing the current directory to the directory containing the above files

Disclaimer: you do all of the following at your own risk. The teams are fairly obvious and should not cause any harm, but this is a “knee-deep” creativity, so it does not have to work in any conditions. Do not execute this script if you do not understand the meaning of EVERY command (especially since execution must be done from under the elevated user). If not, below is a picture of how it looks in the end. In a simplified version, you can simply rename native.exe to smss.exe, copy it over the existing smss.exe in an already loaded virtual machine (any x64 Windows will work - from XP to 7) and reboot.
The script itself:

 $vhdName = "disk.vhd" $wimName = "install.wim" $vhdDisk = "V" $wimMountName = "MountedWim" md $wimMountName dism /mount-wim /wimfile:$wimName /index:1 /mountdir:$wimMountName #del $vhdName @" create vdisk file=$pwd\$vhdName type=expandable maximum=128 select vdisk file=$pwd\$vhdName attach vdisk create partition primary format fs=ntfs quick assign letter=$vhdDisk active "@ | diskpart bcdboot "$pwd\$wimMountName\Windows" /s "${vhdDisk}:" #cmd /c "$wimMountName\Windows\System32\bootsect /nt60 ${vhdDisk}: /mbr /force" $disk = gwmi win32_diskdrive -filter "Model = 'Msft Virtual Disk SCSI Disk Device'" $part = $disk.GetRelated("win32_diskpartition") | select -first 1 $bootmgr = [wmi]"root\wmi:BcdObject.Id=`"{9dea862c-5cdd-4e70-acc1-f32b344d4795}`",StoreFilePath=`"${vhdDisk}:\\boot\\bcd`"" $osloader = [wmi]"root\wmi:BcdObject.Id=`"$($bootmgr.GetElement(0x23000003).Element.Id)`",StoreFilePath=`"${vhdDisk}:\\boot\\bcd`"" $bootmgr.SetQualifiedPartitionDeviceElement(0x11000001, 0, $disk.Signature, $part.StartingOffset) $osloader.SetQualifiedPartitionDeviceElement(0x11000001, 0, $disk.Signature, $part.StartingOffset) $osloader.SetQualifiedPartitionDeviceElement(0x21000001, 0, $disk.Signature, $part.StartingOffset) $osloader.SetStringElement(0x12000002, "\Windows\system32\winload.exe") $osloader.SetStringElement(0x22000002, "\Windows") $osloader.SetBooleanElement(0x26000022, $true) md "${vhdDisk}:\Windows\System32\config\", "${vhdDisk}:\Windows\Fonts", "${vhdDisk}:\Windows\inf", "${vhdDisk}:\Windows\SysWOW64" copy -r "$wimMountName\Windows\System32\drivers" "${vhdDisk}:\Windows\System32\drivers" del "${vhdDisk}:\Windows\System32\drivers\termdd.sys" copy "$wimMountName\Windows\Fonts\vgaoem.fon" "${vhdDisk}:\Windows\Fonts" copy "$wimMountName\Windows\inf\errata.inf" "${vhdDisk}:\Windows\inf" copy "$wimMountName\Windows\System32\config\SYSTEM" "${vhdDisk}:\Windows\System32\config" copy "$wimMountName\Windows\SysWOW64\ntdll.dll" "${vhdDisk}:\Windows\SysWOW64" copy native.exe "${vhdDisk}:\Windows\System32\smss.exe" "ntoskrnl.exe", "hal.dll", "ci.dll", "pshed.dll", "clfs.sys", "kdcom.dll", "ntdll.dll", "apisetschema.dll", "winload.exe", "bootvid.dll", "bootres.dll", "l_intl.nls", "c_1252.nls", "c_437.nls" |% { copy (Join-Path "$wimMountName\Windows\System32" $_) "${vhdDisk}:\Windows\System32" } @" select vdisk file=$pwd\$vhdName detach vdisk "@ | diskpart dism /unmount-wim /mountdir:$wimMountName /discard 

It looks like this:


If everything is done correctly (and with some luck :-)), then after some time the file disk.vhd will appear in the same directory - it can be run in a virtual machine (tested in VirtualBox, but I see no reason why it shouldn’t work in Virtual PC, Hyper-V or somewhere else):


Well, a few comments at the end.

1. Almost 300 drivers are copied, about 100 are loaded, about 10-20 are really needed on a particular system.
2. The eight-megabyte SYSTEM hive from install.wim can be quite normally replaced by a two-megabyte from boot.wim, but you can even manually blind something into a hundred kilobytes.
3. bcdboot copies all localizations of bootmgr and several megabytes of fonts (mainly for CJK) - can be cut
4. You may notice that when creating an image, termdd.sys is deleted - this is not done because it does not work. It just creates another keyboard device (which in normal mode is used for “pressing buttons” on a remote machine in a terminal session), and I found it too lazy to modify native.exe to read clicks from all keyboards.
5. Boot graphics can be suppressed and discarded from bootvid.dll and bootres.dll

And most importantly, win32k.sys is not copied into the created image, which does not prevent this image from working relatively tolerably without any graphics at all. With a great desire, as I said, you can fasten a fully console shell, you can cut out the Windows subsystem and leave only Posix (it would be a very strange desire, as for me, but people often want a strange one). Or (even more strange desire) to implement native X11 on top of the NT core. You can replace smss and “fully control” everything that works above the kernel, or you can leave smss and a couple of edits in the registry to change the set of loaded subsystems. In short, there is simply no “tightly nailed to the core” graphics.

Thanks for attention