While on discord the topic came up of why there is no good/free C compiler for MS-DOS. Oh sure there is OpenWatcom but the 2 heavy hitters of the era, Microsoft C & Borland C are not open in the slightest.
There is DeSmet C, although it’s source is full of unnamed structs meaning that building it with anything sane would require a ‘lot of work ™’ which of course is not what I’m all that about. Instead, I remembered a directory up on TUHS /Applications/Portable_CC with a zip file 8086.zip Although this is a zip file, you’ll want to unzip on something Unix-y as there is a lot of case duplicate files. That said this is a PCC port to the 8086, which includes a libc, 8087 support, and is all expected to be built on a VAX-11/780 running 4.1BSD. Now this ended up being a stumbling block because I tried a *LOT* of things thinking that they were upwards compatible with 4.1, and the answer is USE 4.1!
So to effectively get going you’ll need a SIMH VAX780 and just follow my old steps on Installing 4.1BSD. As far as the zip file, I used Linux but had to create a tar file specifying the Unix v7 format with:
With that said it’s a very strange setup as it relies on the 4.1BSD Vax environment so much that there is assembly injected into the linker.
asm("movc3 r8,(r11),(r7)");
So this will not cleanly run. Just as it depends on many system a.out specifics on building for MS-DOS. It’s not so much a MS-DOS tool chain, rather it outputs to vax a.out and uses a slightly modified vax linker. The MS-DOS magic happens in the conversion of the final a.out into a com file.
That is right it’s a VAX specific cross compiler that only build’s COM files.
I’ve managed to build some trivial stuff, and they work. Sadly my attempt at building that InfoTaskforce of ’87 failed.
I haven’t dug that much further into the linker although I have to wonder if a GNU cross linker to make a.out could make something that the conversion program would be happy with. The assembler of course doesn’t work, perhaps it’s something with packing structs?
As always, the simple stuff looks trivial but it was a fair bit involved.
Since there is no real ‘cc’ it’s a script but the vauge steps are:
This is a bit cheating, but I broke down and did some dump/exports of a building system to get the file layout. Since the MiG phase was totally done native, I didn’t bother with that, or trying to ‘fix’ the nested Makefiles, rather I just dumped the output and worked with that. I guess I could make my own Makefile but for now it’s a stupid script. I used the a.out build tools for Linux as the objects are all the same anyways.
cd mach25-X113\obj\STD+WS-afs-nfs
build-gcc258.cmd
Since there is no Makefile it won’t run in parallel. About 20 seconds or so later you’ll get a linked ‘a.out’ but it won’t run. The script xport.cmd is rigged for me and Qemu 0.10.5 to create a tar file to extract inside of mach and perform the native link.
Obviously this means you can us modern UI’s tools and everything else as you are now on the outside! If you can force your build to use my ancient tools you can even do the build. Nice!
Doing a rebuild of the kernel in Qemu the 2.5.8 -O2 build shaved a whole second off the build, so yes it actually did something.
Things to do would be cross linking, fixing the drivers that don’t build, and probably improving stuff like bigger disks, filesystems and memory… or networking!.. .but that’s all too complicated for me!
InfoTaskForce’87 running on a simple NS32016 emulator
What is it?
It sure may not look like much but it was an adventure getting here.
First, what is it? Well it’s the very simple NS32016 from here, with a few minor changes. I expanded the RAM from 256kb to a whopping 8MB. Then I added simple character I/O allowing me to print messages to the screen. Next looking at the toolchain page, I used my old Linux to Windows GCC 4 cross compiler to build the appropriate Canadian cross compiler to the NS3216.
Building the tools
A while back, I had built a cross compiler from Linux to Windows using GCC 4.1 as the basis as it was the last version that didn’t have massive external dependencies. NS32016 support was dropped some time in the late 3.x or early 4.x GCC so it means we need to go old anyways. I arbitrary picked GCC 2.8.1 for this build, while using the recommended Binutils 2.27
GCC 2.8.1 doesn’t quite know what we are doing so there is some flags we need to run off in auto-config.h namely
#define HAVE_BCMP 1
#define HAVE_BCOPY 1
#define HAVE_BZERO 1
#define HAVE_INDEX 1
#define HAVE_KILL 1
#define HAVE_RINDEX 1
#define HAVE_SYS_RESOURCE_H 1
#define HAVE_SYS_TIMES_H 1
You can just comment them out, or remove those lines all together.
When it came to building GCC, I did run into issues with GCC 7/8 trying to build GCC 2.8.1. I found it much easier to either have that Linux 4.1 compiler, or if you have access to Wine or WSL you can just run the Win32 binaries for the gen phases.
./configure --prefix=/cross --target=ns32k-pc532-netbsd --host=i686-mingw32
make CC=i686-mingw32-gcc xgcc cccp cc1 cc1obj
If you can run your own Win32 exe’s on Linux it’ll run just fine using the Linux to Windows GCC 4 cross. Otherwise you will need to either patch GCC or make your own GCC 4 hosted Linux to Linux cross compiler like this:
make CC=i686-mingw32-gcc HOST_CC=i586-linux-gcc xgcc cccp cc1 cc1obj
Hopefully that worked enough, and now you have your cross compiler. Now it’s time to build libgcc1.a
Again you really want to be able to run the resulting programs on Linux but I guess you could script it out. Naturally if you wanted to just use Linux, it’d be easier to make that cross compiler directly, although I’m not sure how much of GCC 2.8.1 I want to fight, or just get GCC 4 running on Linux and use that to port.
crt0, somewhere for C to start
As mentioned a crt0.s is missing but there was enough inspiration to come up with this:
#NO_APP
gcc_compiled.:
.text
.align 1
.globl _start
_start:
enter [],0
#APP
# setting the stack 256k under 8MB
lprd sp,0x7c0000
jsr _main
#NO_APP
L1:
exit []
# setting the stack 256k under 8MB
lprd sp,0x7c0000
bpt
.align 1
#does nothing
.globl ___main
___main:
ret 0
.globl _exit
_exit:
bpt
ret 0
I used a bit of the C example, and added some hooks that GCC was expecting namely a __main call that is made from main before it does anything (a place to init memory perhaps?), a place to catch an explicit exit call, along with setting the stack of course.
Patching InfoTaskForce without malloc / disk access
It’s not going to win any awards, but it was really great to get it to run a simple program written in GCC. Looking for something more fun, I took the old InfoTaskForce interpreter from ’87, and dug up my modification to run on cisco routers, and cooked up this version, that adds enough of printf from Linux, a bogus malloc that just allocates from a fixed memory array (otherwise you have to actually know about your platform), and a fun trick with later binutils where you can import a binary file directly as an object!
Neat!
Since I don’t have any file I/O being able to have the game data in RAM is crucial. I tried to tweak it so you could build the same working thing on Windows (maybe others?).
So for anyone who wants to look at the standalone adventure Win32 hosted tools are here, although the emulator should be somewhat portable.
I was inspired by NCommander’s MinGW to Solaris cross compiler so I thought I’d dig out the one that got me started decades ago, cross compiling to the RS/6000 from Linux some time back in 1993. For this experiment I was able to beg/borrow a copy of /usr/lib & /usr/include from AIX 3.2.5 and wanted to use that as a base. I decided to use GCC 2.7.2.2 and Binutils 2.11.2 as these were old enough t build somewhat easy enough from MinGW/MSYS 1, but I figured they also had the best luck of being able to parse the headers without needing ‘fixinc’.
I was able to build both binutils and GCC with this simple incanation
sh configure --target=ppc-ibm-aix325 --prefix=/aix3
One weird thing was that binutils completely sidestepped ld, so I had to configure that manually like this:
--target=powerpc-ibm-aix --prefix=/aix3
Also ‘eaixppc.c’ didn’t generate properly I had to rebuild binutils from Linux to get it to pick up and build that file, copy that back in to get a working cross linker. Older stuff has some issues with CR/LF from time to time, and sometimes it’s easier to deal with builds from other systems and pluck files as needed.
exec(): 0509-036 Cannot load program /cdrom/demo/hello/hello because of the following errors: 0509-150 Dependent module libc.a(shr.o) could not be loaded. 0509-022 Cannot load module libc.a(shr.o). 0509-026 System error: A file or directory in the path name does not exist.
Initially I thought this was a problem with the GCC Linker, but after copying the objects to Qemu, and linking from there, I found out that the GNAT gcc driver calls the linker in a different manner:
I thought first I could just tack -lm onto the end. However remembering years ago, linkers ARE position dependent, and on AIX libm must come before libc.
Sadly networking is a bit goofed on 4.3.3, and Im unable to upload more than a few hundred bytes before a stall on the console so slip/ppp would be a bit useless.
Speaking of useless, if anyone is crazy enough, you can follow here: MinGW-AIX325.7z
This is really nothing more than a placeholder for me… Unless someone else knows the answer, then it’s really ‘how not to cross compile GCC’.
First I’m using the EMX’ified version of GCC from my MinGW to EMX cross. It didn’t require that much massaging to get it to build, the usual unzip as ascii to convert text, and in no time I can build cc1.
[email protected]:/src/emx/src/gcc-2.5.8# file cc1
cc1: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=42c0c8de7175edade7614dc92d5d13e4421e0e6f, with debug_info, not stripped
and it crashes in what has to be a 2020 most unfortunte name
Reading symbols from cc1...done.
(gdb) r
Starting program: /src/emx/src/gcc-2.5.8/cc1
Program received signal SIGSEGV, Segmentation fault.
0x004f6b84 in rtx_cost (x=<error reading variable: Cannot access memory at address 0xff7efff0>,
outer_code=<error reading variable: Cannot access memory at address 0xff7effec>) at cse.c:667
667 {
(gdb)
Yes, it really crashes in rtx_cost. Good thing there isn’t a super popular card from Nvidia that is currently being short squeezed by crypto miners right now called the RTX where everyone is looking for a good price. đ
I had then been thinking perhaps it’s because I’m using GCC 8.3.0, maybe it’s introducing some new and exciting bug? So I cross compiled GCC 4.1.2 as follows:
Keeping in mind that my knowledge of ARM is pretty much nill, especially on Linux. The compile went mostly okay, just have to remember the gnu inline macro’s as needed from back in the day (-fgnu89-inline) and while it builds, it is insisting on using collect2 which of course is screwing things up. And of course I don’t want it as my system compiler. As a hack I found system gcc 8 can link things fine as I didn’t want to spend all day messing with GCC/collect2
I copied xgcc, cc1 and cpp from 4.1.2 into a /412 directory, and rebuilt 2.5.8 with the following shell:
As you can see the cross wasn’t picking up the right include paths, so I just cheated, and dumped them from 8, and just copied them into this script. I re-ran the build and had 2 issues,
/412/xgcc -B/412 -g -O0 -I. -I./config -I/usr/lib/gcc/arm-linux-gnueabihf/8/include -I/usr/local/include -I/usr/lib/gcc/arm-linux-gnueabihf/8/include-fixed -I/usr/include/arm-linux-gnueabihf -I/usr/include -c -DIN_GCC -g -std=gnu89 -I. -I. -I./config local-al.c
....
/tmp/ccMguyhs.s: Assembler messages:
/tmp/ccMguyhs.s:5001: Error: selected processor does not support `fltd f1,r3' in ARM mode
/tmp/ccMguyhs.s:5025: Error: selected processor does not support `fltd f0,r3' in ARM mode
/tmp/ccMguyhs.s:5026: Error: selected processor does not support `dvfd f1,f1,f0' in ARM mode
/tmp/ccMguyhs.s:5027: Error: selected processor does not support `ldfd f0,.L489' in ARM mode
/tmp/ccMguyhs.s:5028: Error: selected processor does not support `mufd f0,f1,f0' in ARM mode
and so on. Also failing was global.c Again the same weird instruction/asm mix being triggered. Other than those two, cc1 will build, but unsurprisingly:
Reading symbols from cc1...done.
(gdb) r
Starting program: /src/emx/src/gcc-2.5.8/cc1
Program received signal SIGSEGV, Segmentation fault.
0x004f6b84 in rtx_cost (x=<error reading variable: Cannot access memory at address 0xff7efff0>,
outer_code=<error reading variable: Cannot access memory at address 0xff7effec>) at cse.c:667
667 {
(gdb)
Well, at least it’s consistent?
Or a fun way to kill a couple hours.
**EDIT I went ahead and looked in the 4.1 source for ARM stuff..
[email protected]:/src/gcc-4.1.2# grep arm config*|grep linux
grep: config: Is a directory
configure: arm*-*-linux-gnueabi)
configure.in: arm*-*-linux-gnueabi)
it didn’t like the gnueabihf stuff one bit.
I tried to rebuild as linux-gnueabi
./configure --target=arm-linux-gnueabi --host=arm-linux-gnueabi --build=arm-linux-gnueabi
make LANGUAGES=c HOST_CFLAGS='-fgnu89-inline' CFLAGS='-fgnu89-inline'
And then re-built GCC 2.5.8 with the same error, but slightly further into the program:
Starting program: /src/emx/src/gcc-2.5.8/cc1
Program received signal SIGSEGV, Segmentation fault.
0x004f2a20 in rtx_cost (x=0x41, outer_code=PLUS) at cse.c:679
679 code = GET_CODE (x);
(gdb) bt
#0 0x004f2a20 in rtx_cost (x=0x41, outer_code=PLUS) at cse.c:679
#1 0x004f2e20 in rtx_cost (x=0x60c3f8, outer_code=SET) at cse.c:736
#2 0x004ac2dc in init_expmed () at expmed.c:87
#3 0x0045ae28 in compile_file (name=0x5c96ec "stdin") at toplev.c:1648
#4 0x0045f6fc in main (argc=1, argv=0xfffefd04, envp=0xfffefd0c) at toplev.c:3569
(gdb)
The positive thing is that there was no weird register errors while compiling, and it built 100% normally…? “arm-linux-gnueabihf” almost seems right, specs needs fixing to point to “/lib/ld-linux-armhf.so.3” instead of “/lib/ld-linux.so.3” along with the linker target.
Microsoft OS/2 Software Development Kit Pre-Release 2
I don’t know why, but Microsoft OS/2 2.00 beta’s are beyond rare. At one point I had a documentation set but not disks. However disk images circulated around, so at one point I did have printed documents (that basically didn’t show much interesting other than True Type fonts for OS/2), and the SDK/ToolKit. However there to date has been no operating system images surfacing.
Since yesterday’s look at the 1991 Windows NT Pre-release which turned out to be using the OS/2 compiler, I went back and checked the Microsoft OS/2 SDK, and it turns out that the compiler is a ‘bound’ executable, meaning that it’ll run under MS-DOS!… And for us that means the MS-DOS Player can make native Win32/Win64 executables out of the compiler/assembler.
Microsoft (R) Microsoft 386 C Compiler. Version 1.00.075 Copyright (c) Microsoft Corp 1984-1989. All rights reserved.
As always the devil is in the details, and this time it’s the linker. I now have OS/2 2.00 v123 (February of 1991), Citrix Multiuser 2.0 (March 1992), and OS/2 2.00 GA (July 1993). And not surprisingly despite them all either including a system link386.exe or the SDK link386 they have massive final incompatibilities.
For fun, I’m using a super simple C program, and compiling it with the Microsoft Pre-Release 2 SDK. After that I’m just using various Linkers & OS’s and the same Pre-Release libraries to see the same object relinked and running.
void main(void){
write(0,"hi\n",3);
}
It’s a very simple program that really doesn’t assume or need much other than write.
So looking at OS/2 build 123
Version 1.01.015
This is the SDK Linker 1.01.015. Dated November 28th, 1990. Which sounds a bit late in the year, but don’t worry as the OS includes Version 1.01.018, dated August 15th 1990!
Version 1.01.018
I don’t understand it either.
Citrix Multiuser 2.0
Version 2.00.000
Citrix Multiuser is using the 177H base also known as the OS/2 2.00 LE. It includes a version 2.00.000 linker, which works fine for it. However the SDK and 123 linked files do not run. While the SDK runs fine, I don’t know how did they link the tools as they work fine**.
OS/2 2.00 GA
Version 2.01.005
And finally we have OS/2 2.00 GA using it’s linker, and yeah it runs fine. Also the GA can run the LA linked files. Naturally 123 can’t run either LA or GA EXE’s.
Obviously the tool group was separate from the OS teams, and there was that brief window when everything 32bit was OMF, and LX was going to be the grand behind the doors unification thing providing 32bit exe’s for Windows 3.x VXD’s, OS/2 2.x and Windows NT. But as was obvious in the 1991 Pre-Release the tool to convert OMF to COFF wasn’t going to be a tool much longer and it was going to be integrated directly.
I’ve tried using the link386 from the Windows 3.1 DDK but I can’t get it to link properly. Just as I haven’t tried other MASM386’s or even 16bit MASM 5+ which apparently support 32bit OMF?
Again it’s interesting to me, but is it useful? Not really. Also the last interesting bit is that the Microsoft C from the 73g build of the Windows 95 SDK can produce assembly that the Pre-Release more or less understands:
D:\OneDrive\proj\link386>4.00.73g\BIN\cl /c /Famt.asm mt.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 8.00.3200
Copyright (c) Microsoft Corp 1984-1993. All rights reserved.
mt.c
D:\OneDrive\proj\link386>
And then assembling and linking on OS/2
Useful? Not very. I don’t think anything complicated will run, although I have only tried one thing and it had a tonne of 16bit/32bit collisions. I don’t know if Microsoft C/C++ 8.0 for OS/2 is all that desirable but I’d imagine if it were, smarter people than I would have made it a thing.
**Edit from the future
Well it turns out the SDK tools are 16bit Family mode apps. It’s obvious once Nathan pointed it out that there is no 32bit ‘bound’ for MS-DOS, however there was Family Mode*** for realmode/protected mode 16bit code.
PharLap famously made their early 286 extender based around OS/2, however for the 32bit stuff it was apparently home grown for the early stuff (I have version 4) but there is DLL’s to emulate MS-DOS like the 286 extender. Interestingly enough DOS/4G supports DLL’s but again there is no DOSCALLS.DLL I can find, but the loader loads it.
***Family Mode/Family API
From the book INSIDE OS/2 (ISBN 1-55615-117-9):
2.2.4.1 Family API To provide downward compatibility for applications, OS/2 designers integrated a Family Applications Program Interface (Family API) into the OS/2 project. The Family API provides a standard execution environment under MS-DOS version 3.x and OS/2. Using the Family API, a programmer can create an application that uses a subset of OS/2 functions (but a superset of MS-DOS version 3.x functions) and that runs in a binary compatible fashion under MS-DOS version 3.x and OS/2. In effect, some OS/2 functions can be retrofitted into an MS-DOS version 3.x environment by means of the Family API.
The linker is from an older MS SDK, the compiler from October 1991 preview of NT
So back in the day I wrote something vague about the October 1991 preview version of Windows NT, and after messing with the tools and building f2c & dungeon (among some other stuff) one that that stuck out to me is that the object files had to be converted for NT.
cvtomf!
The interesting thing is of course that it doesn’t support the cl386 direct compile and link (hence CL). Instead you have to compile, convert and then link. A fun thing about the October 1991 version is that there is a cl386 cross compiler for OS/2. So while looking around for OMF linkers (and assemblers that either understand GAS but output OMF, or some translator) I ran across this, and well yeah, it turns out that the OS/2 tool chain is the toolchain. I guess it makes sense in that the NT team was using OS/2 to build NT, but objects and exe’s were not solidified.
I think 6.00.080 was the last version of Microsoft C 386 for OS/2. I need to start collecting more of the SDK/DDK’s of the mixed era, I think the LX/OMF stuff was a bit more widespread hiding in plain sight.
Anyways, interesting?! sure. useful? Maybe 30 years ago. Although I’d probably say just use Watcom C/C++ instead of Microsoft C 6.00
Way back in the late 90’s from the University of Utah there was this fantastic project that promised to bring Operating System construction to mere mortals but taking existing PC operating systems, Linux, NetBSD, FreeBSD and break them down to their best components, and then interlink them using COM allowing you to glue the best parts together like lego.
And the project was called OSKit.
It was fantastic for something unknown at the time for creating so called ‘bare metal programs’ that didn’t have a real operating system, but rather could use operating features like LIBC, or the EXT2 filesystem. It was almost that level of ‘MS-DOS’ like feeling from protected mode, but being able to take more stuff with you.
And of course transforming the ELF into a multiboot executable that GRUB can load:
/oskit/bin/mkmbimage hello
And now you are ready to boot, on say Qemu?
I was kind of surprised it never really took off, maybe it was too far ahead of it’s time. The most notable project I’ve seen that used it was OSKit-Mach, although they later on abandoned OSKit.. I’m not sure why but I would suspect the lack of updates post 2002 would have something to do with it.
Building this was… Interesting as I recall this being somewhat difficult, and I know I’ve probably made it more difficult, but I thought it would be ‘fun’ using the tools of the time. And 1999 has us at Debian 2.2r0. Which thankfully is on archive.org and is a mere 3 CD-ROMS for the i386 binaries. Installing that into VMWare wasn’t so difficult, and swapping CD images around I was able to get enough installed to start building things. For those of you who don’t want to install Debian, here is my pre-compiled Linux on Linux toolchain: i586-linux2.tar.gz. It’s i386 on i386, so you will need to be able to run i386 ELF exe’s. For OS X users that haven’t installed Catalina, you can try OSX-Linux-2.00-i586-gcc2723.tar.gz
I should point out, that although things have to be patched around for older versions of OSKit, 20020317 does build fine using GCC 2.95.2 (20000220) from Debian 2.2r0. So if you want to build in a VM, then you really don’t need any of this. But I’m strange, and I have my WSL2 Debian 10 to think about. So the easiest way to build GCC 2.x is with GCC 2.x so why not start in Debian?
First let’s prep our destination directory, and populate it like a good little cross compiler:
With that out of the way, we can build the ‘patched’ binutils that was on the old OSKit archive, I used this binutils-990818-patched.tar.gz
./configure --target=i586-linux --prefix=/usr/local/i586-linux2
make install
Next I’m going to build GCC 2.7.2.3 as OSKit mentions to use 2.7 and I figured why not the last of the line? It seemed like a good idea to me.
./configure --target=i586-linux --prefix=/usr/local/i586-linux2
make LANGUAGES=c libgcc1.a
make LANGUAGES=c
make LANGUAGES=c install
Building is a little weird, as I build the libgcc1.a first, then ONLY the C language, then install that. OSKit is written in C, and I didn’t feel like even looking at dependencies for C++/ObjectiveC
Unix person, I’m not a great one, so a quick hack to get the new GCC onto the path:
And now I can build stuff!… I then tar’d if up and copied it to my WSL instance, and now I can cross compile fine (a big plus of WSL2 is that you can install the 32bit support, and run old EXE’s! Take that Apple!)
Now it’s worth noting that a few things need to be edited, the ‘OSKit on UNIX’ thing won’t build cleanly and I didn’t investigate as Qemu is a thing now. So disable it in the modules.x86.pc file. Then run configure like this:
sh configure --host=i586-linux --prefix=/oskit --build=i586-linux --enable-modulefile=modules.x86.pc
Despite using the host, build or target setting it doesn’t pick up prefix of our cross compiler, so you have to manually edit Makeconf
Be sure to change the tool exports to look like this:
And finally remove -fno-strict-aliasing from OSKIT_FFLAGS, and now you can build!
The bonus is that it’ll build well under a minute on a modern machine.
As mentioned above you should now be able to take the hello world example kernel, and transform it to a multiboot, and boot it via grub.
Again this was such an exciting project I’d hate for it to just suddenly die in absolute obscurity. Maybe it’ll inspire others to try “assisted bare metal” programs, there was a DooM OS, among others in the era.
The following is a guest post by PA8600/PA-RISC! Thanks for doing this incredible writeup about an ultra rare Unix!
One of the weirdest times in computing was during the mid-90s, when the major RISC vendors all had their own plans to dominate the consumer market and eventually wipe out Intel. This was a time that led to overpriced non-x86 systems that intended to wipe out the PC, Windows NT being ported to non-x86 platforms, PC style hardware paired with RISC CPUs, Apple putting the processor line from IBM servers into Macs, and Silicon Graphics designing a game console for Nintendo. While their attempts worked wonders in the embedded field for MIPS and the AIM alliance, quite a few of these attempts at breaking into the mainstream were total flops.
Despite this, there were some weird products released during this period that most only assumed existed in tech magazine ads and reviews. One such product was Solaris for PowerPC. Now Solaris has existed on Intel platforms for ages and the Illumos fork has some interesting ports including a DEC Alpha port, but a forgotten official port exists for the PowerPC CPU architecture. Unlike OS/2, itâs complete and has a networking stack. Itâs also perhaps one of the weirdest OSes on the PowerPC platform.
Itâs a little-endian 32-bit PowerPC Unix and possibly the only one running in 32 bit mode. Windows NT and OS/2 (IIRC) were the other 32-bit PowerPC little-endian OSes and Linux is a 64 bit little endian OS.
Itâs a limited access release, yet feels as polished as a released product.
It has a working networking stack.
Unlike AIX, it was designed to run on a variety of hardware with room to expand if more PPC hardware was sold. You can throw in a random 3com ISA NIC for example and it will in fact work with it.
It shares several things with Solaris for Intel including the installer.
Iâm going to demonstrate perhaps the weirdest complete PowerPC OS on fitting hardware: the IBM RS/6000 7020 40p, also known as the Power Series 440 (6015) and by its codename âSandalfootâ. The system is a PowerPC 601 based machine, featuring the PCI and ISA buses in an LPX style case. This is also one of the few machines that can run it. All screen captures are from a VGA2USB card as emulators cannot run anything but AIX.
What you need to run Solaris PPC
To run Solaris, the system requirements are just like that of Windows NT for PowerPC. You need a PReP machine (PowerPC Reference Platform, not to be confused with the HIV prevention pill or PrEP according to Wikipedia). Now finding a PReP machine is perhaps the hardest part of setting up Solaris for PowerPC and to understand why you need to know a bit about the history of the PowerPC platform.
One of the biggest problems with PowerPC hardware to this day has been the sheer inconsistency of how each machine boots. While Alpha machines had SRM/ARC and SPARC machines had OpenBoot, each vendor had their own way of booting a PowerPC machine despite rolling out standards.
There were essentially two different camps building PowerPC machines, IBM and Apple. IBMâs plans for universal PowerPC machines consisted of industry standard, low cost machines built around a PowerPC CPU, chipset, and lots of supporting components lifted from the PC platform along with PCI and ISA. The CHRP and PReP standards were essentially PCs with PowerPC processors in them. IBMâs plan was that you were going to replace your PC with a PowerPC machine someday. This was cemented by the fact that Windows NT was ported to the PowerPC platform, that OS/2 had an ill-fated port, and that a handful of third party Windows NT PPC machines were sold.
Apple on the other hand wanted to build Macs with PowerPC CPUs. Older Power Macs featured no PCI slots or Open Firmware, only NuBus slots carried over from classic 68k Macs. In fact much of the boot and OS code was emulated 68k code. Later on Apple would lift bits and pieces of things they enjoyed from the PowerPC standards such as Open Firmware, PCI, and even PS/2 and VGA ports on the clones. Appleâs plan was to replace the PC with the Mac, and Mac clones featured Apple style hardware on LPX motherboards. While the PCI clones featured Open Firmware, this version was designed to load the Macintosh Toolbox from ROM while âfutureproofingâ them by adding in the ability to boot something like Mac OS X/Rhapsody or BeOS.
Despite these similarities Macs were their own computers and were nothing like the IBM systems internally, aside from sharing the same CPU and maybe Open Firmware later on. But even Macs with Open Firmware were incapable of booting from hard disks formatted for IBM systems and vice versa. This is a common problem with installing PowerPC Linux as many installers do not check which machine theyâre run on. Furthermore unlike modern day Intel Macs, PPC Macs were designed to only boot operating systems specifically written for them. They were incapable of running any OS solely written for the IBM machines.
The confusion between PPC machines has also caused a forum question to pop up, âhow can I install PowerPC Windows on my Mac?â Even today the new OpenPower/PowerNV machines use a different bootloader than IBMâs hardware and completely lack Open Firmware.
Anyhow IBM built several different generations of PowerPC UNIX machines under several brand names including RS/6000, pSeries, and Power. Nearly all of them (aside from the Linux models) will run AIX, and later ones will run IBM i as well. Not just any PowerPC IBM hardware will run the OSes designed for PReP hardware however.
To run these old PReP OSes youâre looking at a very specific set of machines from the 1994-95 period, many with no characteristic diagnostic display most RS/6000 machines have. To run PowerPC Solaris much of the same applies here. You need a RS/6000 40p, or 7248 43p (not the later 140 and 150 with the display). The rare PPC Thinkpads and Personal Computer Power Series machines will run Solaris as well. Itâs also compatible with the PowerStack machines from Motorola and one BetaArchive user had luck running it on a VME board. These machines are hard to find and unemulated as of writing, though the firmware files exist for the 40p at least and some efforts have been made in QEMU.
Mine features a PowerPC 601 CPU, 192mb of RAM (the max), a Weitek P9100 video card (branded as the IBM S15 IIRC), and a non-IBM 3com NIC. The 3com NIC has issues with the system as during boot if the NIC is connected to the network the system will refuse to boot fully and will either freeze or BSOD (in NT). The NIC is also not supported on AIX as well, and will eventually need to be replaced.
Curiously, not only is the IBM 40p/7020/6015 not listed in the HCL but the NIC it uses is. Itâs well known that the Sandalfoot systems were used for early PReP OS development and it makes sense. Unlike the RS/6000 model 250, the 40p features PCI and ISA busses along with the same 601 CPU early PowerPC machines had.Â
Installation
To install PowerPC Solaris, you first need to make a boot floppy. This isnât uncommon with PReP operating systems. PowerPC Windows NT also requires a boot floppy for the ARC loader. The difference here is that there are two boot floppies; one for Motorola machines and one for IBM machines. Even on PowerPC this wasnât terribly unusual, both the Moto Powerstack and Apple Network Server computers required custom AIX install media as well and Windows NT had specific HALs for each PPC machine.
On the Motorola PowerStack machines you need the same firmware used to install AIX instead of the ARC firmware for NT. On the IBM machines itâs vastly easier, you just need to make the floppy and shove it in. You then press the power switch and youâll end up dumped to an Open Firmware prompt. As these IBM machines did not have Open Firmware, the bootloader loads Open Firmware from the floppy or hard disk every time you boot the machine. Keep in mind even the system management services are floppy loaded on these machines.
You then run into the first big hurdle to installing the OS, âdiskâ and ânetâ are mapped to very specific devices and if the SCSI IDs of these are different it will not boot. If the CD drive is not at ID 3 and the HDD is not at ID 6 the commands will not work. You will need to set an environment variable and tell it to boot from these disks manually for the first install.
Booting the OS is similar to booting it on a Sun, but the installer resembles that of the Intel version. The first thing that happens is you wait for the slow 2 speed CD drive to load the OS as the screen turns Open Firmware white. You will need to set the terminal type, and then then video and mouse input before X will load. The video options are limited to the S3 864/928, the Weitek P9000 and P9100, and Motoâs Cirrus Logic GD5434. Notice how the Power Series 440 (6015)/RS6k 7020 40p is referred to by its codename âSandalfootâ.
Once you enter this in Solaris will boot load X it does on a Sun or Intel box, and the installer will be exactly the same. This phase is very uneventful as the slow CD drive copies files to the hard disk. I didnât take a lot of screenshots of this part because you can get the same experience with QEMU or an old SPARCStation. You set the network info, you partition the HDD, you choose what you want, and you sit back as it installs.
Then youâll be dropped at the Open Firmware bootloader and youâll enter the right commands to make it boot if âboot diskâ doesnât automatically boot the OS.
The installation is not complete however. The next step is to swap CDs and install the GUI. A default install will drop you at a command line, with the second disk you can install OpenWindows and CDE and get a full working desktop. Login, switch CDs, change to the correct directory, and run the installer.
Once this is done, simply type in reboot and once you login youâll be at a desktop that looks exactly like a Solaris 2.5.1 install on any other platform with one difference. There is literally zero third party software, and for years there was literally zero way of making software for it. Youâre stuck with a stock OS and whatever utilities Solaris 2.5.1 came with. Youâll want to use OpenWindows as well, CDE is vastly slower on the 601 CPU (but not as slow as AIX 4.3 for example). The platform directory also tells you what IBM machines it can run on, and all the RS/6000s are titled PPS. The 6015 is the 40p, the 6040 and 6042 are the ThinkPad models 830 and 850, the 6050/70 are the Personal Computer Power Series variants of the 7248 43p, and the PowerStacks are pretty self-explanatory.
The Compiler Problem (and solutions)
For the longest time Solaris for PowerPC was neglected among those who happened to own a PReP machine for one reason: it lacked a compiler. A compiler is perhaps the most important part of any operating system as it allows one to write code for it. As was the case with UNIX operating systems from the time, the compiler was sold separately. With any UNIX that was widely distributed this wasnât too much of an issue, as GCC or other third party compilers existed for the platform. Furthermore most compilers for these commercial UNIX operating systems ended up dumped online.
Solaris for PowerPC lacked both of these for ages due to the obscurity and rarity of the port. But in 2018 Tenox dug up the official compiler, yet this remained unnoticed for a while. This led to someone else experimenting with cross compilation on Solaris, and managing to compile PowerPC Solaris software. They then released a port of GCC for Solaris 2.5.1 for PowerPC while posting instructions on how to compile it.
To use GCC for Solaris, you need to unzip the compiler, add it to the path, and then symlink a few files that GCC ends up looking for. This is discussed in the BetaArchive thread about this, but Iâll quote it here.
$ ls -l /opt/ppc-gcc/lib/gcc-lib/powerpcle-sun-solaris2/2.95/ total 13224 -rwxr-xr-x 1 bin bin 5157747 Feb 16 10:30 cc1 -rwxr-xr-x 1 bin bin 404074 Feb 16 10:30 collect2 -rwxr-xr-x 1 bin bin 453525 Feb 16 10:30 cpp -rw-r--r-- 1 bin bin 1932 Feb 16 10:30 ecrti.o -rw-r--r-- 1 bin bin 1749 Feb 16 10:30 ecrtn.o drwxr-xr-x 3 bin bin 1024 Feb 16 10:29 include -rw-r--r-- 1 bin bin 673012 Feb 16 10:30 libgcc.a drwxr-xr-x 2 bin bin 512 Feb 16 10:30 nof -rw-r--r-- 1 bin bin 4212 Feb 16 10:30 scrt0.o -rw-r--r-- 1 bin bin 1360 Feb 16 10:30 scrti.o -rw-r--r-- 1 bin bin 1104 Feb 16 10:30 scrtn.o -rw-r--r-- 1 bin bin 7868 Feb 16 10:30 specs lrwxrwxrwx 1 root other 24 Feb 22 21:35 values-Xa.o -> /usr/ccs/lib/values-Xa.o lrwxrwxrwx 1 root other 24 Feb 22 21:36 values-Xc.o -> /usr/ccs/lib/values-Xc.o lrwxrwxrwx 1 root other 24 Feb 22 21:36 values-Xs.o -> /usr/ccs/lib/values-Xs.o lrwxrwxrwx 1 root other 24 Feb 22 21:36 values-Xt.o -> /usr/ccs/lib/values-Xt.o lrwxrwxrwx 1 root other 26 Feb 22 21:37 values-xpg4.o -> /usr/ccs/lib/values-xpg4.o $
Once you do this, you can now compile C code at least with GCC. This means that Solaris for the PowerPC platform now is a usable operating system, aside from the fact it has no precompiled software whatsoever. Even Windows NT for PowerPC has more software for it. Software can now be compiled using GCC or the original compiler, and cross compiled with GCC on a non-PPC box. Using the cross compiler lets you compile more basics for compiling PPC Solaris code as well such as make. In this screenshot you can also see me compiling a basic âendian testâ code example to demonstrate the little endianness of the PowerPC port.
The only problem is that thereâs going to be little interest until someone makes a PReP machine emulator. PReP hardware is very hard to come by on the used market these days and while in the early 2000s it might have been easy to find something like a specific RS6k, but judging by the eBay listings there were a lot more MCA, CHRP, and even later PReP models (like the 43p-140) than there are early PReP machines in circulation. QEMU can emulate the 40p somewhat, but right now its 40p emulation is less like an actual 40p and more like something to please AIX. It definitely has the novelty of being a âlittle-endian PowerPC Unixâ however.
While digging around on bitsavers for new and interesting things, I saw some newer stuff from MIT, and stumbled into the GNU directory and rediscovered the early GNU software depot.
And I re-built the early GCC to target the 68000 which I’d imagine primarily was for the SUN target.
simple program
Using a simple program I can run it through the pre-processor, and the compiler to get the following assembly:
assembly from ’87 GCC
Then it’s a matter of running it through the cross assembler, uuencoding it, and sending it to the target.
I used the cross assembler from the AtariST cross ‘project’, to get an object file. I fired up MachTen, pasted my object file to the VM, and uudecoded the object.
And yeah, much to my surprise the object file linked fine, and I got my native EXE.
It’s not much of a cross toolkit, and honestly it’s kind of useless… but I thought it was maybe worth a bare paragraph to show the other available target available for the 1987 release of GCC.
Also on the MIT archive is TRIX, the MIT Unix work alike that almost became the GNU Kernel, until Mach stole their hearts, and basically lead them on a wild goosechase.
I haven’t bothered uploading binaries or patches or anything yet, I don’t know if people are interesting in such a fringe thing……
