While looking around for simple compilers to see how easy it is to modify their assembly output syntax, I ran across this tiny file, cc68iii3.zip which bills itself as:
This compiler consists of various modules that build up a front end — these modules are common to all versions of this compiler — consisting of parser, analyzer and optimizer, of modules that are specific for the target processor, namely *68k.c (for the 68000) and *386.c (for the i386), and of assembly language output modules that are further dependent on the (syntax of the) target assembler.
Well isn’t that interesting! So instead of doing something 68000 based, I setup the i386-gas compiler, and tried it with MinGW. And amazingly a hello world program worked!
Linux supports ELF binaries for ~25 years now. a.out coredumping has bitrotten quite significantly and would need some fixing to get it into shape again but considering how even the toolchains cannot create a.out executables in its default configuration, let’s deprecate a.out support and remove it a couple of releases later, instead.
I can’t say I’m all that surprised, maintaining backwards compatibility has not really been a Linux thing, as most people are incapable of doing any troubleshooting in the myriad of hundreds to thousands of independent packages, and instead find it far easier to switch to a different distro entirely.
At the same time, the vast majority of Linux packages are available in source code, so re-building things as ELF most likely has happened in the last 25 years.
During the great ELF migration, it was a gigantic PITA having basically 2 copies of all the libraries as things were converted over, and a.out stuff quickly evaporated. For me, the beauty of a.out was for later kernels to be able to mount and run older stuff. But as we are in the era of both ‘cheap’ user mode kernels along with virtualization will the old executable format truly be missed?
Linux has survived the removal of native support for the 80386, and even the detection logic for the NexGen processors (yes they were real, and yes they did ship), so no doubt this further amputation won’t matter to the vast majority.
I have to wonder how long until the i386 32bit target is removed? Distros like Debian have long since removed support for 80486/80586 classed processors to bring the minimum up to requiring SSE-2 based instructions, and I can’t imagine anyone who is running a 32bit OS for their main OS in this day and era.
And Alan Cox points out that the a.out binary loader _could_ be done in user space if somebody wants to, but we might keep just the loader in the kernel if somebody really wants it, since the loader isn’t that big and has no really odd special cases like the core dumping does.
So retrohun is doing their blog thing on github of all things, and the latest entry, is of course Xenix tales. As mentioned in comments on this blog & other places they found another driver for Xenix TCP/IP!
Going back years ago, the tiny NIC driver support for the elderly Microsoft/SCO Xenix 386 v2 included 3COMA/B/C and SLIP. However it’s been recently unearthed that D-Link had drivers for their DE-100 & DE-200 models, and as it happens the DE-200 is a NE-2000 compatible card!
That means that Qemu can install/run Xenix, and it can get onto the internet* (there is a catch, there is always a catch).
You can download the driver either from github or my password protected mirror. Simply untar the floppy under Xenix (tar -xvf /dev/fd0) and do the install via ‘mkdev dlnk’
Setting up the driver is… tedious. Much like the system itself. I found Qemu 0.90 works great, and is crazy fast (in part to GCC 3) even though Qemu 0.9’s floppy emulation isn’t good enough to install or read disks. With all the updates to Qemu 3.1 use that, it’ll read the disks, and allow for networking.
To give some idea of speed I ran the age old Dhrystone test, compiled by GCC 1.37.1 and scored the following:
Dhrystone(1.1) time for 5000000 passes = 8 This machine benchmarks at 625000 dhrystones/second
When compared to the SGI Indy’s 133Mhz R4600SC score of 194,000 @ 50000 loops that makes my Xeon W3565 322 times faster, under Qemu 0.90! And that’s under Windows!
Setting up the commandline/launching is pretty much this:
qemu.exe -L pc-bios -m 16 -net nic,model=ne2k_isa -net user -redir tcp:42323::23 -hda ..\xenix.vmdk added SLIRP adding a [GenuineIntelC] family 5 model 4 stepping 3 CPU added 16 megabytes of RAM trying to load video rom pc-bios/vgabios-cirrus.bin added parallel port 0x378 7 added NE2000(isa) 0x320 10 pci_piix3_ide_init PIIX3 IDE ide_init2  s->cylinders 203 s->heads 16 s->sectors 63 ide_init2  s->cylinders 0 s->heads 0 s->sectors 0 ide_init2  s->cylinders 2 s->heads 16 s->sectors 63 ide_init2  s->cylinders 0 s->heads 0 s->sectors 0 added PS/2 keyboard added PS/2 mouse added Floppy Controller 0x3f0 irq 6 dma 2 Bus 0, device 0, function 0: Host bridge: PCI device 8086:1237 Bus 0, device 1, function 0: ISA bridge: PCI device 8086:7000 Bus 0, device 1, function 1: IDE controller: PCI device 8086:7010 BAR4: I/O at 0xffffffff [0x000e]. Bus 0, device 1, function 3: Class 0680: PCI device 8086:7113 IRQ 0. Bus 0, device 2, function 0: VGA controller: PCI device 1013:00b8 BAR0: 32 bit memory at 0xffffffff [0x01fffffe]. BAR1: 32 bit memory at 0xffffffff [0x00000ffe].
In the file /etc/tcp the default installation does a terrible job of setting up the NIC. I changed the ifconfig line to this:
So there you go, all 20 Xenix fans out there! Not only a way to get back online, but to do it in SPEED!
Thanks to Mark for pointing out that there has been tremendous progress with version 3.1 of Qemu, and it’s TCG user speed is up to the 0.90 levels of speed (at least with dhrystone/Xenix), and it just takes a little (lot) of massaging to get up and running with Xenix with the right flags:
While I’m writing this, I’m listening to Neuromancer via WinAmp & the ancient Speex plugin I had updated about 8 years ago.
I took my Surface, and downgraded it to the North American 8.0 version without updates, added my MS ID, and from there ran the jailbreak and win86emu (sometimes called x86node) and from there I was able to run some simple Win32 exe’s.
Even though I had done a simple cut down QuakeWorld port with the GDI only display, using win86emu it’ll run the 80386 build as well. while I haven’t thrown much at it, I’m just amazed that so far things are working.
When you think that between the jail-break to unlock the ability to run programs combined with a CPU translator, and Win32 to Win32 thunk / translation program, why on earth did this thing ship without it? It’s amazing that between trying to launch a platform with no inertial for applications after Android & Apple were selling millions of hardware units, and billions of software units, and cutting the past applications. It’s just crazy.
And then Microsoft did their normal thing when something goes wrong, which is basically end it, and destroy all evidence it existed. There is no Windows 10 upgrade for the Surface, even though Windows 10 IOT has been hacked to run from a USB stick on the Surface, but it’s insanely slow.
I was kindly sent these a while ago from an avid reader, and I tried to get them to boot up into anything useful and didn’t get anywhere. I’m sure emulators of today are probably up to task, be it Bochs/PCem/86Box or even Qemu.
I stumbled onto these three disks, seemingly out of place in history. Windows/386 version 2.0 is a strange one in that it shipped to OEM’s in late 1987, making it & Xenix part of the initial 386 wave of Operating Systems/Environments and beating out not only the OS/2 launch in 1988, but taking advantage of the 80386’s v86 mode, something that OS/2 wouldn’t be able to do in a shipping product until 1992.
This version itself appears to be a retail version of Windows/386 lacking any clear OEM identification that was so prevalent for the era. Indeed setting it up it offers a few interesting platforms:
Getting this to run was a little bit of a challenge as much as I prefer Qemu, these older 2.0x versions of Windows/386 have a BIOS/disk incompatibility with the hypervisor resulting in errors reading the hard disk. Although PCem/86Box have no such issues. I think it’ll run off floppy/CD-ROM/Network without any issue though.
The PCjs version of 2.03 has 138 setup files (not counting the PIFs), compared to the eBay’s 141, while the PCjs 2.01 has 59 files.
That said, well it’s Windows/386 mostly from 1987 with slightly updated EGA/CGA VMM drivers from early 1988 that just didn’t quite make the cut. To me what is confusing, is that it identifies as 2.03 while it’s closer to 2.01 in file count and functionality, unlike 2.03 it really ought to have been a 2.02, if there even was such a thing.
Otherwise it’s really not all that interesting short of the timestamp. It’ll run on CGA/EGA *IF* you have the proper adapter in place, although VGA is compatible, the environment will detect that it’s not actually the proper card and refuse to run. I tried to put in the 2.01 CGA/EGA drivers, but that resulted in an OS version mismatch (I didn’t check if 2.01 was locked to the Compaq OEM of MS-DOS)
I installed the infamous pair Word & Excel. Despite Word 1.1a demanding at least Windows 2.11, it appears to run okay. Excel 2.1d loaded without complaining. There isn’t very much convential memory for either, but they both can use expanded memory, which the hypervisor can create and share out without any emm386 or any equivalent driver. I can only imagine the incompatibles of trying to balance these drivers at the time, and how much the coming DPMI specification was needed.
And as the old saying goes the three top problems in Windows version 2 is memory, memory and memory. Trying to run anything graphical will exhaust convential ram, forcing you to single task anything graphical which kind of defeats the whole point of Windows. You go from this:
Oh well it’s 1987, and users were kind of used to being disappointed as such. It’s really no wonder why Windows 3.0 became the smash it it was.
And of course you can't talk about Windows/386 without this gem. (Video in MPEG-1/Audio MPEG-2 care of JSMpeg).
It’s incredible how much it’s improved since I last touched on WineVDM, the port of Wine to run on Windows using the MS-DOS Player (and Mame 80386 emulation) at it’s heart.
The latest source build WineVDM_2018_07_30b.7z is now capable of loading and running Sim City for Windows 1.0.
I found it best to install Windows 3.0 into DOSBox, and then your application. After the install I copy the application so the physical drive of the hosts matches where it was installed, and then unpack the 7z build archive into that directory. There is a ‘WINDOWS’ directory and I xcopy the installed Windows directory into there so it has all the INI files, fonts and all that jazz. To make sure it doesn’t conflict I delete the following from Windows 3.0:
Since these files are most certainly going to be emulated by WineVDM. After that it’s time to run stuff!
I should also add that I’ve been able to use QuickC for Windows, and build a ‘non trivial’ program, the Fortran f2c compiler weighing in at 104,245 lines , and use that to compile 16,182 lines of Fortran 77 into C, and then compile the resulting C + the Fortran runtime library a staggering 130,405 lines of code, and the resulting binary works, just like it did on Windows 3.0!
I’ve also been able to print a text file using Microsoft Word 2.0 much to my amazement, although anything involving fonts just locks or crashes. I can’t say I’m all that surprised.
As you can read right now It’s running a simple OpenWatcom 16bit hello world based program. The 16bit OS/2 and 32bit OS/2 API’s ended up having different calling sizes, among other issues which had complicated the bridge program. However Ryan’s newer use of scripts to generate the required glue for the API’s at least mean that adding the 16bit/32bit calling conventions & required bridges/glue is at least now automated.
This is super cool, as this will eventually open the door to Watcom C/Fortran, Zortec C, Microsoft Basic/C/Cobol/Fortran and of course many other languages that burst out into the initial OS/2 scene before the eventual weight of the SDK & associated costs doomed OS/2 to failure.
Seriously, for those among us who love OS/2 and have like $5 to spare, send some encouragement to Ryan… 🙂
Date: 13 Apr 91 18:17:44 GMT
Organization: University of Helsinki
I've recently ported bash to minix-386 (nice, but takes about 300kB of
RAM). It's been "tested" by me using it all the time (good editing and
history - couldn't live without it any more), but I won't make any
guarantees. If anybody is interested in cdiffs against bash-1.05, please
mail me (I'll post if there is enough interest).
The port definitely needs GCC, and 386-minix. ST-minix will probably
work as well (I've sent it to one ST-minixer), after changeing a #define
LITTLE_ENDIAN to BIG_ENDIAN. If the port already has been done by
someone else - just ignore this message.
Linus Torvalds [email protected]
PS. I've hacked the kernel to accept gcc-compiled programs directly
without going through gcc2minix, but I haven't tested it very much yet
(bash works though, so most things probably will). Changes are trivial,
mail me if interested. (And yes - it accepts old minix format too - you
don't have to recompile everything :-)
Naturally it’s about the impending birth of Linux. First he needed to get GCC running under Minix 386, but I didn’t know at the time that he had patches floating around to allow Minix to directly run the GCC A.OUT format executables.
Scary to think that if Minix had allowed submissions and ‘bloat’ that Linux would have never been.
On the other hand, much like 386BSD the backpressure of having some kind of free BSD/UNIX system which did take in submissions was overwhelming, with the false start of 386BSD going the route of Minix and in that first critical year not pulling in any of the additional patches, while Linux grew by leaps and bounds. By the time the AT&T vs BSDi lawsuit hit, well the game was already in Linux’s favour, even with it’s already fragmented distro base.