Coherent OS(en.wikipedia.org)
en.wikipedia.org
Coherent OS
https://en.wikipedia.org/wiki/Coherent_(operating_system)
48 comments
This brings back a lot of memories.
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.
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.
In case somebody did not know yet: Coherent is officially free software now. You can download disk images with the whole system, including full, self-replicting source code, here:
https://www.autometer.de/unix4fun/coherent/ftp/vms/
Udo's Coherent pages in general are worth a visit:
https://www.autometer.de/unix4fun/coherent/
https://www.autometer.de/unix4fun/coherent/ftp/vms/
Udo's Coherent pages in general are worth a visit:
https://www.autometer.de/unix4fun/coherent/
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.
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.
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.
> 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.
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.
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.
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.
Haha, this sounds familiar :)
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.
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.
It did have UUCP, I used to run a USENET leaf node back in the days.
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.
> 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.
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).
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.
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).
I remember the magazine ads for it:
http://2.bp.blogspot.com/-vfzVzVxKynE/To2Hu97jlLI/AAAAAAAAAD...
I met about Coherent thanks a small article in the spanish edition of ComputerWorld[1]. I was 13 y/o and all my computer knowledge was about Basic, Pacal, DOS and Win3.1. Good times. I still remember the accompanying picture in the article, showing the windowing system with an astronaut picture in a window, some terminals and a file explorer. I think that picture inspired my view of what operating systems should be, more than everything I've seen since then.
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)
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)
Back in the day (early 1991) just before Linux appeared I convinced my company to pay for a copy of Coherent and they agreed. It was $99 and I learned a decent amount of Unixy basics on my el-cheapo clone 386 PC. In summary it was a pretty decent learning tool. I managed to get it to connect to my ISP and get some basic text based internet kinda things done.
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)?
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)?
This is only based on playing around with it in a VM and poking at its source code after it was open sourced with a BSD license in 2015, but to me, Coherent seemed like a quite well put together system. Enough that it made me a bit sad that it's now an OS of the past.
Coherent's misfortune was that it was released at the same time that Linux was.
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.
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.
While Linux would have certainly killed Coherent eventually, that's
not quite the case. First Coherent was out long before Linux. Coh was
around long enough for AT&T to have sent Dennis Ritchie to Chicago to
inspect the code and evaluate it for copyright claims. Coherent ran on
the PDP11 and on the 80286. Linux became a real force in the Unix
market around 1998. MWC went out of business in Feb 1995. The first
round of layoffs at MWC happened in Oct, 1994.
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.
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.
> The bug was triggered when your drive when into a very common thermal recalibration mode
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. ]
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. ]
I don't remember the exact cause per say beyond Bob saying that some drives did a thermal recalibration and if this occured during a multi sector transfer, the filesystem got shot to hell. Everyone at MWC had taken a crack at it and you're right, it didn't show up in any of the MWC equipment. At some point in time I think I bought a brand new WD 504MB disk for my home box and I discovered that I could replicate the conditions of the bug regularly. I do remember having a eureka moment on a Saturday morning when I realized that the the issue was error handling after a multi-sector transfer gone bad. However, that was one of the last things I did on the MWC payroll. If I remember right, the first round of layoffs was in October of 1994 and I was in them along with Ed Bravo and a few others. Ed and I ran down to a pub that Addison Snell and Jeff Day had showed me a few weeks earlier and threw some darts.
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.
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.
Thank you for sharing the story! Even these days I enjoy hearing about the company that produced the first Unix system that I used at home (Coherent 3.0). It was my main operating system for more than 10 years and, looking back, I have never enjoyed computing more than in those days.
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.
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.
> I think I later upgraded to a 100MB IDE disk, but was still lucky.
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...
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...
You were then responsible for my first paid "unix" contract: data recovery on some pooched Coherent disks for a Port of Seattle contractor.
What a small world!
What a small world!
> Coherent ran on the PDP11 and on the 80286.
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.
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.
My dad (or maybe his work) bought Coherent for him to learn UNIX and we had a setup in the garage with serially-connected VT100-like terminals.
It was my only time knowingly using a UNIX-like OS until a few years later when I installed Slackware.
It was my only time knowingly using a UNIX-like OS until a few years later when I installed Slackware.
Almost bought it after seeing the stunningly low price. $99 for a Unix like OS? It seemed too good to be true. At the time my housemate and I ran a small multiline BBS we wanted to make into something bigger. Coherent would have been to run Picospan after seeing how well M-Net worked. Someone we contacted at the Mark Williams Company said they didn't think Picospan would work with Coherent's memory model. No idea if that was correct but we went with MajorBBS instead for our big upgrade. Still thought about buying it to play with but Linux showed up before I had the spare money for Coherent.
Coherent was my entrance to the wonderful world of Unix back in 1991. Thanks to Coherent's introduction I never ever had to endure Windows as my everyday personal desktop environment.
Ran this on the Ithaca Intersystems Z-8000 based rig in the early/mid '80s - it was remarkably command compatible with V7 for the basics, even built a MicroAngelo based 3D graphics system on it.....the biggest problem the box had wasn't Coherent, it was the fact the socketed logic on the custom MMU S100 card kept trying to walk out of the sockets because of thermal issues
These days (as another poster has already pointed out) it is under an Open Source license.
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.
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.
I ran this on a 386SX for while in 1991. It came with a very comprehensive "Unix" manual. A couple years later I switched to Linux...
Did Linux deal with any of the same legal scrutiny?
Yes, for years...
https://en.m.wikipedia.org/wiki/SCO–Linux_disputes
https://en.m.wikipedia.org/wiki/SCO–Linux_disputes
SCO was a farce. Microsoft used a company called BayStar to fund SCO's lawsuits, which had absolutely nothing to them; SCO wouldn't even release the evidence it claimed to have proving code copying for a suspiciously long period of time, and when the evidence was released, it was nothing of the sort. Ultimately, the legal merits of the case wouldn't have mattered, in that a bad lawsuit can still drown an opponent. What mattered was that Microsoft waited too damn long to try it: One of the players on the other side was IBM, which by then had a serious business in Linux on mainframes, and a two-bit nuisance suit jumped up with some venture capital wasn't going to sink the damn Nazgul.
https://www.computerworld.com/article/2547289/baystar-exec-s...
https://www.computerworld.com/article/2547289/baystar-exec-s...
>Microsoft used a company called BayStar to fund SCO's lawsuits
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.
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.
MS claimed to have changed their minds, but it's hard to say what really went on there. Due to the nature of the whole enterprise people would be very conscious of what to put on paper / email. 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.
(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)
(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)
Again, you're taking the words of a BayStar managing member at face value. Why? He has a reason to lie and deflect blame. There is no other supporting evidence.
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.
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.
Maybe I assume too much skulduggery on the part of Ballmer-era "THE GPL IS CANCER! LINUX IS CANCER!" Microsoft when it comes to something which attempts to hurt Linux.
>Maybe I assume too much skulduggery
Yes.
Just because you don't like Microsoft, doesn't mean you can just claim things that are untrue.
Yes.
Just because you don't like Microsoft, doesn't mean you can just claim things that are untrue.
It's just a little more complicated than that. If you're interested in what really happened, go to http://www.groklaw.net/staticpages/index.php?page=2008080306... and explore the actual decade plus story.
I was reading Groklaw at the time, but not closely enough to be able to summarize the entire thing in a single Hacker News post without simplifying.
Choosing one debatable point out of a decade plus of litigation involving a dozen entities, millions of pages of legal fillings, untold legal rulings, and declaring "this summarizes the whole thing" is in the best possible case a dubious conclusion.
In this case it's ridiculous.
In this case it's ridiculous.
in 1990, while working for an insurance company, we were looking for what UNIX to port a multi user database to, We looked at SCO, Microport, Cohernet and Sperry. The company chose Microport, and the Sperry went back, so I got to keep SCO and Coherent. Loaded and ran both, liked SCO a tiny bit more because of it successfully compiling a few programs, and heard about the UNIX Copyright controversy.
Coherent installed, and ran, but had a few incompatibilities with our software, but ran solid as hell. The documentation was very good too.
Coherent installed, and ran, but had a few incompatibilities with our software, but ran solid as hell. The documentation was very good too.
I remember using Coherent along with Xenix around the same time. I think I tried everything I could get my hands on :)
I even used 386BSD heh.
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.
[1] https://en.wikipedia.org/wiki/Mark_Williams_Company
[2] https://en.wikipedia.org/wiki/Aaron_Swartz