(This is a guest post by Antoni Sawicki aka Tenox)
Do you remember the famous Windows NT Blue Screen Of Death? For years it was a source of jokes and bad reputation of Windows reliability.
There even was a Blue Screen Saver. Today we fortunately see much less of it, but it still is there, reminding us that Windows NT internally is in fact a text mode operating system. The 1989 NT Design Workbook tells us that in the early days of development, before OS/2, Win32 subsystems or any GUI were developed, there was an ANSI console and bunch of command line utilities running in the text mode. Sadly all were removed in the retail version. The only true text mode application left around was autochk. Since the day Aclock was conceived I always wanted to run it on the NT text mode boot screen. In it’s twisted logic it actually makes a perfect sense.
So how do you actually output to the BSOD screen? Initially there was a lot hope in Windows NT Native Application, which can use NtDisplayString() function to display text before GUI takes over. Mark Russinovitch has written a sample Native Application with source code. Unfortunately I soon realized that NtDisplayString()Â does not allow for any control characters that would let me position the cursor or clear the screen. It doesn’t let much more than to display “Hello World” during Windows boot. This unfortunately wasn’t what I was hoping for. Out of lack of further ideas the project was shelved for nearly 10 years until I recently got some help from a real windows insider.
The new hope came from a HalDisplayString() and it’s helper functions HalQueryDisplayParameters() and HalSetDisplayParameters()which return screen resolution in characters and allow to position the text cursor. Exactly what I needed! Unfortunately these functions are part of the NT Kernel and there was absolutely no hope of calling them from user mode, even a Native application.
So a device driver version of Aclock was conceived. Err WHAT? Yes! A Windows Kernel Mode Device Driver version of Aclock. It sounds like craziest idea and most ridiculous waste of time ever. Worse than that, it definitely is! Despite that, development of the driver was actually surprisingly straight forward and the most difficulties I had was to do with setting up the right environment. It required Windows NT 4.0 SP6, an old version of NTDDK, SDK and Visual Studio. Once I had the project set up correctly, the only thing left to do was to figure out the kernel mode equivalents of some of the things I was getting for granted, for instance sleep(). My last surprise was rather unexpectedly difficult access to floating point in the driver. I was advised to avoid, so I have generated a pre computed tables of sin and cos values for every minute on the clock dial.
Aclock running on Windows NT BSOD in Kernel Mode
I must say that VMware Workstation Snapshots came very handy for launching and testing of the driver. It spared me from constant rebooting and re-launching the whole environment. I could load aclock and literarily click “back” like in a web browser.
Links:
Since running the driver on your own system will render it unbootable (you can always do a snapshot or use last known good configuration) I have built a minimal Windows NT Embedded (NTe) image that loads the driver on startup. It’s available as OVA image.
Windows NT Embedded project
The next steps may involve porting AA-Lib to NTHAL. From there the possibilities are unlimited aalib-quake? 😉
Update:Â Video
