This comes from a response I posted to a thread in the
Vintage Apple Macintosh Enthusiasts
group on Basshook about Michael Dell's bragging, where the thread took a what-if turn about Rhapsody, Yellow Box, and
such. The OP hypothesized how the computer industry could have changed
if Dell had accepted the opportunity to preinstall Yellow Box (essentially,
Steve Jobs's NeXT, but on top of MSWindows, if I understand/remember
correctly) on the computers he sold.
I suggested, for a what-if hypothesis-contrary-to-fact session of daydreaming, going back more than a decade from there to Microware's OS-9, a modular real-time operating system available for Motorola's 6809 CPU from 1979/80, and for Motorola's 68000 from 1983, which included graphics and GUI component libraries.
He said that was before his time.
So I offered him a gratis (heh), technologically dense daydream of my own:
----- My Response -----
Worth checking out. OS-9 was a Unix-like, modular multitasking real-time OS available in 1979. (Wikipedia: https://en.wikipedia.org/wiki/OS-9.)
The open source project has a FB group, Tandy Color Computer OS-9 / NITROS-9, and you can download NITROS-9 and check it out using MAME or the XRoar emulator.
Kind of surprising what could be done on what was essentially a Radio Shack toy computer in 1987.
In the late 1970s and early '80s, the 6809 was viewed by many in the Apple community as the natural evolution from the 6502.
There were a few hanging points -- mainly the need to develop an interpreter front-end to Microware's compiled Basic09, byte order opposite the 6502, incomplete support of pointer variables in the byte-addressed direct page, the need for a simpler, faster MMU than Motorola's over-designed separate 6829 MMU, the penalty that OS-9 placed on non-position-independent programming techniques, and Motorola's lack of plans for evolving the 6809 to a fully 16-bit CPU.
Also, Apple would have had to plan on developing it as a product line to be aggressively evolved.
But they could have delivered a multi-tasking network-server capable business machine with high-level language support in 1980 instead of the Apple III, with minimal engineering effort. This could have been Raskin's text-based appliance computer. They probably would have wanted to introduce 80-column Apple IIs with bundled terminal emulators to go with it.
A model with built-in hard disk support, bank-switching for a 2 MB memory map, and a display buffer could have been produced in 1981. They could have released their own GUI or an improved Multivue in 1983, and it wouldn't have required 80+ hour workweeks for the engineers.
Experience with OS-9/6809 would have allowed them to put OS-9/68000 underneath the Lisa, and bring that to market at least a half-year earlier, without MMU, but cheaper.
With OS-9/68000 underneath the Lisa, the Macintosh would not have required a separate technological base. Or it could have had different hardware with little engineering penalty, and still been part of the same line as Lisa. The toolbox would simply have been a collection of OS-managed library modules in ROM.
Lack of a true OS underneath the Macintosh would never have been a problem, and neither would *nix compatible networking. The Lisa/Macintosh would have been Internet ready pretty much as it was.
How's that for alternate reality?
----- End Response -----
Well, some of what I put in that included false memories about who did what
when, but it wasn't that far off.
But it was dense. So I'll use unpacking it as an excuse to walk through the real-world background of that dense daydream:
===== Real Reality =====
Two decades before Mac OS9 -- a decade and a half before the failure of Copland and the transition to Rhapsody, and a decade before Pink -- a small company called Microware was contracted by Motorola to develop a structured, i-code compiled version of BASIC for the 8-bit M6809 CPU (not the 6800, 6801, or 68HC11). For an operating system to put underneath Basic09, Microware developed the operating system OS-9 (OS-9/6809).
(Microware's lawyers and Apple's lawyers met around the introduction of Mac OS 9, mid-1980s, and were able to come to an agreement about the name fairly quickly. At the time I write this, Wikipedia's page on OS-9 has minimal mention, but more information is available elsewhere.)
OS-9 was (and still is) a modular, multitasking, real-time Unix-like OS, and it was first available
for computers based on the 6809 in 1979. (OS-9/68000 and OS-9000 and later
versions were POSIX compliant.)
It was also a showcase for certain aspects of the 6809 that regularly still get overlooked by the noisier elements of the industry.
A lot of people seemed to notice only one or two features of the 6809, such as the hardware multiply instruction or the second index register.
But the 6809 is much more than that. The architecture of the CPU supports a programming style that is modular, understandable, and, well, engineerable. OS-9 demonstrated that the architecture of the 6809 allowed using concise code to solve truly difficult problems like guaranteed response times and functional verification with generalized hardware and programming tools for a wide range of 8-bit applications.
(The 68000 also supports such a programming style for 16 and 32 bit
applications, but uses roughly twice the number of registers in doing so -- in
a much more flexible way.)
Engineers who understood the architecture made very good use of it in telephony, sound synthesis, various kinds of real-time controllers, and even business systems.
But there were a lot of famous pundits who could not see the forest for the
trees and spread a lot of useless information about the limitations of
isolated features of the 6809.
As just one rather visible example of what the architecture enabled, with Basic09 and OS-9 you had an integrated development environment pretty much as powerful as, say, the combination of Turbo Pascal under CP/M and MS-DOS would be two years later. Admitted, the programming editor provided with the OS was originally a line editor instead of a full screen editor, but third party screen editors came pretty quickly.
One big difference from Turbo Pascal under CP/M or MS-DOS was that OS-9 was multi-tasking from the outset -- Send a long document to the printer and it would print in the background while you worked on accounts receivable, your neighbor in the next cubicle worked on a program she was developing using a terminal on her desk, and a secretary proofread and prepared a letter on a terminal on his desk, all at the same time on the same machine running OS-9/6809.
(For the record, DR produced the multi-tasking MP/M about the same time as
OS-9 came out. MP/M was more-or-less about desktop-level multitasking, where
OS-9 was more general, being able to multi-task on desktop applications as
well as controller applications. Also, for the record, MS-DOS was not
multi-tasking, and had to rely on the individual applications themselves, or
on terminate-and-stay-resident (TSR) utilities, to manage print spooling and
calendars and such.)
The 64K RAM limit in OS-9 level 1 in 1979 did put some limits on things, just
like with any of the 8-bit ALU/16-bit addressing microcomputers of the time.
These limits could be largely overcome with bank switching in OS-9 Level 2,
when it became available in 1980.
OS-9 Level 2 supported bank switching, to open up the address space to 2 MB in
1980. You could have six users or more simultaneously doing pretty memory
intensive stuff on a single machine running Level 2. (And everybody spooling
print jobs, of course.) That meant that single users were also able to make
much more efficient use of the processor's extra cycles, such as compiling and
running utilities and test programs in the background while editing in the
foreground.
OS-9 used device drivers to get around dependence on specific hardware, so
that you could build a computer with a cheap floppy disk controller or with a
good hard disk controller, and the only thing that would change in the OS
would be adding or swapping out the driver code. Application code would not
change at all (if the application code followed the rules). So you could hang
a hard disk on an OS-9 computer basically as soon as the actual hardware was
available, in 1980 or '81.
One thing that OS-9 lacked was system support for virtual memory and demand paging. But it wasn't that necessary, since even native machine code for OS-9 could be (and was supposed to be) written position-independently. You didn't need a virtual machine for position independence. You hardly needed a virtual machine at all.
A position-independent (PIC) code module, whether program or library, could be loaded to any available address without a link loader patching it up first for the address it was loaded to. And multiple processes could call the loaded module from wherever they themselves were located. Even without virtual memory, you essentially had shared dynamically loaded libraries from the first version of the OS.
Data modules could also be created and/or loaded pretty much arbitrarily, and OS-9 could use an MMU for memory protection, so most of what virtual memory gets used for was taken care of without virtual memory.
(Looking at, among other things, those pointer-pointers that enabled mobile
allocation in the Classic Macintosh toolbox.)
There is a fundamental conflict between generalized virtual memory and the requirements of a real-time OS. Swapping system stuff in and out from disk makes it hard to respond to real-world events in real time. For a true real-time OS to support virtual memory would require separating the virtual memory interface from the real memory interface, and the system itself would not use the virtual memory system for anything that had to happen in real time.
In other words, virtual memory in a real-time system must be a secondary
service, provided strictly for the run-time environment of non-critical
applications that need to access more memory than is physically available,
need to access large amounts of high-speed memory backed by persistent store,
or need to make sparse use of large address ranges. According to certain
approaches to computing systems, this is the proper approach to virtual memory
in any system, but it is not an approach that has seen much use in the
industry.
The perception that a real-time OS is not for ordinary users may have contributed to lack of interest in OS-9 in the general-purpose personal computer market.
But the reality is that we as users want the computer to respond in real time,
even if we can choose to be patient. That's a huge part of the magic of the
Macintosh interface.
Network interfaces comparable to those available for Unix at the time were
also available from the first versions of OS-9.
(If you want to take OS-9/6809 for a test drive, I recommend joining the Facebook group for NitrOS9: https://www.facebook.com/groups/1929079184021683/. They can point you to the web sites for the open source project, NitrOS9, and they can help with emulation environments to run NitrOS9 in, such as MAME, VCC, OVCC, and XRoar. )
It's rather surprising what OS-9 could do on what was essentially a toy computer from Radio Shack, the Color Computer, even in 1981. Radio Shack delivered the Color Computer 3, under-engineered and rather late to the game in 1986, but it was still impressive, much more usable than the early versions of Microsoft Windows. Even though it was still only 8-bit, it had features that would not be replicated on PCs in general until the mid-to-late 1990s.
(And the Tandy/Radio Shack Color Computer gets its own share of what-iffing,
of course.)
An important note, Microware ported OS-9 to the 68000, releasing it as OS-9/68000 in 1983. Graphics libraries and GUI for OS-9/68000 came a bit after that, some of them from 3rd parties.
In the late 1970s and early '80s, the 6809 was viewed by at least some of the
talking heads in the Apple community as the next logical step up from the 6502
in the Apple II. Both the 6502 and the 6809 were derived from the 6800. The
indexing techniques commonly used in the 6502 were all more directly and more
efficiently supported by the 6809's design, which produced much faster code in
both benchmarks and real applications. The 6809's partially 16-bit design
helped speed development, as well.
The hanging points relative to migrating from the 6502 to the 6809 that I mentioned above did exist, but a look at them shows they were not serious problems:
-
The 6809 followed the 6800 in putting the more significant bytes of numbers
lower in memory, where the 6502's byte order was reversed, following Intel's
habit of putting the less significant numbers first. This was considered a
low-level optimization by some engineers.
I disagree about it being an optimization. The technological arguments in favor of less-significant digits appearing lower in memory ignore the global effects, especially on testing and debugging. Also, arguments that byte order doesn't really affect algorithms are only excuses for whichever order is chosen, not reasons to make a choice. If less-significant first should be no detriment, neither should more-significant first, and changing the mental habits is not fatal.
As an aside, the Z-80 had the same byte order as the 6502, but the run-time architecture was not comfortable to programmers used to working in assembly language on the 6502..
-
The 6502 inherited its short address zero page (or page zero) from the 6800.
On the 6800 it's called direct page, but it's pretty much the same idea,
although the 6502 allows somewhat more efficient use. In particular, the
6502 allows indirection on memory in the zero page. This allows a great deal
of flexibility and a fair degree of efficiency when working with pointer
variables and address math, once you learn how it's done on the 6502.
The 6809 also inherited the direct page address mode from the 6800. But it has both (almost) general memory indirection and the LEA address math instruction, which mean that you don't need the zero page for address math. Simpler, faster, improved, but different, meaning you have to take a few hours puzzling out the differences.
One of the frequent uses of address math was incrementing and decrementing pointers, and the 6809 supports that as an address mode, often not even needing an extra instruction. Or you can use the LEA instruction, if the addressing mode is not flexible enough. A common issue for engineers used to other CPUs was not realizing the addressing modes and LEA instructions could be used to replace whole sequences of 6502 instructions -- or of 8080, Z-80, etc., instructions. Unfortunately, programmers who didn't know what they were doing shared a lot of code, so example code was often less than useful.
If you want to write good code on a particular processor, you have to spend a few hours looking at the instruction set and addressing modes and thinking out how to use them.
It's a bit odd, but indirection through variables in the direct page somehow got left out of the 6809's indexed address modes. For actual indirection, it's not a big deal -- one extra load with maybe a save and restore of an index register when necessary. But it makes the 6809's relocatable direct-page not quite the advance over the 6502's page zero that it could have been -- especially when trying to calculate the effective address of a variable in the direct page, since it can't be done with just an LEA. This is not a fatal problem, by any means. It just takes 3 to 5 instructions to replicate what should have been doable with just a single LEA.
Specifically (I prefer to use the U stack, so the following uses the U stack. Those who prefer to use the S stack, use PSHS and PULS instead for push and pop.) If the value in X or D does not need to be saved, the push and pop instructions can be left out, and it's just one extra instruction:
-
to achieve indirection on a pointer in the direct page, instead of
LDD [<dp_pointer] ; load value at dp_pointer
free an index register if necessary and use it to load the pointer first:
PSHU X ; (if necessary)
LDX <dp_pointer ; get the pointer
LDD ,X ; load through it
PULU X ; (pop it back if it was pushed)
-
To get the address of a pointer in the direct page at run-time, instead
of
LEAX <dp_pointer
free the double accumulator if necessary, and use it to calculate the address:
PSHU A,B ; (if necessary)
TFR DP,A ; high byte of base of direct page
LDB #(dp_pointer-dp_base) ; offset in B
TFR D,X ; put whole address in X
PULU A,B ; (if it was pushed)
Note that the 6809 does allow memory indirection on the extended address mode. But that's only useful relative to the direct page if the direct page address is known and fixed at assemble time, which interferes with position independent practices and significantly reduces the usefulness of the direct page.
-
to achieve indirection on a pointer in the direct page, instead of
-
Motorola's plans for the future of the 6809 became somewhat unclear once
microcontrollers based on the 6801 and 6805 were shipping in volume and the
68000 CPU saw better than 99.999% reliability in production.
The earliest materials for the 6809 indicated that the 6809 was being considered for system-on-a-chip integration, but that never happened -- at least where it could be seen by general members of the public. Such references tended to disappear from later materials.
I understood from reliable sources that the 6809 was viewed by some members of management as cannibalizing the 68000's market share, and that those members of management pushed for deprecation of the 6809 for marketing purposes. This resulted in an apparent lack of a "road map", which did become a problem in the marketplace. On the other hand, eating into the 68000's market never really was a problem.
-
OS-9 did not directly support non-position-independent code. You could, with
effort, run such code on the system, but you lost most of the advantages of
the OS.
Writing code in a position-independent manner was not a common practice at the time, and many programmers thought it looked more difficult than it really was.
Similar issues existed with the move to the Macintosh, but going to a 16/32-bit run time from an 8-bit run-time could be seen to have more apparent benefits than going from the Apple II/6502 to just the 8/16-bit run-time of the 6809.
Because of the above, code transitioning from the Apple II to OS-9 faced not just translation from 6502 to 6809, but conversion to position independent architecture, as well.
-
Since most of Apple's customers would be wanting to run code written in
BASIC for the Apple II on Apple computers based on the 6809, Apple would
need to provide some means of transitioning the code. Apple's engineers
would face the same apparent obstacles and compatibility issues porting
Apple's Integer BASIC to the 6809 under OS-9 that 3rd-party software
companies and end-users would face.
-
Another alternative, producing software to analyze BASIC programs and
convert them (somewhat) automatically to Basic09, was considered the stuff
of pipe dreams, although it was considered. We just generally didn't know
how to do things like that back then. Still don't know how to do it well.
-
Which would basically leave the alternative of a hardware Apple II emulator
card for the OS-9/6809 computer, for backwards compatibility, and an
OS-9/6809 emulator card to allow Apple II owners to run the OS-9 programs.
We should note that OS-9/6809 cards for the Apple II were, in fact, produced and sold in early 1981.
-
Motorola had a memory management unit (MMU) for the 6809, called the 6829,
but it slowed the 6809 down by basically one memory cycle per memory access.
One memory cycle felt like a lot, and the 6829 was a little expensive, so
simple bank switching was more commonly used.
But OS-9/6809 worked well with moderately-well designed bank switching hardware, so bank-switching was not such a big problem. And one memory cycle per access was actually not all that bad, either.
Comparing the above to the 68000 as a path of evolution from the 6502 --
-
The 68000 was also most-significant byte first, so it would be something to
get used to in migrating to the 68000, just as with the 6809.
-
The 68000's equivalent of a direct page is, instead of 256 bytes from
address zero, the 64 kilobytes centered around address zero -- the highest
and lowest 32 kilobytes in address space.
While it has no specific direct page register comparable to the 6809's DP, to move that 64K of address space around with, it has 8 address registers, one of which might be used as an equivalent of the direct page register, and it has byte (8-bit) indexed address modes to improve code density and reduce clock cycle counts near a base address in any of those 8 registers.
The 68000 did not have memory indirection until the 68020, but, with all the address registers, that was usually not a problem. Similar to memory indirection on a direct page variable on the 6809, just load the pointer into a free address register, and then use that address to load the value pointed to and you're done. One extra instruction that usually didn't cost much in time or code space.
To illustrate, borrowing the examples above, of pointer math in the direct page on the 6809, and assuming A4 points to the local static allocation area and the variable pointed to is a long (32-bit) variable,
-
to achieve indirection on a statically allocated local pointer variable, instead of
MOVE.L [pointer(A4)],D0 ; load value at pointer
free an address register if necessary and use it to load the pointer first:
MOVE.L A0,-(A6) ; (not usually necessary)
MOVE.L pointer(A4),A0 ; get the pointer
MOVE.L (A0),D0 ; load through it
MOVE.L (A6)+,A0 ; (pop it back if it was pushed)
-
To get the address of a local static pointer at run-time
LEA pointer(A4),A0
MOVE.L A0,-(A7)
and
MOVE.L (A7)+,A0
The 68000 had a large set of data registers (accumulators), so math in general did not need a zero page. But it also had the full set of load effective address instructions and auto-increment auto-decrement addressing modes, like the 6809, so you didn't even need to use the data registers to do the address math. Still, you needed to take time to study the register set and instruction set, if you wanted to write good code.
-
to achieve indirection on a statically allocated local pointer variable, instead of
-
Motorola's plans for the future of the 68000 were made fairly clear by the
marketing team. They (or the vocal members of the sales team) considered the
68000 the future of the company. (Fortunately, that faction did not attempt
to push customers to use the 68000 where the 6805 or 6801 could obviously be
used -- most of the time.)
Anyway, it was always clear during the 1980s that Motorola intended to support and improve the 68000 long term. (That clarity disappeared, into the 1990s, but that is after the decisive events.)
-
OS-9/68000 was a bit more forgiving of non-relocatable code, with the
68000's larger address space, but the full features of the OS were still
limited to position independent code. So, writing for OS-9/68000 also meant
learning to write PIC.
-
One convenience of the larger address space of the 68000 was that there
would be more room to build a more complete emulation of the functionality
of Apple II software such as Integer BASIC. Other than that, accomplishing
this on OS-9/68000 would have issues similar to the issues on OS-9/6809.
- Likewise, automatic translation,
-
and hardware emulation. If you had mission-critical software to carry over
from the Apple II, you wanted to keep your Apple IIs, or you wanted an
emulation card.
-
Motorola had a memory management unit (MMU) for the 68000, called the 68451,
and it slowed the 68000 down a bit the same as the 6829 did the 6809. One
difference was that the 68000's addressing timing was a little more
flexible, so that a full memory cycle delay was not induced by the 68451.
Nonetheless, the 68451 was not a perfect MMU by any means. Semiconductor technology and the industry's understanding of the problems were not sufficient at the time.
This lack of technology is also seen in the 68000's design for interfacing with a memory management unit. Things did not quite fit, and the 68000 could not recover correctly under certain conditions when a new page of memory had to be called in from hard disk. These problems were fixed in the 68010 CPU, released publicly in 1982.
But, like OS-9/6809 , OS-9/68000 worked well without memory management or virtual memory, and it really wasn't a big problem.
The 68000 provided support for separating system mode from user mode, which was also improved in the 68010.
One improvement I think they missed on was failing to add 32-bit constant offsets to the the indexed addressing modes of the 68000, penalizing large module designs. This was addressed in the 68020, which, in my opinion, added way too much complexity.
Among other things, too many of the new instructions and addressing modes of the 68020 cost more in time and bytes of code than simply doing the same in existing 68000 code. (The execution time did improve significantly in the 68030.) Also, testing become significantly more difficult on the 68020 because of the complexity.
For some reason, Motorola refrained from pushing customers to move their designs to the 68010. I assume that was because they preferred the customers moving to the 68020, instead, when moving up.
All of that said, Jeff Raskin was known to be working on a text-based appliance computer around 1979. The 6809 was one of the options he was known to have considered. I would be surprised if he hadn't considered OS-9/6809 for the project, but I do not at present have proof.
That's the factual background.
With the factual background laid out, here's the short version of the daydream again
***** Alternate Reality, Short Version *****
If Raskin had induced Apple to produce an Apple-branded text-based appliance computer running OS-9/6809, they could have introduced the machine in late 1980 with minimal design effort and expense.
With that timing, the buggy Apple III of our reality could have been postponed
and redesigned as a bridge machine. Instead of a pair of 6502s, it could have
had a 6502 for Apple II emulation and a 6809 for business applications. Paired
with OS-9/6809, this would have provided a stable mini-computer class
offering.
The 6502 emulator might have done double duty as the system console for the
6809, especially if the video buffer in the emulator provided 80-column wide
text.
If the initial model did not have bank switching, an advanced model with bank switching could have been produced quickly, in 1981. This model would have supported a 2 MB memory map, giving more room for a larger video buffer.
They could have produced their own graphics environment/GUI, or, by 1983, they
could have delivered it with Microware's Multivue. None of this would have
required engineers to work 80+ hour weeks.
When OS-9/68000 pre-release became available to Apple, Apple might have
re-engineered the Lisa with OS-9/68000 underneath. Perhaps the re-engineering
would have been part of the Macintosh project, or, if Microware were working
with Apple early enough, the Lisa might have had OS-9/68000 as its original
foundation OS. The Toolbox would have been a collection of OS-9 modules.
With a shared technological base, the Lisa and the Macintosh would have shared most of their software architecture and the success of either would have supported the success of the other, the Lisa positioned as an office machine class computer and the Macintosh as a true personal computer at a price within reach of individuals.
A/UX would never have been necessary. Copland could have been NeXT, instead of a failed mess of marketing dreams.
IBM PC?
IBM would have had to re-think that launch. Even if they had ended up using the 8088, they wouldn't have dared launch it with PC-DOS. They'd have been motivated enough to overlook the miscommunications with Kildall, so maybe MP/M. Or maybe they could have gone to TSC and got a Uniflex/8086 -- that might have been achievable before year-end 1981. Or maybe they'd have been sensible enough to scrub the 8088 prototype and redo it with a 68000.
Or simply copy the OS-9/6809 gambit, get it out in August, and put their stamp of approval on Apple and Tandy. Or, more likely, set up two lines of PCs, one based on the 6809 and one on the 8088. And when OS-9/68000 came out, simply add another line based on the 68000.
At any rate, we'd have had a much more pluralistic market, relative to CPUs. Whether that would have improved the substance of the CPU wars or pushed the wars more toward pathological can't be seen from here, but we could hope:
Among other actual fixes to the 80x86 architecture, Intel might have been
motivated to stretch the segment register widths in the first iteration of the
8086 line, instead of just adding a DMA controller to the register-poor model
continued in the 80186. This might have allowed them to avoid most of the
detours of the 80286. (I think it's doubtful. They had the heritage of the
iAPX 432 to get over.)
Motorola, on the other hand, might have made a fully 16-bit 6809 capable of 24
or 32 bits of address. True segment registers? Or maybe just extending the
width of the index registers and the direct page register? (I'd lean toward
the latter, actually.) Hopefully, they'd have fixed the infelicities I've
mentioned above, and a few others related to system/user space separation,
that I haven't.
And maybe, just maybe, instead of over-designing the 68020, Motorola might
have taken the lessons of the 6809 and the nascent RISC designs to heart and
refrained from adding instructions and addressing modes that took more time
and more bits of code than simply doing the same thing with existing
instructions, and generally added to complexity more than utility. With a
simplified target run-time architecture, they could have brought a fully
tested, true 32-bit internal 680X0 to market much more quickly.
Commodore, of course, would have jumped on OS-9/6809, if they wouldn't have
been doing it alone.
And Tandy would have quit puttering around and focused on the Color Computer
line, and had a Color Computer 3 equivalent ready, probably with DMA and other
business-class features, when Microware released Multi-vue in 1983 or '84.
Who knows what would have become of Microsoft? We can suppose they would have built their company on Xenix. Microsoft BASIC running on Xenix? Heh. But, yes. We can guess that "Windows" would have remained a GUI paradigm, instead of becoming a captured trademark of Microsoft. Or maybe Bill Gates would have doubled down on "Windows", but at least it would have had Xenix underneath.
BSD/Research Unix would probably have remained the dominant OS in colleges.
Minix, Xinu, and such would still have been developed. But Minix probably would not have been written first for the 8088, since the 8088 would have been left behind much earlier.
Likewise, the GNU re-implementation of the Unix Workbench. With more solid
microprocessor technology to choose from and earlier implementation of the
core tools, the migration from LISP would not have been necessary on the one
hand, and, on the other hand, the vaporware kernel for Hurd might have seen
real implementation by the early 1990s.
Linus might still have made his own kernel, but probably not on the 80386. But
he might not have felt the need to, if the Gnu/Hurd OS were already there.
How's that for alternate reality?
(Yeah, I've been thinking about this for a while. Maybe too long. In fact, I'm
working on a novel based in something like this alternate reality, but a little different.)
No comments:
Post a Comment