Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: Multitasking
Message-ID: <14840@smoke.brl.mil>
Date: 13 Jan 91 03:02:03 GMT
References: <1991Jan12.050921.1002@clark.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 42

In article <1991Jan12.050921.1002@clark.edu> johns@pro-library.cts.com (System Administrator) writes:
>With all the talk of multitasking going on, is it going to become a reality
>on the GS?  Please, please, say it is so.

I haven't heard even a rumor of Apple working on it.  If outside parties
were to produce a good multitasking environment for the IIGS, which I
think is technically feasible (a few hobbyists have been working on it),
for it to attain any degree of commercial acceptance it would have to
permit most IIGS applications that follow current Apple programming
guidelines to work adequately under the multitasking system.  (Of course,
many existing applications access the "bare metal" in ways that are
likely to interfere with any multitasking coordinator.  Even many NDAs,
which are supposed to take this into account, interfere with some "main"
applications; anybody remember SytleWare's DeskPak?  Will it ever be
overhauled to work right with current GS/OS?)

There was one such multitasking implementation posted to some computer
information services, in a preliminary ("alpha test") form.  I tried it
and was amazed to find that it actually worked, sort of, although it
wasn't sufficiently robust at that point to use for more than a demo.

Note also that there have been a few Apple II emulations posted for use
on (non-Apple) UNIX-based systems.  Except for the slowdown caused by
emulation, clearly in theory any sort of operating system could be
implemented as an emulation of the desired behavior.  However, for this
to be practical on the IIGS, native code execution would have to be used
for the bulk of an application, or in other words the multitasking OS
would kick in only at the points where applications make toolbox or
GS/OS system service requests.  (That's how the demo I mentioned works.)
There are several ways in which the tools and GS/OS could have been
designed differently to facilitate such an approach, but we don't have
the luxury of changing their interfaces now.

My own IIGS system support projects for the near term are limited to
making the ORCA/APW and GS/OS environments more nearly UNIX-like, so far
as applications are concerned, to facilitate porting applications that
were developed for UNIX systems.  After that I would probably concentrate
on cooperative multitasking systems, for example a NewSqueak interpreter.
Such a system would support effective concurrency and intercommunication
among the concurrent processes, but only if they were written and
"compiled" specifically for such a target environment; existing IIGS
applications would not be able to participate.