Path: news.uiowa.edu!chi-news.cic.net!nntp.coast.net!bofh.mi.org!frankensun.altair.com!wlbr!news.cerf.net!nntp-server.caltech.edu!nathan
From: nathan@cco.caltech.edu (Nathan Mates)
Newsgroups: comp.sys.apple2
Subject: Font Manager 601 & Teach Bug [Was System 602]
Date: 22 Feb 1996 05:46:36 GMT
Organization: California Institute of Technology, Pasadena
Lines: 64
Message-ID: <4ggvvs$8cg@gap.cco.caltech.edu>
NNTP-Posting-Host: accord.cco.caltech.edu

Well, Jay Krell was complaining about a real fast way to get a lockup
out of Teach 6.0.1, unlike previous versions. So, I started tracing
stuff around, and found the bug. Here's a quick way to duplicate it:

Start Teach 6.0.1, type a few characters. (The exact characters
shouldn't matter, but while testing this, I used 'aaaa'). Select
'ChooseFont... from the Font menu. Click on the Plain checkbox. Boom.

   In tracing this, I found that the control handle at the Font Mgr's
DP for the plain checkbox was getting overwritten. [DP+$C4 was getting
FFFF dropped in it]. Some tracing to find out exactly why that FFFF
was being dropped across some perfectly valid bytes was done.

   It is only partly Teach 601's fault. It's mostly FontMgr
601's. According to the 601 update in the manuals, _DoModalWindow can
do background updates of windows if a particular bit is set for
them. Teach does that. No problem here. When updating the background
window, Teach subcontracts out to the TextEdit toolset to redraw the
window, which is a big TextEdit box. No problem here. As part of
redrawing the text, TextEdit sets the font before drawing each part of
the text. Seems innocent. But, in setting the font, DP+$C4 is blasted
by the _InstallWithStyle call.  [This is why if there's no text to be
displayed, DP+$C4 is never blasted since the font was never set to
anything]

   Thus, it is only because Teach 601 allows background updates of its
windows that this problem is exposed: the Font Manager is not
re-entrant in its use of DP+$C4 between the _ChooseFont and
_InstallWithStyle calls. In _ChooseFont, it's used for a control
handle. _InstallWithStyle uses it for some sorts of preferences byte,
possibly with GS/OS system prefs. It only references it 4 times as
part of its work, so it was the obvious candidate for changing.

   Without really being able to take apart the rest of the Font
Manager on short notice, I tried to pick another location for the
variable stored in DP+$C4 during _InstallWithStyle. A NiftyList search
seemed to indicate that DP+$FE was unused, and changing the references
didn't _SEEM TO BREAK_ things. Clicking on the checkboxes and changing
fonts worked fine. Being more cautious than normal, I'm going to wait
for confirmation from someone with a clue before releasing any patcher
programs.

   If you're the adventurous type, the load segment is of length
$2FC5, and the 4 $C4 bytes to change are at +16F8, +175F, +1782 and
+17A8. [A patcher program like GameHacker is perfect for patches of
this kind, written by yours truly :]

   Since this problem only occurs when programs take advantage of this
particular feature in System 6.0.1's _DoModalWindow, I'd suspect that
Teach 6.0.1 is about the only program that would be affected by it.
If DP $FE is a valid place to drop this byte [Comment on this, any
Apple types that still exist], I'll release a FixFont601B that fixes
this and the previous problem I found and patched in FixFongMgr601.

   Feel free to repost this (yeah, it's long by their standards) to
GEnie and other places where GS programmers tend to hang out.

Nathan Mates

-- 
<*> Nathan Mates http://www.ugcs.caltech.edu/~nathan/      <*>
# And he said to them, "To you has been given the secret of the
# Kingdom of God, but for those outside, everything comes in 
# parables" Mark 4:11, NRSV