This honestly should have been much easier.

Or maybe I’ve just forgotten how absolutely hostile early OS X could be.

The mistake begins

It started, as these things always do, with someone mentioning the PowerBook G4 Titanium. One quick eBay search later and, well £30 later I owned one.

It showed up absurdly fast (Sunday delivery? really?), in surprisingly good condition, and I already had a charger. So naturally, the sensible thing to do was…

Install Tiger.
Which worked. Immediately. Of course it did.

But that wasn’t good enough

Tiger is fine. Great, even.

But it’s not Jaguar.

10.2 was always my favorite early OS X, that weird in-between era where it still felt experimental but usable. And according to basically everything online, early Titanium PowerBooks should run it.

So I grabbed a cheap “reproduction” 10.2 CD set.

And this is where everything went wrong.

Not a great start.

At first glance it looks like some kind of network address corruption, but in reality it’s just the kernel screaming because something is very wrong at a hardware level.

Time to go verbose.

Welcome back to Open Firmware

You can’t just hold C and Cmd+V like a normal person.

No, this is 2002.

So into Open Firmware we go:

boot cd:,\\:tbxi -v

Now we get actual output… and a much clearer failure.

FireWire: the red herring

The panic traces back to:

com.apple.driver.AppleFWOHCI

Ah yes — FireWire.

Because of course it is.

So the obvious thing to do is disable it from Open Firmware:

dev /pci@f4000000/firewire
" disabled" encode-string " status" property

And… it works.

Kind of.

The system gets further. No panic. Progress!

And then: the stop sign

Instead of a crash, we now get a

The classic “this OS is not supported on this Mac” symbol.

Which is when it finally clicks:

This machine is a PowerBook3,5 (867MHz)
And 10.2.0 predates it

So no, this was never going to work.

The FireWire panic wasn’t the root problem; it was just the first thing new enough hardware broke.

At this point, a normal person would stop

I did not stop.

If Apple won’t build it, we will

If 10.2.0 won’t run, then clearly the answer is:

• build a 10.2.8 install manually
• using QEMU
• on a completely different machine
• then sneak it onto the laptop

Perfectly reasonable.

Building Jaguar in exile

QEMU can emulate a G4 well enough to:

1. Install Tiger
2. Install Jaguar
3. Update Jaguar → 10.2.8

Something like:

qemu-system-ppc \
  -M mac99 \
  -cpu G4 \
  -m 512 \
  -drive file=macosx_6gb.vmdk \
  -boot c

From there:

• swap disks around
• update Jaguar
• boot back into Tiger
• use Disk Utility to create a compressed image

Eventually producing:

osx-10.2.8.dmg

Of course it’s not that easy!

First off is to get ISO images. I actually started this process with the Tiger I already have in hand. To grab an ISO under macOS 26 it’s a simple command:

hdiutil convert /dev/disk4 -format UDTO -o OSX_Tiger_10.5.iso

And about 20 minutes of the DVD drive spinning around I got my ISO image.

 % file OSX_Tiger_10.5.iso 
OSX_Tiger_10.5.iso: Apple Driver Map, blocksize 512, blockcount 5531738, devtype 0, devid 0, driver count 1, contains[@0x200]: Apple Partition Map, map block count 4, start block 1, block count 63, name Apple, type Apple_partition_map, valid, allocated, contains[@0x400]: Apple Partition Map, map block count 4, start block 64, block count 8, name Macintosh, type Apple_Driver_ATAPI, boot arguments DMMY, valid, allocated, real driver, chain driver, contains[@0x600]: Apple Partition Map, map block count 4, start block 72, block count 5531656, name Mac_OS_X, type Apple_HFS, boot arguments goon, valid, allocated, readable, writable, mount at startup, contains[@0x800]: Apple Partition Map, map block count 4, start block 5531728, block count 10, type Apple_Free

Now to run it under qemu:

qemu-system-ppc \
    -L pc-bios \
    -M mac99,via=pmu \
    -cpu G4 \
    -m 512 \
    -prom-env 'auto-boot?=true' \
    -prom-env 'boot-args=-v' \
    -drive file=tiger.iso,media=cdrom,format=raw \
    -drive file=macosx_6gb.vmdk,format=vmdk,cache=unsafe \
    -boot d \
    -net none \
    -no-reboot

And in a minute or so on my mac mini running “QEMU emulator version 10.1.2” from homebrew I was up and running. yay. I don’t need or care about audio/networking as this is just to get a PowerPC OS up and running, using the media I have in hand. Bring up the disk util, partition the VMDK, the install the OS. You’ve probably seen/done it a dozen times so nothing to really see here.

Once my 10.2 reproduction media arrive, I went through the hardware boot to only find out that 10.2.0 just won’t run on my PowerBook G4. This is where we use the emulation route. Could I simply grab an ISO using hdiutil?

NO

Of course not. Why would it work? It comes down to the older versions of OS X being very MacOS 9 style disks, which hdiutil simply will not grab. You end up with meaningless data. What about ‘dd’ on /dev/disk4? /dev/rdisk4? did you set bs=2048? YES YES YES… none worked.

So back in homebrew I got the cdrutils from Joerg Schilling which gives me the readcd command, which finally let me grab the ISO’s

% file OSX_Jaguar_10.2-disc1.iso
OSX_Jaguar_10.2-disc1.iso: Apple Driver Map, blocksize 2048, blockcount 331264, devtype 1, devid 1, driver count 4, contains[@0x200]: Apple Partition Map, map block count 10, start block 1, block count 63, name Apple, type Apple_partition_map, valid, allocated, in use, readable, contains[@0x400]: Apple Partition Map, map block count 10, start block 64, block count 56, name Macintosh, type Apple_Driver43, boot arguments ptDR, valid, allocated, in use, has boot info, readable, writable, pic boot code, real driver, chain driver, contains[@0x600]: Apple Partition Map, map block count 10, start block 120, block count 140, name Macintosh, type Apple_Driver43_CD, boot arguments CDrv, valid, allocated, in use, has boot info, readable, writable, pic boot code, real driver, chain driver, contains[@0x800]: Apple Partition Map, map block count 10, start block 0, block count 0, type Apple_Void, contains[@0xA00]: Apple Partition Map, map block count 10, start block 260, block count 56, name Macintosh, type Apple_Driver_ATAPI, boot arguments ptDR, valid, allocated, in use, has boot info, readable, writable, pic boot code, real driver, chain driver, contains[@0xC00]: Apple Partition Map, map block count 10, start block 316, block count 140, name Macintosh, type Apple_Driver_ATAPI, boot arguments ATPI, valid, allocated, in use, has boot info, readable, writable, pic boot code, real driver, chain driver, contains[@0xE00]: Apple Partition Map, map block count 10, start block 456, block count 512, name Patch Partition, type Apple_Patches, valid, contains[@0x1000]: Apple Partition Map, map block count 10, start block 0, block count 0, type Apple_Void

As you can see it’s a lot of partitions, and various bits that it’s expecting. Kind of annoying that the system utils cannot grab these kinds of images, but in the end we got there.

Naturally, Jaguar has to be run differently as it’s just more tied to older hardware:

qemu-system-ppc \
-machine mac99 \
-cpu G4 -m 1G \
-name "Mac OS X 10.2" \
-hda "macosx_6gb.vmdk" \
-cdrom "OSX_Jaguar_10.2-disc1.iso" \
-device pci-ohci,id=usb1 \
-device usb-mouse,bus=usb1.0 \
-device usb-kbd,bus=usb-bus.0 \
-device usb-audio,bus=usb1.0,audiodev=audio \
-audiodev id=audio,driver=coreaudio \
-device sungem,netdev=network \
-netdev id=network,type=user \
-no-reboot \
-accel tcg \
-boot d

The next catch is that the diskutil just hangs partitioning the hard disk. I’ve no idea why.

So, the solution is to boot back into Tiger, add a second disk, partition it there, and then use that disk in the Jaguar boot. After that it installs just fine. I enabled the sound and network just to setup NTP so at least my image isn’t too stuck in 2002.

Oh, one trick I found out decades too late, is that you can cloverQ the named registration, so you don’t have to make up bogus phone numbers and a semi valid mailing address. I didn’t know is that, it’ll just kick you to the account creation screen, and you are good to go!

After that it’s just a matter of running the 10.2.8 combination patch, to bring the VM up to 10.2.8

From there the final hurdel is to create a RAW disk image to transfer the Tiger diskutil ‘disk image’ to. This way you can easily mount the RAW image by renaming the extension to .dmg and OS X (thankfully) still supprots HFS+ so you can simply use finder or ‘cp’ to copy off the compressed disk image onto a USB drive, and now we are ready to image the PowerBook using our updated OS X Jaguar!

The USB betrayal

Naturally, the Tiger installer refused to mount USB.

Because of course it did.

The final workaround

So instead:

1. Repartition internal disk
   • small staging partition (~4GB)
   • main target partition (remainder of the disk)
2. Install Tiger (again)
3. Copy 10.2.8.dmg to staging partition
4. Boot Tiger installer
5. Use Disk Utility → Restore image onto main partition

And finally…

Success

Jaguar 10.2.8.

On a machine that absolutely refused to run 10.2.0.

With Office 2004, because why not.

Lessons learned

• Early OS X is tightly hardware-bound, not just “older”
• Kernel panics are often symptoms, not causes
• FireWire was innocent (this time)
• USB support in installers was… optimistic

And most importantly:

Just because you can reconstruct a historically accurate install pipeline via emulation and disk imaging…
doesn’t mean you should.

The obvious solution (that I ignored)

A single FireWire cable.

Target Disk Mode.

Done in 20 minutes, by using my B&W G3 PowerMac that is currently running Windows NT, but it wouldn’t matter as I could just hold option and select the FireWire target disk to boot to/from as it’ll happily boot/install 10.2.0 without a hitch. It being a G3 makes no difference as the same kernel works on G3/G4 processors.

But where’s the fun in that?

For those brave enough to get to the end of the post, I uploaded all my Jaguar images onto archive.org. I’m sure it’s been preserved before, but since I was in the mood, I also uploaded Office 2004.

Definitely not the first person doing this. In fact this has been quite widely documented, in particular by astr0baby and openpa.net. Just my personal observations and tweaks.

Install

ISOs from 2006 MCOE work just fine

qemu-img create -f qcow2 hpux.img 20G

qemu-system-hppa \
-machine B160L \
-smp cpus=4 \
-accel tcg,thread=multi \
-boot d \
-drive if=scsi,bus=0,index=6,file=hpux.img,format=qcow2 \
-m 512 \
-d nochain \
-cdrom mcoe.1_5.iso \
-net nic,model=tulip \
-net user

I installed mostly the defaults, removed Java spyware and Web based management.

I recommend using advanced mode and editing File Systems to your desired size or just leaving /stand and / and deleting everything else. Otherwise, if you do defaults, you will be facing resizing them in single user mode later.

Forget any serial console, telnet stdio or forwarding X over SSH nonsense. Graphical console now works fully end to end without any issues, except for nsswitch.conf.

When trying to login via CDE you will get an error about unable to start desktop messaging system. Login either via text console or failsafe session. Copy /etc/nsswitch.files to /etc/nsswitch.conf. Also make sure that your hostname can resolve via /etc/hosts.

Once this is done you should be able to login via CDE:

If you left filesystem defaults, you will be facing this:

To fix this, add -boot menu=on to qemu parameters, run boot pri then answer yes to interact with IPL and then type hpux -is.

This will land you in single user mode where you can extend volumes like so:

# cat /etc/fstab
....
lvextend -L 4096 /dev/vg00/lvol7
extendfs /dev/vg00/lvol7
....

But ideally this should be done ahead of time during install in File Systems tabs (advanced mode).

I like to disable some slow starting and unnecessary services on startup, to do so go to /etc/rc.config.d and edit bunch of files changing value from =1 to =0. I typically disable SNMP, CIM and Mailserver, Webadmin, Diagnostics, EMS, nettl, icod, etc at minimum. Also some stubborn services need to be disabled by renaming or removing them from /sbin/rcX.d …

Software Install

Note that this emulates PA-RISC 1.1 (32bit) and software built for PA-RISC 2.0 (64bit) will not work. Very little software is marked which platform is it for, so your mileage will vary. You will encounter errors and crashes. To avoid confusion check the binary with file(1) utility.

I have a bunch of handy tools like bash/gmake/gzip/gtar/ncftp bundled up here. There is GCC 4.0.2 here as a depot and here as a tarball. I also installed a bunch of tools and enhancements from Soft Pack and Apps cdroms.

Most importantly SimCity!

More games can be found here. However this emulated HP-UX doesn’t have working OpenGL so don’t expect much.

Finally, to shut down the os:

reboot -h

The ready to run image is available here. It works with QEMU 10.1. It has bash & gcc pre-installed. Login as root/root.

Luckily you can happily install Proxmox into a VM that can’t properly run Proxmox, but it’ll give access to the utility to extract it.

It’s pretty self-explanatory other than the ‘tmp’ directory to extract to mustn’t exist. Weird.

vma extract vzdump-qemu-101-2024_10_07-12_26_33.vma tmp

In this case it extracted 2 raw files, and a config file.

disk-drive-sata0.raw
disk-drive-sata1.raw
qemu-server.conf

And looking at the config file we have:

boot: order=sata1;sata0;ide2;net0
cores: 4
cpu: x86-64-v2-AES
ide2: none,media=cdrom
memory: 8192
meta: creation-qemu=8.0.2,ctime=1691052188
name: KSA-ZABBIX-01
net0: virtio=C2:39:27:42:56:6B,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: l26
sata0: local-lvm:vm-101-disk-0,size=500G
sata1: local-lvm:vm-101-disk-1,size=10G
scsihw: virtio-scsi-single
smbios1: uuid=6e0757ff-565e-429d-8f47-3b425b89253e
sockets: 2
vmgenid: 70b4cbfe-de9f-4690-b7a1-64e68f4c5c30
#qmdump#map:sata0:drive-sata0:local-lvm:raw:
#qmdump#map:sata1:drive-sata1:local-lvm:raw:

Ok the first thing is those raw files are ENORMOUS. Convert them to a better container, I went with vmdk because … reasons.

qemu-img convert -f raw -O vmdk disk-drive-sata0.raw disk-drive-sata0.vmdk
qemu-img convert -f raw -O vmdk disk-drive-sata1.raw disk-drive-sata1.vmdk

I then could copy the VMDK’s to my machine and then destroy the Proxmox VM.

Since I’m weird I’m going to do this on Windows, using the Win64 port of Qemu. Because, why not? Also, I’m going to setup a different NAT network, and some port redirect:

"\Program Files\qemu\qemu-system-x86_64.exe" -net none -serial none ^
        -m 8192 ^
        -device virtio-net-pci,mac=C2:39:27:42:56:6B,netdev=net0 ^
        -netdev user,id=net0,net=192.168.1.0/24,dhcpstart=192.168.1.10,hostfwd=tcp::8080-:80,hostfwd=tcp::8022-:22 ^
        -device ahci,id=ahci ^
        -drive id=disk,file=disk-drive-sata0.vmdk,if=none ^
        -device ide-hd,drive=disk,bus=ahci.0,bootindex=2 ^
        -drive id=disk2,file=disk-drive-sata1.vmdk,if=none ^
        -device ide-hd,drive=disk2,bus=ahci.1,bootindex=1 ^
        -boot order=c,menu=on ^
        -smp 2 ^

So, I managed to keep the virtio network device, bind it to a DHCP network of 192.168.1.0/24 with the first address starting at 192.168.1.10. I also redirect port 8080 to port 80, along with 8022 to 22, allowing basic HTTP & SSH access into the VM.

The weird requirement is the 2 SATA disks, where the 2nd disk is the bootable one. I don’t know why it was configured this way, but I just preserved it.

I had to reset the root password, so this was a bit weird as I had to clear so much nonsense of the boot setup, basically pruning everything after ro, to add “rd.break enforcing=0”

With that, it was a matter of mounting the /sysroot as readwrite, chrooting into it, and then setting the password. yay.

Now I can reboot the VM on my desktop and have it running on Qemu, where I could bring up the WebUI for the mystery product and have it all running as a tame user mode application.

Nice!

The CLI syntax is always evolving and getting complex but don’t give up hope!

I often need to install a specific / older version of QEMU on a Mac using Homebrew. If you search for how to do it, typical answers are create a local tap, extract some files and other nonsense. Building from sources is equally retarded because configure can’t easily find includes and libraries installed by Homebrew.

This is how to do it in a simplest possible way. Find QEMU Homebrew Formula file on Github. Then click history on the top right corner. Browse for the desired version. Then on the right of the version, click a little icon saying “View code at this point”. It should show you an older version of the same formula. You can click download raw file or copy the URL and use curl to fetch it. Then simply run brew install ~/Downloads/qemu.rb or wherever you saved it. Magic! Hope it helps!

First off, I got a new VPS to house this on, size wise, I’d just plain outgrown the old one, even with SquashFS. Over on lowend box, I had spotted this one: LuxVPS

It’s not an AD, just thought the pricing seemed pretty good for 5€. One of the nice things about converting so much of my data to SquashFS is that moving single files is WAY easier to deal with!

Mice in my 1970’s teletype text editor?!

But editing text files had me facing off some feature of VIM I’d somehow not dealt with that Debian 11 set by default, and that is mouse integration!

CAN YOU BELIVE IT?

Somewhere out there, is people who use a mouse with a VI clone. 

It bares repeating

SOMEONE THINKS YOU NEED A MOUSE TO USE VI.

So much so, it’s the system default.

Good lord.

The fix is to edit /etc/vim/vimrc:

set mouse=
set ttymouse=

Problem solved. Obviously, I’m not going to remember this, but now I can right click/paste the way G’d intended it!

Stale encryption

The next source of annoyance is the ancient stunnel 4.17 that I use for altavista.superglobalmegacorp.com. I’m kind of trapped with this setup as it needs to be a 32bit ‘workstation’ OS, and I don’t want to run something as heavy as XP or Vista when NT 4.0 is more than enough. Anyways OpenSSL won’t talk to this ancient encryption, throwing this error trying to do a connection with “openssl s_client -connect 192.168.23.6:443”:

error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
Unable to establish SSL connection.

The fix, thanks to dave_thompson_085 is simple enough.

Basically, modify /etc/ssl/openssl.conf and place this at the top:

openssl_conf = default_conf
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#

then place this at the bottom:

[ default_conf ]

ssl_conf = ssl_sect

[ssl_sect]

system_default = ssl_default_sect

[ssl_default_sect]
MinProtocol = TLSv1
CipherString = DEFAULT:@SECLEVEL=1

Now when I connect to stunnel, I can verify that I am indeed using ancient crap level security:

New, SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 19D20D30E0026E8417E00402DE939E90770D4658C3A9CFE4DB4E5F2A5454DE9D
    Session-ID-ctx:
    Master-Key: 498C648E77E9B9C944A8B1D16242240A161A05A087881C6AD300718DD9B8C443EA12FB76440B666B7C6634A7E7DBE9D5
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1718352960
    Timeout   : 7200 (sec)
    Verify return code: 10 (certificate has expired)
    Extended master secret: no
---
DONE

I don’t care about the encryption, I could as a matter of fact just run without it, as I only need the reverse proxy aspect of it, to make the AltaVista web server accessible over the LAN/WAN/INTERNET. It’s all fronted with CloudFlare so from the end use POV it’s all encrypted anyways

A rainbow of happiness

Another nice side benefit of this SquashFS setup is that I can forever rebase the disks as the content never changes.

#!/bin/bash
# rebase the disk
rm /usr/local/vm/AltaVista/altavista-c.vmdk
rm /usr/local/vm/AltaVista/altavista-d.vmdk
rm /usr/local/vm/AltaVista/altavista-u.vmdk

qemu-img create -f vmdk -b /usr/local/vmdk/AltaVista_C/altavista-c.vmdk -F vmdk /usr/local/vm/AltaVista/altavista-c.vmdk
qemu-img create -f vmdk -b /usr/local/vmdk/AltaVista_D/altavista-d.vmdk -F vmdk /usr/local/vm/AltaVista/altavista-d.vmdk
qemu-img create -f vmdk -b /usr/local/vmdk/AltaVista_U/altavista-u.vmdk -F vmdk /usr/local/vm/AltaVista/altavista-u.vmdk

qemu-system-i386 -vga std -cpu pentium -m 64 \
        -vnc 192.168.23.1:6 \
        -net none  \
        -hda /usr/local/vm/AltaVista/altavista-c.vmdk \
        -hdb /usr/local/vm/AltaVista/altavista-d.vmdk \
        -hdd /usr/local/vm/AltaVista/altavista-u.vmdk \
        -device pcnet,netdev=alta,mac=5a:00:11:55:22:22  \
        -netdev tap,ifname=tap6,id=alta,script=/usr/local/vm/AltaVista/alta-up,downscript=/usr/local/vm/AltaVista/alta-down

One thing is for sure, it makes hosting AltaVista a bit easier to deal with. And for the sake of archiving, I uploaded a pre-loaded & indexed dataset Altavista Pre-Loaded (squashfs). I found that you can just copy the databases into a new VM, as long as you keep the drive letters the same as your source. So luckily, I had kept the OS on C:, installed AltaVista on D: with all the usenet posts on U:. Even better, for those strapped for space, you don’t technically need the U: drive, if you just want to search. Of course, you probably do want to look at them, but we’ve gone down this road before. And we know where it leads.

Enter the apt*

Of course we can’t just start building apt, rather we need to start at the 1990’s super star scripting language that revolutionized massive, shared code libraries, accelerating web development, and building the modern web, of course I’m talking about PERL.

Even back in the original effort building Perl was a slog. Even with temporary wins with miniperl it quickly fell apart from missing symbols. When it comes to the system libraries Darwin is not complete, rather it’s a lot of amputations from OPENSTEP. Which of course, itself was amputated from NeXTSTEP. I’m not sure what held back NeXTSTEP from being ‘open’ back when ‘open’ meant published specifications, not open source, or open in any other sense of the way, like The Open Group being a gatekeeping organization that is NOT open at all.

Anyways, Perl from the Darwin 0.1 downloads & the 0.3 CD-ROM don’t build. I gave up and moved to the OS X Server version and that one did build! As much as I could diff them out and find the breaking difference, honestly, it’s just easier to stick with what works.

I should point out that the source to Darwin was preserved on this now defunct site “next.68k.org”, which in turn was also preserved on the defunct site “nextftp.onionmixer.net“. Amazing how mirrors go. Other fun things on the ftp site include MacOSX-Server public sources, which did include the Perl that we built.

Darwin 0.3 however was pressed onto CD-ROM, and distributed out to the masses. It took me a short while to get a tip to a hidden server that had a copy, which really was a massive breakthrough as it had a far more complete set of files than the 0.1 ftp dump. However at the same time there are files in the 0.1 dump that are not in the 0.3. Was there ever a 0.2? I have no idea, the mailing lists don’t seem to have been preserved so I really don’t know. Does anyone have any other ftp site archives? Not to my knowledge but I’d be more than happy to be wrong.

With a working Perl the next thing to do is to patch the buildtools & dpkg to not be PowerPC centric. It’s no secret that all the official effort going on was to get OpenSTEP up and running on Apple PowerPC’s and to transition away from OPENSTEP to Rhapsody, the MacOS 8 Platinum feeling type OS, where everyone was going to love the ‘Coca’ API, and dump the old MacOS stuff or be forced to run it in the ‘BlueBox’ MacOS 8 emulator. Obviously this future didn’t happen as developers were not interested in rewriting for Steve’s decade+ fever dream of a Unix for the ‘rest of us’, instead they wanted their existing software to ‘just work’ and the Carbon API had to be created, along with a drastically different and modern looking OS X.

-    $flags->{'RC_CFLAGS'} = '-arch i386 -arch ppc ' . &liststring (@cflags);
-    $flags->{'RC_ARCHS'} = 'i386 ppc';
+    $flags->{'RC_CFLAGS'} = '-arch i386 ' . &liststring (@cflags);
+    $flags->{'RC_ARCHS'} = 'i386';

Frequently in the build tools it’s a matter of looking for ppc/powerpc and replacing them with i386. It’s really no surprise that Darwin always built on intel, and it had to, as it’s life depended on it. Back when NeXT hit their first real big stumbling blocks of being a vertical platform is that they just couldn’t compete in the hardware space. But dumping the 68k based black boxes, they could now take their software and port it to the much more coveted RISC platforms, and shipping with NeXTSTEP 3.3 they supported both SPARC & HPPA. There had always been talks of further platforms like MIPS or DEC Alpha, but these never materialized, much like the i860 which had been relegated to a simple Postscript co-processor.

Anyways.. Keeping with yesterday’s setup, and of course the .darwin-builder-04-23-2024.iso CD-ROM with all the stuff we need, let’s DOIT!

With phase 3 completed we are now ready to build the rest of the system. I hope you are excited! As I’m sure hoping you kept the original disk layout from the prior setup, or I’ve totally trashed your system by now.

I should say that deb files are just specially tagged ‘ar’ archives, that contain a data & control files telling apt how to process them. In this case I’ve taken the cc_783.1-1_i386-apple-darwin.deb file and modified it to contain the OS X 10.0 modified CC compiler. Apt had stumbled on building it, and I’m not interested into troubleshooting why or how. Basically, use ar to extract the contents of the deb, then tar to expand the data, replace the files, tar to put the files back into the data tar file, and ar to rebuild the archive.

ar r cc_783.1-1_i386-apple-darwin.deb debian-binary control.tar.gz data.tar.gz

In this case, debian-binary is a text file that simply contains ‘2.0’. Amazing!

The first thing to do is build a manifest of what needs to be built. I just simply extract all the ‘fixed’ source that I’d used last time to build Darwin, apply patches were needed, and then kick off the process with a darwin-buildall.

ls -l | awk '{print "dir /usr/src/"$9 " all"}' | tail -n +2 | grep -v gdb |grep -v cc- > /tmp/manifest.txt

In this case I skip building the C compiler, as it takes too long, and I’ve already done it. If you really want to do it, you can do so at your own leisure. GDB has issues building, and I haven’t even begun to tackle them. As you can guess the format of the manifest is pretty simple:

dir /usr/src/CoreOSMakefiles-1/ all
dir /usr/src/Csu-1/ all
dir /usr/src/Libc-1/ all
dir /usr/src/LibcAT-1/ all

Debian uses deb’s to populate a fake root directory in order to cross compile the packages. This is like installing multiple copies of the operating system, and that is why we use a separate scratch disk. This can consume several gigabytes when it’s done.

Also this presented the chicken/egg problem with how do you make debs from a system that needs debs? Thankfully NCommander had done extensive work with Debian / Canonical and was able to fake enough of a ‘build-base’ fakery that satisfied the build system just enough to start building stuff. In this weird way all roads lead back to the first build-base. Thankfully we live in the future where VMs are fast, and virtual disks are cheap.

I then create the /built directory, where the compiled deb’s will be populated, and copy in my modified compiler Debian into the built directory so that it’s used in all the compiling. On the CD-ROM I have 2 selections of deb files, the ‘deb’ directory from when I’d originally done this back in 2017, and the ‘fresh’ directory that I’ve just built. You can always manually source where the debs some come.

Kicking off the build is as simple as running:

darwin-buildall /tmp/manifest.txt /source/fresh /built

This will take.. a while. It’s a lot of files to copy & expand, and compiling takes a fair bit of a toll on the olde CPU.

By default, 118 of the 127 can be built.

• boot-2 the sarld won’t compile as.. there is nothing to compile. I’m lost. Also some driverkit headers didn’t make it into the packe!
• cvs-1 is upset about bison grammar not being in usr local lib?!
• flex is also upset about bison grammar locations.
• libgpp ppc/ppc-nextstep/_G_config.h missing?!
• perl.. should be patched __environ vs _environ
• bootstrap-cmds “multiple definitions of symbol _migcom_untypd_VERS_STRING”
• volfs seems plain broken but subdirecotories okay?
• netinfo missing netinfo.defs and headers?! arpa/nameser.h missing (can just touch)

That just leaves AppleTalk & HFS not building. Which I believe is period correct.

The good news is that the kernel that was built boots up seemingly fine.

The NeXTSTEP, of course is to now setup a new disk image, and see what is involved in booting up!

I’m going to assume if you want to follow along, that you’ve completed the first part of this exercise, and you have a Rhapsody DR 2 system up and running. Due to some issues I’ve had with creating a lot of files & filesystem corruption, we are going to create and add two more disks to the system. On Qemu we need to add them via the CLI:

qemu-img create -f vmdk source.vmdk 8G
qemu-img create -f vmdk scratch.vmdk 8G

Adding them to the command line gives us something like this:

qemu -L pc-bios -m 512 ^
-k en-us ^
-rhapsodymouse ^
-hda rhapsody.vmdk ^
-hdb source.vmdk ^
-hdd scratch.vmdk ^
-cdrom darwin-builder-04-23-2024.iso ^
-fda nic.flp ^
-net nic,model=ne2k_pci,vlan=1 ^
-net socket,udp=127.0.0.1:5001,remote=127.0.0.1:5000,vlan=1 ^
-boot c ^
%1 %2 %3 %4 %5 %6 %7

Additionally you’ll also need to download the current ‘darwin builder’ ISO that I’ve put up on sourceforge. As of today it is darwin-builder-04-23-2024.iso

Step one is to boot into single user mode. As we need to prep & format the disks under Darwin before the system starts up.

We need to check the hard disk, and then create the device names for the third hard disk.

fsck -y /dev/rhd0a
mount -w /
cd /dev
./MAKEDEV hd2

Now we need to run the ‘disk’ command which will abstract the whole volume creation. There are numerous flags, but we don’t need all that many.

disk -i -l 'src' /dev/rhd1a
disk -i -l 'scratch' /dev/rhd2a

The output scrolls off the screen, so I didn’t capture it, but you’ll see all the inodes being created, it’s a lot of output!

With the disks created, we can now shut down the VM

shutdown -h now

and then restart Qemu, and let it boot up normally. We’ll get to the login screen, login as the root user.

The first thing I’d recommend is to drag the Terminal.app from /System/Administration to the desktop to make it easier to get to. Rhapsody, unlike NeXTSTEP & OPENSTEP doesn’t have any dock, as the goal back then was to make Rhapsody look and feel more like Platinum MacOS.

The next thing to do is to make the system very insecure by allowing remote root logins. It’s just easier to deal with. You could use sed or just copy the one I provided from the CD-ROM.

cp /source/ttys /etc

And with that in place, its easy enough to telnet into the VM so you can copy/paste stuff in and out with ease!

You should now be able to verify that all 3 disks are mounted:

# mount | grep hd.a
/dev/hd0a on / (local)
/dev/hd1a on /src (local)
/dev/hd2a on /scratch (local)

From here it should be very simple to kick off the build process:

/source/phase1.sh

And this will kick off the build, recreating all the fun steps I’d gone through so many years ago. These projects now are building in the following order:

• kernel-1
• driverkit-139.1-1
• cc-798
• bootstrap_cmds-1
• objc-1

The first phase of the script will unpack both the kernel & driverkit and install their respective header files into the OS. NeXT a bunch of symlinks are created to link the system to the driverkit. Next I decided to build the ObjectiveC compiler from 10.0, hoping it’s more bugfixed and slightly more optimized than what was available back in 1999. Building the compiler is a little involved, as a good GCC tradition is to be cross compiled first, then re-compile itself with itself, then do that again and verify that the 3rd recompile outputs the same as the second one. Yes it’s a thing. Yes it’s slow. Yes you are lucky to live in the future, this was really painful back in the day.

With the kernel compiled, we can then compile the bootstrap commands, and the objectiveC runtime that is used by the kernel. Nothing too exciting here.

DriverKit however….

The PCMCIA code was not included in any of the 0.x Darwins, so for laptop enthusiasts you are basically SOL. As a matter of fact, a lot of weird stuff was pruned out, that either could be ‘touched’ or borrowed from the PowerPC port and massaged into place. Luckily I had at least figured out a simple fix for PCIKernBus.h so at least PCI works.

Likewise for the kernel, there was some guessing on the EISA config, which also overlaps ISA, along with having to remove the PCMCIA cardbus .. bus.

I had issues with the APM (Advanced Power Management), another laptopisim I suspect. I had to amputate that.

Naturally the cpuid code is broken much like early NT (I wonder if both were contributed by intel?), so it doesn’t detect any half way modern Pentium processors correctly which causes it to fall all the way back to the i386, which unfortunately, Rhapsody is compiled as 486 (remember NeXTSTEP had fat binaries allowing you to recompile for different processors and ship a single binary that can be ‘lipo’d into the appropriate one for the host). So being degraded to a 386 means nothing works.

yay.

Luckily patching the cpuid was pretty simple just force it always to be a Pentium. It is 1999 afterall.

I’ve done my best to make this a single script to run, and all being well you’ll get something that looks like errors, but it should be fine?!

System/Library/Frameworks/System.framework/Versions/B/Headers/bsd/i386/table.h
System/Library/Frameworks/System.framework/Versions/B/Headers/bsd/i386/types.h
System/Library/Frameworks/System.framework/Versions/B/Headers/bsd/i386/user.h
System/Library/Frameworks/System.framework/Versions/B/Headers/bsd/i386/vmparam.h
private/
private/dev/
private/dev/MAKEDEV
private/tftpboot/
private/tftpboot/mach_kernel
mach_kernel
tar: private/dev: Could not change access and modification times: Permission denied
tar: private/dev: Cannot change mode to 0755: Permission denied
tar: private/dev: Cannot chown to uid 0 gid 0: Permission denied
tar: Error exit delayed from previous errors

A quick look around shows that there is tgz files indicating that things have been compiled. I did backup the old original kernel as “rhapsody-gcc.tgz” in case you ever need it. Can’t imagine why but who knows?

qemu:13# ls -l /usr/src/*.tgz
-rw-r--r--  1 root  wheel   173706 Apr 23 15:25 /usr/src/bootstrap_cmds.bin.tgz
-rw-r--r--  1 root  wheel  2184460 Apr 23 15:33 /usr/src/cc-798-bin.tgz
-rw-r--r--  1 root  wheel  2747289 Apr 23 15:36 /usr/src/driverkit-kern-bin.tgz
-rw-r--r--  1 root  wheel  1264957 Apr 23 15:26 /usr/src/kernel-driverkit-hdrs.tgz
-rw-r--r--  1 root  wheel   116343 Apr 23 15:26 /usr/src/objc-bin.tgz
-rw-r--r--  1 root  wheel  2173005 Apr 23 15:26 /usr/src/rhapsody-gcc.tgz
qemu:14# ls -l /mach_kernel*
-r--r--r--  2 root  wheel  1459520 Apr 23 15:36 /mach_kernel
-r--r--r--  1 root  wheel  1404116 Apr 23 15:38 /mach_kernel-rhapsody

You should now be able to reboot into the kernel that you’d compiled!

Next up is Phase 2, where we compile the tools to enter the dark magic that is the Debian build system. Yes, you read that right, Apple/NeXT was all in on Debian.

It’s hard to believe it’s been 7 years ago since I reproduced Ncommander‘s adventure in building the Mach kernel from Darwin 0.1 sources that had been found years ago. At one point we’d managed to build enough of Darwin to do a dump/restore onto a new disk image, and have a mostly built Darwin system save for a hand full of files.

Time goes on by, and memories fade, and I thought it’d be worth going over the adventure, yet again. Just as it was true back then, I thought I’d reproduce the same setup that I’d been using back then. Qemu was a new and exciting thing back then, and

the Disk driver is VERY picky and honestly ancient Qemu is a pretty solid option to emulate NeXTSTEP/OPENSTEP/Rhapsody with some patches to both 0.8 & 0.9 by Michael Engel, which change a nested interrupt and add support for a busmouse, as the PS/2 mouse doesn’t work for some unknown reason. I know many are scared of old Qemu, but the disk support is pretty solid and the CPU recompilation is very fast, so having to rely on MinGW v3 isn’t so terrible.

While I had hid away a lot of these resources on archive.org, I thought it was best to just go back to the oldest post I had where I had painfully documented how to compile Qemu and get it working with NeXTSTEP, back on BSDnexus. I’m so glad I took the time so long ago to not only write it down, and add screenshots, but also tag the version numbers. Software drift, especially free software can be so difficult to pin down, and it’s nice to be able to return to a known good value. I went ahead and placed the recreated toolchain over on archive.org.

Rhapsody is a weird OS, in that NeXT had kind of given up on the OS market after their NeXT RISC Workstation had basically died with the 88k, and even their early abandoned PowerPC 601 aka MC98000/98601 port. Apple had left a few of the changelogs, in the source code. It’s very interesting stuff! I guess to go off on my own tangent NeXT was just too early, the cube with it’s Unix & magnetic optical media and great audio DSP capabilities was just too ahead of the curve. What the cube couldn’t pull off in 1988, the iMac and OS X sure did in 2001.

I also added UDP support to this Qemu so I could use the HecnetNT bridge trick giving me the ability to telnet/ftp into the VM greatly reducing my pain. Back in the day I had used NFS and the network slirp redirection. But I like having direct access so much more!

Rhapsody throws up yet another fun ‘road block’ in that the mouse buttons map backwards for some reason. It’s a trivial fix in the source code, but I made it a runtime option in case I needed or wanted to run NeXTSTEP. And it was a good thing, as I did need to find the NXLock.h file for building one part of Darwin.

When building Darwin, I started with the last x86 version of NeXTSTEP that was available, and that was Apple ”Rhapsody” / Titan1U x86 Developer Release 2. My thinking at the time and still is that the closer you can get your build to whatever they were using as ‘current’ the easier this will be.

Rhapsody can support an 8GB disk, so let’s go with that. This always has an issue with people that try much larger, and just fail, so for my sake and yours let’s just go with 8.

qemu-img.exe create -f vmdk rhapsody.vmdk 8G

And to simply start off the installer:

qemu -L pc-bios -m 128 ^
-k en-us ^
-rhapsodymouse ^
-hda rhapsody.vmdk ^
-cdrom rhapsody_dr2_x86.iso ^
-fda rhapsody_dr2_x86_InstallationFloppy.img ^
-boot a

You may be wondering, why only use 128MB of RAM? Well there is a bug in the shipping Rhapsody kernel that prevents booting on machines with more than 192? MB of RAM. Naturally, once we are to the point of building our own kernels this won’t be a problem but for now we are limited.

The bootloader will give us a few seconds to do anything fancy, I just hit -v so I always have the verbose boot.

From here it’s just a few options to go thru the installer

And a disk change is required

CONTROL+ALT+2 will bring up the monitor prompt, where we can change the disk

CONTROL+ALT+1 will return us to the console. Now we have to go through all the SCSI cards, and kind of compatible IDE cards

Further..

Further still…

And how select the Primary/Secondary(DUAL) EIDE/ATAPI Device Controller (v5.01)

We only need the one driver, so we’re good to go!

Continuing onwards will now start the kernel, along with a change to graphical mode. Just like a NeXT!

Now we can confirm again we want to install

As you can see there is our hard disk!

In the future we don’t need to dual boot so, just give it the entire disk.

A few more 1’s and we are finally installing!

Trust me it’s fast on Qemu!

And just like that, we’ve completed the first part of the install.

You can use CONTROL+ALT+2 to toggle back to the monitor and type in

eject fda

to eject the floppy, then it’s CONTROL+ALT+1 to return to the display and have it reboot. Qemu won’t try to boot to the hard disk, and with no disk in the drive, it’ll hang at the BIOS. Now is a good time to close Qemu and backup the hard disk. Mostly because I hate repeating this stuff.

To try to make this a bit easier, I’ve made a floppy disk with the NE2000 driver and updated kernel in one place where they can be injected via single user mode. A simple enough config file:

qemu -L pc-bios -m 128 ^
-k en-us ^
-rhapsodymouse ^
-hda rhapsody.vmdk ^
-cdrom rhapsody_dr2_x86.iso ^
-fda nic.flp ^
-boot c

Type in -s for SINGLE USER MODE. This is where a lot of Unix problems got solved in the old days

It’s a little tricky as this does involve typing. As instructed we need to check the hard disk prior to mounting it read/write

run the commands:

fsck -y /dev/rhd0a
mount -w /

Now we can mount the floppy disk

mkdir /mnt
mount /dev/fd0a /mnt
ls /mnt

I’ve included both the kernel & NE2000 driver in one file, and JUST the NE2000 driver in the other. For my sake I use the first one, update.tar.gz as I wanted to use the newer kernel ASAP. tar -zxvf didn’t want to run, so I did a rather awkward version to achieve the same thing.

cat /mnt/update.tar.gz | gzip -dc | tar -xvf -

With the files in place, you can now shut down the system with a simple

shutdown -h now

Once more again, I’d shut down the emulator, and backup the hard disk. If anything goes wrong you can restore your backups at any phase, at least saving some time!

Next is the graphical install. In this case I use the hecnet bridge to give full access, you can setup with the slirp driver with a simple “-net user” but it doesn’t matter at the moment Since I opted for the newer kernel, I can take advantage of the 512MB RAM.

qemu -L pc-bios -m 512 ^
-k en-us ^
-rhapsodymouse ^
-hda rhapsody.vmdk ^
-cdrom rhapsody_dr2_x86.iso ^
-fda rhapsody_dr2_x86_InstallationFloppy.img ^
-net nic,model=ne2k_pci,vlan=5 ^
-net socket,udp=0.0.0.0:5001,remote=127.0.0.1:5000 ^
-boot c ^

Booting Rhapsody

Now we have to setup the hardware. It should be somewhat straight forward, first we start with the monitor. The mouse should be working although I find that I have to move slowly. Sorry it tracks weird on real hardware too.

The Cirrus Logic GD5446 should be detected automatically, I just go with the default 1MB

Next under the mice, select the PS/2 mouse and remove it

This leaves us with the Bus Mouse driver.

Under the network tab, the NE2000 should be automatically detected.

On the last tab, I make a habit of removing the Parallel port freeing IRQ 7, in case I wanted it for something else.

Back to the summary, we now have Cirrus Logic video, NE2k networking, with no SCSI, no Audio.

With the config saved, now we can just install as is. I un-installed Japanese, but it doesn’t matter. You absolutely need the Development Tools, so may as well go with eveything.

The installation only takes a few minutes and we are ready to reboot

The kernel will now shut down.

Once more again this is a great time to make another backup of the hard disk. At this point this is a great backup to save, as we’ve installed the OS, and selected drivers, in the next reboot we’ll be personalizing the operating system.

We can re-run the last config once the disk has been saved. We’ll be greeted with a message that the Server isn’t responding. Answer YES to continue without networking.

From here we are in the Setup Assistant, taking a nod from MacOS 8

I use USA keyboards. The best keyboards! I touch type so I don’t have to deal with weird layouts.

Specify for a LAN connection

There is no DHCP support so specify a manual IP address.

The default stuff is just wrong.

On my LAN this is good enough. DONT add a router. It’ll just confuse it.

We don’t have or want NetInfo. This would be the server to give out IP addresses, and authentication. We don’t need it!

Leave the DNS servers blank

You can setup any location, it doesn’t matter.

Likewise, with NTP, turn it off.

We will then get the option to set the date/time manually. The default time is far too old and it’ll break stuff.

Next up is user accounts.

I always make local accounts.

Come up with some creative name

and a password

I don’t have it doing any automatic login. You can if you want, it’s all up to you, this one doesn’t matter.

Next is an Administrator password

And now we can apply our changes.

It takes seconds!

And now we’ere done. You may want yet another backup as this is tedious!

With the final configured backup in hand, now we can boot back one more time, and now we’re in SVGA mode!

Logging in as root will give me the desktop

And there we are, all installed.

For anyone brave enough to have read all of this, but wants the quick and easy version, it’s up on archive.org!

In part two I’ll pick up with the source CD-ROM I’ve prepared, so we can start compiling Darwin!

The UnixWare 7.1.1 install program has a date & time Y2k problem. And this always ends in whatever licensing you give it to install will expire and be nullified. Luckily this time while re-installing on VMware I saw if you defer the license on install, It’ll grant you a temporary eval license. It’s not going to matter as it’ll immediately expire, but it get’s us past the install.

Qemu however let’s you rev up the time machine and specify a starting time

-rtc base=1999-09-29T15:00:00

As simple as that. I found for installing with Qemu 8.0 (Latest win32) binary it worked well enough like this:

"c:\Program Files\qemu\qemu-system-x86_64.exe" ^
-m 1024 ^
-hda UnixWare711.vmdk ^
-cdrom SCO_UnixWare711.iso ^
-net nic,model=pcnet ^
-rtc base=2010-09-29T15:00:00

Installation in a stock boring VM goes fine, there is built in support for the AMD PCnet driver, so things ‘just work’. And then on the VMware reboot it never launches X11.

Under Qemu, I’m greeted by CDE and the login page. On VMware however…

I know t his used to work on VMware, but there is some regression in the VESA video driver. The fix was to use scoadmin and knock the video settings down to stock VGA. Luckily I have an X server running on Windows, so I could just export the display and set it up.

Whereas I had to set VMware to VGA:

And one more reboot, and I was at least given a graphical console:

Inputting the licenses

Being a commercial Unix from back in the day, it relies on License Numbers, and activation codes to actually use the software. I have the box, so I have codes so yay me. Post install, I could remove the expired licenses, and then input the ones that were in the box.

These are 5 user licenses, just enough to show off the system, I suppose: The advanced features of the day are nothing special these days, but it’s nice to have the PCC derived compiler, if not to compile GCC but more so for SYSV code from back in the day.

Networking

Networking for VMware is straightforward, I use the NAT interface VMnet8 that is installed by default, selecting a valid Tcp/IP address on the interface range gives me not only full internet access, but also allows me to easily telnet into the VM.

Qemu however…

"c:\Program Files\qemu\qemu-system-x86_64.exe" ^
-m 1024 ^
-hda UnixWare711.vmdk ^
-net nic,model=pcnet ^
-net user,hostfwd=tcp::42323-:23

I had been using the user mode SLiRP code for ages, but after all the MIT PC/IP fun, I was thinking I bet modern Qemu supports UDP transport for network traffic, and that it’d just integrate with HecnetNT just fine. And it does!

"c:\Program Files\qemu\qemu-system-x86_64.exe" ^
-m 1024 ^
-hda UnixWare711.vmdk ^
-net nic,model=pcnet,netdev=hecnet ^
-netdev socket,id=hecnet,udp=127.0.0.1:5001,localaddr=127.0.0.1:5000

Configuring the HetnetNT bridge was simple, as always make sure you have Wireshark/pcapng installed and simply run ethlist to get the list of interfaces:

D:\qemu>ethlist.exe
Network devices:
  Number       NAME                                     (Description)
  0  \Device\NPF_{E79F6278-3E7E-4547-955A-2080A0473AD6} (Local Area Connection* 8)
  1  \Device\NPF_{1D960E08-2A3A-43F7-BAD6-21FCB466717B} (Local Area Connection* 7)
  2  \Device\NPF_{98053A85-B049-45A0-AC33-961E2C136FCA} (Local Area Connection* 6)
  3  \Device\NPF_{BFA868ED-E508-4436-B085-EC815C4C544C} (LoopBack)
  4  \Device\NPF_{C75EAF23-0FA3-433B-B271-9CB0F5EB92D0} (VMware Network Adapter VMnet8)
  5  \Device\NPF_{B615DE21-AEC3-4347-916C-332AC4A4DA70} (VMware Network Adapter VMnet1)
  6  \Device\NPF_{82E5A370-6D3D-40AD-A9D5-C4E0E0C50F0D} (Ethernet)

And then create a simple bridge.conf file with the VMnet8 adapter and the UDP pariing to talk to Qemu:

[bridge]
update 127.0.0.1:5000
vmnet8 \Device\NPF_{C75EAF23-0FA3-433B-B271-9CB0F5EB92D0}


[tcpip]
update
vmnet8

Then launch the bridge program listening on port 5001:

D:\qemu>hecnet.exe 5001
Config filename: bridge.conf
Adding router ''update''. 0100007f:5000
Opening pcap \Device\NPF_{C75EAF23-0FA3-433B-B271-9CB0F5EB92D0}
Adding router ''vmnet8''. 00000000:0
Host table:
0: update 127.0.0.1:5000 (Rx: 0 Tx: 0 (Drop rx: 0)) Active: 1 Throttle: 0(000)
1: vmnet8 0.0.0.0:0 (Rx: 0 Tx: 0 (Drop rx: 0)) Active: 1 Throttle: 0(000)
Hash of known destinations:
Adding new hash entry [52:54:00:12:34:56]. Port is 0
Adding new hash entry [00:50:56:c0:00:08]. Port is 1
Adding new hash entry [00:50:56:f1:dd:d0]. Port is 1
Adding new hash entry [00:0c:29:9a:2b:fb]. Port is 1

It’s a little bit more involved to setup as we have to link the 2 programs via UDP, but I can say it’s totally worth it.

I can now easily FTP files into Qemu, and of course telnet as much as I want to. I don’t see why NFS wouldn’t work either.

Which brings us to the bigger elephant in the room, which one is ‘worth the squeeze’?!

I thought it’d be fun to do a totally unfair CPU intensive thing like building GCC. I would do a quick stage 3 compile blindly running this:

./configure --host=i386-sysv4 --target=i386-sysv4 --prefix=/usr/local/gcc-2.5.8
make
make stage1
make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O"
make stage2
make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O"
make stage3
make CC="stage3/xgcc -Bstage3/" CFLAGS="-g -O"

This way we can just look at the timestamps between completed releases. It does build C++ & ObjectiveC as well, and compared to machines from 1999 this is amazing!

-rwxr-xr-x 1 neozeed other 3495688 Mar 29 12:42 ./cc1
-rwxr-xr-x 1 neozeed other 2646888 Mar 29 12:37 ./stage1/cc1
-rwxr-xr-x 1 neozeed other 3495720 Mar 29 12:39 ./stage2/cc1
-rwxr-xr-x 1 neozeed other 3495688 Mar 29 12:40 ./stage3/cc1

Qemu timing

-rwxr-xr-x 1 neozeed other 3884076 Mar 28 20:12 ./cc1
-rwxr-xr-x 1 neozeed other 2647116 Mar 28 20:11 ./stage1/cc1
-rwxr-xr-x 1 neozeed other 3884124 Mar 28 20:11 ./stage2/cc1
-rwxr-xr-x 1 neozeed other 3884076 Mar 28 20:12 ./stage3/cc1

VMware timing

As you can see VMware is substantially faster when it comes to computation. This shouldn’t come to anyone as any surprise. And this isn’t a fair competition, but it does show that you can stage GCC on Qemu just fine, so that’s actually great!

Now let’s mix in some more nonsense, I have a Merge license so let’s try it! First off it really wants Windows 95 from CD-ROM. It will not accept anything else. I have a hacked-up copy of the floppy version of Windows 95 on CD-ROM, and it accepted that just fine, it appears to search through.CAB files looking for files to setup it’s preferred environment. I’m not all that familiar with the whole thing as PC’s are cheap, and virtual machines are even cheaper!

After the setup completed, I thought I’d try my Sarien 286/386 ports.

Sadly, neither worked. Maybe it’d have better luck with Windows 95 actually installed. I wanted some high colours so I went over to Qemu and found out that it cannot run Merge.

The error lies in a missing opcode 000000FF. Maybe it’s invalid to trigger an exception to call between DOS and the supervisor?

Either way it doesn’t matter, it doesn’t work. I did get feedback that it does run under KVM.

I don’t know why I didn’t think about doing the HecnetNT bridge earlier as it gives things far more flexibility for tapping into networks, or even being transported. I guess I should look at other transport mechanisms besides UDP since it’s 1:1. Also, it might be worth dropping the protocol restrictive filters to allow everything on the wire to flow.

I did go a bit overboard showing how to install MS-DOS & Windows 3.0 on Qemu. Maybe it’ll help someone who wants to try to use Qemu, but is too scared? Maybe I moved too quickly.

One thing I did do differently in this run, is launching the monitor and a serial port as tcp servers so I could telnet into the VM, effectively having a way to share text like a clipboard back and forth. I’m kind of surprised I hadn’t really started using Qemu in this manner much earlier.

qemu.exe -L pc-bios ^
-m 16 ^
-hda apricot.vmdk ^
-net nic,model=pcnet -net user ^
-monitor telnet:127.0.0.1:4000,server,nowait ^
-serial telnet:127.0.0.1:4001,server,nowait ^
-fda yourdisk_here.vfd

Surprisingly it went surprisingly well, other than my goof of having the OS/2 driver instead of the MS-DOS driver for the nic.

Sadly, the tn3270 program bundled with Chameleon doesn’t work properly with Hercules.

As always I’ve uploaded it to archive.org: apricot-dos4-win3-chameleon3.7z