3 ms·
AIX on RT PC had a rather interesting architecture: the AIX kernel ran on top of a microkernel called VRM. VRM also supported two other operating systems, AOS (
by skissane 2y ago
AIX on RT PC had a rather interesting architecture: the AIX kernel ran on top of a microkernel called VRM. VRM also supported two other operating systems, AOS (IBM’s port of 4.3BSD) and PICK. VRM could run multiple operating systems simultaneously, with a hotkey to switch which had access to the keyboard, mouse and screen. Similar idea to Windows NT’s environment subsystems, and IBM’s later Mach-based Workplace OS (cancelled before it ever went GA, but shipped in beta form to customers as OS/2 PowerPC Edition).
VRM was written, not in C, but in a PL/I dialect (not sure which, but probably PL.8). So AIX for RT PC is a rare example of a Unix whose kernel is (partially) written in a language other than C. The only other example of that I know of is IBM z/OS (which most people don’t think of as a Unix, but officially it is one, since it passes the certification test suite and IBM pays The Open Group the Unix trademark license fees.)
I say partially because the actual AIX kernel is in C, but it then calls to the VRM microkernel which isn’t in C. But a lot of basic functions which normally belong in a Unix kernel are in the VRM instead and the AIX kernel is just a thin wrapper over them.
When AIX moved to the RS/6000, the VRM microkernel was dropped, and AIX from then onwards was a classic monolithic kernel all in C.
Well, historically “AIX” has been a brand for (many but not all) IBM Unixes, with several unrelated code bases being labelled “AIX”. One of those, AIX/ESA (for IBM mainframes), was actually based on OSF/1, and hence used the Mach microkernel. But it was discontinued in the first half of the 1990s, when MVS gained Unix compatibility support. And all the other “weird” AIX variants are also now long dead, so in practice AIX for RS/6000’s descendant is the only AIX left.
AIX is a bit like DB2, in that both were brand names for multiple distinct code bases. The difference is all but one AIX code base died, whereas multiple DB2-branded code bases are actively supported today.
- tiahura 2y agoUpvoting for Pick mention.
- brucehoult 2y agoI only ever saw Pick here in New Zealand running on Pr1me.
- skissane 2y agoPick ran on a plethora of different platforms. Ultimate even had a port for IBM mainframes, PICK/370. How much use all these different ports saw, I don’t know. Obviously some of them were pretty big (you mention Prime, I’ll mention R83) - others less so. I wonder how many customers IBM RT PC PICK ever actually had. Probably significantly less than PICK ever had on AIX for RS/6000 (at one point several different PICK vendors offered Unix ports, and AIX was commonly on the list of supported Unix flavours)
- smackeyacky 2y agoUniverse is alive and, not well, but surviving. It’s still used in a common central banking system. Still chugging away on AIX too. I hate it.
- sillywalk 2y ago> I wonder how many customers IBM RT PC PICK ever actually had. According to Wikipedia: Approximately 23,000 RTs were sold over its lifetime, with some 4,000 going into IBM's development and sales organizations. Pick OS sales accounted for about 4,000 units.
- gcoleman 2y agoA blast from the past! Years ago I worked on some J2EE nonsense to do e-commerce websites on top of a Pick application. It was I think called Mailbrain, I think running on HPUX though I could be mis-remembering. There was a horrible text based socket protocol for passing data records back and forth. I do remember the Pick greybeards being dismissive of this new fangled SQL stuff: "we had relational databases before SQL don't you know"
- sillywalk 2y agoFor those who were wondering what VRM stands for it's Virtual Resource Manager. I found a quick introduction to it[0]. It says it was programmed in PL.8. [0] https://ardent-tool.com/615x/The_Virtual_Resource_Manager.pdf https://ardent-tool.com/615x/The_Virtual_Resource_Manager.pd...
- chasil 2y agoWe know from papers published by Bell labs that there were two other UNIX kernel implementations that ran on top of foreign kernels: One ran on top of Sperry/Univac OS2200 EXEC-8 (and this was the first SMP UNIX AFAIK): https://www.bell-labs.com/usr/dmr/www/otherports/newp.pdf https://www.bell-labs.com/usr/dmr/www/otherports/newp.pdf "The UNIX system for the UNIVAC 1100 series was built as an integrated development environment for transactions that run directly on EXEC. Unlike most other implementations, therefore, it runs not directly on the hardware but as a collection of user-level activities under control of EXEC. These obtain services that would normally be provided by device drivers, and some process creation and management services from EXEC. Any configuration supplied by Sperry, including multiprocessor ones, can run the UNIX system." A Bell Labs port to an IBM mainframe ran on top of TSS/370: https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf "Of the available systems, TSS/370 came the closest to meeting our needs and was thus chosen as the base for our UNIX system implementation. The choice of TSS/370 was a controversial one; it is a little known and inadequately documented system. Still, it came the closest to providing the structure and function needed to support UNIX system processes, and it appeared that it could be enhanced to provide any missing functions with reasonable effort. In 1979 we proposed to IBM that they make the necessary modifications to the TSS supervisor to support UNIX system processes, according to our design. IBM agreed to do so under a program license agreement, and the first version of the enhanced TSS was delivered in 1980."
- skissane 2y agoI knew about the TSS/370-based port but had forgotten its relevance I can think of another: the University of Wollongong’s port of Unix V6 to the Interdata 7/32 started out running under Interdata’s OS/32, until the port advanced to the point that they could get rid of OS/32 and run it directly on bare metal. I suppose this differs from these other ports in that it was only ever intended as a temporary stopgap while the port could be completed, not as a final destination: http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/32bit/unix/univWollongong_v6/miller.pdf http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/... The Princeton port that evolved into Amdahl UTS maybe also counts, since early versions could only run under VM, not bare metal. That meant they could use VM’s simplified paravirtual device API (hypercalls via DIAG instruction), that hid some of the complexity of mainframe IO-running on bare metal required dealing with those complexities directly