Subject: Re: [OT] Apple vs. MSFT OS technology (was Re: MacOS X 10.1)
From: ../randydog (yellowdog@randys.org)
Date: Fri Nov 09 2001 - 15:21:51 MST
[OT] != ok to talk of topic
On Friday, November 9, 2001, at 01:18 PM, Joe Buczek wrote:
> --- 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
>
- r a n d y : s e s s e r
d e s i g n : s t u d e n t
: c s u c h i c o
This archive was generated by hypermail 2a24 : Fri Nov 09 2001 - 15:33:38 MST