Subject: [OT] Apple vs. MSFT OS technology (was Re: MacOS X 10.1)
From: Joe Buczek (joe_buczek@yahoo.com)
Date: Fri Nov 09 2001 - 14:18:47 MST
--- Michael Giffin <Michael.Giffin@Colorado.EDU>
wrote:
[ snip ]
> nnow, i have a question for Joe B:
> i know little about Apple's systems pre-OSX, but was
> Apple's stuff at
> such a competitive disadvantage against M$, given
> that the latter was
> really DOS? my understanding was that Apple's main
> failure was in
> marketing. Windows2000 is the only operating sys
> from M$ i would
> use, especially if i never had to fix it when it
> breaks, yet they
> dominated the world on on lousy GUIs slapped onto a
> weak and ancient
> system. but i imagine i do not fully understand the
> situation.
>
> i am interested in hearing Joe's and other's
> comments.
"Apple's main failure..." Geez that's tough because
there were so MANY!! And I can say this with 20-20
hindsight, having been there:
1. inferior underlying system (no memory protection,
no scheduler, "Patch City")
2. diarrheal ASIC engineers and management that was
too f***ing STUPID to realize that a common h/w API
would benefit both the h/w development cost and
software development costs and capabilities
3. inept management at the highest levels
Now a few expansions of the above:
1. The fact that MacOS had no memory protection was
the key reason it was held up as being unreliable by
critics. It was a fair criticism, especially after the
68030 machines were introduced, all of which had
onboard MMU's which were largely only ever used to fix
holes in the physical address space (see item #2).
But this has other implications that affect more than
reliability. An MMU can be used to make execution more
efficient because the system doesn't need mechanisms
to either relocate instructions or make up for the
lack of relocation. An example of leveraging the MMU
for this purpose would be shared libraries. Now,
eventually, Apple did implement this technology,
mostly due to the changes that were required to
support the PPC (there's a real microkernal under the
hood, and this help make it possible to acutally use
the MMU).
Also in this category, more about management than
engineering, is the topic of "emulation". For years,
and EVEN NOW, large parts of Apple's system software
are 680x0 assembly language!! Sure, there would have
been a cost associated with converting all this to 'C'
when PPC came along, but stupid, chintzy management
allowed this to linger on forever. The result was
crappy performance. The original claims of PPC
performance over X86 were never realized, not because
the processor was inferior, but because a ton of MacOS
code was being EMULATED!! The emulator was a beautiful
work of art. The guy who wrote it is a friend of mine
and is a genius. This is not a dig at his work, but at
the lousy decision on Apple's part to IGNORE the need
to get all the system components to run NATIVE PPC and
not be emulated. The loser was the Macintosh User
because of the loss of performance.
Today's MacOS is a mish-mash of native and emulated
code. And developers have had to fart around,
supporting both emulated and native processing models
(viz a viz, the "FAT binary"). What a waste of effort.
Oh, and did I mention all the work needed to support
low-level debugging in an emulated world? How many
developers pulled their hair out until Macsbug was
finally up to this task? Sigh.
2. While Apple was pissing away time and money,
creating a new and incompatible set of ASICs for every
machine they ever made, the PC world standardized on
the system hardware API. A small, unheard of company
called Chips And Technologies took the PC system
interfaces and put them on one ASIC. The whole
industry adoped this, and MSFT started holding annual
conferences to drive the strategy of the hardware API.
Note that MSFT didn't have to flail around changing
Windoze each time Dell, Compaq, Gateway, IBM, HP and
others introduced new hardware. But guess what? Apple
OS Engineers had to jump through hoops every time a
new Mac was introduced because the f***ing system
ASICs were all different!!!! So much for the
"advantage" of Apple being both hardware and software
under one roof. And, guess what? Because so much
bandwidth of the Software engineers was wasted on this
stupid crap, REAL DEVELOPMENT took a second seat. Go
back and take a look at the System 7 time frame, and
how long it slipped. Then look at how many new
machines were introduced around then. The marketing
idiot, Sculley, thought "more is better", and that
started an avalanche of Mac models, many of which were
obsoleted withing 6 MONTHS(!!) of their release. All
this caused software to slip and slip.
If Apple had had the presence of mind to simply look
at the PC h/w world and take advantage of a frozen (or
very stiff) hardware API for Macs, instead of allowing
the ASIC engineers to "play in the sand", it would
have enabled Apple software development to make actual
developmental progress much sooner than the late
1990's, which is when some of the underlying system
architecture problems were finally tackled. Its no
coincidence, IMO, that this period coincided with a
serios downturn in Apple's budget, which put some
serious brakes on the number of new Mac models, and
hence, the number of new ASICs that had to be
supported.
If Apple functioned as a "systems company" and not a
"hardware company", the advantage of standardizing the
hardware API would have been exploited. Did I mention
the cost of not doing this? Whenever Apple launched a
new line of Macs, they would almost always have a
"low, medium, high end" set of machines. Sometimes,
these used different ASICs. Guess what it costs to
ramp up ASIC production for a hundred thousand or so
machines? A couple hundred thousand bucks, when you
count the NRE and the multiple turns of the parts
before they are shippable. Guess what happened to all
these CUSTOM PARTS when marketing was wrong about
which models would be bought? That's right: THEY WERE
THROWN AWAY!!! If they had a common hardware API,
those parts could have been moved over to the
production line for the machines that were actually
SELLING!!! There were countless times when Apple had
shortages of either high-end or low-end machines,
precisely because there weren't enough ASICs to build
them.
This was one of the most profound, if not THE most
profound, failures of Apple's management IMO. It
screwed software by forcing it to jump through hoops
that didn't benefit the users one way or another. It
screwed customers who wanted machines they couldn't
get because of ASIC shortages. And it screwed Apple
stockholders, who got to eat the mistakes of the
marketing idiots who NEVER CAUGHT ON than people only
want top of the line or totally cheap machines and not
much in the middle! What a waste of time, money,
effort and opportunity!
3. Books have been written about the ineptitude of
Apple's management. The thing that cheezes me off
most, though, is the LOST OPPORTUNITY related to
bungling management. What might MacOS have been if so
much effort wasn't wasted on stupid ASIC support? What
usable features, other than "sound input", did Mac
users get out of all that waste, after the MacII time
frame? What? Onboard video? Sheesh.
But another MAJOR mangement ineptitude was Apple's
wholesale abandonment of development tool technology.
Since you made the mistake of asking my opinion, I
will tell you that it is THIS, more than any of the
other things I've ranted about here, that caused Apple
to fall behind MSFT. Yep. Tools. When I started
working on MacOS at Apple, it was 1987. MPW was the
development environment. For those who don't know, MPW
is a Mac-ified unix command line interface. This is
the same environment that Apple suggested its own
developers use. The year was 1987. Guess what? The
only technology Apple sold on top of this was MacApp,
which was an Object Pascal (and later C++) application
framework. There was no graphical debugger, only a
command line debugger. And then Apple killed MacApp.
THINK C was the development tool of choice, then
later, Metroworks Codewarrior. Somewhere in there,
there was a failed attempt at Apple working with
Symantec to create an O-O IDE to replace MacApp and
MPW, but the project got screwed up and was canned.
Meanwhile, MSFT was spending $5M a year on Visual C
development. During the late 80's and early 90's Apple
cut the Development Tools Group from about 30 down to
about 5 staff!! Barely enough to support Macsbug
changes needed by new hardware (and new ASICs!!!).
Yes, Windoze was a pile of crap implemented on top of
DOS. But the MSFT Foundation Class Library (MFC)
allowed MSFT to change the developer API to the sytem
without needing to rev the actual system software.
They could experiment with system technology advances
by putting them into the MFC. For example, initially,
Win 3.0 didn't have an equivalent to MacOS "Standard
File". But there was a mechanism built into MFC that
hid this deficiency. Later, this was integrated into
their system and removed from MFC. Apple, meanwhile,
was shipping MPW, not shipping MacApp, and counting on
external tool developers to support MacOS. Not much
happened. Big surprise. Microsoft INVESTED BIG in
tools so that its platform (and its inherent
deficiencies) could overcome Apple (and its inherent
advantages - ease of use and good integration of h/w
and s/w). They "enabled" developers with their tools.
You know what Guy Kawasaki's pitch was to software
developers when he was trying to get them to develop
for Macintosh? Yep, that's right: that the system
provided all this power and the developer didn't have
to write it. So there's just another example of MSFT
coopting Apple's approach, but actually executing and
getting it done instead of losing focus and wimping
out on investment in the platform.
I'm going to stop here because I don't have any more
time to spare to write about this. These are just the
high bits.
Maybe more some other time. Gotta get back to work
now!!
--Joe
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
This archive was generated by hypermail 2a24 : Fri Nov 09 2001 - 14:30:41 MST