NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/sys/apple2/25542

Text File | 1992-12-14 | 7.1 KB | 122 lines

Newsgroups: comp.sys.apple2
Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!ux1.cso.uiuc.edu!news.iastate.edu!news
From: [e-mail] (Harold Byron Bouma)
Subject: Re: The Apple II Now and Forever
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Iowa State University, Ames IA
References: <[e-mail]>
Date: Mon, 14 Dec 1992 18:46:36 GMT
Lines: 110

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: [e-mail]    |
| Macalester College, St. Paul, MN.    | and           [e-mail] |
 \  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!!  /