Minor technical discoveries

In Windows 7 and prior, without DWM on (or maybe with it on, I'm not entirely sure about the architecture), the desktop was drawn by the kernel driver win32k.sys (Windows User), which implements most of the actual Windows user environment. The desktop itself is actually just a window, but it's window procedure is stored in this kernel-mode code, so there's no practical way to modify it.

Basically, in these older versions, the window procedure for the desktop (xxxDesktopWndProc) would call a paint procedure (xxxInternalPaintDesktop) which would call xxxDesktopPaintCallback for each monitor, and this would be responsible for painting the desktop background and things like the build string. Prior to Windows 8.0, this checked if the user had a wallpaper set and called xxxDrawWallpaper if this was the case, otherwise it would call simply FillRect for the solid background (screenshot).

In Windows 8.0, they removed all functions relating to drawing the desktop background from Windows User, leaving it to only handle drawing a solid background (screenshot). This is probably where they released the two user-mode wallpaper hosts: WallpaperHost.exe from the Windows 8+ PE, and Explorer.exe. If I had to guess, they probably made this change in order to use newer technologies, such as the user-mode-only Windows Imaging Component, to be used for drawing the desktop wallpaper instead of GDI. (Although I have not looked into how either WallpaperHost or Explorer handle it.) This is possibly a change that Microsoft were meaning to make since Vista or 7, but they could only get around to it after deprecating classic theme completely in Windows 8.

By the way, I can't exactly tell if Windows 7 checks if the User environment is composited (DWM) for the desktop paint routine, but Windows 8+ completely skip calling xxxInternalPaintDesktop if the desktop is composited (screenshot). This must mean that drawing the desktop watermark (i.e. Windows version) is also handled by DWM since Windows 8.

Fun quick post because of the anniversary of NT 3.5!

I've been looking into the history of the Windows window manager for a while now, and one thing that is peculiar is how they changed the storage of window manager icons in Windows NT 3.5.

If you didn't know, Windows 3.1 stores all window manager icons (including the mouse cursor, window caption buttons, scroll buttons, etc.) in each video driver, which is why changing these icons involved modifying the video driver. Supposedly, this was a feature to allow OEMs to use custom icons by shipping a custom video driver with different icons.

NT 3.1 does the exact same thing, but NT 3.5 seems to have changed the storage a little bit. I'm not sure if 3.5 supported custom OEM icons at all, but it is certainly true that the default icons were moved from being stored multiple times in each default video driver to only one time in winsrv.exe. NT 4.0 changed this architecture once more: when pretty much all of winsrv was moved to kernel-mode code in win32k, all icons that were previously stored in winsrv.exe were moved over to user32.dll, where they remain today.

It's also fun how the Windows 2.0 (or OS/2 Presentation Manager? There is an MDI state for the system menu button, which I don't think should have existed when Windows 2.0 was designed...) caption button bitmaps persisted through Windows 3.1 and Windows NT 3.51. You can see them pretty easily if you open up NT 3.1 VGA.DLL or NT 3.5x WINSRV.EXE in Resource Hacker. Speaking of which, I don't actually know anything like Resource Hacker for Win16 or OS/2 NE binaries, only for Win32 PE binaries.

I intend on writing more on this subject in the future, but this is all that I'm really comfortable saying on the subject for now.

Apart from OEM bitmaps, the Windows 3.0 window manager (which NT 3.x inherited) seems to originate from the OS/2 Presentation Manager for the most part, and is functionally just a high-colour (VGA) reskin of the Windows 2.x window manager (which was designed for lower colour video cards such as EGA), so it makes sense that they would use bitmaps for historical reasons. This was still GDI though. Since Windows 3.x supported more than 96 DPI scale, however, there were multiple fixed size bitmaps as well as variations designed for any other non-standard scale.

95 and NT 4.0 replaced these with real-time-rasterised vector buttons which have scalable glyphs drawn by the Marlett vector font; fonts were the most effective way to implement scalable vector graphics at the time. XP obviously went back to bitmaps because of the desire to have more visually complex themes. NeXT-style 3D buttons like what Windows 95 introduced are very simple to draw compared to rounded corners and complex gradients.