Learn Something Old Every Day, Part XI: DOS Directory Searches are Bizarre

A while ago I started playing with EMU2, a piece of software which calls itself “A simple text-mode x86 + DOS emulator”. It is indeed relatively simple, only emulating an 8086 (or maybe 80186, with little bits of 80286 here and there), but it’s in some ways quite capable, doing a remarkably good job of running at least some text-mode DOS programs (such as the Turbo Pascal IDE).

Spurred by the release of the MS-DOS 4.0 source code, I thought I’d see if I could use EMU2 to build MS-DOS 4.0 on a non-DOS system. It did not go well.

The MS-DOS 4.0 source BAK includes almost everything needed to build, with the exception of COMMAND.COM, which is required by NMAKE to execute certain commands. OK, I thought, let’s just grab an existing MS-DOS 4.0 COMMAND.COM.

Not even a single DIR command worked right. After a bit of tinkering, I got that working, only to find that TREE.COM was hopelessly broken. And I found other programs mysteriously failing, such as Watcom wmake (wmaker.exe to be exact, since the default 386-extended version has no chance of running under EMU2).

In the process I learned a lot about how DOS directory searches work, and what kinds of seemingly crazy things DOS itself does.

Continue reading
Posted in Development, DOS, Undocumented | 53 Comments

Learn Something Old Every Day, Part X: The VGA Attribute Controller Is Weird

A few days ago I finally swatted a VGA emulation bug that I had known about for several years, but couldn’t identify until recently. The problem affected only Windows 3.1 running in Standard mode. It did not occur in Windows 3.1 running in 386 Enhanced mode, and it did not occur in Windows 3.0 Standard or 386 Enhanced mode.

The failure mode was rather interesting. Start Windows 3.1 in Standard mode, then start a DOS box. No problem there. Use Alt-Tab to switch to the Windows desktop, no problem. Use Alt-Tab to switch back to the DOS box—still no problem. Use Alt-Tab again to go to the Windows desktop (no problem) and then again to the DOS box: Blank screen!

Running ‘MODE CO80’ in the blank DOS box would restore visibility but a few Alt-Tab round-trips would result in a blank screen again.

After a little bit of poking around it was clear that the screen was blank because bit 5 in the VGA attribute controller index register (at I/O port 3C0h) was not set… but why? I had a strong suspicion that the problem had something to do with the attribute controller flip-flop, but couldn’t figure out what exactly.

Continue reading
Posted in Bugs, PC hardware, VGA | 9 Comments

How Not To Release Historic Source Code

This is how to not do it:

GitHub

Don’t get me wrong, it’s absolutely brilliant that Microsoft was able to release a fairly complete (minus DOSSHELL) source code for MS-DOS 4.00 or 4.01 (see below). As much as it was hated, DOS 4.0 was an important milestone and DOS 5.0 was much more similar to DOS 4.0 than not. This source code will be an excellent reference of modern-ish DOS until Microsoft officially releases the long ago leaked MS-DOS 6.0 source code. The source code includes all required build tools, which makes building it (compared to many other source releases) extremely easy.

But please please don’t mutilate historic source code by shoving it into (stupid) git.

First of all, git does not preserve timestamps, which causes irreversible damage. Knowing when a source file was last modified is valuable information.

Second of all, the people releasing the source code clearly thought, hey, it’s source code, let’s shove it into git, what could possibly go wrong. Well, this is what could go wrong:

Nope, not building

For practical purposes, old source files are not text files. They are binary files, and must be preserved without modification. It is not OK to take an old source file and convert it to UTF-8. For one thing, UTF-8 didn’t even exist in the times of MASM 5.10 and Microsoft C 5.1, of course old tools can’t deal with it!

The above problem was most likely caused by taking a source line using codepage 437 characters and badly converting them to UTF-8. That made the source line too long, past the circa 512 byte line length limit of MASM.

Continue reading
Posted in Development, DOS, Source code | 82 Comments

The Future That Never Was

Microsoft OS/2 2.0 SDK Pre-Release 2, June 1990

In 1990, the strategic PC operating system of Microsoft and IBM was not DOS, not Windows, but OS/2. The first 16-bit OS/2 was initially released in 1987 with a reduced feature set, but by the end of 1989, OS/2 1.2 completed two major features: The Presentation Manager GUI (first seen in OS/2 1.1) and installable file systems, notably the new HPFS file system.

OS/2 1.2 desktop

Since before the initial release, Microsoft talked about a 386 specific version of OS/2, with support for a 32-bit, flat model API, and much improved DOS support utilizing the 386’s virtual 8086 (V86) mode.

In 1987, 386-based PCs were few and far between; IBM wanted an operating system better than DOS then, rather than years in the future, and Microsoft had been working on “Advanced DOS”, still 16-bit but utilizing the 286’s protected mode, for several years. The result was OS/2 1.x.

By 1990, the number of 386 and brand-new 486 systems had been gradually increasing. 386-specific software, such as memory managers (“LIMulators”) and DOS multitaskers (including Microsoft’s own Windows/386), was becoming more popular.

Just before the end of 1989, Microsoft made available the first pre-release version of the long promised 32-bit OS/2 2.0, which was intended to be the first mass-market 32-bit PC operating system. This was accompanied by a press release detailing the $2,600 OS/2 2.0 Software Development Kit (SDK).

Unfortunately, the December 1989 pre-release of OS/2 2.0 may not have survived to the present day. But in June 1990, Microsoft shipped the second pre-release of the OS/2 2.0 SDK. And that version has now turned up, after twenty years of searching, and almost 34 years after its release!

OS/2 2.0 SDK Pre-Release 2 box

The SDK specimen was in original unopened box, with printed documentation and everything.

OS/2 2.0 SDK Pre-Relase 2 on 5.25″ media

Here’s what the June 1990 pre-release of OS/2 2.0, also known as build 6.78, looked like when installed:

OS/2 2.0 build 6.78

It looked awfully similar to its 16-bit contemporary, OS/2 1.2. The big tell was the lack of the DOS icon in the lower left corner (the one and only limited DOS box in OS/2 1.x, also known as “DOS coffin”), and more importantly, the addition of DOS Window and DOS Full Screen icons in the Main group.

To put the OS/2 2.0 pre-release in perspective, it came out almost simultaneously with Windows 3.0, a year before DOS 5.0, almost two years before the release of OS/2 2.0, and over three years before Windows NT 3.1.

Continue reading
Posted in 386, IBM, LAN Manager, Microsoft, OS/2, PC history, Pre-release | 76 Comments

Unlocking NetWare 2.0a

A few months ago, the OS/2 Museum obtained a seemingly complete and error-free set of floppies with SFT NetWare 286 Level II version 2.0a. And just recently, a disk set of Advanced NetWare 86 2.0a turned up, though sadly incomplete.

Both releases are from 1986 and share one rather unpleasant feature: The NetWare OS won’t run without a hardware key card:

No NetWare for you, pirate!

All or most old NetWare versions sold before circa 1988 needed a custom hardware key which had to match the serial number that was burned into the NetWare disks. I’m not sure what the exact history was, but it is known that the NetWare serial number could be provided by Novell’s DCB, or Disk Coprocessor Board:

Novell DCB, an early SCSI HBA

I don’t quite understand what was the point of selling a custom disk controller and requiring a serial number match. But NetWare 2.0a could also run on off the shelf hardware using standard AT disk controllers and drives. For those machines, Novell provided a simple key card:

A NetWare key card. There’s not much to it!

I’m not entirely sure if Novell was more worried about piracy by end users or by unscrupulous resellers. In any case, in 1986, during the era of NetWare 2.0a, a hardware key was required by NetWare.

Needless to say, if you are incredibly lucky and find a complete NetWare 2.0a disk set, and the disks are actually readable, the chances of also having the matching hardware key are close to nil. And even if you did have one, that does not at all help when trying to run NetWare 2.0a in an emulator. So, what do we do?

Continue reading
Posted in NetWare, Software Hacks | 21 Comments

Tarbell to Cromemco

While playing around with old versions of 86-DOS, I came across a disk image of 86-DOS 1.14. I ran the older 86-DOS versions in the SIMH simulator which can emulate the Cromemco disk controller supported by 86-DOS.

Unfortunately the 86-DOS 1.14 disk was meant to be used with the different and incompatible Tarbell disk controllers. SIMH doesn’t emulate the Tarbell controller and the disk can’t be booted.

Then it occurred to me that 86-DOS came with all the required source code and it should be possible to adapt the Tarbell disk to use the Cromemco disk controller instead. The two 86-DOS variants (Cromemco and Tarbell) used the exact same 8″ floppy format (77 tracks, 26 sectors of 128 bytes each), just the disk controller was different, and therefore only the boot loader and the I/O system (both within the reserved tracks) were different; the actual files on the FAT file system were identical.

Everything necessary is on the 86-DOS 1.14 disk, all that’s missing is a way to edit and reassemble the source files and put the resulting object code into place on the disk. But that’s actually not too difficult either — the only additional requirement is an 86-DOS disk that boots in SIMH. And fortunately there is a suitable 86-DOS 1.10 disk. With that in hand, it is possible to attach both the (bootable) Cromemco 86-DOS 1.10 disk and the (non-bootable) Tarbell 86-DOS 1.14 disk to SIMH and boot.

Continue reading
Posted in Development, DOS, PC history | 16 Comments

Misconceptions on Top of Misconceptions

While researching the precise meaning of the Ctrl-Z (26 decimal, hex 1Ah, ASCII SUB) character in DOS, I was somewhat taken aback by this article which purports to correct a common misconception.

The article is, for the most part, entirely correct. The handle-based file API in DOS 2.0 and onward deals with pure binary files and no byte has any special meaning. Any special meaning that the Ctrl-Z character might have in such files is generally implemented in application programs and run-time libraries.

However, the statement that “MS-DOS didn’t have an End-Of-File character of any sort” is grossly misleading. The statement that “The treatment of character 26 and the handling of “text” files was a shared delusion, […] wholly layered above DOS itself” is simply untrue.

First of all, claiming that COMMAND.COM is “just an application” requires stretching the definition of what is “DOS” to the breaking point, and likely beyond. Sure, COMMAND.COM is not part of DOS… now try booting DOS without it.

And COMMAND.COM certainly ascribes special meaning to Ctrl-Z — for example when interpreting batch files, processing stops at a Ctrl-Z character. Again, claiming that batch files are merely an application construct, not part of DOS, is contrary to most people’s understanding of what DOS is.

But it’s not just COMMAND.COM. The DOS kernel itself (MSDOS.SYS in Microsoft’s releases) very much does ascribe special meaning to Ctrl-Z. One look at DOS 1.25 MSDOS.ASM is enough to ascertain that DOS does treat Ctrl-Z (look for ‘1AH’ in the source code) specially.

Continue reading
Posted in DOS | 21 Comments

86-DOS Revisited

At the end of December 2023, several disk images of very old versions of Seattle Computer Products 86-DOS unexpectedly turned up. This includes previously unseen releases of 86-DOS version 0.11 and 0.34 (going by the version number in the 86-DOS kernel).

Just how old these releases are is somewhat difficult to establish. Unlike 86-DOS 1.0 from April 1981, the older versions used a different format of FAT directory entries. The old format only used 16 bytes per entry (rather than 32) and had no room to store any timestamps, much like CP/M formats of the era.

The 0.34 disk (8″ of course) has a handwritten label which includes a date, 81/02/20. If the disk was written and the label was made on February 20, 1981, the 86-DOS files on the disk are presumably not newer than late February 1981.

86-DOS version 0.34 disk

The file INIT.ASM on the 86-DOS 0.34 disk contains the following comment:

; Translated from the Z80 on 12-19-80 and subsequently upgraded to handle
; all of the following controllers. Set switch to one to select.

Assuming the comment is correct, 86-DOS 0.34 must have been released sometime after December 19, 1980 but before late February 1981.

The file MSDOS.ASM released by the Computer History Museum includes revision history that starts with version 0.34, which is dated as December 29, 1980. It is likely that the date refers to the DOS kernel itself and not necessarily when 86-DOS 0.34 was shipped to customers.

The 86-DOS 0.11 disk contains no real clues about its age. The sign-on message says “Copyright 1980 Seattle Computer Products, Inc.” which is not too helpful. An interview with Tim Paterson from 1983 suggests that “QDOS 0.11” was finalized in August 1980. While this is possible, the interview is somewhat questionable because there is no sign of “QDOS” in 86-DOS 0.11; the system clearly identifies itself as “86-DOS version 0.11”.

In any case, August 1980 is at least plausible as a release date of 86-DOS 0.11. If so, it would pre-date the release of the IBM PC (and PC DOS) by a whole year.

Continue reading
Posted in DOS, PC history | 24 Comments

From the Annals of Preprocessor Hackery

Over the last few days I’ve been slowly attacking the source code for 386MAX, trying to build the entire product. One of the many problems I ran into turned out to be quite interesting.

There are several (16-bit) Windows components in 386MAX, and many have some sort of GUI. As is common, dialogs etc. are built from templates stored in resource (.rc) files. But… trying to process many of the resource files with the standard Windows 3.1 resource compiler fails:

The resource compiler does not like something

The problem is dialog text labels composed of multiple strings. Something like this:

LTEXT "Qualitas 386MAX\nVersion " "8" "." "03",-1, 12,7,112,17

For obvious reasons, the authors wanted to automatically update the strings with the current version numbers, and used macros to build those strings. Only that doesn’t quite work in the resource compiler.

Continue reading
Posted in 386MAX, C, Development, Microsoft | 25 Comments

VDS: Borne out of Necessity

In July 1990, Microsoft released a specification for Virtual DMA Services, or VDS. This happened soon after the release of Windows 3.0, one of the first (though not the first) providers of VDS. The VDS specification was designed for writers of real-mode driver code for devices which used DMA, especially bus-master DMA.

Why Bother?

Let’s start with some background information explaining why VDS was necessary and unavoidable.

In the days of PCs, XTs, and ATs, life was simple. In real mode, there was a given, immutable relationship between CPU addresses (16-bit segment plus 16-bit offset) and hardware visible (20-bit or 24-bit) physical addresses. Any address could be trivially converted between a segment:offset format and a physical address.

When the 386 came along, things got complicated. When paging was enabled, the CPU’s memory-management unit (MMU) inserted a layer of translation between “virtual” and physical addresses. Because paging could be (and often was) enabled in environments that ran existing real-mode code in the 386’s virtual-8086 (V86) mode, writers of V86-mode control software had to contend with a nasty problem related to DMA, caused by the fact that any existing real-mode driver software (which notably included the system’s BIOS) had no idea about paging.

Continue reading
Posted in 386, Documentation, Microsoft, PC history, Windows | 10 Comments