From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: 486 vs. Mac Benchmarks
Date: 20 Dec 92 16:33:28 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Dec8.073209.8262@cs.uoregon.edu>, tracer@majestix.cs.uoregon.edu (Roger M. Wilcox) writes:
> In article <6465.2b1cf767@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>>In article <2894@ulysse.enst.fr>, majid@blizzard.enst.fr (Fazal Majid) writes:
>>> 
>>> - if you're doing word processing, DTP, spreadsheets, then get a Mac, it's way
>>> ahead in terms of speed or ease of use over that bungled imitation, Windows
>>
>>Amen.
> 
> Oh yeah?
> Bunguled imitation, eh?!!

Yeah. Bungled.

> Windows has child windows, and child window callback procedures, supported
> right there in the operating environment's API.  

The Windows MDI interface is an ABOMINATION! It is awful. A simple user
interface study would have killed that off long ago....

> To the same thing on a Mac you need a toolkit like MacApp, which a lot 
> of people won't use due to its cost or bulkiness.

a) You wouldn't want to do MDI windows on a Mac
b) You wouldn't need MacApp to do it, even if you wanted to
c) MacApp isn't incredibly costly or bulky. ( You could also consider the
   cheaper/thinner cousin to MacApp -- the Think Class Library )

> Windows uses Dynamic Link Libraries to implement its API.  This means the
> system is not only user-expandable, the user-supplied library routines can
> be called BY NAME AT RUN-TIME.  

I agree. This is a good feature of Windows. (Of course, it has nothing to
do with the user interface)

> MacOS only has traps for its OS functions,
> which means it's using the same mechanism for invoking system services as
> YOUR arch-enemy, MS-DOS, which also uses program-invoked Interrupts.

The MacOS does have several built-in mechanisms to provide for developer
APIs. (INIT management, the CTB, QuickTime's component manager, and 
AppleEvents come to mind) Plus, you can achieve run-time installation using
Dinker or SLM, both of which are available recently.

> As of version 3.0's standard mode, Windows provides hardware-level memory
> protection.  MacOS, which always runs in Supervisor mode, didn't provide
> any kind of memory protection prior to System 7.  (Some Mac people have
> informed me that System 7 does catch 95% of invalid address accesses --
> although I don't know if it catches invalid jump addresses -- but I have no
> idea how it allegedly does this.)  Windows also was first with full-blown
> demand-paged virtual memory (version 3.0's 386 enhanced mode uses this).

Memory protection would be a nice thing for System 7. The real solution,
however, is to have applications that don't crash, which would obviate the
need for memory protection entirely.

As for virtual memory, System 7 has this. As for Windows being "first", I
think there are a few people at Burroughs and IBM that would disagree with
that assertion.

> Windows supports up to three buttons on the mouse.  

As we have discussed at great length in another thread, multiple mouse
buttons is a liability, not a feature. A single button design is better.

Nonetheless, you can purchase multiple-button mice for the Macintosh.

> Whether you believe that
> having more than one mouse button is a Good Thing or not, the fact remains
> that you couldn't tell MacOS to give you right-button or third-button
> MouseDown or MouseUp events if your life depended on it.

I don't see that it matters, since any more than one mouse button on the
Mac is superfluous, anyway.

> The Mac has, at most, fifteen different kinds of event messages.  Windows
> has several HUNDRED.  

a) while 15 different types are defined in an event mask, there are actually
more when you consider System 7 an the passing of high-level events. By
using high-level events, applications could have dozens of different event
types, each of which could convey thousands of meanings. (See the Object
Support Library, and the Apple Event Suite)

b) The number of event messages is immaterial. If the Mac can convey in a
dozen event kinds the same content that Windows requires hundreds, that
would appear to be a plus.

> You can ignore these messages if you desire, or use
> them to give you excrutiatingly accurate details of what is happening to
> one window of your application or to your application as a whole.

As you can on the Mac.

> The Mac puts one menu bar across the top of your screen.  At first glance,
> it is difficult to tell which of your applications this bar belongs to.

Not at all. 

> (That tiny, sub-icon-sized application picture in the upper-right corner is
> NOT that immediately obvious.)  

Sorry.

> Windows applications have their menu bars
> in their respective Main Windows, thereby instantly associating them with
> the application they belong to.

Yes, and this makes the menus physically tiny in mouse dimensions, making
menu selections a much more difficult task. The Mac, on the other hand, has
an infinitely tall menu bar, which is very easy to hit.

> And before you go yelling that Windows resources are read-only (which, yes,
> they are), I should point out that Apple itself has decried "The Mac
> resource manager is not a DBMS" -- and almost every time you write something
> to a resource, you would probably be better off writing it to a real DBMS
> anyway.

Not at all. The resource manager has many uses for keeping track of bits of
related information in the same file. The cautions in the technical note about
the resource manager not being a DBMS is exactly that -- a note that the
resource manager has strict limitations, and using it to store wads of
data within a single file is probably ill-conceived. 

>>And that's what the majority of computer users are doing.
> 
> Yes, they're using Windows.  I'm glad you agree.  

I'll agree that a lot of people are buying Windows. And it certainly is
easier than using DOS.

Compared with the Mac, though, Windows is a bungled imitation.

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.