4 ms·
I don't think that was the fundamental issue. It was one of mindset. Xerox tried to sell to their existing customers, with the same sales structure and pricin
by FullyFunctional 4y ago
I don't think that was the fundamental issue. It was one of mindset. Xerox tried to sell to their existing customers, with the same sales structure and pricing they were used to. They simply weren't structurally set up to deal with mass-market consumers. The Macintosh team targeted a completely different set customers, with a less ambitious and much cheaper product.
The IBM story is a bit of an outlier, but Microsoft saw the same potential Apple did.
- TheOtherHobbes 4y agoI think it was both. No one in Xerox management understood that they could grow a new market - possibly with loss leader hardware sales - instead of trying to farm their existing market. So the Alto was never properly productised. It was essentially a boutique product at a big-mini price. That made it competitive with DEC and IBM minis, but not with budget the $10k S100 systems that were just about - barely - powerful enough for a small business. To be fair to Xerox, six figure systems weren't unusual for business customers at that time. Which could be why the company never understood that it had the key to popular budget semi- and non-pro commodity computing. DEC died for much the same reason. DEC management were used to selling to fellow nerds and business people, and couldn't imagine super-affordable commodity products. MS, Apple, and the IBM clone makers saw the new market for what it was. So did some of the new software houses. IBM itself almost did, but couldn't quite shake its monopoly-oriented culture. So MS and the clones killed it in the commodity space.
- ncmncm 4y agoThe Alto was super-slow, even by standards of the time. It had a very, very limited CPU running an emulation of a more powerful ISA that app code was compiled to. Things we expect to have dedicated hardware for -- network interface, display screen painter, disk interface, laser printer driver -- were just interrupt routines all on the one CPU. Programs competed for CPU time with feeding pixels out to the CRT-scanning electron beam, and with bits moving directly to and from disk-head R/W coils. It did switch between those tasks pretty quickly, not like most machines then or today: there was no foolishness about saving and restoring registers. Each interrupt task was assigned a couple of registers permanently, including its own program counter, so an interrupt only ever just flipped which program counter was in charge. The app-level instruction interpreter got to use what few registers remained. So, on an interrupt, it would execute a half-dozen instructions to move one machine word, and yield. There were 16 PCs that ran in strict priority order, with the user-program instruction interpreter last in line. Each "yield" put the current PC back to the entry point for the next word to be processed, and the next live lower-priority PC determined the instruction to run next. The OS was just one of those user programs. It resembled the I/O processor on CDC mainframes of the time. It just ran the programs, too, not only the I/O. But it really is amazing what they got it to do. Later machines e.g. Dorado and Dolphin had more stuff done in hardware so could be faster.