The previously mentioned warez mega dump contains disk images of SCO 286 XENIX 2.1.0.
Booting 286 XENIX 2.1.0 (1986) from floppy
The release appears to be from February 1986. It is the oldest SCO 286 XENIX release that I know of. But there’s a hitch.
The warez archive only contains the system disks, N1 to N4 (all in 360K format of course). To install the system, the Basic Utilities disks (B1 to B3, most likely) are also required. Attempting to use a newer B1 disk from XENIX 2.1.3 failed, presumably because the older 2.1.0 kernel lacks some required interfaces. So it’s possible to boot 286 XENIX 2.1.0, but not possible to properly install it.
Who has more XENIX 2.1.0 disks? The ‘B’ disks were almost certainly the same between XENIX 286 and XENIX 86.
Thanks to the recent warez mega dump, another long lost gem has come to light: NetWare 386, also known as NetWare 3.0.
Booting NetWare 3.0
In September 1989, Novell released NetWare 386 V3.0, the first in a long line of 32-bit network operating systems. At the time, Novell’s mainstay was NetWare 2.15, a system designed to run on 286-based machines.
NetWare 386, as the name suggests, required at least a 386 processor. It was a major redesign of the NetWare OS intended to take advantage of (then) high end 32-bit hardware. Whereas NetWare 2.x was linked from object modules during installation (much like commercial UNIX implementations), NetWare 386 utilized modules (NLMs, or NetWare Loadable Modules) which could be loaded and unloaded at run-time.
Disk drivers, network drivers, protocols, and all sorts of added functionality were implemented as NLMs in NetWare 386. This made NetWare 3.0 installation and maintenance far simpler compared to NetWare 2.x. The NetWare 2.x kernel had to be linked during installation (a lengthy process), and any change of a disk or network driver required the OS to be re-generated again. In NetWare 3.0, all it took was copying a new driver and changing a configuration file.
NetWare 3.0 was in some ways a limited release, although at the same time it was a fully functioning file server which could support up to 250 users (compared to the 100 user maximum of NetWare 2.x). That was reflected in the pricing—$7,995. NetWare 3.0 was Novell’s flagship product, even though it didn’t fully realize the NetWare 386 vision. Only the IPX protocol was supported, the set of available disk and network drivers was quite limited, and third-party NLMs were more or less nonexistent.
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.
Someone 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.
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.
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.
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.
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?
