Kernel Debugging with VirtualBox

Virtualization readily lends itself to debugging of low-level code that is difficult to analyze in conventional environments. It is also convenient for kernel debugging which would otherwise require two separate systems or at least a separate serial terminal.

OS/2

Setting up kernel debugging in OS/2 is quite simple: the standard retail kernel (OS2KRNL) on the target system (i.e. system being debugged) is overwritten by the debug kernel, typically distributed as OS2KRNLB, which includes the kernel debugger (KD). It is highly advisable, though optional, to also copy selected symbol (.SYM) files alongside their corresponding binaries. The symbol files are typically included on OS/2 installation media and available separately for fix packs.

The OS/2 kernel debugger assumes that a terminal is attached to a serial port, normally COM1. A terminal normally need not be attached to boot the system, but if a crash occurs, OS/2 will stop and wait for input from the debug terminal. Continue reading

Posted in Development, OS/2, VirtualBox | 4 Comments

How to please WDCTRL

As any user of 16-bit Windows knows, Microsoft Windows 3.1x in 386 Enhanced mode supported a coveted feature called 32-bit disk access (sometimes also called FastDisk). The “32-bit” designation was slightly misleading as there was no 32-bit data path to the disk; it just meant that the system could access the disk without leaving 32-bit protected mode.

The 32-bit disk access was implemented in a VxD called WDCTRL, built into the WIN386.EXE component. WDCTRL was nothing more and nothing less than an IDE hardware disk driver, named after the original Western Digital controller (WD-1003) used in the IBM PC/AT. WDCTRL replaced the INT 13h BIOS for disk access.

The advantage of WDCTRL was twofold. It avoided expensive switching between protected-mode and real-mode (that is, V86 mode) contexts, and also avoided the blocking nature of BIOS calls which only return after an operation completes and allow very little else to happen in the meantime. Not using the INT 13h BIOS service also avoided the need to copy disk buffer to/from memory addressable by the BIOS; WDCTRL could directly access memory anywhere in the system.

However, WDCTRL was very picky when determining whether to run, because if anything went wrong, severe data loss was likely to occur. The algorithm for determining whether WDCTRL could be used was quite involved.

Continue reading

Posted in BIOS, Windows | 3 Comments

Retro development with aclock

In the past few days, I embarked upon a project to port Antoni Sawicki’s aclock, a small text-based clock program (aclock stands for analog clock), to 16-bit Windows. While aclock itself has been ported to over 150 platforms, it is a console program, so a chunk of new Windows-specific code had to be written.

For guidance I went to Charles Petzold’s classic, Programming Windows, in the second edition which covers Windows 3.0. To keep things simple, the Windows version of aclock chooses one of the stock fixed-pitch fonts offered by Windows, calculates how many characters fit into the application’s window horizontally and vertically, and treats the window as a text console in order to draw the clock. The clock is updated every second and resized if the window size changes.

Continue reading

Posted in Development, PC history, Windows | 14 Comments

What’s in a name… OS/2 or DOS?

There have been many rumors that the name “OS/2” was chosen only shortly before the product was announced. It’s not entirely clear what the name would have been otherwise, but quite likely DOS 5; certainly DOS in some form.

There are various vestiges of the old naming; for example the OS/2 system call interface is implemented in a library named DOSCALLS.DLL—not OS2CALLS.DLL as one might expect. (It’s actually called DOSCALL1.DLL on disk for some unknown reason, although the internal module name is DOSCALLS, and the corresponding import library is DOSCALLS.LIB.) In the IBM C/2 compiler, version 1.0, libraries are named in the format SLIBC3.LIB and SLIBC5.LIB, where “3” means DOS 3, i.e. plain DOS, while “5” means DOS 5, i.e. OS/2. Later Microsoft compilers used “R” for real-mode DOS and “P” for protected-mode OS/2 libraries.

The OS/2 Museum recently scanned and converted into PDF a pre-release version of the Microsoft OS/2 1.0 Setup Guide. This document was published in April 1987, a quarter of a century ago, very soon after OS/2 was officially announced. It was shipped as part of the famous $3,000 OS/2 SDK in May 1987. The interesting fact about this manual is that except for the title page and preface, it nowhere mentions OS/2. Instead, it consistently talks about DOS. Continue reading

Posted in Documentation, DOS, OS/2, PC history | 1 Comment

How to make sure your program doesn’t run on Windows 95

For Christmas, I bought myself the book The Old New Thing by Raymond Chen, a long-time Microsoft programmer. The purchase was spurred by discovering, through Google Books, an excerpt of a riveting description of how various software titles abused the DPMI specification (and often common sense, too) in ways that made it difficult to run such software under Windows 95.

When I was nearly done reading my copy of the book, I realized that the protected mode programming treatise wasn’t there. Back to Google, I checked that my memory wasn’t deceiving me—yep, still there on Google Books. But for some odd reason, there are no page numbers in the excerpts of The Old New Thing that show up on Google Books, so I could not cross check with my printed copy. After a few more searches, I concluded that there are two appendixes which were probably never printed and only exist in electronic form. Continue reading

Posted in PC history | 10 Comments

DOS/V graphics text modes and scrolling

I recently ran into an interesting difference in the way various DOS/V versions manage VGA memory. DOS/V of course refers to the Japanese versions of DOS which are capable of running on standard “Western” hardware.

Microsoft has a very long history of supporting the Far East (how they used to be called) markets, especially Japanese and Korean, going back to the early 1980s. At that time, standard PC hardware was simply not capable of displaying Kanji ideographs; MDA had no user-definable fonts, and CGA had woefully low resolution. Systems tailored to the Japanese market used custom hardware, more or less incompatible with IBM PCs.

Once the VGA appeared, the technology was capable of emulating text modes using a relatively high resolution (for the time) graphics mode. MS-DOS/V versions 5.0 and 6.2 (released in March and December 1993, respectively; further referred to as DOS/V) both used a 640×475 graphics mode, slightly unusual but logical. The character cell was 19 pixels high and 8 or 16 pixels wide (Kanji ideographs, usually encoded as two bytes, were also displayed twice as wide as standard ASCII characters). To display an 80×25 text mode using a 19 by 8 pixel character cell, a 640×475 resolution is required. That’s not quite the same as the standard 640×480 VGA resolution, but it’s the closest lower resolution usable for relatively detailed glyphs and 80×25 grid. Continue reading

Posted in DOS, VGA | Leave a comment

Jumpy PS/2 mouse in Enhanced mode Windows 3.x

There’s an interesting (and quite annoying) bug specific to Windows 3.x running in 386 enhanced mode (also known as Windows/386) and using a PS/2 mouse. In some situations, the mouse may jump to the top or the bottom of the screen, especially when the system is somewhat unresponsive. The cause of the jumpiness turns out to be a subtle bug in VKD (Virtual Keyboard Device), a virtual device (VxD) which is part of Windows/386.

The way PS/2 mouse input is handled in Windows/386 is extraordinarily complex. The mouse driver (MOUSE.DRV) simply uses the BIOS INT 15h, sub-function C2h interface to register a mouse callback routine. The BIOS uses IRQ 12 and I/O ports 60h/64h to read data from the mouse. However, the VKD VxD inserts a whole new layer between the BIOS and the mouse hardware. Continue reading

Posted in Windows | 7 Comments

Simple Windows NT video miniport for VirtualBox

A few months ago, I developed a trivial video miniport for use in Windows NT virtual machines. The primary goal was to improve display speed and get past the 800×600, 16 color display mode which is the maximum Windows NT (up to an including Windows 2000) can handle out of the box on “modern” hardware. The miniport is designed to work with the synthetic SVGA “hardware” emulated by VirtualBox.

A secondary objective was to write the miniport in such a way that as many Windows NT versions could be supported with a single binary. That objective was fulfilled beyond expectations; the driver binary works with every x86 version of NT from the initial July 1993 release of Windows NT 3.1 up to and including Windows 7 released in October 2009. Windows 8 appears to drop the video miniport interface and thus cannot be supported. Continue reading

Posted in NT, VirtualBox | 26 Comments

Microsoft OS/2 1.0 user documentation

In late 1987, Microsoft shipped a set of OS/2 1.0 user documentation as part of the OS/2 SDK. The set included the Setup Guide, Beginning User’s Guide (a tutorial style document), and User’s Reference. The manuals were similar in style to DOS documentation from that era and likely produced on XENIX using the standard UNIX document production tools (i.e. troff and related utilities).

The manuals shipped by Microsoft were not entirely finished. Some of the more involved explanations were incomplete, screenshots were missing, and a few illustrations weren’t provided. That said, end users were not expected to see those manuals. Instead, OEMs would adapt (or completely rewrite) the OS/2 documentation provided by Microsoft. Continue reading

Posted in Documentation, OS/2 | 3 Comments

Converting NT DDK/SDK PostScript documents to PDF

Pre-releases of Microsoft’s NT development tools, as well as the final NT 3.1 SDK and DDK, shipped with a full set of printable documentation in PostScript format. The PostScript book-style document were rather more pleasing to the eye than the WinHelp format, and especially for the explanatory “guide” material, some readers found them much nicer to work with.

But really, who wants thousands of pages of dead tree matter? The complete SDK/DDK documentation set ran to somewhere in the 10,000 pages range. It should be easy to convert the PostScript documents to PDFs and obtain a nice set of easily viewable and searchable documents. It should be easy… It’s anything but. Continue reading

Posted in Documentation, NT | 5 Comments