(This is a guest post by Antoni Sawicki aka Tenox)
Previously I managed to crack and unlock the demo version of DUX SimCity for UNIX. It worked just fine on the original pre-built platforms, DEC Unix, HPUX, SunOS and IRIX. Unfortunately the IRIX binary is for 5.3 in COFF format and doesn’t work on more modern ELF based IRIX like 6.2 and above. More importantly however, there never has been a release for IBM AIX! Inability to play SimCity on RS/6000 is excruciating. Not to mention several other Unix systems of that time.
A few days ago I ran a VCF West 2024 exhibit showcasing this important piece of software history. I got to chat with many people about these shortcomings and decided to see if something can be done about it.
On the right of the picture above, you can see a OLPC XO. This laptop plays an important role of SimCity history. During conception of OLPC, the game has been open sourced under a new name “Micropolis”. This was insanely fantastic endeavor, kudos for everyone involved. Unfortunately the software has been “enhanced” to run on XO Sugar GUI thing, ported to C++ Python and otherwise defaced in several different ways.
Fortunately there survives a very early source code of Micropolis, aka old gen. While GPL and under a new name, has only minor, cosmetic changes compared to the original source code. With some minor tweaking and working around funnies with xlC and MIPSpro compilers, I was able to build old-gen Micropolis for AIX 4.3, 5.1, IRIX 6.5 and HP-UX 11.31 on IA64.
Most importantly however, in the process, I discovered that the original DUX SimCity assets, including TCL/TK GUI cruft was directly usable with just a few small changes in sim.c. Effectively undoing all the changes mentioned in DONE and making it almost the original, except for name. A hybrid GPL Micropolis – DUX SimCity Demo Asset build has been born!
The first thing I wanted was to install the Pre-Release onto a HPFS disk. I’ve uploaded this over on archive.org (Windows NT December 1991 prepped for Qemu). I took the CD-ROM image, removed all the MIPS stuff, built a boot floppy, and setup the paths so that the floppy can boot onto the secondary hard disk to a ‘full’ version of NT. This lets me format the C: drive as HPFS, and then do a selective install of Windows NT to ensure that that the software tools (compiler) are installed.
I use a specially patched vintage QEMU build, qemu-0.14.0.7z which kind of makes it ‘easier’, along with the needed disk images in dec-1991-prepped.7z
This will bring up the boot selection menu. The default option is fine, you can just hit enter.
NT will load up and you now have to login as the SYSTEM user. We need the advanced permissions to format the hard disk.
From the desktop we first format the C: drive as HPFS. I made icons for all this stuff to try to make it as easy as possible.
You’ll get asked to confirm you want to do this, and give the disk a creative name.
And with the disk formatted it’s time to start the setup process.
Who are you?
And what slick account do you want? It doesn’t matter tbh.
I’m going to do a custom install as the NIC’s aren’t supported, and even if they were it’s just NetBEUI anyways.
And select your hardware platform. NT basically only supports this config, so it doesn’t matter.
The default target drive is our C drive, which we had just formatted to HPFS.
Next, I unchecked everything only leaving the MS Tools
It’ll offer the samples & help files. I always install them as I eventually need examples of stuff to steal, and to learn that including <windows.h> won’t work right unless you manually define a -Di386 on the command line. I’m saving you this pain right now up front.
Files will copy, and on a modern machine this takes seconds.
And there we go!
And Windows NT is installed.
Yay.
I put in a ‘CAD’ feature in this Qemu hitting control+alt+d will send the familiar pattern, and after a few times NT will reboot. We are pretty much done with NT for the moment, but congrats you’ve installed the December 1991 Pre-release onto a HPFS disk for those sweet long long file names!
Going over the strategy:
I’ve already built GCC 1.40 for NT, so what is the rest of the stuff needed to build Linux? It’s a quick checklist but here goes, in no specific order:
GCC 1.40
bin86
binutils
gas 1.38
bison
unzip
zip
Luckily as part of building on Windows 10 using MinGW, I had fixed the weird file issues as MS-DOS/Windows NT/OS2 handle text/binary files, as we went through with how Github mangled MS-DOS 4.00.
The primary reason I wanted a working zip/unzip was to deal with long file names, and to auto convert text files. And this ended up being an incredible waste of time trying to get the ‘old’s code on the Info-Zip page.
I’m sure like everything else, the old versions are removed as they probably suffer from some catastrophic security issue with overflows. The issue I ran into is that the version 5 stuff uses so many features of shipping NT, to even 2000 that it was going to be a LOT of work to get this far. The quicker & easier path as always turned out to be a time machine.
Thankfully, since I had made a copy of the UTZOO archives, I was able to fish out, both version 3.1 from the archives. Also known as “Portable UnZIP 3.1”, parts 1/2/3. I also found version 4.1 as well. And people wonder why you want to save these ‘huge’ data sets. If the lawyers could have their way, they would obliterate all history.
I spent a lot of time messing with Makefiles, as linking & object conversion on old NT is a big deal, and not the kind of thing you want to do more than once. Another big pain is that large files become delete only. I don’t know what the deal with notepad is, but I could remove text, but not change or add. I solved that by wrapping a number of things by including it in another file with some #define work to go around it. Needless to say, that sucked.
One thing that constantly threw issues is that this version of Windows doesn’t handle Unix style signals. I removed all the signal catch/throw stuff, and the binaries ran fine. Why on earth does ‘strip’ need signals is beyond me, but it runs fine without them!
On Windows I just unzip the bin.zip file and leave source.0.zip intact into a directly say something like temp. Then I can use a cool feature of Qemu where it can mount a directory as a read-only FAT disk. This saves a lot of time!
Will drop to the bootloader. Hit enter to login, and you’ll be at the desktop. Hit enter again, and open a command prompt.
By default, the Numlock is messing with the arrow keys (I think it’s mapping to the old 83 key keyboard no matter what?) Hit num-lock and your arrow keys should kind of work. It’s a great time saver.
I copied the binaries & the ygcc.cmd file into the \bin directory, created a \proj directory and get ready to unzip all the source code. For some reason this version of unzip doesn’t understand the zip compression, so it’s just storing instead, much like TAR. It’s not that involved but unzip with the -d flag so it creates directories as needed.
This will let us keep long file names. HPFS is case insensitive, but it also preserves the case, so don’t worry about the names being all weird. It doesn’t matter.
One thing worth mentioning is that even though the C pre-processor does compile it just hangs when trying to run it. I’m not sure what is wrong exactly, but it’s just not worth fighting. Instead, I had the better idea, of using the Microsoft C compiler to pre-process the source. Apparently, this is how they originally built Windows NT, pre-processing on OS/2, then uploading the pre-processed files to a SUN workstation with the i860 compiler and downloading the objects to be converted & linked. Wow that must have been tedious!
I created a CMD file ‘ygcc.cmd’ to run the cl386 pre-processor, call CC1 & GAS and clean up afterwards.
Before you can build Linux, you need to create both a \tmp & \temp directory. Also the include files need to be copied to the \include directory to make the pre-processor happier.
I’ve tried to make this as simple as possible there is a ‘blind.cmd’ file which I built that’ll manually compile Linux. There is no error checking.
And saving everyone the excitement here is an animation of the build process
And there we go! All compiled!
From there it’s a matter of copying the Image file out of the VM, I used the boot floppy and 7zip’s ability to extract FAT images, and then boot up Qemu using the Image file as a ‘floppy’ as back in the day we used to rawrite these to floppy disks.
And of course you’ll need your Broadcom ID. I did convert mine over in the migration as I had been buying Fusion for MacOS, well until they stopped supporting the 2013 Mac Pro.
And, as to be expected everything is gone. I am pretty sure I’d also registered all the freebie ESXi in there as well. So yeah, all gone.
Well not to fear, as when they had announced that they were going to give Pro away, I downloaded a copy to save the name, VMware-workstation-17.5.2-23775571.exe, and a quick search on that gave me this fun tree:
The biggest gotcha seems to be that the MSDE/Visual C++ 4.0 studio crashes. And pinball doesn’t work. Very possible some issue with the dingus PowerMac emulator.
I’ve tried to port MAME 0.36 & Fallout1-RE, but both I’m having some DirectX issues. I’m honestly surprised MAME links. It’s getting harder and harder to find those old win32 update packages for MAME. Not sure anyone saved them?
Windows NT 3.51
And as a bonus, for those wanting 3.51, I’ve also setup a CD-ROM with SP5:
first off I was surprised when I got up about the reach of this through South Africa, Australia and New Zealand.
its shocking how nobody stages anything just roll directly to production. I know this is CI/Agile so expect more of this, not less.
next is the file everyone is crying to reboot into safe mode to delete. It’s all zeros. Not a valid device driver. Not a valid anything.
how is it getting loaded??
looking at the stack trace I found on twitter the driver csagent is faulting. Is it actually binary loading a blob into kernel space and executing it, bypassing all checks for valid/signed code by the kernel?
With all the excitement of PowerPC NT being runnable under emulation, I thought I’d try to do something fun, and port Alexander Batalov‘s fallout1-re, to Visual C++ 4.0.
The ‘problem’ is that it’s written using a more modern C that allows C++ style variables in the code. In traditional C, the declaration of variables has to be at the start of each function, however C++ allows you to place them wherever you want in the code.
The ‘fix’ is quite simple, you just have to separate the creation of variables in the code, and place them on top, as simple as!
You can see in this case the deletions in red, and the additions in green.
115 changed files with 21,455 additions and 4,437 deletions.
It was a LOT of changes. It took me 3 days to go through the code. But with a lot of work I was able to get it to compile first with Visual C++ 2003. I then created a Makefile allowing me to compile with Visual C++ 4.0
I have to admit, I was kind of surprised that it actually compiled for the PowerPC. And instantly saddened that it doesn’t actually work. Maybe some code amputations may get around the running part, but that’s just speculation right now.
Shockingly the opening animations play fine, the menus load, however you get about one frame in the game, and it goes unresponsive.
I don’t know why but Visual C++ 2003 won’t debug it correctly. I’m not sure why it won’t set the working directory correctly. Attaching to the process seems to produce different results, where it’s stuck in some loop that I can’t peg down.
Obviously, I did screw something up, the ‘solution’ is to install a newer version of Visual Studio and ‘blend’ the files, to try to rule out where or what went wrong.
The annoying thing is that even if I go through the required steps to get the VC4 version working, it won’t matter as at best this would only be relevant for the currently unemulated Dec Alpha.
This has been a rush of excitement! Rairii published their port of the ARC & Drivers needed to get NT 4.0 working on commodity PowerMac hardware over on github. And what about running it under emulation? Once more again Rairii provided a custom fork of dingusppc, again over on github!
A custom CD-ROM worked best (for me?!) for installation, combining the ARC & Drivers, along with a copy of Windows NT Workstation onto a single disc. Rairii provided the magical recipie for creating the ISO:
# ext. xlate creator type comment
.hqx Ascii 'BnHx' 'TEXT' "BinHex file"
.sit Raw 'SIT!' 'SITD' "StuffIT Expander"
.mov Raw 'TVOD' 'MooV' "QuickTime Movie"
.deb Raw 'Debn' 'bina' "Debian package"
.bin Raw 'ddsk' 'DDim' "Floppy or ramdisk image"
.img Raw 'ddsk' 'DDim' "Floppy or ramdisk image"
.b Raw 'UNIX' 'tbxi' "bootstrap"
BootX Raw 'UNIX' 'tbxi' "bootstrap"
yaboot Raw 'UNIX' 'boot' "bootstrap"
vmlinux Raw 'UNIX' 'boot' "bootstrap"
.conf Raw 'UNIX' 'conf' "bootstrap"
* Ascii '????' '????' "Text file"
I went ahead and made the image, and added in Service Pack 2, Internet Explorer 3 and IIS3 onto the same CD-ROM to make things easier for me to deal with. It’s on archive.org.
On Discord and impromptu porting session broke, out and we got NP21 up and running!
Unfortunately, it is very slow. I have no idea how it performs on real hardware, it’s entirely possible that it really is unplayable. It’s still pretty amazing that the OS booted up and I could actually compile something!
Even the usual fun text mode stuff from Phoon, Infocom’87, F2C, compiled!
But will it run DooM?
Of course, it runs! I’m using the 32bit C code from Sydney (ChatGPT), which runs just great.
Into 3D space
I was able to compile GLuT on the way to try to build ssystem but there is two textured OpenGL calls missing, meaning that the more fun OpenGL stuff simply will not work.
Setting expectations
As a matter of fact, lots of weird stuff doesn’t work, the install is very touchy so don’t expect a rock-solid experience, but instead it was incredibly fun to try to get a bunch of stuff up and running.
Thanks again to @Rairii for all their hard work! This is beyond amazing!
— it’s 3am and I’m exhausted, but I had to share this out some how some way!
(this is a guest post by Antoni Sawicki aka Tenox)
Previously I wrote a boring lengthy article about need for “simple html mode” in WRP. Today I want to introduce addition of images to this contraption! You can now browse modern web like it was in 1994!
The say that image is better than 1000 words, so here we go:
You can regulate the image size and make them however big you want, also PNG, GIF and JPEG of course:
The simple html mode is still quite buggy and needs a lot of fixes. I see some 400 errors here and there, Captha problems, etc. I think these can be all fixed in time.
I had originally planned on doing this for the 4th of July, but something happened along the way. I had forgotten that this is 1995, not 2024, and things were a little bit different back then.
Back in the early days of the internet, when Al Gore himself had single handedly created it out of the dirt, The idea of address space exhaustion didn’t loom overhead as it did in the late 00s. And in those days getting public addresses was a formality. It was a given that not only would the servers all have public TCP/IP addresses, but so would the clients. Protocols like FTP would open ports not only from client to server, but also server to client. This was also the case for RealAudio. Life was good.
The problem with trying to build anything with this amazing technology is that while I do have a public address for the server, it’s almost a given that YOU are not directly connected to the internet. Almost everyone these days uses some kind of router that’ll implement Network Address Translation (NAT), allowing for countless machines to sit behind a single registered address, and map their connections in and out behind one address. For protocols like FTP, they have to be built to watch and dynamically add these ports. FTP is popular, RealAudio is not. So, the likelihood of anyone actually being able to connect to a RealAudio 1.0 server is pretty much nil.
The software is pretty easy to find on archive.org, (mirrored). Since it’s very audio centric, I decided to install the server onto a Citrix 1.8 server using Qemu 0.9. I had gone with this, as the software is hybrid 16bit/32bit and I need a working sound card, and I figured the Citrix virtual stuff is good enough.
First thing first, you need some audio to convert. Thankfully in modern terms ripping or converting is trivial unlike the bad old days. First off, I needed a copy of the Enclave radio, and I found that too on archive.org. The files are all in mp3 format, but the RealAudio encoder wants to work with wav files. The quickest way I could think of was to use ffmpeg.
ffmpeg -i Enclave Radio - Battle Hymn of the Republic.mp3 -ar 11025 -ab 8k -ac 1 enc01.wav
This converts the mp3 into an 11Khz mono wav file. It’s something the encoder can work with. Another nice thing about Citrix is how robust it can use your local drives, cutting out the whole part of moving data in & out of the VM.
One thing about how RealAudio works is that first there is the ability to load up a .ram or playlist file. In this case, I took the ‘enclave playlist’ from Fallout 3, and made a simple playlist as enclave.ram:
The encoder allows for some metadata to be set. Nothing too big.
And then it thankfully takes my i7 seconds to convert this, even under emulation, using a shared drive. And import option to deselect is to enable playback in real-time, as it’ll never work as it cannot imagine a world in which the processor is substantially faster than the encoder.
Converting the 8 files took a few minutes, and then I had my RealAudio 1.0 data.
The playlist should be served via HTTP, and I had just elected to use an old hacked up Apache to run on NT 3.1. As it only has to serve some simple files.
The scene is all set, the RealAudio player pulls the playlist from Apache, then it connects on TCP port 7070 of the RealAudio server to identify itself and get the file metadata. Then the RealAudio server then opens a random UDP port to the client and sends the stream, as the client updates the server via UDP of how the stream is working. And this is where it all breaks down, as there is not going to be any nice way to handle this UDP connection from the server to the client.
Well, this was disappointing.
In a fit of rage, I then tried to see if ffmpeg could convert the real audio into FLAC so you could hear the incredible drop in quality, and as luck would have it, YES it can! To concatenate them, I used a simple list file:
And thanks to ‘modern’ web standards, you can now listen to this monstrosity!
This takes about 10MB of WAV audio derived from 8MB of MP3’s, and converted down to 472kb worth of RealAudio. Converting that back to a 4.4MB FLAC file.
To keep in mind what network ports are needed at a minimum it’s the following:
TCP 1494 * Citrix
TCP 7070 * RealAudio
UDP 7070 * RealAudio (statistics?)
TCP 80 * Apache
And of course, it seems to limit the RealAudio server to the client in the 7000-7999 range but that is just my limited observation. This works find at home on a LAN where the server is using SLiRP as the host TCP/UDP ports appear accessible from 10.0.2.2, while giving the server a free-standing IP also works better, but again it needs that 1:1 conversation greatly limiting it in today’s world.
Also, as pointless as it sounds, you can play the real audio files from the Citrix server for extra audio loss.
Personally, things could have gone a lot better on the 3rd of July, I thought I’d escaped but got notified on the 5th they forgot about me. Oh well Happy 4th for everyone else.
(this is a guest post by Antoni Sawicki aka Tenox)
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!