Hacker News new | past | comments | ask | show | jobs | submit login

> What killed it is they, for some reason, spent time and treasure port XWindows to it instead of working on a TCP/IP stack

Just to be clear, there's a whole heaping helping of really big work required to get there either way, since Coherent was still essentially a 16-bit OS that started out as a V6 clone on the PDP-11 and hadn't really kept up during the 1980's with any of what was happening in the wider UNIX world beyond, oh, the Seventh Edition.

The key starting point for Coherent 4.x was essentially a single piece of work (almost all of it provided in a single .c file) that let a 3.x kernel boot into 386 protected mode and provided a system call handler that more-or-less emulated the call sequence specified in the Intel iBCS specification and mapped the iBCS system calls to the original 16-bit Coherent 3.x ones, and a very basic loader for statically linked SVR3 COFF files.

[ See https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Sta... which essentially formalized a subset of what the SCO port of System V did. Note, that omitted a number of system calls; I'm fairly certain that the iBCS manual didn't include any of the socket-related system calls anyway, so the public spec for what people took to mean "will run SCO binaries" left a lot to be desired. ]

Everything else around that was still, essentially, 16-bit code that was written around some variation of Sixth Edition or Seventh Edition, not System III/ or System V (so to be iBCS compliant the bible was the System V Interface Definition, aka SVID), let alone any of the things that were being added to POSIX.1 or POSIX.2

So, the work required for releasing the V4.x series of Coherent included a massive number of upgrades of almost everything, along with all kinds of awkward technical compromises to a) not break any existing things from the 16-bit userland, which stayed 100% supported, b) navigate between SVID and POSIX because while we on the one hand wanted to be able to run SCO binaries (hence, do things per the SVID) while we had all kinds of enthusiasts really wanting to use the ability to 32-bit code to run various shar archives of GNU project code unmodified.

So, I'd just note about that 16-bit userland from Coherent 3.x was that virtually everything on the (nominally 32-bit) version 4.x install floppies - all the standard utilities, pretty much everything that could be - still was built as 16-bit a.out binaries to keep the install size down. Pretty much everything we did in terms of C libraries and such had to be, and had to stay, buildable both 32-bit and 16-bit from the same source since both subsystems were needed. At some point we could conceivably have (at a technical level) cut over to all-32-bit, but just from the point of view of media duplication, doing that and still staying at a $99 price point wouldn't fly, and also the resulting increased memory footprint wouldn't have made existing customers happen since the kernel didn't have any support for demand paging, at a time when lots of people had just 1-2Mb (or 4Mb for a relatively beefy system) of RAM.

[ So for all the work required to let /bin/sh able to run successfully run multi-megabyte autotools scripts that tried relying on POSIX.1 shell features? Yup, everything involved in POSIX.2 support was all done with code that stayed 16-bit. ]

Without getting too much into the weeds of all the other various challenges involved getting a system like this out, for TCP/IP specifically the question was what kind of TCP/IP stack to pursue and most critically of all the question of where were the NIC drivers going to come from. There was not going to be any plausible way we could work with third-party SCO driver binaries, which were the most common type of UNIX driver that NIC vendors did provide at the time; SVR4.2, however, had STREAMS and the DDI/DDK so there was a plausible, reasonably portable driver model which seemed like a realistic future, but just licensing Lachmann and trying to bolt that into the kernel wasn't realistic at the $99 price point (and at the time, there weren't much of any third-party NIC drivers either).

To make 4.x happen we had to come from a very very long way behind, and getting to where we needed to go while staying within the constraints of a small staff and that $99 price point just made for an incredibly tight set of constraints. None of the resulting tradeoffs were fun to make. We did our best.

On top of all of that you had to compete with Sun Microsystems selling a fully boxed set of Solaris 2.5.1 for the i86pc for $50 USD. There was just no way to compete with them.

Yeah, cross-subsidised products like that were an issue. But it's worth noting that part of the fine line we had to walk was that lots of the people who bought Coherent had hardware on which something like Solaris would have been totally unusable in practice, at least unless they spent US$5K on brand-new machines with enough grunt.

For context, while we we working on 4.x I recall Norm Bartek having a crack at installing one of the early Windows NT 3.1 beta releases on one of the beefiest machines we had in the office. After grinding over half the day copy stuff to the install partition, then when it went to actually boot it just bluescreened because the machine had "only" 12Mb of RAM (which was the minimum spec for release NT 3.1, but the betas were built in debug mode and so needed more).

There was a big gap between what the "workstation" folks thought PC hardware was like and the reality of what most people could actually afford, hence why the minimum spec target for Windows 95 - a couple years later! - was still only down around 4Mb, even though that still tended to page hard.

So, for us, although it sometimes took fairly heroic efforts in size-coding, by keeping everything we possibly could still as 16-bit, our install floppy was actually a fully live system, without any tricks like compressed filesystems expanded to RAMdisk or anything. You booted off the install floppy to the 32-bit kernel, with the regular init and login and /bin/sh and everything - the installer was a shell script that just helped walk through fdisk and mkfs and then did an untar of the remaining stuff on later floppies (with things like the C compiler and libs) but right from the install floppy you could quit (or Alt-F2 to an alternate console TTY) to a root shell and have a usable system that happily ran in 1Mb of RAM.

So, there was still a niche for Coherent (and similarly, QNX), albeit that it wasn't a large enough one to bridge it through the growing pains of the changes at the time, especially given the forces that would shortly wipe out AT&T and DEC and almost all the other UNIX vendors despite their size.

It's interesting, given what I then went on to, to compare that niche to some of the customer response to Ghost. Even well after 2005 we had plenty of paying customers there who absolutely clung to being able to build and boot to DOS via floppies, even though we did have to use the RAMdisk trick once the UPX-packed Ghost binary exceeded about 2Mb by itself (a lot of which was due to a mistake I told the other devs not to make around the time Symantec acquired it, which was to rely on C++ exception handling; alas after several years, something like about 40% of the size of the binary was just GCC's exception metadata).

To be fair, Solaris always required very little memory, which was both ironic and cool given that it ran on some of the largest supercomputers at the time. Even to this day, Solaris still requires liliputian amounts of memory: once booted and with unnecessary services turned off, there are only about 13 processes running in less than 64 MB of memory.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact