Coherent OS
en.wikipedia.org
en.wikipedia.org
A couple of friends and I drooled over an AT&T Unix manual that our public library had in 1990 - 1991. Unix seemed really cool but we could never afford a real Unix machine. We talked about pooling our money and buying a copy of Coherent but we never did. Then Linux came on the scene and Coherent was forgotten.
I was an intern an Inetco sytems in Vancouver (circa 1989?). They developed switching software for ATMs that used Coherent running on Intel PCs.
My task was to extend the Coherent shell (a clone of the standard Unix sh) with BSD csh features (history, etc.). I had nothing to go on except the csh man page.
I have since lost the source code (it was called the "wsh"), but I suspect I would cringe looking at it now.
Coherent was definitely my gateway drug into Unix.
https://www.autometer.de/unix4fun/coherent/ftp/vms/
Udo's Coherent pages in general are worth a visit:
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.
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.
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.
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.
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).
Also, I recently stumbled upon Idris[2], which, as far as I know, predates Xenix and Coherent in the PC scene.
[1] https://www.computerworld.es/archive/omega-anuncia-coherent-... [2] https://en.wikipedia.org/wiki/Idris_(operating_system)
I eventually filched a copy of SCO Unix from a customer (which is what I had to support way back then - along with SCO Xenix) with a license key and ran that for a bit and once Linux became a bit more stable (for me it was Slackware circa 1994/1995) I started running that instead.
I kinda wonder what would have happened if MWC had open sourced Coherent back then (provided they owned all their own code, or the third party code was compatible with GPL/MIT/et-al)?
All through the 90s as I progressed from Coherent to AT&T Unix to Novell's Unixware to Sun's Solaris, I used to to look at Linux every six months or so. I was always gobsmacked at how quickly Linux (actually Gnu/Linux) was moving ahead in leaps and bounds.
By the time that 2001 rolled around, it was time for me to put away my Solaris and switch to Linux fulltime.
A perfect storm of several things killed Coherent The two biggest problems were:
The customers dinging Mark Williams Company in the newsgroup mainly complained about the lack of TCP/IP networking. This happened because MWC had done a customer pole to see what big feature should come next? TCP/IP or X11. X11 won.
The real or perceived drop in quality of the product. This one is hard to explain. Coherent 3.10 and 4.0 had been solid V7 Unix clones with V7 sensibilities. When 4.2.05 shipped it included a really nasty disk driver bug that basically destroyed your file system beyond the ability of fsck to fix. The bug was triggered when your drive when into a very common thermal recalibration mode. This mode was rare or hadn't existed during the days of MFM/RLL/ESDI drives but became common with ATA drives especially as the market got flooded with cheap 504MB drives. While the bug was fixed somewhere between 4.2.10 and 4.2.14, the damage to Coherent's reputation was done.
As the person responsible (alas), my specific recollection of this particular bug was that the root cause wasn't thermal recalibration, but rather UDMA signalling errors.
Prior versions of Coherent using PIO mode had excruciatingly slow access, and when adding support for UDMA I also added support for the disk driver to recognise sequential access and issue multisector transfer requests; this boosted performance fairly massively, something like 3-4 times for some common things, and it was run for a fairly long time in-house and by beta testers with no trouble before it shipped.
The problem though, was a small - literally one line - arithmetic error when the drive end of things reported a UDMA transfer error had occurred in the middle of a multisector operation; the error-handling code that set up a retry of the operation didn't compute the start kernel address correctly when a whole bunch of transfers had been merged (and some subset had worked).
The primary problem with the UDMA modes was sensitivity to correct cable termination - see https://en.wikipedia.org/wiki/Parallel_ATA#Cable_select for some of that; basically, signal reflections from parallel ATA cable runs that didn't have terminating resistors made things electrically marginal and some systems would have really excessive numbers of UDMA CRC faults as a consequence, and given sufficiently high error rates and really bad timing that could end up polluting the buffer cache with stuff that was skewed by a sector :-(
The big thing (on top of not having any in-house hardware that triggered this specific bug) was the sheer volume of work required for those releases, since getting from what was basically a fairly vanilla Seventh Edition UNIX to where it needed to be to start running large pieces of third-party code expecting POSIX was a big lift. Since there weren't many people, everyone was having to wear lots of hats; for instance, aside from kernel work I did a huge amount of work for POSIX.1 and .2 compatibility and on top of doing the underlying code changes (which ranged all over the system, particularly for some of the stuff we ran into Autotools scripts relying on) all of those needed documenting, too.
[ Fred Butzen did amazing work writing the actual manpage text and making it really easy to understand - he justly deserved the credit for the quality of the manual in terms of its readability. But the scale of the changes needed to bring so many parts and pieces from V7 to POSIX meant lots and lots and lots of work trying to iterate over docs for technical accuracy at the same time as having to redesign all the affected parts and pieces. It was, in a word, exhausting. ]
Regarding the driver bug, I guess I was lucky, because I still used a MR-535 MFM disk in the late 1990's. I think I later upgraded to a 100MB IDE disk, but was still lucky.
Personally I was not even happy about the move from V7 to POSIX, because I enjoyed the simplicity of V7 very much, but things started to change and supporting POSIX was certainly a neccessity at that time.
Anyway, thanks for contributing to a great OS! I still keep a VM with 3.2 around and use it regularly.
Well, it really wasn't luck as much as keeping with the electrical specs. Do that, you'd never see a problem, and the later IDE "cable select" schemes did really help to mitigate a lot of the damage from improperly terminated cables.
> Anyway, thanks for contributing to a great OS!
Well, other than living in infamy due to introducing that bug, I didn't start there until the push to turn 4.0 from a tech demo into a real product. So really all the credit for 3.2 and earlier which set the foundation for Coherent belongs to the other guys, many of whom were long gone by the time I got there like Dave Conroy (who wrote the MicroEMACS I loved to use) and Randall Howard (who went on to found MKS). There were some great people from the earlier days still there though, like Norm Bartek, Hal Snyder and La Monte Yarroll who where there when I joined and of course Steve Ness who was the sole man behind the MWC C Compiler (much as Fred was responsible for that remarkable manual).
Also worth a mention, among all the other notable characters I remember fondly is one of the support/QA folks at MWC: Jim Leonard aka Trixter, who became a notable demoscene figure - https://trixter.oldskool.org/2015/04/07/8088-mph-we-break-al...
What a small world!
PC hardware was all over the map in those days. I didn't remember this bug being tied to cabling but I only worked it to the point where we recognized that the cause was not handling an error in multi-sector transfers correctly. I do remember putting Scatter/Gather handling into the SCSI driver so that SCSI drives could do the same multi-sector trick. I also dimly remember that Louis Gilberto had to patch my driver for a bug afterwards and Hal said that he didn't have kind words for me.
And on the 8086 and on the Z8000.
Did not know about the disk driver bug! I guess I was lucky, because I used small MFM disks even when IDE disks became ubiquitous. Anyway, I wonder why I never heard about it. I read comp.os.coherent every day.
It was my only time knowingly using a UNIX-like OS until a few years later when I installed Slackware.
The author of this page:
https://www.autometer.de/unix4fun/coherent/index.html
previously worked for MWC and has put some quite detailed notes on setting up various aspects of Coherent running under Virtualbox there.
https://www.computerworld.com/article/2547289/baystar-exec-s...
Your article suggests otherwise. It seems like some over-eager Microsoft exec promised that BayStar's investment would be 'guaranteed' by Microsoft. That exec was subsequently fired and nothing was formalized. BayStar ultimately lost money on SCO. But even that much is suspect as this account is hearsay and comes from a managing member of BayStar who has cause to deflect blame for his or his company's dumb investment in SCO.
Yes.
Just because you don't like Microsoft, doesn't mean you can just claim things that are untrue.
(And in any event, actions by the responsible executives are actions of the company, and going back to say "it was just this guy, not MS the company" is not really the right way to think about it)
Nothing else rings true about his story either. Like for example, you don't make a big investment as private equity firm based on flimsy (at best) guarantees. Regardless, had that guarantee actually happened and BayStar really believed it, they would have sued Microsoft just to embarrass them and force a settlement.
I'm sure Microsoft was applauding the lawsuit but that doesn't mean they funded it as OP just outright stated.
> It seems plausible that the SVP was just paid a lot of money to quit and not refute the blame placed on him after the rest of MS decided to wash their hands.
Only if you're conspiratorial minded because that doesn't seem plausible at all.
I think your dislike of Microsoft clouds your judgment.
In this case it's ridiculous.
Coherent installed, and ran, but had a few incompatibilities with our software, but ran solid as hell. The documentation was very good too.