Re: wolf 3d-- bug? -- the culprit?

[nathan@visi.com (Nathan Mates)]

In article <34EFD9BB.9076ABB7@swbell.net>,
Rubywand  <rubywand@swbell.net> wrote:
>>    As I've said many times, this problem is exposed by apps doing some
>> things. Hierarchic is *not* an app. Thus, this bug cannot apply to
>> it.

>     Hierarchic does not have to be an application (no one said it is)
>in order to modify a toolset pointer. My idea is that, once anything
>modifies a toolset pointer, any later attempt to modify that toolset's
>pointer could produce problems if the later mod assumes that the
>toolset's pointer has not been modified.

   Incorrect in so many ways that it simply exposes your blatant
ignorance of the *rules* of GS progamming and toolset pointers. Go
read http://www.visi.com/~nathan/a2/tn/iigs/101.html and while you're
at it, actually *program* something using said techniques so that you
actually understand them. The rules are DIFFERENT between an app and
an init. That's the official word from Apple. Your blind ignorance in
repeatedly commenting on it shows that you lack the programming
knowledge to begin to comment on it. Because inits go thru special
code to set the default TSPtr, they are NOT affected by the bug.

   That technote specifically further says that "On exit, when you
call TLShutDown your patch will be automatically removed." That is
what the OS is doing after Wolfy, problem is, it wields a chainsaw to
remove the patch when a quick surgical slice will do the same.  The OS
figures that any toolset that has been patched must be removed from
RAM *without* flagging internally that the toolset is no longer in ram.
You quit back to the Finder, parts of the finder get loaded over that
toolset. It calls the "toolset" it thinks is in ram, *boom*.

>     So far, there have been no facts, just claims. Earlier you said
>that you could prove, with code, that a bug exists in the OS which
>explains the Wolf-3D crashes. Okay; list the code and explain the bug.

   Explanation: see above. List the code is trivial... from a ROM 3,
go to bank $FE, start disassembling from $0342. That is the beginning
of the ROM code for _TLShutdown. Near $AFD is the part where it
compares the current TSPtr for each toolset to the default, and if
it's changed, it goes to $B23 where it dumps it out of RAM. Parallel
code for the ROM 01 is roughly +$1D4 into the size-$57FE block of TS2.

   That is more than enough information for any sufficiently clued GS
programmer (whom you seem hell-bent on flaming all of them despite
giving of their own free time to both develop games like wolfy and fix
OS bugs) to come to the same conclusion that it is the OS is
incorrectly disposing of toolsets from RAM and trying to call them
later when they are not present in RAM.

Nathan Mates

--
<*> Nathan Mates http://www.visi.com/~nathan/      <*>
# What are the facts? Again and again and again-- what are the _facts_?
# Shun wishful thinking, avoid opinion, care not what the neighbors
# think-- what are the facts, and to how many decimal places? -R.A. Heinlein