Installing SCO Unix 4.2, part 3: LBA disks

This is a guest post by Friggigatto

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.

Installing SCO Unix 4.2, part 2: the devsys

This is a guest post by Friggigatto

In the previous post we saw how to install SCO Unix 4.2 and SCO ODT on a virtual machine. Sadly, both distributions lack the development system, making them a very limited toy.

At some point I noticed that the filesize of the ISO of SCO ODT 3.0 branded by Compaq (found again on the Internet Archive or WinWorld) is way larger than the other available distributions: could it be that it includes the Development System as well? I decided to find out.

Inside the ISO we can find a N1.IMG file, and we can start the installation by booting from that.

At the serial request I discovered that this version is not the same as regular ODT, and thus the serials I had did not work. I tried extracting a to-be-serialized file from inside the CD.IMG file found on the ISO by opening it with a hex editor (the file is not in ISO9660 format; it’s specific to SCO and somewhat emulates a tape drive, with multiple tar files in it. Opening it with a hex editor, it’s easy to see where one of these tar files starts and ends), extracting it with tar, and running it through brandy to generate a new serial.

Brandy, however, generated the same serials/activation I had already, indicating that the validation mechanism used by the installer in this release is different. I was afraid it would be a Compaq-specific addition, thus almost unrecoverable, but after searching Usenet I found this post (mirror) which suggests that different versions of ODT have different generation mechanisms; in any case, the keys provided in the “OSE” (Open Server Enterprise) column work.

Anyway, after inserting the serial the installation proceeds smoothly, and we can even select to install the Development System:

The DevSys also requires a serial, and for that I used one found on the archive of Tenox. The installation started with the incredibly slow process of badtracking the hard disk (and I had selected the “quick” check!) and proceeded smoothly, until it tried to install the “Compaq EFS for SCO Unix”:

The error interrupts the installation scripts and leaves the system in a half-baked state: we can reboot from the HD and load the kernel, but instead of getting to a terminal or login prompt we are dropped in a broken installation script that won’t proceed.

To fix the issue, I opened up again the ISO with a hex editor and looked at the install script (/inst5/customize). The fix is easy: search for the string “cleanup $FAIL” inside the CD (line 238 of the customize script), and replace the initial “c” with a “#” to comment out the line entirely (a neater solution would be to change the script so that it won’t install the Compaq EFS in the first place; I tried to do that as well, but it didn’t work).
Since we are at it, we can also modify the params.stz file in the ISO and disable badtracking completely (search for badtrk_none) and speed up the next installation considerably.

Restarting the installation once again with the same settings will still give the error, but this time it won’t kill the installation script and it should now complete successfully (with some warning messages since it’s not an EISA machine).

After the reboot, we should be finally welcomed into “SCO Open Server (From Compaq) Enterprise System Release 3.0”.

We can now remove the whole Compaq EFS using custom, or just the UPS drivers /etc/rc.0d/*ups and /etc/rc2.d/*ups, in addition to /usr/bin/compaq. We can also apply the patch to the disk driver to run on faster machines, as mentioned in the previous post. Finally, we can install SCO supplements from SCO’s FTP, and in particular:

  • uod426d – Y2k fix;
  • uod374a – better CD support (you can run programs from ISO-9660 CDs, for example from early SCO Skunkware releases; you can also mount CDs forcing each name to lowercase, instead of the annoying default where everything is in uppercase);
  • net382e – better TCP/IP support.

Now we have a working SCO Unix 4.2 system with the development system! The good thing about SCO Unix is that the C compiler is more modern than the one provided by SCO Xenix, but can still target Xenix (with the -l2.3 directive). This means we can compile slightly more recent software for both systems, for example bash 1.13.5 and bzip2 0.1pl2.

Continued in Part 3!

Installing SCO Unix, part 1

This is a guest post by Friggigatto

I’ve been messing around with SCO Xenix for about 10 years now, and in the process I have been playing with OpenServer 5/6 as well (mostly as a mean to copying big/many files to a Xenix VM: I’d just create an ISO file, mount that in OpenServer, then share the Xenix HD with OSR5 and copy the files over); however, I never got around to use SCO Unix.

A while ago I decided to change this, but it took many tries to get to install everything, especially the Development System; so, when I eventually managed, I decided to do a writeup of what I did (and part of what stumbling blocks I encountered along the way).This is the “first episode”, which should give you enough info to install SCO OpenDesktop 3.0 as found on WinWorld or on archive.org, and the ODT Server 3.0 version from BetaArchive. ODT is nothing else than SCO Unix 4.2 bundled with X11 and TCP/IP (while on Xenix these are separate products).

Installing SCO ODT, floppy version

The secret to installing the 4.2 floppy version was to use the updated N1 boot diskette (SLS uod429a from SCO). Once you have it, the installation process is quite straightforward and self-documenting, especially if you are used to the slightly more convoluted Xenix install. This version can even be installed in VMWare.

The serial/activation is included in the release files; create a VM with an hard drive <2gb, during the setup process select “Floppy” as the install media, a “quick” bad track scan type and then simply confirm every step. You will be asked to insert all the disks in order, and the only challenge should be surviving the mind-numbing boredom of handling more than 40 floppies.
Unfortunately, the network and graphics card are not supported on VMWare (I suggest to boot the first time in single-user mode and disable the GUI from starting automatically with “scologin disable”), so it’s a good idea to install on 86box instead.

While we are at it, we can even spare ourselves some of the boredom by using the CD version instead.

Installing SCO ODT, CD version

For the ODT CD version, I looked up at what SCSI devices are supported (mostly by running ‘strings’ on the kernel inside the boot floppy image, looking at the device driver names and comparing them with those of OpenServer 6), and created a machine on the latest unstable 86box build (3.0.0.2983) like this:

  • i486-socket 2 and 3: [i420EX] ASUS-PVI-486AP4 (many other boards work as well, but faster CPUs/machines would give me issues… more on this later)
  • Intel i486SX 33mhz + 487SX
  • 32 Mb RAM
  • Serial Logitech mouse, 3buttons
  • Video: ISA16 Orchid Farenheit 1280 [note for the setup: the emulated bios is 2.0 – supports 1024×768@256 colors]
  • SCSI controller: aha-154xA
    Address 0x330, IRQ 11, DMA 5
    Host ID 0
    BIOS C800H
  • SCSI cdrom
    Controller 0, ID 5
  • IDE hard drive, <2Gb, non-LBA (check the BIOS settings)
  • If you want Ethernet, use WD8013EBT (drivers are included)
    IRQ3 address 240

The OpenServer release I found on BetaArchive was missing the N2 disk, but the one from the floppy release works fine. The process is simple: boot from N1, the SCSI adapter should be recognized by the kernel (a line that starts with “%adapter” and then the IRQ settings etc.), and so should be the disk drive (%disk):

You can use the same serial as for the floppy release, but this time indicate “SCSI CD-ROM” as the install media, and it should install fine. You should however deselect the DOS Services, as Unix will crash after the first reboot while trying to install them.

Once the installation is complete and the system restarted, it will greet you with this very dramatic login screen (and ironic too: SCO and Open Systems in the same logo) and its pastel-colored UI:

Running on faster machines

The 33 mhz CPU is surely not a beast by today’s standards, and the emulated system feels sluggish enough also under ODT; however, switching to a faster CPU would crash the system. Luckily, SCO’s former support website (I created a mirror of the tech articles on archive.org) has a solution for this: we can modify a driver to avoid kernel panics on quick systems. After booting into single-user mode, we can run

# cd /etc/conf/pack.d/pit
# cp Driver.o Driver.orig
# _fst -w Driver.o
* spinwait+2D?w F989 FEE2
* $q
# cd /etc/conf/cf.d
# ./link_unix -y

Finally we can safely reboot, this time with a better CPU. The fastest machine I could test is a Socket 5 (i430NX Gigabyte GA-586IP) Pentium MMX Overdrive 200Mhz. When a faster system is selected (e.g. those based on Socket 7), the mouse stops registering the vertical axis.

In the next post, we’ll see how to install ODT with the development system.

Running VMWare ESXi on Raspberry PI

(This is a guest post by Antoni Sawicki aka Tenox)

Just for fun with virtualization I wanted to try out VMWare ESXi for ARM64, most specifically Raspberry PI. ESXi for ARM has been around for a couple of years now. Since PI4 packs 8GB of RAM and has a reasonably fast CPU it can be a worthwhile experience. Also more OSes for Raspberry PI are now available in UEFI boot mode.

Not going to go through exact installation steps as these are all around the web and youtube. Just to summary you will need to download an image from VMWare website as well as bunch of UEFI firmware files from github and combine it all together on to a SD card. When you boot it you will go through an install process which is straightforward. You can overwrite install media and use it as the target so no need for multiple SD cards. Once it boots you will see familiar ESXi boot screen:

ESXi booting on Raspberry PI 4

In order to get it going you will obviously need to add some storage. You can use NFS, iSCSI or locally attached USB drive. For the latest you need to disable USB arbitrator.

# /etc/init.d/usbarbitrator stop
# chkconfig usbarbitrator off

What can it run?

ESXi ARM only officially supports only UEFI boot based OSes. Fortunately this is a default option for Ubuntu PI, Free/Net/OpenBSD also work and so does Windows. But what about OSes that use U-Boot? Since ESXi-ARM Fling 1.1 you can boot oses in a “direct” mode with no UEFI! This is a huge step, but unfortunately as of today it doesn’t support UEFI-less VGA, only a serial port. Hopefully this can be fixed in future. I would love to have a RISC OS and/or Plan 9 VM. On the other hand Plan 9 supports EFI boot so an image could be made.

Windows guest install was also much easier than I expected. Thanks to UUP dump you basically roll your own bootable ISO. I think it’s actually easier to get it going on ESXi than natively on RPI hardware or QEMU.

Windows 10 Guest VM on ESXi Fling Raspberry PI

NIC driver obviously did not work by default, but there is a VMXNET3 ARM64 driver in the wild:

VMXNET3 for Windows 10 ARM64 on ESXi Fling on Raspberry PI

What is it good for?

Right now probably just for fun. But I can easily see datacenters filled in with ARM servers running ESXi. Future is bright and free of Intel! Personally I will keep it around for development purposes if I need to make builds for ARM on various OSes.

Interestingly enough you can even run VMWare ESXi ARM on QEMU with nested virtualization!

Also this is the official VMWare ESXi ARM Blog worth checking for future updates.

Web Rendering Proxy (WRP) 4.5.2

(This is a guest post by Antoni Sawicki aka Tenox)

Pleased to announce WRP version 4.5.2. This is just a bug fix release however it also contains two frequently requested features:

UI customization via HTML template file. This has been requested by many users and it makes total sense. To use it download wrp.html from github, place in the same directory as wrp binary and edit to your liking. WRP will load built-in version if file is not present.

This should enable easy development of more modern UI for never browsers. Potentially with JS and CSS. Please send PR if you make something!

Second most frequently asked feature – re-capture (retake?) of a screenshot without page reload. For example if the page did not capture correctly or if something is changing on the page.

I have also updated Docker Hub and gcr.io repos.

Sun IPX using WRP at VCF West

As usual please test and report bugs!

The next update will focus on issues with page size, viewport and rendering full length pages (h=0) which is currently very broken.

Windows Dev VM

(This is a guest post from Antoni Sawicki aka Tenox)

I have been living under a rock for several years now when it comes to Windows development. Recently wanting to do some maintenance on couple of my projects I needed to download Visual Studio and Windows SDK. Poking around the download page I have discovered that Microsoft now provides a fully pre-installed VMs with Visual Studio, SDK etc. for VMware, Hyper-V, VirtualBox and Parallels. That’s actually super cool and handy. Thank you Microsoft!

Looks like this has been available for 3 or 4 years now. Oh well.

Yedit – The missing edit.com replacement for modern Windows

(This is a guest post by Antoni Sawicki aka Tenox)

I previously lamented about lack of a small text editor for Windows text mode console. Something simple to just edit a text, configs, .ini, .reg or .cmd/bat files. Kind of like edit.com in MSDOS and Windows 3.x/9.x. Edit.com could even run under Windows NT up until XP inside NTVDM DOS emulator. I seen plenty of people use it this way. Sadly, instead of porting it to the modern Windows it was just whacked. While there are plenty of 3rd party editors to choose from none of them is perfect. They are either expensive, overly complicated, poorly ported from Unix, VMS or TOPS20, no longer maintained or require a steep learning curve for a casual Windows user.

My cries must have been heard in Redmond circles. Malcolm Smith aka malxau (author of Yori, a super awesome command line replacement for Windows) stepped in and made a brand new, text mode editor called Yedit. By default It comes as part of Yori installer however it’s easy to separate it to a stand alone exe.

Yedit on Windows NT

There really isn’t much to talk about Yori. It has no special features. It doesn’t try to be an IDE, word processor, hex editor or an operating system. It’s just a perfect replacement for edit.com. Thank you Malcolm! I really wish that Microsoft just put it in Windows 10 now.

Yedit on Windows 10

While checking out Yedit you should also give Yori a try. It’s really a fantastic CMD replacement shell.

Reverse-engineering QNX 1.2 to boot from HDD

This is a guest post from Mihai Gaitos, hawk.ro. A winning entry for Virtualization Challenge IV – Act II – QNX 1.2 HDD Boot ($2000 prize).


Since a lot of people (especially Zir Blazer) tried to use the available QNX 1.2 / QNX 2 tools to install a HDD boot loader and load the existing kernel, I decided to take a different approach and build a new loader. At first I was under the impression that maybe a BIOS disk driver was already present in the kernel. After realizing that there was no HDD driver included, I decided to try reverse-engineering the relevant parts of QNX.

Starting from the start (boot sector) helped me extract the kernel from the boot diskette and analyze it just enough to validate that it’s the right thing and the assumed entry point is correct.

In order to make things easier (and because it was a fun project per se) I wrote a somewhat simple QNX filesystem access tool that enabled me to extract files from the diskette and HDD images.

Going for mount

Afterwards, my main activity was centered on mount. As opposed to typical Linux/Unix mount, here it also loads the HDD driver. After finding out the executable file format (ftp.qnx.com/usr/free2/technotes/qnx_load) I wrote another small tool to extract the code and data segments of QNX executables. Analyzing the disassembly, I have determined what operations mount performs in order to install the driver and mount a QNX partition. The main steps are:

  • load the driver file contents into malloc-ed buffer (inside the data segment of mount)
  • send a TA_ALLOC_SEG message to task in order to allocate a separate segment and copy driver there
  • build a DEFINE_DRIVER message using data from driver file and the allocated segment address and send the message to fsys (part of kernel, but separate task)
  • send a SET_ATTR message to fsys that has the side-effect of initializing the driver
  • use the driver to read first HDD sector (partition table)
  • send another SET_ATTR message to adjust disk size and offset to values read from partition

Knowing this gave me an idea to what my loader would need to do beside simply loading the kernel from HDD. However, this still depended on having an already running kernel to send messages to.

Back to kernel

The kernel is split into 5 parts:

  • task (task and memory management)
  • fsys (disk and filesystem)
  • dev (terminal devices)
  • idle (CPU arbiter)
  • shared (int 72 handler, mostly libc and other shared functions)

Description in parenthesis are my assumptions.

The copy protection routine (tries to read the last sector from diskette and if the read succeeds resets the computer) provides a good entry-point into the fsys part of the kernel. I assumed it can be replaced with some code to emulate what mount does. However, trying to allocate a segment (via TA_ALLOC_SEG message) hangs. I think this is causing a deadlock, since fsys initialization is called from task before it finished its initialization. Fortunatelly, while digging into this I noticed the header structure of the kernel, thus enabling me to increase its size in order to fit the xt driver at the end of fsys (it would have been slightly easier to put it at the end of shared, but that didn’t occur to me at the time).

Failing to use syscalls (DEFINE_DRIVER and SET_ATTR) meant I had to determine what those messages actually did. I disassembled fsys separately and proceeded to manually follow the code path in order to determine the effect each of those messages should have in the context of mounting a disk. Eventually it emerged that almost all of the data structures can be prefilled in the kernel image, leaving only the call to driver initializaion function.

I modified the kernel to add the xt driver at the end of fsys (modifying the header by hand), replaced the copy-protection routine with code to call its initialization, and indeed the harddrive was available from the start, without the need to run mount. I was still booting from diskette at this time but I was past the most difficult hurdle.

Finishing touches

Loading the kernel proved somewhat simple (I still have some knowledge about 16-bit assembly and real-mode BIOS) but the kernel “insisted” in trying to run /cmds/sh from floppy. At first I solved this by an ugly hack, modifying the command line string in kernel image from “/cmds/sh” to “3:/xi/sh” and “/config/sys.init” to “3:/xi/sys.init” (3: being the HDD identifier, similar to C: from DOS). The xi was needed in order to keep the same string length, or at least not making it larger since there was some other importand data just past this.

This mostly solved the challenge (there were some other minor mistakes and fixes), except I disliked that hack and went on to analyzing that first start of /cmds/sh, disassembling fopen (in shared) and finally finding the memory location where of the search system variable (somewhat similar to PATH). Modifying that variable eliminated the need for starting the first shell with “3:”.

Room for improvement

At present some parameters are hardcoded and the kernel is just placed at the end of the HDD, outside of QNX parition and its position and size is written in the boot sector (somewhat similar to the original QNX diskette approach). The partition size itself is hardcoded (by hand) in the kernel data structures instead of being read from the partition table on boot. Still, for something that is unlikely to ever run outside an emulator, I deem it good enough (for now).

Thanks

  • to Zir Blazer for putting a lot of effort into his approach and documenting each step
  • to Mitchell Schoenbrun for providing insight into QNX system philosophy
  • to forty for beating the first challenge and identifying the copy-protection routine address
  • and of course, to Tenox, Neozeed and Dan Dodge for the challenge. And for providing me with a great prize for 3 weeks of hard-working fun!

To access files, tools, bootable image and ready to run in your browser PCjs with QNX 1.2 go to Mihai’s site hawk.ro post.

UnixWare 1.0 on 86Box

(This is a guest post by Antoni Sawicki aka Tenox)

I certainly can’t claim to be the first as this has already been done by our friends at OS/2 Museum. However with low vanilla VGA resolution and no networking the results were unsatisfactory. Having so much success with 86Box I decided to try to do a little better.

I bought my UnixWare 1.0 media kit years ago on eBay. Unlike the tape set owned by OS/2 Museum mine had CDROM as install media. Unfortunately despite many many tries with different types of cdrom/bus/ide/scsi card I could never get the OS to see it. The cdrom/iso image is just a typical set of sysv packages. As such I wanted to see if it would be possible to convert it to a set of floppy disk images and install this way. Attached the iso image in UnixWare 7.1.4 VM and did a pkgtrans like so:

pkgtrans -s cdrom1 diskette1

From there I created a bunch of floppy disk images, which I later used for installation. Thanks to Plamen I was also able to get TCP/IP disks which I added to the install set.

Update: thanks to ArtiomWin I also got a BusLogic HBA driver disk, which allowed me to see the cdrom attached over SCSI. As such I decided to remaster the original iso image with added TCP/IP set, Update package and bash+gzip. The iso image is here.

Upon first boot after install from CDROM you get prompted to choose a NIC driver:

Unfortunately none of them really worked in 86Box for some reason. They get detected and you can see the MAC Address but not much after that. 3C503 and NE2K freeze the system, WD works bit better but you can’t really communicate with anything. Maybe it’s just my PCap configuration.

After installation I mounted the cdrom again and added TCP/IP set:

mount -r -F cdfs /dev/cd0 /mnt
pkgadd -d /mnt tcpnfs
pkgadd -d /mnt update

cp bash gzip /bin

One of main issues bugging me was lack of proper resolution. UnixWare 1.0 has a high resolution mode for Tseng ET4000 card which is supported in 86Box. You can change the resolution using /usr/X/adm/setvgamode as root. It worked perfectly, except for fonts, which required some surgery in /usr/X/defaults/Xwinfont (remove everything after 75dpi font path). This is how it looks like fixed up:

UnixWare comes with Merge DOS emulator. It can even run graphical applications in windowed mode for CGA and HGC. VGA is only possible in full screen mode.

All this cool stuff before Linux was even born!

DOS Menu is invoked by Scroll Lock. You can switch consoles between text and X11 by pressing CTRL+ALT+SYSRQ and ‘p’. I have also added bash and gzip binaries.

The ready to run 86Box image is here. Virtual Box OVA here. Install media here. Login with user/user, root/root.

Have fun with Virtualization !

QNX 1.2 Virtualized

(This is a guest post by Antoni Sawicki aka Tenox)

A few week ago we ran a Virtualization Challenge to virtualize QNX 1.2. The difficult part of this one was that the boot disk was copy protected. Thanks to Kryoflux and SuperCard Pro I was able to image the disks and convert them to usable images using HxC software tool HFE.

Technically the competition has been won by Crazyc who was the first to submit disk images with copy protection worked around. He however waived his monetary prize and did not do any further work on making whole system bootable from hard disk.

While the copy protection turned out to be quite easy to circumvent and several people did it independently, installation on a hard disk proved to be quite impossible. You can fdisk, create partitions, lay out file system, mount and copy files to hard disk. However there is no way to install a boot loader and the kernel. QNX 2.x and above provide a way of doing it but unfortunately not version 1.x. Many people including various QNX gurus looked at it and we all gave up at this point.

Probably the only reasonable way of using hard disk with QNX 1.x is to copy all files from all the floppies to the hdd. Then use the boot floppy disk for booting and the rest from hard disk. This is likely why the disk set came with a backup copy of boot disk. This is what Forty eventually did in effect winning the competition. Forty supplied a 86Box ready to run configuration with patched and modified boot floppy to mount and use the hard disk image. I have buffed it up a bit to a faster XT and EGA video for better resolution. This is how it looks like during boot:

You can safely ignore date/time prompt with enter. To login to the system just enter slash ‘/‘ as the user name:

You can find all the binaries in /cmds directory. The system does have some sort of networking facility but I have not figured it out yet. Probably a good candidate to explore in another post.

QNX has a super cool editor which is basically ed on steroids. Documentation for it can be found in 2.x manuals.

Also working C compiler:

Finally QNX has some sort of a DOS emulator or hypervisor called QDOS:

Unfortunately I don’t know how to exit that. There is a little bit information about QDOX in expl inform section about other QNX products:

Congratulations to Forty for winning the competition and gettin $100 via PayPal. Thanks to his time and work you can boot and play the system yourself. 86Box files are here.

You may also be interested in QNX 2.x, QNX Windows and QNX 4.x posts.

Finally QNX 1.2 also works under PCjs emulator and you can try it online here.

Have fun with virtualization!

UPDATE : QNX 1.2 challenge Act II – HDD Boot

UPDATEReverse-engineering QNX 1.2 to boot from HDD