So let’s do some obligatory scratch of the surface. Like all the other 1991 pre-releases there really is just a text mode setup install script. Choosing the lesser amount of pain, I went with a MS-DOS hosted install. However, using MS-DOS 6.22 resulted in a broken dual boot system. But we live in the era of virtual machines, so it really doesn’t matter. I’m using Qemu 0.14-rc2, something that is ‘era correct’ for when the first avalanche broke on early Windows NT pre-releases. I’ve had issues with more modern versions of Qemu, and I felt that if we’re using vintage software may as well go in all the way.

The boot loader identifies itself as being 1990 vintage. Pretty sure it doesn’t mean anything, but we haven’t been blessed with the “blue screen” of ARC yet.

The login screen and desktop have a very strong Windows 3.1 beta feel to them. And that would land this where it was, Windows was such a big seller that Maritz had been trying to convince Gates & Balmer to ‘switch to the Windows horse’ in the spring/summer of 1990, culminating in Gate’s July decision to walk away from NT/OS2 and rebrand the new OS as Windows NT. Oddly enough it was Balmer who was in favour of OS/2 & IBM. (Showstopper 89-90)

At first glance the opening window isn’t all that interesting. It’s just very. Windows.

Rest assured Reversi, of course made the this Win32 cut. And it’s full of weird easter eggs, oddly enough in the OS/2 surviving bits.

type OS2LDR.DOS
OS2LDR 01.00.01
by KeithMo 01/08/91

On the Discord there had been a big discussion about early NT executable formats, and the whole COFF vs ECOFF vs PE/PEI. I had tried to hunt down the specific version of GCC I used ages to to build a so called Dec Alpha GCC cross compiler, but the short version is that it didn’t work as we don’t have any assembler/linker for anything GNU targets. There had been a cygwin port and an OpenNT on Alpha, but all that is lost to the winds, minus what few scraps I had saved. I did try building some cross tools to elf hoping to just objcopy out the data and get linkable objects, but that didn’t work either.

So I though this was a perfect opportunity to take a look at this early pre-release version of NT, and although I do know that you have to convert your objects into something the ‘COFF’ linker will accept:

And I never really paid that much attention to the object files. I do know that you can link them with Link386 for OS/2, but the NT object files themselves report:

wsl file SIMPLE.OBJ
SIMPLE.OBJ: Intel 80386 COFF object file, not stripped, 4 sections, symbol offset=0x102, 20 symbols, created Thu Jun  1 14:13:50 2023, 1st section name ".text"

Well, now that is interesting. And of course the COFF thing reminded me of Xenix! And sure enough ages ago I had found the source to a modified version of GNU GAS that outputs COFF. Once more again this is an indication that all 386 roads in Microsoft really did originate with Xenix. It’s too bad there never was a Windows/386 on Xenix/386. What an incredible OS that would have been! There must be some incredible stories from the tool teams that worked on Microsoft C/386 along with other projects. Oddly enough they never get anywhere near as much exposure as Office or OS.

Now this is fun, but nothing takes in these ancient COFF objects, do they? I tried to run LINK 1.0 from Win32s SDK and surprisingly it didn’t complain about the object, rather, it auto converted it in memory:

Microsoft (R) 32-Bit Executable Linker Version 1.00
Copyright (C) Microsoft Corp 1992-93. All rights reserved.

SIMPLE.OBJ : warning LNK4016: unresolved external symbol "__chkstk"
LINK : warning LNK4016: unresolved external symbol "_mainCRTStartup"
SIMPLE.OBJ : warning LNK4016: unresolved external symbol "_printf"
SIMPLE.exe : error LNK1120: 3 unresolved externals

Does this mean that if I give it some libraries it will actually link?

LINK.EXE SIMPLE.OBJ /SUBSYSTEM:CONSOLE /MACHINE:i386 -entry:mainCRTStartup -out:simple.exe libc.lib kernel32.lib
Microsoft (R) 32-Bit Executable Linker Version 1.00
Copyright (C) Microsoft Corp 1992-93. All rights reserved.


C:\temp\nt196\x\dec\x>simple
Win32, it's happenin'!

This was. VERY unexpected.

So I had this crazy idea, what if the Xenix assembler could in fact build objects that are also compaible in this manner? I used the a.out GCC / Linux porting tools I had built so I could compile Linux on Windows NT using the vintage tools as a starting point. I guess I should also add that when people always say ‘use newer version of THING’ this is how you miss out on old stuff like this. If I had been obsessed with using modern tools and modern operating systems, I’d have missed out on this Xenix filled window.

I took the gcc driver & the cc1 compiler from 1.40 and the c pre-processor from 2.5.8 as it can understand C++ comments. First I manually compiled the ‘simple’ example to assembly:

gcc -v -nostdinc -I/xenixnt/h -S SIMPLE.c -O simple.S
gcc version 1.40
 cpp -nostdinc -v -I/xenixnt/h -undef -D__GNUC__ -Dunix -Di386 -D__unix__ -D__i386__ -D__OPTIMIZE__ SIMPLE.c C:/Users/jsteve/AppData/Local/Temp/cca2_048.cpp
GNU CPP version 2.5.8 (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 /xenixnt/h
End of search list.
 cc1 C:/Users/jsteve/AppData/Local/Temp/cca2_048.cpp -quiet -dumpbase SIMPLE.c -O -version -o SIMPLE.s
GNU C version 1.40 (80386, BSD syntax) compiled by GNU C version 5.1.0.
default target switches: -m80387
 cpp -nostdinc -v -I/xenixnt/h -undef -D__GNUC__ -$ -Dunix -Di386 -D__unix__ -D__i386__ -D__OPTIMIZE__ simple.S C:/Users/jsteve/AppData/Local/Temp/cca2_048.s
GNU CPP version 2.5.8 (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 /xenixnt/h
End of search list.

Which gave me the following assembly:

        .file   "SIMPLE.c"
gcc_compiled.:
.text
LC0:
        .ascii "Win32, it's happenin'!\0"
        .align 2
.globl _main
_main:
        pushl %ebp
        movl %esp,%ebp
        pushl $LC0
        call _printf
        leave
        ret

Now to assemble with the GAS Xenix assembler

C:\temp\nt196\files\MSTOOLS\SAMPLES\SIMPLE>ax386 SIMPLE.s -o SIMPLE.obj

C:\temp\nt196\files\MSTOOLS\SAMPLES\SIMPLE>wsl file SIMPLE.obj
SIMPLE.obj: 8086 relocatable (Microsoft), "SIMPLE.c", 1st record data length 10, 2nd record type 0x88, 2nd record data length 11

Not quite the same. But it does closer resemble the output from the OS/2 bound versions of the Pre-Rease compilers:

file EMPTY.OBJ
EMPTY.OBJ: 8086 relocatable (Microsoft), "empty.c", 1st record data length 9, 2nd record type 0x88, 2nd record data length 7

So will it link?!

C:\temp\nt196\files\MSTOOLS\SAMPLES\SIMPLE>LINK.EXE SIMPLE.OBJ /SUBSYSTEM:CONSOLE /MACHINE:i386 -entry:mainCRTStartup -out:simple.exe libc.lib kernel32.lib
Microsoft (R) 32-Bit Incremental Linker Version 2.50
Copyright (C) Microsoft Corp 1992-94. All rights reserved.

SIMPLE.OBJ : warning LNK4033: converting object format from OMF to COFF

C:\temp\nt196\files\MSTOOLS\SAMPLES\SIMPLE>simple
Win32, it's happenin'!

Well now this is interesting! LONG before MinGW, or the GCC port to Windows NT, it turns out that in fact GCC could target Windows NT the entire time!

So the next thing to do is something not as trivial, like phoon.

I setup some quick script to pre-process, compile, assemble and then try to link, but as this one uses floating point, disaster struck:

phoon.obj : error LNK2001: unresolved external symbol "___fixdfsi"
astro.obj : error LNK2001: unresolved external symbol "___fixdfsi"
phoon.exe : error LNK1120: 1 unresolved externals

Now ages ago while messgin with old GCC & DooM I also had weird math calls not working. In the end I ended up extracting them from libgcc builds, so I thought I’d try the libgcc built during the GCC 2.6.3 on NT adventure.

link /NODEFAULTLIB:libc.lib /NODEFAULTLIB:OLDNAMES.LIB -out:phoon.exe astro.obj date_p.obj phoon.obj -entry:mainCRTStartup libgcc1.lib LIBC.LIB KERNEL32.LIB
Microsoft (R) 32-Bit Incremental Linker Version 2.50
Copyright (C) Microsoft Corp 1992-94. All rights reserved.

And of course:

To try to make the steps make a little more sense, and to allow for some higher level of automation I made a Makefile:

CC=gcc
CC1=cc1
AS=ax386
CPP=cpp


CFLAGS= -O
CPPFLAGS= -lang-c-c++-comments -nostdinc -I/xenixnt/h

OBJ =   astro.obj \
date_p.obj \
phoon.obj

LIBS = libgcc1.lib LIBC.LIB KERNEL32.LIB

phoon.exe: $(OBJ)
        link -out:phoon.exe $(OBJ) -entry:mainCRTStartup $(LIBS)

%.obj: %.c
        $(CPP) $(CPPFLAGS) $< $*.i
        $(CC1) $*.i -quiet $(CFLAGS) -version -o $*.S
        $(AS) $*.S -o $*.obj


clean:
        del $(OBJ) *.i *.S phoon.exe

I’m sure there is better ways to do this, but it breaks the compile up to it’s individual parts:

Run the pre-processor to allow // in the comments, C++ hadn’t been the default thing back when GCC 1.40 was a thing. Also path it to the headers, in this case I’m using the ones from NT 196. Trying to link with the 196 libraries gave me this:

C:\xenixnt\demos\phoon>link /NODEFAULTLIB:LIBC.LIB /NODEFAULTLIB:OLDNAMES.LIB -out:phoon.exe astro.obj date_p.obj phoon.obj -entry:mainCRTStartup base.lib wincrt.lib ntdll.lib \xenixnt\lib\libgcc1.lib
Microsoft (R) 32-Bit Incremental Linker Version 2.50
Copyright (C) Microsoft Corp 1992-94. All rights reserved.

wincrt.lib(maincrt0.obj) : warning LNK4078: multiple ".data" sections found with different attributes (40000040)
astro.obj : error LNK2001: unresolved external symbol "_asin"
astro.obj : error LNK2001: unresolved external symbol "_atan"
astro.obj : error LNK2001: unresolved external symbol "_atan2"
phoon.obj : error LNK2001: unresolved external symbol "_cos"
astro.obj : error LNK2001: unresolved external symbol "_cos"
astro.obj : error LNK2001: unresolved external symbol "_floor"
astro.obj : error LNK2001: unresolved external symbol "_sin"
phoon.obj : error LNK2001: unresolved external symbol "_sqrt"
astro.obj : error LNK2001: unresolved external symbol "_sqrt"
astro.obj : error LNK2001: unresolved external symbol "_tan"
phoon.exe : error LNK1120: 8 unresolved externals

Which is not surprising as there is no FPU/Floating point math support in 196. I tried the December 1991 Pre-Release, but it failed for other reasons:

I did copy over BASE.DLL BASERTL.DLL CSR.DLL DBGDLL.DLL as it wanted, but despite the symbol being in the DLL it didn’t load.

So that’s why I’m using the libraries from the Win32s SDK.

Okay, so far now we have GCC 1.40 compiling to an old Xenix GAS assembler, and linking with Microsoft link from Visual C++ 1.0/2.0 era. The next step is to see if we can just link the objects under 196, and get a running EXE!

I have this tiny fibonacci example program, so with it compiled & assembled by GCC & GAS, I did the final link under 196, and YES it runs!

I then built the ’87 InfoTaskForce, Infocom interpreter, and it was just a simple link, and it’s running!

Possible things to do? GCC should be able to build itself, so it should be possible to build GCC and link that on 196 or December 1991, and get a native version of GCC on NT. The other possibility is to get newer versions of GCC (cc1 drop in replacements) to build for Xenix and / or OS/2. Obviously this Xenix linker is the gateway to older 386 Microsoft based products!

For those interested in such things, I’ve uploaded all of this to archive.org here: windows-nt-196-linking-and-running-gcc

So I went ahead and added the zeeDooM thing I had been working on a while ago which is a combination of the John Romero released maps, and the FreeDoom assets. So it’s not 100% the released version, it just looks that way.

I’ve gone ahead and created a qemu disk image (if you convert it, it does run on VMware, so probably far more 386 capable emulators than I can imagine), along with an old Qemu exe for some stand alone fun on archive.org.

There is no sound, nor music. I should look closer one day, and see if I can drive some direct music to an Adlib since it’s just IO ports, and maybe grab all the direct sound code from viti95’s FastDoom?

Anyways, it’s zeeDooM!.. on Xenix!

In the previous post we managed to install a Compaq-branded version of SCO Open Desktop. One of the recommendations was to use a small hard drive and avoid LBA, since SCO Unix does not recognize it.

It turns out, however, that SLS UOD429A, the bootdisk + patch that we used in the first post of this series to install ODT, also adds LBA support (as found out on A.P. Lawrence’s excellent website).

Apart from enabling you to fully use larger disks (you can install on a disk larger than 2048 cylinders, as long as you set its size to 2048 cyls during installation; you are of course going to “waste” a lot of space), LBA is more convenient if you want to have a large root partition, since the root partition has to be entirely in the first 1024 cyls.

So of course I tried repeating the installation of the Compaq version by booting off UOD429A, inserting the N2 from SCO ODT, and… I quickly found out that it would not recognize the CD as a valid installation media. Annoying.

Eventually I found out that the N1 disk from Compaq has a ramdrive compressed in the kernel, from where the initial installation script is run, while the rest of the files (mostly installscript) are on the CD itself.

The fix was, in the end, relatively simple. All I needed to do was mounting the N2 floppy in the VM I had created before, copying “N2.Z” on my harddrive. I then uncompress-ed it, extracted it (it’s a regular tar file), and replaced the installation script with the one provided on Compaq’s CD. Then, the reverse process can be done: recreate the “N2” tar file, compress it, and copy it in the mounted N2 disk. If you don’t want to go through the same process again, you can download the patched disk.

The installation process is then simple: boot off UOD429A, insert the updated N2 disk when requested, and proceed with the rest of the installation as usual.

This way I managed to install SCO Unix on a TI TravelMate 6050, alongside DOS and Windows 95. It took a bit of trial and error (reading SCO technical support documents was, again, very helpful), but in the end this is more or less what I did:

1. install Unix as LBA with a ~20mb DOS partition
2. hide DOS partition & create a new one as primary active partition
3. install Win95 on that
4. install boot manager (I used Paragon’s Boot Magic) on first DOS partition (the hidden one)

Steps 1 and 2 were done in 86box, after creating a disk with the same cylinders, heads and sectors found in the BIOS of my TravelMate (using the LBA setting in the BIOS of both laptop and emulated machine, of course). After installing DOS and SCO Unix (I’m not sure anymore in which order), I copied the Win95 installation files on the new partition and finished the installation process on the laptop, after dd-ing the image to the CF card I’m using as hard drive.

After configuring Boot Magic (and creating a custom background and icon), now I’m greeted with this every time I boot up the laptop:

Since Windows 95 is installed in a FAT16 partition, I can mount it or access it via dosls/doscp inside SCO Unix too, which is convenient for sharing files (I tried installing a 3Com 3C589 PCMCIA card directly in Unix, since according to the docs it’s supported; unfortunately, the provided drivers only work with IBM PCMCIA controllers).

SCO Unix software

A large collection of ports for SCO Unix can be found at ftp.celestial.com, but it’s faster to use the ISO with all the ports I uploaded on archive.org.
To mount the CD with lowercase filenames, run #mount -rf HS /dev/cd0 /mnt

It’s worth noting that, before using the CD, we need to install it with mkdev cdrom (yes, even if we did install the whole system from a CD). In the process we will be asked whether we want a CD-ROM/TAPE device, which can be used to install more components for the system (CD-ROM/TAPE is the format used by the setup CD), and if we want to add to the kernel ISO9660 support, which of course we need. As usual, SCO documentation has a lot of information about this.

Gzip is included in the Celestial ports, but I also managed to compile an early version of bzip2 (here is the binary). If you compile it yourself use gcc, the code will be faster. The provided Makefile undefines __STDC__; gcc sets the flag and this creates problems at linking time, resulting in a call to a missing “__unlink” function.

Bonus content: recovery disks

In the process of getting more familiar with the installation process of SCO Unix, I realized I could benefit from having a set of spare bootdisks that would allow me to mount the hard drive and modify files at will (including after the first part of the installation process). So, I created them, using a ramdrive + compressed disk (similar to what SCO’s install process does, but also the boot floppy of Windows 98) to pack as many utilities as possible on a single disk.While I was at it, I did the same for Xenix 386.

I bet most would never imagine an article like this. And yes, it’s really Bill Gates on the cover. And yes the lead story is about Xenix. Really.

And can you imagine what magazine would have such a glowing photo shoot of Gates? I almost wonder if anyone can imagine which one it would be?

The main point of course is binary compatibility between x86 distros, and killer apps. Of course not quite in that terminology but it’s there. Even in 1985 the hints of the far superior 80386 was being actively talked up, and the promise of a Xenix for the 386 as well.

And the magazine?

Yeah it’s Unix World. Volume 1, issue 5.

A bunch of early issues found their way onto archive.org, and it’s great stuff going over the old ads for SUN, HP, and all the old vendors, the articles wondering what will the future of BSD be, and Bill Gates on Xenix.

I know this will be a great score for all my Xenix fans!

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 [0] s->cylinders 203 s->heads 16 s->sectors 63
ide_init2 [1] s->cylinders 0 s->heads 0 s->sectors 0
ide_init2 [0] s->cylinders 2 s->heads 16 s->sectors 63
ide_init2 [1] 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:

ifconfig dlink0 10.0.2.15 -trailers broadcast 10.0.2.255 netmask 255.255.255.0

Which at least brings it up a bit better. I added in a gratuitous ping also in the startup script to build the arp for the gateway.

ping 10.0.2.2 32 1

Which brings us to the next point, the routing command is broken after loading the D-Link driver. I tried all the available TCP/IP drivers for Xenix (1.1.3.f 1.2.0e).

# route add default 10.0.2.2 1
add net default: gateway 10.0.2.2 flags 0x3: No such device or address

So no dice there. And yes, for SLIP/no interfaces the route command works as expected, just not with the DLINK driver.

However local connections from the host machine do work, so yes, you can telnet into the VM!

This makes using Xenix far more usable say for managing files, control/compiling etc.

For you die hard IRC fans, all is not lost, you can simply run a local proxy (See: Teaching an old IRC dog some new tricks) on your host machine, and point the irc client to 10.0.2.2

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:

qemu-system-i386.exe -net none -L . -m 16 -hda xenix.vmdk -device ne2k_isa,mac=00:2e:3c:92:11:01,netdev=lan,irq=10,iobase=0x320 -netdev user,id=lan,hostfwd=tcp::42323-:23

This is based off my old post, Running Netware 3.12 on Qemu / KVM 2.8.0 although with a few more flags to assert the user mode tcp redirect.

I’m using Stefan Weil’s build of the x64 native i386 Qemu.

I have recently acquired this artifact:

It’s the Microsoft BASIC compiler for XENIX 286 Operating System. Compiler as opposed to just BASIC interpreter, it can produce executable a.out files, similar to C compiler for example.  

Carefully removed the shrink wrap. Inside were couple of 5.25″ floppies, registration card and a manual:

Interestingly the 32 year old disks read just fine on a first attempt. I need to start backing up important files to 5.25″ floppy disks as they seem to outlast everything else.

Thanks to efforts of Michal Necasek from OS/2 Museum now you can run Microsoft XENIX 286 in Virtual Box. 

The disks can be installed in to XENIX running on Vbox following a few simple steps:

tar xvf /dev/fd0
./msinstall /dev/fd0

Upon installation you invoke the compiler like this:

bascom demo.bas
./a.out

And it produced an a.out executable which worked perfectly fine.

It’s fun to write BASIC code in vi editor, which I just realized I never done before.

Curiously the compiler also worked on the brand spanking new Xenix 2018, or rather I should call it Open Server 6, which you can download here.

The BASIC compiler is available for download from my archive along with the manual in pdf.

Apparently lots of IRC servers have slightly changed their syntax, which prevents ircII-4.4 from working.

It’s a simple fix.

In server.c, the the last line of the procedure login_to_server should be:

send_to_server(“USER %s 8 * : %s”, username,realname);

That’s it!

ircII-4.4 on Xenix 2.3.4

For Xenix users, you can download the binary tar here.

As for how you’ll get it working, well…

3comB network card

What has long been a frustration with the beleaguered Xenix community is that although there was a TCP/IP package for Xenix (and a much required streams package…) it only worked with a handful of ethernet cards.  And all of them were early 3com’s.  While the world was using NE2000’s on just about everything, the most common ethernet board Xenix would talk to was the 3c503, which is getting harder and harder to find as the years go on by.

But right now none of this matters.

I was looking at this article on setting up Apollo Domain UNIX, on MESS.  And apparently it will do networking!  Which is cool, so I poke around MESS, and what do I see? 3c503.c. Could it be true?

Now I ended up having to download the source to mame 0.151 (mame0151s.zip) and building it on OS X.  Of course remembering to alter the makefile to include the ‘USE_NETWORK=1’ statement, and build for Mess.  And just as it looks like something out of SIMH, Mess makes use of libpcap which means that you are *unable* to send/receive on the host computer. (OS X & Win32 binaries).  And of course you’ll need a ROM & Xenix diskettes.

Installing Xenix is pretty straightforward as long as you know your system key, and how to navigate the mess UI without rebooting mess or exiting by mistake (scrolllock on the PC, function/Delete on OS X).

First create a hard disk, and as always it should be ~500MB max.

chdman.exe createhd -o xenix.chd -chs 1015,16,63
chdman – MAME Compressed Hunks of Data (CHD) manager 0.149u1 (Aug 10 2013)
Output CHD: xenix.chd
Compression: none
Cylinders: 1015
Heads: 16
Sectors: 63
Bytes/sector: 512
Sectors/hunk: 8
Logical size: 523,837,440

then with the disk in hand, I just setup a 486 like this:

./mess64 at486 -harddisk1 xenix.chd -isa2 3c503 -ramsize 8388608 -floppydisk1 xenix/n1.vfd

Naturally you’ll need to setup the CMOS, for your memory size, and the hard disk.  The BIOS I’m using didn’t autodetect the IDE drive, but it doesn’t matter as I know it’s characteristics as I created it.

From there Xenix was a pretty straight forward deal.  Mess has good floppy drive emulation so it just worked.  Adding TCP-IP was just as involved, and all went well.  When it came time to install TCP & the network driver, remember to use thinnet, as the thicknet transceiver isn’t connected (as it would seem).  The 3c503 is softset, so I went with IRQ 5, port 0x300, and thinnet, and it works fine for me!

Xenix TCP/IP in action, inside of MESS!

Remember you will not be able to attach to it from your computer.  Instead you must attach from another computer.

Also MESS tries to emulate true to hardware so it’ll be just as slow on MESS as it was on the real hardware.  I suppose you could go with the at386 driver, but yeah it’ll be slow.  The current at586 driver has issues booting from the hard disk, and I didn’t mess with it too much as Xenix is known to have issues with some Pentium systems.

Although I think the next place for adventure is the emulated Adaptec 1542CF.

Hack

I figured that since I could build hack for some ancient 4BSD flavors that I should be able to build hack for good old fashioned Xenix.

And it all seems to work as it should!

I used the source from here, and only had to do a few small modifications to get it to compile and run on Xenix via GCC 1.37.1 .

You can download my binary, and source mods.

I’ve managed to keep this instance of Xenix up for 19 hours, I was thinking about doing some kind of public access to this system, but I don’t know if people would even be vaguely interested..

But if you want access, I can set you up.

Although all that is of interest is ‘dungeon’, fortune, hack, robots, and ircII …

USER Not enough parameters

Not enough parameters? And the worst thing is that I got this error EVERYWHERE… Googling this has become useless as everyone just says google it, so google made all that turn into a negative feedback loop! Or even useful advice like ‘upgrade your client, LOL’, but after going through an hour of `fun` getting this to run on Xenix I wasn’t going to try a new version of the source just yet.

Going through the source, looking for the USER command and where its used and found this:

send_to_server(“USER %s %s %s :%s”, username,
(send_umode && *send_umode) ? send_umode : hostname,
server_list[server].name, realname);

Which looks nice, but according to this as a reference, it doesn’t have enough parameters! So I figured I’d change it to something more like this!

send_to_server(“USER %s 8 * : %s”, username,realname);

this is a bug free client. honest

And as you can see, it works!  Even the version string reports Xenix!

If anyone cares, you can download the binary here.