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

Internet Message Format | 1992-12-14 | 3.7 KB

Path: sparky!uunet!stanford.edu!apple!dlyons
From: [e-mail] (David A Lyons)
Newsgroups: comp.sys.apple2
Subject: Re: The Apple II Now and Forever
Message-ID: <[e-mail]>
Date: 15 Dec 92 01:46:24 GMT
References: <[e-mail]> <[e-mail]>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 73

In article <[e-mail]> [e-mail] (Harold Byron Bouma) writes:
>[...]
>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.

I was not around for the initial design, but I can safely say four
things:

  --GS System Software folks have always been aware of the concept of
    reentrancy.

  --The system was never intended to be fully reentrant (a few parts
    are, but the toolbox is not reentrant in general, and GS/OS is
    not reentrant at all).

  --"MultiFinder"-style multitasking is cooperative, not preemptive,
    and therefore does not require the system software to be reentrant
    (Macintosh system software is not generally reentrant, either).

  --Reentrant system software is considerably harder to design, implement,
    test, debug, maintain, and extend.  This is an understatement.


>Other limitations however, such as the hard-coded QuickDraw II is a better
>example. Last year, there was quite a bit of discussion about having
>better resolution supported by QuickDraw II. One article that Dave Lyons
>wrote was that there were some constraints that had to be done for time/
>space/budget reasons. And some assumptions about the hardware were made
>to meet these requirements. And as Dave said, to fix these would make a
>lot of current software not able to run anymore. [...]

There are three interesting topics here:

Genericness of QuickDraw II

  QD supports 2- and 4-bit deep pixel maps only.  It could have been
  written to support arbitrarily deep pixel maps (or 1, 2, 4, 8, 16,
  and 32), but it would be way slower, so the current 2- and 4-bit
  code would still have to exist for performance, as would the special
  code for rectangular regions and 160-byte-wide pixel maps that gives
  you the level of performance you get today (ROM 3+ or System 5.0+).

System Software peeking through the QD encapsulation of graphics

  There are places where the system software "knows" things that would
  be cleaner if only QuickDraw knew about them.  This includes the Menu
  Manager slamming the pixel images of menus onto the screen itself, and
  restoring what was underneath itself. -- The Menu Mgr "knows" that the
  screen is only 200 pixels tall and 160 bytes wide.  A few other parts
  of the system "know" similar things.

Third-party software accessing hardware directly

  This is the big one.  For whatever reasons, tons of 3rd-party software
  accesses the screen hardware directly.  (A popular reason is that QD
  wasn't fast enough for their purposes, of course.)

  Even if you get past toolbox application-interface issues and fix the
  system software to always use QuickDraw instead of knowing things about
  the screen, careless 3rd-party software compatibility is a big problem
  if you're trying to do a larger-than-standard screen, or an other-than-
  2-or-4-bit-deep screen.

--
David A. Lyons, Apple Computer, Inc.      |   DAL Systems
Apple II System Software Engineer         |   P.O. Box 875
Internet:[e-mail]                 |   Cupertino, CA 95015-0875

My opinions are my own, not Apple's.