Path: utzoo!attcan!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!uwvax!umn-d-ub!umn-cs!berlin!sec
From: sec@berlin.acss.umn.edu (Stephen E. Collins)
Newsgroups: comp.sys.mac
Subject: Re: multitasking and IPC
Message-ID: <264@berlin.acss.umn.edu>
Date: 18 Dec 88 05:34:42 GMT
References: <1988Dec16.191309.21623@cs.rochester.edu> <326@internal.Apple.COM>
Organization: U of M MicroGroup, Minneapolis
Lines: 57

In article <326@internal.Apple.COM>, goldman@Apple.COM (Phil Goldman) writes:
> In article <1988Dec16.191309.21623@cs.rochester.edu> miller@ACORN.CS.ROCHESTER.EDU writes:
> >    In article <1988Dec14.223739.16280@cs.rochester.edu> @DOUGHNUT.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU writes:
> The only reason you cannot switch out of the Finder during file copy is
> that the Finder runs in such a small partition that it swaps out its event
> handling segment during the copy and thus cannot be switched. 

Is that a bug or a feature?

> > o I've also noticed that tasks that put up dialog boxes also inhibit my
> >switching tasks from multifinder. Lose, lose. This may be a side effect of
> 
> No.  This is *strictly* a user interface decision.  Modal dialogs are put
> up by the application when it demands the users attention.  Therefore,
> it does not make sense to allow the user to switch, just as he cannot
> do anything else to the machine except respond to the modal dialog.  If
> the app's need is not that pressing it should put up a modeless dialog, or
> use the notification manager.  The point is, that it *is* the application
> writer's decision, not the OS's.  The OS provides the mechanism only, not
> the policy.

If this is the case, then any application that might ever be run under
Multifinder should never make use of a Modal Dialog (so just burn 'em
out of the ROMS).  While an application may frequently require the
user's attention before IT can continue, the system, in a MF environment,
should ALWAYS be able to continue without requiring the user to
attend to ANY individual application, no matter what state that
application may be in.  You are still thinking in terms of single-tasking.
 
> I think that everything you say has merit in most computing environments.
> However, the Mac w/ MF is an entirely different beast.  It has two very large
> differences from other systems:  it must remain compatible with software
> (including the ROM!) designed for a single-tasking machine, and it is driven
> by a user interface designed for hiding the innards of the machine
> completely beneath the desktop metaphor.

I've been working on computers for some 15 years, and I can't think of
a single system (nor application, for that matter) that didn't have
the problem of remaining compatible with previous versions; and that
includes many single-tasking vs multitasking evolutions.
 
Furthermore, the Mac user interface is not "entirely different".
(ever hear of a company called Xerox?).  SUN, HP, and Microsoft
come to mind immediately; I'm sure there are others.

The problems faced in the evolution of the Mac are not unique to the
world of computing.  Those at Apple may like to think they are going
where no man has gone before, but they would do well to examine and
learn from the experiences of others.

+-----------------------------------------------------------------------+
| Stephen E. Collins                             | sec@ux.acss.umn.edu /
| ACSS Microcomputer & Workstation Systems Group | sec@UMNACVX.BITNET /
| 125 Shepherd Labs                  +-----------+-------------------/
| University of Minnesota            | Cum hanc intellegas, Latinam /
| Minneapolis, MN  55455             | sententiolam potes legere!  /
+------------------------------------+----------------------------+