PC DOS 1.0, But Not Quite

Last week a most interesting image of a 160K disk arrived at the OS/2 Museum. The files on the disk image are rather old. When the disk boots up (not trivial, see below), the following message appears:

Almost like PC DOS 1.0

Astute readers will notice that that’s exactly the same message as PC DOS 1.0 (August 1981) shows, but this COMMAND.COM did not prompt for the date. That’s because this disk is not from August but rather early June 1981—newest file is timestamped June 6, 1981—which may make it the oldest known surviving piece of software written for the IBM PC (not counting the IBM PC ROMs which are dated April 1981). It’s certainly the oldest known surviving PC operating system. It comes with a short text file which provides further insight into the development history of PC DOS.

Even better, the disk can be explored at pcjs.org live in its native habitat. Note that the original disk had AUTOEXEC.BAT which immediately asked for the current date and launched Advanced BASIC; for improved ease of use, the batch file was disabled by renaming it to AUTOEXEC.BAK. Continue reading

Posted in DOS, IBM, Microsoft, PC history, Pre-release | 2 Comments

How Many Gravis UltraSounds?

The question came up a while ago. Just how commercially unsuccessful was the Gravis UltraSound? There appears to be no public information about the sales volume of the UltraSound. But now, looking at a sample of 3 (three) classic GUS cards, it occurs to me: Could the serial number be exactly that? I know that’s extrapolating a lot from very little.

Lots of folks put pictures of their GUSes on the Internet. Not too many show the reverse side where the S/N sticker is usually located. So let’s start with mine:

  • GUS 2.4, PCB week 47/92, S/N: K33579
  • GUS 3.7, PCB week 50/93, S/N: K103633
  • GUS 3.73, PCB week 16/94, S/N: K119146

If the serial number is a true serial number, it would mean there were somewhere upwards of 120,000 GUS Classics made, perhaps around 150,000 (in 1994, the GUS MAX took over).  The 2.4 is an early revision (2.2 was the first production rev), so it has a relatively low serial number. The 3.7 and 3.73 are fairly close to each other in age so makes sense their serial numbers wouldn’t be very far apart. The 2.4 and 3.7 are a year apart so there’d be a much bigger gap.

GUS MAX does not appear to have a real serial number. The S/N looks to be a production week/year (mine says “Serial Number 0695”).

What serial number does your GUS Classic have? With enough data, it should become apparent if the serial number looks like a simple counter incremented for each card, and it should be possible to estimate how many there were. Please list the version, the date code etched on the reverse of the PCB, the serial number, and other identifying information if it seems relevant. Continue reading

Posted in PC history, Sound, UltraSound | 38 Comments

VME Broken on AMD Ryzen

That’s VME as in Virtual-8086 Mode Enhancements, introduced in the Intel Pentium Processor, and initially documented in the infamous NDA-only Appendix H.

Almost immediately since the Ryzen CPUs became available in March 2017, there have been various complaints about problems with Windows XP in a VM and with running 16-bit applications in DOS boxes in Windows VMs. Multiple versions of Windows are affected. Some (but not all) other operating systems are affected as well, for example OS/2 Warp running in a VM on Ryzen when attempting to open a DOS window:

OS/2 Warp VM DOS session on Ryzen

After analyzing the problem, it’s now clear what’s happening. As incredible as it is, Ryzen has buggy VME implementation; specifically, the INT instruction is known to misbehave in V86 mode with VME enabled when the given vector is redirected (i.e. it should use standard real-mode IVT and execute in V86 mode without faulting). The INT instruction simply doesn’t go where it’s supposed to go which leads to more or less immediate crashes or hangs.

How did AMD miss it? Because only 32-bit OSes are affected, and only when running 16-bit real-mode code. Except with Windows XP and Server 2003 it’s much worse and these systems may not even boot. Continue reading

Posted in AMD, Bugs | 34 Comments

SGDT/SIDT Fiction and Reality

PSA: Actual hardware behavior takes precedence over vendor documentation. Or, as they say… trust but verify.

A reader recently complained how Intel and AMD do not implement the SGDT and SIDT instructions the same way. AMD documentation states that these instructions ignore any operand size prefixes and always store full 32 bits of base address. Intel documentation on the other hand states that with 16-bit operand size, SGDT/SIDT stores 24 bits of the base address and the 4th byte is zeroed, and while using 32-bit operand size, all 32 bits of the base address are stored.

What a mess, right? How is a poor developer supposed to write code that works on all CPUs, and why the heck is AMD inventing its own things? Yet the reality is a bit different… Continue reading

Posted in 286, 386, AMD, Documentation, Intel | 35 Comments

OS/2 2.0, Xmas ’91 Edition

After reviewing the OS/2 2.0 level 6.605 pre-release, another re-discovery is the “Limited Availability” (LA) level 6.177 from December 1991. This was the last OS/2 2.0 pre-release of 1991 and also the last one using the 6.1xx numbering; the next pre-release was 6.304 in February 1992.

Install disk of OS/2 2.0 6.177

The installation floppies are labeled 12/91 and the files appear to have been finalized on Christmas Eve (December 24) of 1991. The labels read “IBM Operating System/2 S.E. Version: 2.0”; it’s not entirely clear what S.E. stands for—possibly Standard Edition, in line with OS/2 1.x SE, even though with 2.0 there was no EE (Extended Edition).

The 6.177 pre-release was very important for IBM because it was meant to fulfill certain promises made to customers, namely delivering OS/2 2.0 in 1991. That promise was kept and not kept: OS/2 2.0 LA was built before the end of the year, but it was only manufactured in larger quantities in mid-January 1992. It was also very limited availability indeed, not something anyone could just buy. And, obviously, it was not the actual public release of OS/2 2.0.

OS/2 2.0 LA booting

The notable feature of the 6.177 disks was that they did not say “pre-release” or “evaluation” or anything like that, and in fact IBM provided official support for OS/2 2.0 LA. Continue reading

Posted in 386, IBM, OS/2, PC history | 11 Comments

CF/IDE/SCSI Benchmark Update

To see how the CF-to-IDE-to-SCSI solution really performs, I tried it in a slightly faster system. GA-586HX motherboard (Intel 430HX chipset), AMD K5-133 processor, and PCI SCSI HBAs.

The first tested configuration was using a Tekram DC-390 HBA. Sysinfo showed 8.7 MB/s, not much more than the 8.4 MB/s the VLB 486 reached. The limit here is probably the 10 MB/s Fast SCSI transfer rate and we’re getting close to 90% of the theoretical maximum, although a different HBA would perhaps do better. The DC-390 is a Fast SCSI HBA limited to 8-bit wide transfers and 10 MB/s.

The second HBA was a classic Adaptec AHA-2940UW, but it did slightly worse than the Tekram, at a little under 8.6 MB/s. But wait, the ‘U’ in 2940UW stands for Ultra, and the Acard IDE-to-SCSI adapter is the 7720U, where ‘U’ once again indicates Ultra SCSI. So why can’t we get past 10 MB/s? Continue reading

Posted in CompactFlash, SCSI, Storage | 10 Comments

How the PC Industry Screws Things Up

I was recently involved in investigating a problem that turns out to be a complete SNAFU which nicely illustrates the chaos that is the PC platform. It’s about the NX/XD bit. Let’s start with a bit of history.

It turns out to be useful, and in fact required for improved security, to separate code and data. On the 8086, no such separation existed. On the 80286, protected-mode segmentation clearly distinguished between code and data segments. Writing to a code segment required creating a data-segment alias. The same segmentation rules carried over to 32-bit protected mode on the 80386, but lost any meaning in flat-model operating systems (OS/2 2.0, Windows NT, 32-bit UNIX). Because the data (DS) and code (CS) segments mapped the entire memory, any data page could be written to and executed. In the age of Internet, that turned out to be a terrible idea because any buffer overflow on the stack could be immediately exploited to inject and execute code in a vulnerable process.

In 2003, AMD introduced the NX (No-eXecute) bit as part of the AMD64 architecture. When enabled in the EFER MSR, 64-bit and PAE page tables support an additional bit which makes a page non-executable. As a result, it is again possible to separate between code and data, and make data pages non-executable. That makes exploits harder (far from impossible!) because there is no longer a ready supply of writable and executable pages and most importantly, the stack is no longer executable.

Microsoft saw NX as a Good Thing and added support for it in a Windows XP SP2 (2004), calling the feature DEP, or Data Execution Prevention. This was initially an opt-in feature because certain classes of legitimate software did not bother distinguishing between data and code and crashed with DEP enabled (typically software which generated code on the fly in one manner or another).

Microsoft presumably made it known to Intel that NX was a desirable feature. Intel had to support NX in all AMD64-compatible CPUs, but also added NX support to late-model 32-bit Prescott Pentium 4 CPUs, and even the later Pentium M processors.

Intel of course couldn’t leave well enough alone and called the bit XD (eXecute Disable), and more importantly, also added a way to completely disable the NX through the IA32_MISC_ENABLE (1A0h) MSR. That’s where things started going south. Continue reading

Posted in AMD, Intel, Microsoft | 32 Comments

OS/2 2.0, Summer ’91 Edition

In a fascinating example of poor timing, disk images of OS/2 2.0 pre-release level 6.605 from July/September 1991 were missing for over 25 years, only to show up literally one day after after the 25th anniversary of the OS/2 2.0 release (big thanks to a very helpful reader!).

Install disk of OS/2 2.0 6.605

Let’s go back to the odd numbering for a moment. The build “levels” of OS/2 2.0 started apparently at 6.00 and went all the way up to 6.307 for the GA release (though the 6.2xx range may have been skipped entirely). The 6.605 pre-release from September 1991 became available between 6.149 (July) and 6.167 (October). It is not known what possessed IBM to assign it a completely out-of-sequence number. It is known that 6.605 is very close to 6.149 but contains additional fixes to work better with LAN Server (LS) and Extended Services (ES) pre-releases.

For reference, OS/2 1.0 used internal revisions 3.xx, version 1.1 used internal revisions 4.xx, and OS/2 1.2 used 12.xx. The fact that OS/2 2.0 used the 6.xx range probably reflects the fact that its development started after OS/2 1.1 but before 1.2.

Even though the 6.605 disks are clearly labeled 7/91 (July), they were just as clearly finalized in September 1991. It is possible that 6.605 was somewhat unplanned because the next level (6.167, or OS/2 2.0 LA) was the first to contain the Workplace Shell (WPS), and putting that together may easily have taken longer than anticipated.

The upshot is that 6.605 was in fact the last OS/2 2.0 pre-release which didn’t use the WPS and instead utilized the same old Desktop Manager as OS/2 1.2/1.3, which makes it the closest surviving relative of the MS OS/2 2.0 SDK:

Desktop in OS/2 level 6.605

The look and feel was not quite the same as OS/2 1.3 and in fact was a cross between OS/2 1.3 and Windows 3.1. Continue reading

Posted in 386, IBM, OS/2, PC history | 34 Comments

OS/2 2.0 at 25

Twenty-five years ago, on March 31st, 1992, IBM released OS/2 2.0, the first mass-market 32-bit PC operating system. The road to OS/2 2.0 was quite long and winding, and the OS was a proud member of the vaporware club (just like, say, Windows NT or Windows 95).

Talk of 32-bit OS/2 goes almost as far back as OS/2 itself. In 1987, Gordon Letwin wrote about OS/2-386 in Inside OS/2 and it is clear that future 32-bit extension was a consideration when OS/2 1.0 was on the drawing board. And we now know that in late 1986, Microsoft already started experimenting with using the 80386’s V86 mode to run Virtual DOS Machines (VDMs) on top of OS/2.

1991 OS/2 2.0 6.167 (left) and 1992 GA (right)

Microsoft launched actual development of OS/2 2.0 probably in 1988, the same year development of NT OS/2 (later known as Windows NT) started. The goal was to provide a PC operating system which is upwardly compatible with OS/2 1.x, supports native 32-bit applications, and supports VDMs; the latter was especially important in light of the fact that compatibility with existing DOS applications was a weak point of OS/2 1.x.

The entire history of OS/2 2.0 development is one of missed deadlines and broken promises. In July 1988, OS/2 2.0 was supposed to be released in early 1989. In February 1989, an OS/2 2.0 SDK was supposed to be released by the end of the year and the finished product in 1990. Continue reading

Posted in 386, IBM, Microsoft, OS/2 | 32 Comments

Something New Every Day…

Apparently in 1990, Intel still sold complete systems, and they were PC compatible at that point. And perhaps not surprisingly, Intel also OEMed MS OS/2 1.21:

Intel OEM OS/2 1.21 Boot

And there was this cute ASCII-art logo:

Intel OEM OS/2 1.21 Installer Logo

There very little customization that Intel did, the biggest difference from standard MS OS/2 1.21 was that Intel shipped additional DISK01.SYS driver which was in fact standard Adaptec ASW-1420 driver for 154x HBAs (actually 1x4x, presumably also covering EISA if not MCA). That supported the Adaptec 1542 SCSI controller used in the Intel 303 (386/33) tower system that these MS OS/2 disks came with.

Big thanks to a helpful reader.

Posted in Intel, OS/2 | 14 Comments