From: hal@budapest.math.macalstr.edu (Harold Byron Bouma)
Subject: Re: The Apple II Now and Forever
Organization: Iowa State University, Ames IA
Date: Mon, 14 Dec 1992 18:46:36 GMT

Jay M. Krell writes
  
> As far as I know, the Mac design was totally devoid of forthought on
> "multitasking", backgrounding, application-switching, etc. Much published
> material indicates MultiFinder is quite a hack. There is now (well after the
> fact) some design to it. There is a Process Manager and apps should do 
> certain things to be compatible.

	I'm not saying that "Gee, these toolboxes planned to have these  
features one day, but they made it really hard to do it anyways." What I am  
saying is that when you write code, you should make it more prepared for the  
idea that one day your code might be asked to do something that you had not  
planned, and thus make it a bit more flexible. The fact that it was not well  
thought out showed that stuff like getting Multifinder for the Mac was very  
difficult to do, and the solution was not very pretty.
 
> The IIGS has a call SetSwitch, intended to post "switch" events to 
> applications about to switched in/out. This is an obvious consideration of 
> multitasking, or at least program switching ahead of time. The call remains 
> unimplemented and the docs do not say how to respond to switch events.
>  
> Time/budget constraints are not usually the creation of companies; they are 
> the creation of the marketplace. Unless, of course, you believe Apple 
> tightend the budget and rushed to market the IIGS in an effort to hurt it as 
> it was being developed. The Mac was also developed under great time 
> contraints. There are stories (publisted) of the crunch to finish the 
> software and how many hours people like Atkinson and Hertzfeld were putting 
> in.

	I really doubt given Apple's strength in the consumer market at the  
time, that getting the mac out in Januray 1984 would have really mattered much.  
The Mac Plus two years later was dubbed "the first real mac" because it finally  
had adequate hardware to run the operating system, and it took until 1988-1989  
before the Mac sales really began to take off. Apple was pushing the Mac, just  
like it had pushed the Apple III and Lisa, so that was internal pressure to get  
it out more than the marketplace need for it. The GUI of the Mac was so far  
advanced that I doubt that had it taken a year longer that it wouldn't have  
mattered much at the time. In fact, I would have rather seen that time working  
on getting the Mac's OS done right and had concentrated on selling the Apple II  
more. Instead they throw out a machine that had a kludgy (albeit revolutionary)  
OS, a machine that wasn't powerful enough to run it, and sapped R&D from the  
Apple II to support the Macintosh.

	Using one product line isn't bad to pay for another just as long as it  
doesn't hurt those who are using them. However, I feel that Apple just took  
from the Apple II and gave to the Mac, which has alienated a lot of its  
customers. Apple's wonderful bridge during 1986 between its two lines was very  
lopsided. Its new Apple File Exchange program only had IBM file translators and  
completly lacked any Appleworks translators, which was by far the most popular  
program in Apple history. Its this kind of neglect that I am talking about. (I  
also think that) Apple also pushed to get the GS out to help pay the bills for  
the Mac. (so that) That was another internal pressure source to get a machine  
out.

> >        However, it is known that there were some decisions that were made
> >while the toolbox was being written that has created some problems. Some of
> >the long term effects of certain decisions were not know about, such as not
> >making the toolbox calls re-enterant. If they were re-enterant, this would
> >have made making a Multifinder much easier. But these concepts were not well
> >known at the time, so I can understand that.
>  
> Do you really think programmers at Apple didn't realize a non-reentrant 
> System makes multitasking difficult? _Maybe_ they sacrificed multi-tasking 
> for speed (well, speed is probably hurt w/o multitasking), development 
> time/effort, price, and maybe they didn't think the IIGS needed multitasking.
> I'm pretty sure the Mac toolbox also isn't reentrant. I doubt Windows is
> reentrant. Multitasking (not true multitasking, but something convincing 
> enough to users) does not require reentrancy.

	Look, my first point was that given the current status of the toolbox  
it has made stuff like Multifinder GS hard to do. Dave Lyons has often stated  
that to make a Multifinder GS would reqire a re-enterent toolbox, which is why  
I had used this example. Dave has written more system software than you have,  
so I trust his judgement over yours about the need for having re-enterant calls  
for this to work. Maybe it might work without it, but I do not know.

	Dave also has said that _perhaps_ stuff like making quickdraw not be  
hardcoded was considered, but given the time/budget constraints of the  
projects, it was probably dismissed. Ideas get thrown around while these things  
are being created. Maybe ideas such as multitasking came up, and maybe they  
didn't. However, my point is that there _were_ shortcuts done. Hardcoding for a  
given machine in a toolbox call is not the most advocated act. It makes  
upgradability difficult and inhibits porting to new machines, all of which the  
toolbox is supposed to improve upon. The most common reason for it is haste,  
and as already mentioned earlier, there was this urgency. Even Matt said that a  
lot of work needed to be done to get the GS to where it is today (the 500  
engineers comment comes to mind) and this pressure came from inside Apple to  
get something out when the GS was shipped (IMO).


>  
> >Quickdraw hardcoded to hardware and resolution
>  
> Quickdraw is slow enough as is. It would be even worse if it were written 
> more generally to support other video. Then again, other video could include 
> a graphics coprocessor to allevate the 65816 graphics tasks.
>  

	If done well, code that is more flexible for different video output  
devices does not have to have a major slowdown. It could be like a termcap  
entry, that you read upon startup and it would fix the constants into memory.  
like vmax, hmax, pixeldepth, etc. it would make the code a bit bigger, but  
nothing too extraggavant. Other tool calls such as vRAMstart and such could be  
also given for those who wish to bypass QuickDraw. Its 

| Hal Bouma                            | Send mail to: HBouma@Macalstr.edu    |
| Macalester College, St. Paul, MN.    | and           HBouma@Macalstr.Bitnet |
 \  Things that make you go Hmmm:  System 6, GNO, DreamGrafix, SoundMeister  /
  \  Coming sometime this decade for the //GS : NBA! (GNO compatible too!)  /
   \  Drop by and say hi to us anytime on the #AppleIIGS channel on IRC!!  /
Newsgroups: comp.sys.apple2