4 ms·

Prior to POWER on the RS/6000, AIX ran on the IBM PC RT: https://en.m.wikipedia.org/wiki/IBM_RT_PC https://en.m.wikipedia.org/wiki/IBM_RT_PC This ran on the R

by chasil 2y ago

Prior to POWER on the RS/6000, AIX ran on the IBM PC RT: https://en.m.wikipedia.org/wiki/IBM_RT_PC https://en.m.wikipedia.org/wiki/IBM_RT_PC This ran on the ROMP processor: https://en.m.wikipedia.org/wiki/IBM_ROMP https://en.m.wikipedia.org/wiki/IBM_ROMP This system was a bit before my time.

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 ago
  Upvoting for Pick mention.
  - brucehoult 2y ago
    I only ever saw Pick here in New Zealand running on Pr1me.
    - skissane 2y ago
      Pick 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 ago
        Universe 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 ago
    A 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"
lproven 2y ago
> This system was a bit before my time. Not mine. First Unix box I ever touched, in my first job, here on the Isle of Man 36Y ago. It was a demo machine, but my employers, CSL Delta, never sold any AFAIK. It sat there, running but unused, all day every day. Our one had a mono text display on it, and no graphics ability that I know of. I played around, I wrote "Hello, world!" in C and compiled it and it took me a while to find that the result wasn't called "hello" or "hello.exe" or anything but "a.out". If I had the knowledge then, I'd have written a Mandelbrot generator or something and had it sit there cranking them out -- but I was not skilled enough. It was not networked to our office network, but it had a synchronous modem allowing it to access some IBM online service which we used to look up tech support info. Synchronous modem comms, or serial comms, are very different indeed to the familiar Unix asynchronous serial comms used on RS-232 connections for terminals and things. Sync comms are a mainframe thing, more than a microcomputer thing. https://wiki.radioreference.com/index.php/Asynchronous_vs_Synchronous https://wiki.radioreference.com/index.php/Asynchronous_vs_Sy... That modem was a very specialised bit of kit that cost more than a whole PC -- when PCs cost many thousands each -- and it couldn't talk to anything else except remote IBM mainframes, basically. The RT/PC felt more powerful than a high-end IBM PC compatible of the time, but only marginally. It had a bit of the feeling of Windows NT about 6-7 years later: when you were typing away and you did something demanding, the hard disk cranked up and you could hear, and even feel the vibrations, that the machine was working hard, but it stayed responding to you the same as ever. It's a bit hard to describe because all modern OSes work like this, but it was not normal in the 1980s. Then, OSes didn't multitask or they did it badly, and things like hard disk controllers of the time took over the CPU completely when reading or writing. So on MS-DOS, or PC-DOS or OS/2 1.x or DR Concurrent DOS, when you typed commands or interacted with programs, the computer responded right away as fast as it could. But if you gave a command that made the machine work hard, like asked for a print preview or a spell-check of a multi-page document, or sorted a spreadsheet of thousands of rows, or asked it to draw a graph from hundreds of points of data, the computer locked up on you. The hard disks span up, you heard the read/write heads chattering away as it worked, but it was no longer listening to you and anything you pressed or typed was lost. Or, worse, buffered, and when it was done, then it tried to do those commands, and quite possibly did something very much not what you wanted, like deleted loads of work. (Decades later something similar happened with cooling fans, and now that's going away too. But with hearing the fans spin up, there's a hysteresis: it takes time, and tens of billions of CPU cycles, for the CPU to heat up, so the fans come on later, and maybe stay on for a while after it's done. A PC locking up as the hard disk went crazy was immediate.) The RT/PC was a Unix box. It didn't do that. No idea how much RAM or disk ours had: maybe 4MB if that, perhaps 100-200MB disk. A lot for 1988! But if I did, say, cd / ls -laR ... then it would sit there for several minutes with the HDD chuntering away, listing files to screen... but what was remarkable was that you could switch to another virtual console and it stayed perfectly responsive as if nothing were happening. That hard disk was SCSI of course, so it didn't use loads of CPU under heavy disk load. The machine always felt a little slower, a little less responsive than DOS, but it never slowed down even when working hard. You had the feeling of sitting behind the wheel of a Rolls Royce with some massive engine there, but pulling a massive weight, so it didn't accelerate or brake fast, but could just keep accelerating slowly and steadily 'til you ran out of road... and you'd make an impressively large crater. We sold a lot of IBM PS/2 machines with Xenix, and it was a Unix too and felt the same... but limited by the puny I/O buses of even high-end 1980s IBM PS/2 kit, so it sssslllloooowwwweeeedddd way down doing that big directory listing. Whereas contemporary PC OSes responded quicker but just locked up when working hard. This included Windows 2, 3.x, 95, 98 and ME, and also OS/2 1.x, 2.x, and Warp. The kernels did not support multithreading and background I/O very well, so it didn't matter that the hardware didn't either. Then Windows NT 4.0 came along, and it did. Suddenly the hardware mattered. But if you had a Pentium 1 machine, with an Intel Triton chipset on the motherboard, there was an innocent looking driver floppy in the box. On that was a busmastering DMA driver for the Intel PIIX EIDE controller. Install it on Win9x and it could see a CD-ROM on the PATA bus. Handy but not world-shattering. Install it on an NT machine and once the kernel booted, the sound of the hard disk changed because the kernel was now using busmastering to load stuff from disk into RAM. As the machine booted the mouse pointer kept moving smoothly, with no jerkiness. When the login screen appeared it blinked onto the screen and you could press Ctrl-Alt-Del and start typing and your username appeared slowly but smoothly. The stars representing your password, the same. It suddenly had that "massive computer power being used to keep the machine responsive" feeling of an RT/PC the decade before. Like that PIIX driver had made the machine's £100 cheapo IDE disk into a £400 SCSI disk.

by chasil 2y ago

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 ago
Upvoting for Pick mention.
- brucehoult 2y ago
  I only ever saw Pick here in New Zealand running on Pr1me.
  - skissane 2y ago
    Pick 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 ago
      Universe 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 ago
  A 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"

lproven 2y ago

> This system was a bit before my time. Not mine. First Unix box I ever touched, in my first job, here on the Isle of Man 36Y ago. It was a demo machine, but my employers, CSL Delta, never sold any AFAIK. It sat there, running but unused, all day every day. Our one had a mono text display on it, and no graphics ability that I know of. I played around, I wrote "Hello, world!" in C and compiled it and it took me a while to find that the result wasn't called "hello" or "hello.exe" or anything but "a.out". If I had the knowledge then, I'd have written a Mandelbrot generator or something and had it sit there cranking them out -- but I was not skilled enough. It was not networked to our office network, but it had a synchronous modem allowing it to access some IBM online service which we used to look up tech support info. Synchronous modem comms, or serial comms, are very different indeed to the familiar Unix asynchronous serial comms used on RS-232 connections for terminals and things. Sync comms are a mainframe thing, more than a microcomputer thing. https://wiki.radioreference.com/index.php/Asynchronous_vs_Synchronous https://wiki.radioreference.com/index.php/Asynchronous_vs_Sy... That modem was a very specialised bit of kit that cost more than a whole PC -- when PCs cost many thousands each -- and it couldn't talk to anything else except remote IBM mainframes, basically. The RT/PC felt more powerful than a high-end IBM PC compatible of the time, but only marginally. It had a bit of the feeling of Windows NT about 6-7 years later: when you were typing away and you did something demanding, the hard disk cranked up and you could hear, and even feel the vibrations, that the machine was working hard, but it stayed responding to you the same as ever. It's a bit hard to describe because all modern OSes work like this, but it was not normal in the 1980s. Then, OSes didn't multitask or they did it badly, and things like hard disk controllers of the time took over the CPU completely when reading or writing. So on MS-DOS, or PC-DOS or OS/2 1.x or DR Concurrent DOS, when you typed commands or interacted with programs, the computer responded right away as fast as it could. But if you gave a command that made the machine work hard, like asked for a print preview or a spell-check of a multi-page document, or sorted a spreadsheet of thousands of rows, or asked it to draw a graph from hundreds of points of data, the computer locked up on you. The hard disks span up, you heard the read/write heads chattering away as it worked, but it was no longer listening to you and anything you pressed or typed was lost. Or, worse, buffered, and when it was done, then it tried to do those commands, and quite possibly did something very much not what you wanted, like deleted loads of work. (Decades later something similar happened with cooling fans, and now that's going away too. But with hearing the fans spin up, there's a hysteresis: it takes time, and tens of billions of CPU cycles, for the CPU to heat up, so the fans come on later, and maybe stay on for a while after it's done. A PC locking up as the hard disk went crazy was immediate.) The RT/PC was a Unix box. It didn't do that. No idea how much RAM or disk ours had: maybe 4MB if that, perhaps 100-200MB disk. A lot for 1988! But if I did, say, cd / ls -laR ... then it would sit there for several minutes with the HDD chuntering away, listing files to screen... but what was remarkable was that you could switch to another virtual console and it stayed perfectly responsive as if nothing were happening. That hard disk was SCSI of course, so it didn't use loads of CPU under heavy disk load. The machine always felt a little slower, a little less responsive than DOS, but it never slowed down even when working hard. You had the feeling of sitting behind the wheel of a Rolls Royce with some massive engine there, but pulling a massive weight, so it didn't accelerate or brake fast, but could just keep accelerating slowly and steadily 'til you ran out of road... and you'd make an impressively large crater. We sold a lot of IBM PS/2 machines with Xenix, and it was a Unix too and felt the same... but limited by the puny I/O buses of even high-end 1980s IBM PS/2 kit, so it sssslllloooowwwweeeedddd way down doing that big directory listing. Whereas contemporary PC OSes responded quicker but just locked up when working hard. This included Windows 2, 3.x, 95, 98 and ME, and also OS/2 1.x, 2.x, and Warp. The kernels did not support multithreading and background I/O very well, so it didn't matter that the hardware didn't either. Then Windows NT 4.0 came along, and it did. Suddenly the hardware mattered. But if you had a Pentium 1 machine, with an Intel Triton chipset on the motherboard, there was an innocent looking driver floppy in the box. On that was a busmastering DMA driver for the Intel PIIX EIDE controller. Install it on Win9x and it could see a CD-ROM on the PATA bus. Handy but not world-shattering. Install it on an NT machine and once the kernel booted, the sound of the hard disk changed because the kernel was now using busmastering to load stuff from disk into RAM. As the machine booted the mouse pointer kept moving smoothly, with no jerkiness. When the login screen appeared it blinked onto the screen and you could press Ctrl-Alt-Del and start typing and your username appeared slowly but smoothly. The stars representing your password, the same. It suddenly had that "massive computer power being used to keep the machine responsive" feeling of an RT/PC the decade before. Like that PIIX driver had made the machine's £100 cheapo IDE disk into a £400 SCSI disk.