The video miniport driver for VirtualBox has been updated. The miniport now supports a much broader range of resolutions, up to 1920×1200. Color depths of 32, 24, 16, 15, and 8 bits per pixel are supported for all resolutions, although Windows typically filters out some of those.
The above screenshot shows Windows NT 3.50 running in 1680×1050 resolution (16:10 aspect ratio), providing an impressive amount of screen real estate. Continue reading
Sometimes, the old and the new intersect in unexpected ways. After upgrading to a Sandy Bridge based system (Core i7) and Windows 7 SP1 64-bit some time ago, I noticed that debugging exceptions in 32-bit user programs didn’t quite work right. Recently the issue has been brought to my attention again and I had to do some digging.
The symptom of the problem is that when a debugger stops on a second chance exception, the context of the (32-bit) process being debugged is damaged and the debugger stops in a bogus location, namely ZwRaiseException or NtRaiseException (same thing with two different names). That is a huge problem when the debugged process handles certain exceptions. The debugger can’t stop on every first chance exception, because those occur in the normal flow of execution. Yet if a real bug pops up and causes an unhandled exception, the debugger will not show where the problem is! Continue reading
I recently spent some time trying to access disks shared by a Windows 7 machine from various versions of OS/2 (running in VMs, although that’s not really relevant). The OS/2 clients ranged from OS/2 1.3 with LAN Manager 2.1 (1991 vintage) to MCP2 (released in 2001/2002), in all cases configured to use only NetBIOS over TCP/IP transports.
This endeavor was far more difficult than it should have been. One part of the problem is that the default Windows 7 configuration is inimical to all older Microsoft/IBM network clients, including DOS, Windows 9x, and old versions of Windows NT. That is more or less obvious and relatively well documented.
With the necessary changes on the Windows 7 side in place, OS/2 clients can connect to Windows 7 shares and browse disks. However, attempts to access files more often than not result in SYS0240: The network connection is disconnected. Continue reading
The virtual flat framebuffer driver, or VflatD, was introduced in Windows 95 in order to ease development of display drivers. It was surprisingly poorly documented and the sample drivers did not illustrate its use very well.
A short backgrounder may be in order. Traditional VGA adapters accessed all of their 256KB of video memory through a 64KB aperture at physical address A0000h. Because of the unusual four-plane memory organization, the 64KB aperture was enough for covering four times 64KB, or 256KB. A distinguishing characteristic of Super VGA adapters was that they sported more than 256KB of video memory; perhaps 512KB, perhaps 1MB, perhaps more.
However, accessing that memory was not easy. The 64KB aperture was no longer sufficient to address all video memory. Linear framebuffer access was not always available, in part because it was difficult to use from 16-bit software, in part because mapping a megabyte or more in the 16-megabyte ISA address space was problematic. Super VGA adapters therefore supported bank switching, i.e. controlling which part of the larger framebuffer the 64KB aperture at A0000h accesses. The simplest case was a single read-write “window” which could be positioned with 64KB granularity. Continue reading
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.
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
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.
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.
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
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
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
