DOSBox… in a box!
I don’t know why I never tried it before, but it actually works! And it’ll even spawn out to a window two. Although without share/record locking it’ll end up being a world of pain, I suspect. Maybe vDOS/vDosPlus will work? I know it’ll work fine if you boot MS-DOS inside of DOSBox, but for some reason I never actually tried to stress the v86 mode of DOSBox from within Windows.
A good friend mentioned that Slackware 14.1 was just released.
So I thought I’d take this time to instead install SLS 0.98-1 on Qemu.
Now this was the first version of Linux that I actually started to use. Â The 0.11 stuff was really a pain to install Minix then copy over enough linux to get it working. Â Instead SLS gave us a more usable distro to be installed on a machine with nothing. Â And thanks to cd.textfiles.com locating a download set was trivial.
Back in late 1992 I downloaded the zip files from CCUG at a blistering 2400 baud. Â I remember it took a week to get the A, B and C series. Â And I had to get a new box of 5 1/4″ High Density diskettes for the install (and another two for my MS-DOS / Windows 3.1 backup).
And just as back then, these zip files are missing files. Â INSTALL.END is missing from the A & B sets, which confuses the installer. Â The kernel source is linked to /usr1 which by default doesn’t exist and will cause that part to fail unless you use a virtual terminal (alt+f2) to remove /root/usr/src/linux so the installer will create the path itself after the installation of the A set.
SLS 0.98-1
Once it’s installed, it is pretty bare. Â vi, more, less, grep, and make are not in the install set, so it’s kind of difficult to move around. Â Emacs is there if you want it. Â As ultra primitive as this set is, it does install on an empty machine, which for the time was a big accomplishment.
One cool feature of this installset is that you aren’t tied to Minix’s filesystem, but you can use the new and exciting extfs, or Extended File system.
While the default kernel doesn’t see my emulated ne2000, as at this point the only supported NIC is the Western Digital 8003.
wd8003
As mentioned in we.c it was heavily based on the 386bsd code, although Linux used it’s own TCP/IP implementation, and not importing the Net/1 code.
I would imagine there are patches out there that’ll  no doubt add in NE2000 support.
Also included was a very primative dosemu version 0.3, that can sort of run some MS-DOS programs.
DOSEMU 0.3
More complicated stuff like Qbasic will crash it out. Â Although with a bit of work I did get MS-DOS 5 to boot from it’s “virtual hard disk”. Â It really is more so amazing it works as well as it does at this point.
For anyone feeling crazy, here is my installed disk image, and here is the ‘fixed’ install diskettes.
the v86-64 patch, Allows you to enter v86 mode from long mode on a 64bit linux kernel.
Basically it works just like an old school DOS Extender, where it’ll switch from long mode, to 32bit compatible mode, then enter v86 mode run some code, then re-enter 32bit mode, to jump back into 64bit long mode.
From an old mailing list:
PERFORMANCE This 64-bit DOSEMU compile runs substantially slower than the 32-bit compile that I used previously on this computer. I have several rather large PowerBASIC/DOS programs that are, in fact, the main reason why I use DOSEMU. Up until a couple of days ago, I had Fedora 7/i386 on this computer. I just happen to still have the numbers when compiling one of those programs with PowerBASIC/DOS under DOSEMU: With F7/i386: 1686600 lines per minute -- total time to compile the program: 0.2 seconds With F8/x86_64: 230400 lines per minute -- total time to compile the program: 1.6 seconds. The F8/x86_64 DOSEMU is running approximately 13 times slower. Which I bet runs a bit faster than an old 386.
275,000 transistors of awesomeness!
Kind of interesting is that Linux has finally dropped support for the 80386 microprocessor.
The 386 is perhaps one of the top ten things that has changed our world, along with 4.3BSD .
No, really!
The 386 microprocessor was the first CPU by Intel that was single sourced. This means that Intel, and only Intel would fabricate the 386 processor. Before this time, Intel had licensed their processors to other companies (Siemens, AMD, Harris, IBM etc) So that if there was some kind of production issue at Intel other companies could manufacture 8086,80186s and 80286s. However this all changed with the 386, as Intel stopped renewing these agreements with other companies (IBM had a license that included the 386, although they were slow in making their own), so now Intel was in charge of its destiny.
The 386 brought three major changes onto the then champion processor the 286. The first being a 32bit processor where it could handle larger data sizes than the 16bit 286 & 8086. The 386 also included a larger memory model, the so called “flat mode†where it could directly address 4GB of combined code+data, while the 286 could address 1GB it was limited to 64kb segments. Lastly the 386 introduced hardware virtualization, the “v86†mode where the 386 could emulate multiple 8086 processors, allowing people to have multiple ‘virtual machines’ on the desktop.
At the time the only consumer grade 32bit processor was the hybrid 32/16 68000 from Motorola. The 68000 could work with 32bit data, but it was restricted to a 16bit data bus, and only could address 24bits of RAM (16 megabytes). The 68000 however did not include any kind of memory management unit (MMU) making things like porting UNIX improbable (The SUN-1 workstation included a custom MMU). Because of the open nature of the IBM PC, clone manufacturers were able to leapfrog IBM, and release 386 based machines before IBM got around to releasing the PS/2 model 80. It was this that effectively brought 32bit computing to the masses with the Compaq Deskpro.
Compaq’s 386 Deskpro
The 8086 processor could address 1MB of RAM, with its 20bit address bus. However to preserve some compatibility with the 8080 processor it was decided that the 8086 (and 8088) CPUs would work with 64kb segments. This became a massive headache for years as you could not easily contain more than 64kb of data at a time as you would exceed a segment. Compiler vendors made some workarounds via the large & huge memory models, but porting a program from a 32bit minicomputer (VAX) would prove difficult if it addressed large amounts of memory, and would require a rewrite. The 286 increased the addressable memory to 16MB, and included a limited MMU, which enabled an address space of 1GB. However the 286 was flawed in that again the 286 could only work in 64kb segments, and in order to work with large amounts of memory, the processor had to be shifted to protected mode. However in protected mode, you couldn’t (easily) switch back to real mode. This needlessly delayed the adoption of protected mode environments, as you would then lose access to the sizable, and growing, library of MS-DOS programs. Although workarounds were in place for things like OS/2 and DOS Extenders, they were hacks and couldn’t fix the fundamental 64kb issue. The 386 built upon the 286’s foundation and included a flat memory model where it could address all 4GB of addressable memory in a single segment. This meant that you could now use massive amounts of data on a consumer grade machine.
For a while the only 32bit environments were Xenix and MS-DOS via DOS Extenders this proved to be a huge liability and effectively stagnated the industry for a long while. The 286 was a massive determent. Making things worse was IBMs insistence that the new OS/2 be able to run on the 286, while Microsoft wanted to create OS/2 to run on the 386, and ignore the IBM AT all together. Basically the 286 was created with the assumption that the 8086 wouldn’t be anywhere near as popular as it was.
With the ability to address large amounts of RAM programs only seen on minicomputers and mainframes were finding their way to the microcomputer such as AutoCAD, Oracle, Links 386 Pro, and of course many in house programs where departments now wouldn’t have to pay to run on then ‘big’ minicomputers. Combined with the 386’s MMU it was also possible to use more memory than was available in the computer, also known as virtual memory. The 386 made this transparent to the program, only the 32bit environment needed to handle the swapping.
Finally the last big feature of the 386 was v86 mode. V86 mode in short is a hardware virtualization platform where the 386 can emulate multiple 8086 processors in hardware. Each virtual machine can get its own isolated memory space, virtual hardware. Effectively 8086 programs (such as MS-DOS) can run unaltered inside of v86 mode, with the added benefit of being able to run more than one at a time. Windows/386 lead the charge into this new world of virtual machines for the end user. Before this point, the only wide scale virtual machine environment was the IBM 370 mainframe which could also create virtual mainframes within itself allowing groups to share a single mainframe, but run incompatible software platforms all at the same time.
Thanks to its capabilities the 386 also brought UNIX to the end user. First with Xenix, then Microport SYSV, and with the removal of AT&T code BSD was able to be released on the 386 via 386 BSD (and later BSDi’s BSD/OS). During this timeframe the research OS, Minix was extended by Bruce Evans to be able to use some of the 386’s features which then gave rise to Linux.
Thanks to cheap commodity based 32bit computers, and the GNU projects development tools (binutils, gcc, bash) people could then finally realize GNU’s dream of bringing a free and open UNIX like operating system to the masses.
Needless to say, a lot has changed since 1991, and Linux now moving beyond the 386 processor is no surprise. The rapid adoption of 64bit computing via AMDs extensions, and the new forthcoming 64bit ARM processors do signal the eventuality that one day Linux will even drop support for 32bit processors… Although I wouldn’t expect that for another 20 years. Even Intel has ceased manufacturing the 386 processor in 2007.
So it is now time to say good bye to the 386 processor. At the same time thanks to full software emulation, you will never truly be dead. And as always you can check out Linux’s early versions.
Concurrent DOS/386
Concurrent DOS/386 was a successor to MP/M, from Digital Research.
I’ve been able to track down a few versions:
What is interesting is that these versions include a CP/M 8086 emulator. I would imagine that would be a ‘big deal’ for users of the older MP/M to migrate into a newer 80386 environment. From what I’ve seen in other places these were compatible with MS-DOS 3.0 . It can also read extended dos partitions! Since they predate VCPI/DPMI there is no way to run protected mode applications. Concurrent DOS/386 is later followed up with Digital Research Multiuser DOS. It is interesting, well to me that DR-DOS was basically a single user, single tasking version of the Multiuser DOS.
Multiuser DR-DOS
I was able to install this on Qemu 0.13.0. Although this includes some IPX/SPX stuff from the later purchase of Digital Research by Novell, it still remains a largely MS-DOS 3.3 compatible OS. Because it uses protected mode, and the v86 mode, it is still incapable of running VCPI/DPMI programs. Also absent is the CP/M emulator. I think there was a DR-DOS 6 equivalence sold as a multiuser, but by the time of DR-DOS 7, the product had been forked and several VARS started to sell their own versions based on Multiuser DR-DOS. These included (but probably not a complete list)
Of these, REAL/32 seems to be the only one that is still alive, and being sold by Intelligent Micro Software. I’ve located a demo version of REAL/32 here.
REAL/32 logo
REAL/32 certainly feels a lot like DR-DOS (which it is derived from) and what is cool is that it supports DPMI applications. I’ve tested some Borland Pascal stuff, along with DJGPP. Like the others it supports serial terminals to be hooked up.
real32 serial connection
Qemu makes it super easy to simple to switch to the serial port, and bring up the ‘second user’. I’m pretty sure you could use qemu to redirect it’s serial port over TCP…
And speaking of networking, the install program also seems to have some kind of networking config built in, so I would imagine each VM can have it’s own IPX/SPX setup? I’ll have to mess some more with it.
If you’ve ever liked DR-DOS, you may want to give real/32 a whirl, it’s certainly more… interesting.
This has been a fun thing to go through, but at one point it was a popular trend to convert big expensive 386 computers from the late 1980’s into multi-user, multi-tasking beasts much like a mainframe. But instead of CICS, and PROFS people ran Dbase III, WordPerfect, and all kinds of email solutions from ccmail, to MS mail, and even some dbase programs, compiled by clipper into being email clients.
In a way things were more ‘simple’ back then, and the 80386 CPU had a card up it’s sleeve v86 mode. v86 mode provides hardware emulation of a 8086, allowing the base OS to spawn dozens of these virtual machines. All that was up to the ‘supervisor’ was to create virtual peripherals, much like how Windows/386 of the day ran multiple MS-DOS VM’s on a single machine that you could see at once, these solutions provide the output to multiple terminals.
While Windows/386 sat on top of MS-DOS, these multitasking DOS’s had the v86 mode multitasking as part of it’s core, and some of the later ones were themselves protected mode operating systems.
But juggling multiple MS-DOS applications at one could be quite a challenge. And of course there was the whole dos extender thing, leading up to VCPI, and DPMI.
While MP/M-86 is a grand daddy to a bunch of Digital Research derived OS’s, it’s not 386 specific so I’m going to omit it for now. I’m sure it’ll be worth doing it’s own write up.
I’m sure I’m going to miss a bunch of these, but let’s have a quick rundown.
If anyone knows of any others feel free to give me a shout. It does seem that multiuser DOS was a good market at one point.