6 ms·

Coherent was a great option in and around the 1990-92 timeframe. It was a great UNIX clone for $99 (with a great manual to boot). What killed it is they, for so

by cowmix 7y ago

Coherent was a great option in and around the 1990-92 timeframe. It was a great UNIX clone for $99 (with a great manual to boot). What killed it is they, for some reason, spent time and treasure port XWindows to it instead of working on a TCP/IP stack. It would have been the perfect Internet OS.

anyfoo 7y ago
Just from memory, I can sort of see how they could have mistaken those priorities. Windowing systems (with which X11 was synonymous on unixy systems) were a big deal at the time, while TCP/IP, even networking in general, was still emerging in what probably was Coherent's target market. Coherent did have UUCP, didn't it? In a lot of cases, that got you much further in small to mid scale environments than TCP/IP. I wouldn't even be surprised if Novell Netware would have been considered more important.
- teh_klev 7y ago
  > I wouldn't even be surprised if Novell Netware would have been considered more important. Speaking as a field engineer from the UK from days of yore... Up until around 1995 IPX/SPX, Novell's default networking stack at that time, was hugely prevalent in corporate and governmental environments. I didn't start bumping into TCP/IP in any serious way until around 1992 in my job as a field engineer. The general kinda setup was groups of departmental Novell Netware 386 servers (I was a Netware engineer since around '87) with loads of DOS and Windows 2/3.x clients running Novell's IPX/SPX stack atop NE2000 compatible NIC's. Around '95 things changed. Novell Netware 4 (as did NT 3.51 - NT done properly) shipped and the default stack became TCP/IP...the rest is history.
  - Jaruzel 7y ago
    I think people forget how prevalent IPX/SPX and Netware was back in the late 80s-early 90s. Fun anecdote: I used to work on a large MoD site as PC support during that era, and one call I got was to visit a bunch of porta-cabins to fix their Netware network because they wanted to play network DOOM and for some reason it wasn't working.
    - teh_klev 7y ago
      Haha, this sounds familiar :)
- ecksii 7y ago
  Coherent had Taylor UUCP. The most enthusiastic users were doing Usenet News delivered via UUCP. Coherent ran into big issues due to a nasty bug in the ATA disk driver. The users who got hit the worst were the ones running C news.
- nils-m-holm 7y ago
  It did have UUCP, I used to run a USENET leaf node back in the days.
- wildduck 7y ago
  Yeah but back then you got all kinds of stuff like Token ring, Novell as alternative to TCP/IP. Seems they have gone with other ones.
ecksii 7y ago
The decision was before my time but it was based on a user survey. I have to admit that my vote was also for X11 rather than TCP/IP. I don't think people realized how tightly X11 was bound to networking. This blinded them to the the extra effort required to port X Windows to an OS without TCP/IP.
nils-m-holm 7y ago
You could run KA9Q NOS under Coherent, which provided TCP/IP over serial line. Not many people used it, though. Most used UUCP. Personally, I cared neither about X11 nor networking and I know I was not the only one, so the decision may have been solid back then. Of course this changed very quickly in the following years. Bad timing, I guess. The shutdown of MWC was really sad, Coherent was my favorit OS, and I still have a few VMs running 3.2 (286).
nigel_bree 7y ago
> 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_Standard 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.

by cowmix 7y ago

anyfoo 7y ago

Just from memory, I can sort of see how they could have mistaken those priorities. Windowing systems (with which X11 was synonymous on unixy systems) were a big deal at the time, while TCP/IP, even networking in general, was still emerging in what probably was Coherent's target market. Coherent did have UUCP, didn't it? In a lot of cases, that got you much further in small to mid scale environments than TCP/IP. I wouldn't even be surprised if Novell Netware would have been considered more important.

teh_klev 7y ago
> I wouldn't even be surprised if Novell Netware would have been considered more important. Speaking as a field engineer from the UK from days of yore... Up until around 1995 IPX/SPX, Novell's default networking stack at that time, was hugely prevalent in corporate and governmental environments. I didn't start bumping into TCP/IP in any serious way until around 1992 in my job as a field engineer. The general kinda setup was groups of departmental Novell Netware 386 servers (I was a Netware engineer since around '87) with loads of DOS and Windows 2/3.x clients running Novell's IPX/SPX stack atop NE2000 compatible NIC's. Around '95 things changed. Novell Netware 4 (as did NT 3.51 - NT done properly) shipped and the default stack became TCP/IP...the rest is history.
- Jaruzel 7y ago
  I think people forget how prevalent IPX/SPX and Netware was back in the late 80s-early 90s. Fun anecdote: I used to work on a large MoD site as PC support during that era, and one call I got was to visit a bunch of porta-cabins to fix their Netware network because they wanted to play network DOOM and for some reason it wasn't working.
  - teh_klev 7y ago
    Haha, this sounds familiar :)
ecksii 7y ago
Coherent had Taylor UUCP. The most enthusiastic users were doing Usenet News delivered via UUCP. Coherent ran into big issues due to a nasty bug in the ATA disk driver. The users who got hit the worst were the ones running C news.
nils-m-holm 7y ago
It did have UUCP, I used to run a USENET leaf node back in the days.
wildduck 7y ago
Yeah but back then you got all kinds of stuff like Token ring, Novell as alternative to TCP/IP. Seems they have gone with other ones.

ecksii 7y ago

The decision was before my time but it was based on a user survey. I have to admit that my vote was also for X11 rather than TCP/IP. I don't think people realized how tightly X11 was bound to networking. This blinded them to the the extra effort required to port X Windows to an OS without TCP/IP.

nils-m-holm 7y ago

You could run KA9Q NOS under Coherent, which provided TCP/IP over serial line. Not many people used it, though. Most used UUCP. Personally, I cared neither about X11 nor networking and I know I was not the only one, so the decision may have been solid back then. Of course this changed very quickly in the following years. Bad timing, I guess. The shutdown of MWC was really sad, Coherent was my favorit OS, and I still have a few VMs running 3.2 (286).

nigel_bree 7y ago

> 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_Standard 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.