Over the last few weeks, two “new” pre-releases of OS/2 2.0 have been found in ancient warez archives.
The first is OS/2 2.0 build 6.64, released in early April 1990:
In general, this build is not substantially different from the MS OS/2 2.0 Pre-Release 2 (build 6.78) from June 1990.
Continue readingWhen Microsoft released the unique early beta build of Multitasking DOS 4, I quickly found out that it does not run in VirtualBox:
This was a bit of a surprise, because the more-or-less released versions of Multitasking DOS 4 from 1986 runs just fine.
As an aside, I originally thought that “Internal Error 4560” had some meaning… but it does not. 4560h is just the offset within the DOS kernel code segment where the failure is detected.
After digging deeper, a further surprise awaited me: The May 1984 beta does not work because it probably really shouldn’t.
Continue readingSomeone recently asked an interesting question: Why do Microsoft C and compatible DOS compilers have no truncate() and/or ftruncate() library functions? And how does one resize files on DOS?
OK, that’s actually two questions. The first one is easy enough to answer: Because XENIX had no truncate() or ftruncate() either. Instead, XENIX had a chsize() function which, sure enough, can be found in the Microsoft C libraries at least as far back as MS C 3.0 (early 1985).
The second question is rather more interesting. The way files are resized on DOS is moving the file pointer to the desired size by calling the LSEEK function (INT 21h/42h), and then calling the WRITE function (INT 21h/40h) with zero length (CX=0).
Now, this mechanism is rather curious, because the handle-based file API in DOS 2.0 was modeled on XENIX, yet on UNIX systems, the write() function asked to transfer zero bytes simply does nothing. If the mechanism didn’t come from XENIX, where did it come from?
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 readingA 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 readingThis is how to not do it:
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:
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 readingIn 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.
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!
The SDK specimen was in original unopened box, with printed documentation and everything.
Here’s what the June 1990 pre-release of OS/2 2.0, also known as build 6.78, looked like when installed:
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 readingA 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:
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:
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:
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 readingWhile 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 readingWhile 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