Semantic Differences, Microsoft v. Microsoft

While comparing the behavior of various versions of old Microsoft C compilers, I tried building a trivial hello-world type program with CL.EXE from Microsoft C/C++ 7.0 (March 1992) running on top of a 32-bit Windows Server 2003. This seemingly trivial task failed:

Command line error D2018 : cannot create linker response file

A quick search revealed that rather predictably, I wasn’t the first person hitting this problem. And as usual, there were only questions, not answers.

MS C/C++ 7.0 was Microsoft’s first compiler with C++ support included, but that’s not what made it special. It was Microsoft’s first DOS/Windows 3.x compiler which required a 386 host and used a 32-bit DOS extender.

Looking at the C/C++ 7.0 executables a bit closer, it’s apparent that these are in fact 32-bit PE modules, with a DOS extender in their respective DOS stub. The catch is that due to their age (released more than a year before NT 3.1), the PE modules are different enough that no NT release can use them. Hence the compiler must be run through NTVDM as if it were a normal DOS executable.

Now, given that when NT 3.1 was released (1993), Microsoft C/C++ 7.0 was still a current product, one would expect that the compiler would run under NT 3.1… and indeed it did! MS C/C++ 7.0 also works under NT 3.50 (1994), but it no longer functions under NT 3.51 (1995). The compiler fails with the above D2018 error message in NT 3.51 and all subsequent releases. At that point, Visual C++ 1.0/1.5 had taken over and C/C++ 7.0 was more or less obsolete, so perhaps the problem slipped under the radar, but why did the compiler stop working at all? What changed? Continue reading

Posted in DOS, Microsoft, Virtualization | 4 Comments

NT Video Miniport for VirtualBox, With Source Code

Upon reader request, the OS/2 Museum is publishing the source code to the NT video miniport driver for VirtualBox. To recap, this is a NT video miniport which allows 32-bit NT versions to use high-resolution graphics modes in a VirtualBox VM. The miniport is unique(?) in that a single binary supports every released version from NT 3.1 through Windows 7 (Windows 8 no longer supports the same video miniport model).

The boxvnt miniport in NT 3.50The source code now lives in a private Mercurial repository. The credentials are ‘guest’/’guest’. The complete source code can be downloaded as a zip/gzip/bz2 archive from the above page. A floppy image with a driver binary produced from this source is also available for download.

The source code is published under the very liberal MIT license. Anyone can more or less use it as they see fit. However, if you fork it, please do not ask for help—you’re on your own. Continue reading

Posted in Graphics, NT, Source code, VirtualBox | 4 Comments

Windows Presentation Manager Documentation

The OS/2 Museum just posted a three-volume set of draft Windows Presentation Manager reference documentation. This refers to the OS/2 Presentation Manager GUI but highlights the story Microsoft pushed in 1987: Windows and OS/2 both used the same graphical user interface called “Windows Presentation Manager”.

Microsoft Windows 2.03, 1987, 3.5" DD media

By the time OS/2 1.1 was released, the “Windows” part was dropped and the GUI was called simply Presentation Manager. And conversely Windows dropped the “Presentation Manager” moniker again and went back to being simply Windows. Continue reading

Posted in Documentation, Microsoft, OS/2 | 5 Comments

OS/2 Programmer’s Toolkit

For those wishing to write OS/2 1.x programs, the complete Microsoft OS/2 Programmer’s Toolkit documentation is now online. This is Microsoft’s programming documentation for OS/2 1.0 programming.

It is worth noting that IBM’s programming documentation was different; worse yet, IBM’s headers and libraries were different, and source code written for OS/2 1.0 is not necessarily portable between IBM’s and Microsoft’s tools! The reason for this appears to be that IBM published OS/2 tools relatively far in advance of Microsoft, and Microsoft’s Toolkit reflects a newer style (for example, including os2.h instead of doscalls.h). IBM released its C/2 compiler (roughly rebranded Microsoft C 5.0 with OS/2 support) in November 1987 and the headers and libraries used by IBM were probably finalized around August or September. Microsoft’s contemporary C 5.0 did not support OS/2 yet; that only came in MS C 5.1, released in March 1988, more or less six months later. Continue reading

Posted in Development, Documentation, Microsoft, OS/2 | 2 Comments

Weekend Reading, OS/2 and Windows

In a recent post I mentioned that the OS/2 Museum’s stack of PC Tech Journal issues ironically does not include the first PCTJ issue devoted to OS/2. Thanks to pcjs.org, the October 1987 issue of PCTJ can now be read online. It’s interesting to read what computer professionals thought about the future in OS/2 back before it was released. Not surprisingly, the issue also includes screenshots and a detailed description of a mid-1987 OS/2 beta build available in the MS OS/2 SDK. It looks like the 1.01 SDK from the screen captures.

But there’s more. The OS/2 issue of MSJ (Microsoft Systems Journal) from May 1987 is now also available thanks to pcjs.org. This may have been the first in-depth information about OS/2 publicly available after the initial announcements in April 1987. The interview with Gordon Letwin is one of the more interesting items.

The Evolution and History of MS-DOS article in this MSJ issue may also be of interest, even if it probably doesn’t present any new information. Continue reading

Posted in Documentation, Microsoft, OS/2, Windows | 3 Comments

Careful with that Buffer…

Last week I was sorting through several sets of Microsoft C 5.1 disks from 1988  (more about that later). While I was comparing the disk images to see whether the disks were the same or not, despite different labels and part numbers, I did a double take when I realized that a file with random e-mail fragments was, in fact, a MS C 5.1 disk:

nts to the beginning of an _iob structure within the _iob array.
But that's not very likely.
What usually happens is people passing in NULL or some random
value.

From davewe Wed Nov 11 11:10:28 1987
To: jeffrob stevesa
Subject: stream validation
Cc: barrymc billjo dougbo gregf
Date: We

It’s not clear on which host OS the MS C 5.1 disks were created and how (copying files to a floppy vs. creating disk images on a hard disk). But it is certain that the software involved did not sanitize the buffers and random fragments of data stored in the host system’s memory ended up in the final sectors of numerous files. Continue reading

Posted in Microsoft, Security | 6 Comments

S3 Fraternal Twins

Sometimes identifying old hardware is a bit tricky. Consider these two graphics cards:

S3 Graphics Card #1

S3 Graphics Card #2The PCB is the same, the BIOS chips look the same, the DAC is slightly different but an 80 MHz part in both cases, memory is the same… but wait—the graphics controller is different! The top specimen is equipped with the original S3 86C911 accelerator, while the bottom one uses the newer and improved S3 86C924 with added 24-bit true color acceleration. Continue reading

Posted in Graphics, PC hardware, S3 | Leave a comment

Intel 287XL… From 1986? Or 1996?

Many or most readers of this site probably know that most chips (and PCBs) have the date of manufacture stamped on them, almost always indicating the year and week (usually not the actual date) they were made.

Especially with PCBs, there is no standard for whether the year or week comes first. For pre-millenial hardware that’s not a problem, because it’s unambiguous what’s the year and what’s the week. It’s a bit tricker when something like 0403 is stamped on a PCB—is that week 3 of 2004 or week 4 of 2003? In such cases, both might be plausible and one has to look further.

Intel A80502-90

Chips more or less universally use the year/week convention, but some manufacturers label their products with a two-digit year and others only use a single digit. Intel is of course in the latter category. The above image shows a typical vintage Intel chip with a date code stamped on the bottom side of a chip and etched on the top (a 90 MHz Pentium, manufactured in week 15 of 1995). Note that there are actually three date codes, 515 on top, and 501/515 on the bottom of the chip. Intel makes things slightly difficult by often embedding the date code in a longer string, with the three-digit date code starting at the second position (the first might be a digit or a letter).

Most of the time, it’s easy to tell whether a date code like 927 means week 27 of 1979, 1989, 1999, or 2009. But sometimes the answer is not so obvious. Continue reading

Posted in Intel, PC history | 11 Comments

Floppy Capacity Math

After more or less accidentally coming across a BBS listing of various high-capacity floppy formatting programs, I began wondering: How much data can really be stored on a diskette in a PC floppy drive? And what’s the relationship between formatted and unformatted capacity? When I started doing the math, I realized that the problem is both simpler and more complex than I had thought. And that one megabyte is not like another.

Note: This discussion is limited to 3½” high-density floppies, by far the most common format, unless otherwise noted.

2.0 MB Unformatted Capacity

Since floppies store essentially analog signals, how is their theoretical capacity calculated? There are no addressable memory cells like those in RAM chips, so how does one arrive at 2 MB? The math is actually remarkably straightforward and has little to do with the medium and everything to do with the floppy controller (FDC) and drive. Continue reading

Posted in Floppies, PC hardware | 17 Comments

The IBM PC BIOS and Intel ISIS-II

An interesting question recently popped up: How exactly did IBM build the ROM BIOS for the IBM PC? Knowing what tools were used should make it possible to use the ROM listing published in the IBM PC Technical Reference and reproduce the ROM image.

Only one thing was clear—the PC BIOS wasn’t developed on a PC. With later IBM PC/AT and XT/286 ROMs, the situation is simple because the published listings identify IBM Macro Assembler 2.00 as the tool used. With the PC BIOS (and early AT BIOS), there’s no such identification.

The PC BIOS source code is remarkably straightforward. It is a single source file which does not use any macros. The one telltale marker is a $TITLE directive at the very beginning. No known version of MASM accepts this syntax… but at least one other assembler does. Continue reading

Posted in BIOS, IBM, Intel, PC history | 7 Comments