The OS/2 Display Driver Zoo

Posted on October 14, 2025 by Michal Necasek

I have recently explored (again) the possibility of writing a high-res display driver for virtualized OS/2. But I ran (again) into a dizzying array of possible solutions, each with its own advantages and a good deal of drawbacks.

OS/2 display drivers underwent something of a rapid evolution in the 1992-1996 timeframe. The OS/2 Warp 4 DDK comes with no fewer than four significantly different display driver code bases, which reflect this evolution.

Warning: This article is long! It contains notes from research into the evolution of OS/2 display drivers, DDK sample code, and accompanying documentation. Much of the article is something of a signpost, showing where to find what.

OS/2 1.x

In the days of OS/2 1.x, things were simple. Display drivers were 16-bit, written in assembler (out of necessity more than anything else), and there was only one driver model. The drivers for OS/2 Presentation manager (PM, code name Winthorn) were circa 1987 cloned from Windows 2.x display drivers, since the inner workings (bitmaps, patterns, brushes, fonts, ROPs, and all that jazz) were very similar. Like Windows drivers, OS/2 display drivers worked by “compiling” (dynamically constructing) code to implement various drawing functions.

800×600, big enough for OS/2 1.1 command prompt window

OS/2 1.1 (1988) supported device driver interface (DDI) version 1.0, being the first Presentation Manager release. The interface resembled Windows 2.x and was just as ugly.

In OS/2 1.x, the Presentation Manager shell (PMSHELL.EXE) directly linked against the display driver, which had to be named DISPLAY.DLL–much like in Windows 3.x and earlier the display driver had to be called DISPLAY.DRV.

Continue reading →
Posted in Development, Documentation, Graphics, IBM, OS/2 | 12 Comments

Messy Mastering

Posted on September 29, 2025 by Michal Necasek

Large companies like IBM, Microsoft, or Novell typically had a well defined process for releasing software on floppies. More often than not, files were not directly copied onto a physical floppy; instead, a tool was used to create an image of a floppy disk from distribution files, and the image was then sent off for mass duplication.

Quite often, timestamps of files were set to a predefined value when creating the image. That practice is probably as old as timestamps in the FAT file system. PC DOS 1.0 kept track of the date when a file was modified, but not the time of day. PC DOS 1.0 has all non-system files set to a 08/04/1981 date, although it is theoretically possible that this was a result of normal file manipulation.

A somewhat strange IBM TCP/IP 2.0 for OS/2 Base Kit (1994)

With PC DOS 1.1, there is no ambiguity. The timestamps of all files are set to 12:00:00 on 05/07/1982. Floppy disks are not nearly fast enough to write all those files within two seconds (the FAT timestamp resolution), even in the extremely unlikely case that someone sat there waiting until exactly noon to start the operation. It is a given that IBM artificially set the timestamps of all files to match, and that was before the PC was even a year old.

It is notable that Novell followed a different strategy and strictly kept the original timestamps of shipping files. It was common that different releases had some files with matching timestamps and some files different. One could be reasonably confident that two files with the same name and timestamp were in fact identical. That was not always the case with IBM or Microsoft, where two files with different timestamps were often identical. And in rare cases, two different versions of a file were distributed with the same timestamp, arguably completely defeating the purpose of timestamps.

Continue reading →
Posted in Archiving, Floppies, IBM, Kryoflux | 18 Comments

8×19 Text Mode Font Origins

Posted on August 15, 2025 by Michal Necasek

I was recently made aware of something that I had noticed before, but never paid much attention to. Consider this screenshot of a BIOS POST screen:

Intel AN430TX board POST screen

VGA text modes usually use 720×400 resolution and 8×16 fonts (expanded to 9×16). The above screenshot uses 640×480 resolution (VGA graphics), but it is with a high degree a certainty a text mode, using a custom 8×19 font. The BIOS is a Phoenix BIOS 4.0 Release 6.0, running on an Intel Anchorage (AN430TX) board.

For the sake of clarity: The screenshot was taken by digitizing the analog VGA output of a physical AN430TX board with an integrated ATI Rage 3D graphics chip. The VGA connector was plugged into a Lantronix Spider KVM, which was used to save the screenshot. It is not a screenshot of an emulated system.

Some of the earliest examples of boards with an 8×19 font were reportedly Intel Anchorage AN430TX (see above) and Intel Atlanta AL430LX (one of the first AGP-capable boards), both released in 1997. These were probably the first boards using Phoenix BIOS after Intel had been using AMI BIOS for several years, a fact which may or may not be relevant.

Continue reading →
Posted in BIOS, Computing History, Intel | 39 Comments

More than Two Hard Disks in DOS

Posted on July 22, 2025 by Michal Necasek

Investigating the rather odd behavior of the Microsoft OS/2 1.21 disk driver led me to Compaq and their EXTDISK.SYS driver. While experimenting with various setups, I realized that DOS versions older than 5.0 do not support more than two hard disks exposed by the system’s BIOS, and will in fact quite likely hang early during boot-up if there are “too many” hard disks.

This seems to have been one of the many things that “everyone knew” back in the day, similar to the fact that DOS versions older than 3.3 may hang while booting from disks with significantly more than 17 sectors per track.

As was the case with the “too many sectors per track” problem, the issue with “too many hard disks” was missed for years simply because no one had a PC with more than two hard disks. This was a technical rather than architectural limitation. While the IBM PC/XT and PC/AT BIOS implementations were limited to two hard disks, the INT 13h interface as such was not.

In the days of full-height 5¼” drives, it simply was not feasible to install more than two hard disks into a PC, especially when a 5¼” floppy drive was also required. Even the big IBM PS/2 Model 80 (1987) with a tower case could only house two full-height 5¼” drives. There might also be trouble with the power supply, as the PC hard disks of the time were not designed for staggered spin-up and a standard AT power supply might have trouble spinning up four drives at the same time.

Sure, there were half-height hard disks, but who wanted four drives in the first place? People who needed to maximize the storage capacity… and the most obvious way to do that was buying a large capacity drive, which in the 1980s was inevitably a full-height 5¼” monster. Like my 1988-model 650 MB ESDI drive, for example.

Yes, there were solutions like the NetWare DCB which supported many drives, but those were only usable by NetWare and did not expose the drives via INT 13h.

Two things happened circa 1988. One was Compaq releasing the Deskpro 386/25 with an expansion unit option, a system which supported up to four hard AT-style disks (that is, the expansion unit housed up to two ESDI drives accessible via the PC/AT hard disk style programming interface, which may be called WD1003 or WD1010 or several other things). The other development was Adaptec releasing the AHA-1540/1542 SCSI HBA, and there were perhaps other SCSI vendors as well.

Continue reading →
Posted in Bugs, Compaq, DOS, Microsoft, PC history | 83 Comments

Learn Something Old Every Day, Part XVII: DHCP and ARP Don’t Mix in WSA SMP

Posted on July 19, 2025 by Michal Necasek

I just spent an inordinate amount of time debugging a VM running OS/2 Warp Server Advanced SMP (WSA SMP). The VM was working fine (except for sometimes hanging very early during boot, a known issue with the SMP kernel), but TCP/IP networking just would not work.

It’s not that networking did not work–using LAN Server with NETBEUI (that is, NetBIOS Frames protocol) worked fine. So I started digging deeper. I soon realized that Warp Server was unable to resolve hardware addresses using ARP. It sent out ARP queries, but never received any response. That is, the other end did send an ARP response, but it just seems to have vanished somewhere in the ether before it could get processed by the TCP/IP stack.

I tried to find out what debugging tools were available. I checked the packet statistics–nothing received. OS/2 comes with a pair of handy debugging tools, IPTRACE and IPFORMAT. These are sort of like an old-timey Wireshark, working on the IBM TCP/IP protocol stack. Sure enough, IPTRACE/IPFORMAT showed that ARP packets were going out, but the replies weren’t coming in.

If I manually added the requisite ARP entries (using arp -s) then TCP/IP happily sprang into action. But without that, no luck. Nothing worked because the system could not even figure out how to talk to the gateway. The only thing that worked was DHCP, because by definition the DHCP client does not need to know the server’s address (either IP or hardware).

Continue reading →
Posted in Bugs, IBM, Networking, OS/2, TCP/IP | 3 Comments

1990 Networking: LAN Manager 2.0

Posted on July 16, 2025 by Michal Necasek

In 1990, Microsoft released LAN Manager (LM) 2.0, a member of a long line of Microsoft’s networking products that started with MS-NET circa 1984 and eventually morphed into Windows NT file sharing.

Microsoft LAN Manager 2.0 admin interface

LAN Manager 1.0 was released in 1988 as an OEM-only product, with the largest OEM being 3Com and their 3+Open. Microsoft collaborated with 3Com1 and the two companies jointly published the NDIS specification for network drivers. However, the relationship soured in 1990 after Microsoft decided to sell shrink-wrapped LAN Manager directly and bypass OEMs.

LAN Manager 2.0 (2.0b) installation disks

The OS/2 Museum owns a boxed copy of Microsoft LAN Manager 2.0 from circa December 1990, but recently a pirated copy of LM 2.0 from June 1990 came to light, found right next to MS OS/2 1.21 disks. That brought an obvious and simple question: When was LAN Manager 2.0 released? The answer, is unfortunately far from simple.

Besides the warez archive, there is physical evidence that Microsoft built something at the end of June 1990 and that it was the “final” release of LAN Manager 2.0. Normally a press release would answer a lot of questions, but one for LM 2.0 has remained rather elusive so far. The closest thing we have is this press release about OS/2 1.21 from August 1990. But it happens to be highly relevant.

Continue reading →
Posted in 3Com, LAN Manager, Microsoft, Networking, PC history | 10 Comments

Learn Something Old Every Day, Part XVI: DOS 4.0 SELECT Is Too Clever

Posted on July 2, 2025 by Michal Necasek

A while ago I discovered an antique pirated copy of IBM DOS 4.00 on 5.25″ media, which was something that was missing in my archive. And by antique I mean from August 1988, when DOS 4.0 was practically brand new.

IBM DOS 4.00 installer, SELECT (1988)

There were SNATCH-IT disk images in files DOS400-1.ARC to DOS400-5.ARC (DOS400-6.ARC includes the disk from the IBM DOS 4.0 Technical Reference, not part of the OS per se). There were two problems. At first, I didn’t know what to do with SNATCH-IT images at all, and also the image of the install disk (DS40INST.CP2) was corrupted, with ARC reporting a CRC error.

Once I sorted out SNATCH-IT image decoding, I was left with the corrupted disk. The corrupted image was 60 bytes longer than it should have been, but it was actually mostly OK. A “feature” of old compressors like ARC is that they work with blocks of several kilobytes in size, and if one is lucky, one block will be corrupted but the rest won’t.

I set out to determine where exactly the SNATCH-IT image was corrupted. Armed with the knowledge of the format, I found the corruption was in one of the data blocks (large chunks, a few dozen kilobytes in size, that hold bare sector data) and not in any of the control structures. So far so good; since I have images of 720K disks of IBM DOS 4.00, I would likely have good files to recover from the damage.

Then I tried to cut out the extra 60 bytes while causing minimal damage. That was tricky because the sector data was stored interleaved in the SNATCH-IT image. In the end I localized the damage and created a semi-fixed DS40INST.CP2 which I could convert to a raw image.

Continue reading →
Posted in Archiving, DOS, IBM, PC history | 17 Comments

Where Did CP852 Come From Again?

Posted on June 27, 2025 by Michal Necasek

An earlier article explored the history of codepage 852 (Latin-2 PC codepage) in released and pre-release versions of DOS and OS/2. At the time of this writing (June 2025), the earliest OS/2 build with some form of CP852 support including keyboard layouts and explicit knowledge of countries using CP852 (Czechoslovakia, Hungary, Poland, Yugoslavia) was OS/2 2.0 build 6.64 from March/April 1990. The first officially released OS with CP852 support was DOS 5.0 in June 1991.

Czech support using CP852 in DOS 4.0 with an NLS add-on

There is confusion as to how old CP852 is. IBM’s globalization registry suggests that CP852 is from 1993, but that is patently impossible because it was included in the DOS 5.0 release in 1991. And the article referenced above clearly demonstrates that CP852 existed in early 1990.

In fact there is every reason to think that CP852 is a contemporary of CP855 (Cyrillic PC codepage) which is supposedly from 1988, or perhaps even a contemporary of CP850 (Latin-1 PC) from 1986.

Continue reading →
Posted in DOS, I18N, IBM, PC history | 28 Comments

Learn Something Old Every Day, Part XV: KEYB Is Half of Keyboard BIOS

Posted on June 16, 2025 by Michal Necasek

Recently I had an opportunity to reacquaint myself with the DOS KEYB utility. KEYB is interesting in that it is designed primarily for international users, but one can also run KEYB US to load KEYB with standard US layout.

It is obvious that the KEYB utility was written by IBM. Unlike most of DOS, KEYB not only uses documented BIOS interfaces, but makes quite a few assumptions about how the keyboard BIOS works internally, in ways that were never documented.

This starts when KEYB loads and needs to detect whether the system BIOS supports extended keyboards or not—that is, whether the BIOS supports INT 16h functions 10h and 11h. To do that, KEYB calls INT 16h function 92h. Which is not, in fact, a BIOS function at all.

Rather, KEYB knows exactly how the IBM INT 16h implementation works. KEYB expects that when encountering an unsupported (too high) function, BIOS INT 16h keeps decrementing register AH until it decides that it’s too low, and then returns with that modified AH. On systems with extended keyboard support (newer PC/AT systems and most later machines), AH will be decremented to 80h. On old systems, AH will be decremented to somewhere around 8Eh. On machines with 122-key support, AH will be decremented even further, below 80h. In any case, KEYB executes INT 16h/92h and if the resulting AH value is 80h or less, it assumes that extended keyboard BIOS should be enabled.

Because KEYB “knows” exactly how the keyboard BIOS works, it gets away with only overriding half of it. While KEYB installs an INT 9h handler (corresponding to IRQ 1, or the keyboard hardware interrupt), it leaves INT 16h (the user callable BIOS keyboard service) untouched. In fact, the INT 9h handler in KEYB clearly started its life as a copy of the INT 9h handler in the IBM PC/AT BIOS, which only IBM could legally do.

Continue reading →
Posted in BIOS, DOS, IBM, Keyboard | 16 Comments

1989 Networking: 3+Open LAN Manager 1.1

Posted on June 4, 2025 by Michal Necasek

The previously mentioned warez dump on archive.org contains a lot of little gems that would have been otherwise lost. One of those might be 3Com’s networking package from 1989, the 3+Open LAN Manager version 1.1.

3+Open LAN Manager admin interface

The software was released in August 1989, a few months before OS/2 1.2 became available, and well over a year before Microsoft released LAN Manager 2.0. In the late 1980s, Microsoft produced LAN Manager 1.x, but their distribution strategy mirrored OS/2 and DOS. Microsoft did not sell LAN Manager to end users but rather licensed it to OEMs, and 3Com may have been the biggest of those.

3Com collaborated with Microsoft on LAN Manager development and co-developed the NDIS specification for network drivers; that is why 3Com copyrights can be seen even in later Microsoft networking software.

Continue reading →
Posted in 386MAX, 3Com, DOS, LAN Manager, Microsoft, Networking, OS/2 | 21 Comments