Re: Rubywand's new award! Plus, a few Questions

[Rubywand <rubywand@swbell.net>]

Nathan Mates writes ...
> 
> In article <34F485E8.BE297A0C@swbell.net>,
> Rubywand  <rubywand@swbell.net> wrote:
> 
>    Look, Mr. Admitted Pirate


     What!!!

     Nathan Mates has called me a Pirate! (Hey, Sandy, LJ, are you guys
reading this? I made it! Nathan says I can be a Pirate, too!!)

    "Admitted Pirate"? Does that mean "Admitted to real Piratehood"? Or,
maybe it's for when I was talking about downloading Wavy Navy from
Asimov. An "Admitted Pirate" is better than a plain Pirate, right?!

     Wow! This is just like in Monkey Island II, except my Real Pirate's
Badge came from the monkey!!!




> will you ever learn to SHUT UP about
> bullshit GS programming practices

     That's not a very nice way to talk to a freshly crowned Pirate.


> which have been shot down many times
> this week?

     No fair! Tripping over mutilated, sliced-up half-wits is not the
same as being shot down.


> At least you could read what's been mentioned several times
> this week and learn you're REALLY in the wrong, versus blabbing your
> mouth off for everyone to see. Such uncalled-for abuse about wrong
> programming advice is why csa2 has become such a wasteland for actual
> programmers who care about the truth

    "Truth"? You should not use words unless you know what they mean.


>, and about the facts.

     You mean like a game that causes machines running the standard OS--
the one all those other programs run on with no problem-- does not have
a BUG? Perhaps it has escaped your notice that there is _no_ popular,
installed OS under which the particular game will run without bombing
some user systems.



> Why does
> the general public permit these idiots to feel welcome in their midst
> if all they're here for is to try and destroy the future of GS
> programs?

     Hard to say. Maybe some users want their software to work
correctly. Maybe a few are grateful when bugs are exposed before they
ripped up their systems.


     By the way, as you may recall, we worried about, identified, and
discussed the bug for roughly a week on the world's largest Apple II
newsgroup without getting a word of feedback from the creator.

     At the time, this caused some bad feelings because practically
everyone assumned that, of course, after posting the announcement on
csa2 and releasing the game, the author word be monitoring csa2 for user
responses.

     As it turns out, the bad feelings may have been misplaced. The
author took the time to tell me that he was not reading csa2 during that
time and was unaware of the bug discussions. You however were. Why did
not you or Henrik, or Geoff, or one of his other true-blue Delphi pals
tell him what was going on?


> 
> >     Granted, Apple did not slap a big yellow "Pelegro" sticker on the
> >ToolBox Reference page describing SetTSPtr; but, they might as well
> >have. It is amply clear that SetTSPtr is not intended to be CALLed from
> >an application and that doing so is risky. To quote:
> 
> >>>Note: This call is normally used only if you are writing your own tool
> >>>set. See Appendix A, "Writing Your Own Tool Set," for more information.
> 
>    "Normally" does not mean *always*, except in the pirating idiot's
> guide to English, I suppose. Also, were you a *real* GS programmer
> with 2 brain cells to fire off occasionally,

     Granted, the above description aptly describes some (not all) of
those "*real* GS programmers" who have tried to tell us that a bug is
not a bug. I guess "2 brain cells" makes it kind of tricky debating with
'half your brain tied behind your back', doesn't it?



> ....
> GS technotes are more recent and supercede what's written in toolbox
> ref manuals.
> .... 
> --- snip
> PATCHING THE TOOLBOX FROM AN APPLICATION
> 
> An application can easily patch a function for the duration of that
> application.
> 
> After starting up the tools, construct a Function Pointer Table (FPT) the same
> size as the existing FPT (call GetTSPtr and examine the first word of the
> table; multiply it by four to get the size of the FPT in bytes).  The first
> longword of your FPT is the number of functions in the tool set; do not
> hard-code this value!  Get it from the existing FPT on the fly.  Fill the rest
> of your FPT with zeroes, except for the functions you want to patch.  You must
> always patch the BootInit function (the first function) to return no error.
> Remember that the function pointer values are one less than the addresses of
> your replacement functions.
> 
> On exit, when you call TLShutDown your patch will be automatically removed.
> (If you're using ShutDownTools, you should call MMShutDown and TLShutDown
> after you call ShutDownTools.)
> 
>    Note : In the description of SetTSPtr on page 24-19 of Apple
>           IIgs Toolbox Reference, Volume 2, there are several
>           references to the TPT.  Keep in mind that the TPT is the
>           Toolset Pointer Table, not the Function Table Pointer
>           you pass to SetTSPtr.  While SetTSPtr copies the TPT to
>           RAM if necessary, it does not make a copy of the FPT.
>           After you call SetTSPtr, the FPT you passed is being
>           used, and any zero values in your table were filled in.
> 
> --- snip
>

     Well, no one ever said dear old Apple couldn't spew out the docs
when they felt like it. Interesting.

     Two points:

     1. The same bunch who put out your doc put out the OS which has
some serious bugs, including at least one associated with the CALL
described. In such a doc, the expression "can use" means "can use if you
want to try and are willing to test the results". When you consider the
number of OS components which must function correctly-- including
components which are known to have bugs-- making the CALL from an
application is, clearly, risky. If you make it from an application, you
test the application thorougly. If you do not, your application may end
up Initing some user's hard disk.

     2. In the particular case under discussion, the CALL _does_ lead to
crashes on many systems.


     That the CALL is risky does not necessarily make using it a bad
idea. It may, in some cases, be a very clever idea. But, really, this is
not the kind of thing you tack onto a major game just hours before
release. There are too many things which can go wrong and no time to do
the necessary testing.


     According to the credits, you did some last-minute modifications to
the game. Was the CALL to SetTSPtr one of your modifications?


     If it was, not posting a notice that a last-minute change had been
made and requesting that users having problems post the information was
a bit risky, but, understandable. You did not want to mess up the game's
release with a downer warning. But, once users started reporting
problems, why did you not explain what had happened?

     In any case, whoever added the CALL, you had to know that there had
been changes which had not been thoroughly checked. Why did you permit
us to believe that we were dealing with a bug-- one which could not
possibly have escaped detection by the play testers-- in a game which
had been thoroughly play tested?

     Did you not realize that an obvious explanation for the presence of
the bug would be that the bug had been detected and that the game had
been released anyway? All you had to do to make sure that there was no
such misunderstanding was provide a complete explanation the moment
users began to post problem messages.


     Why all the secrecy?

     Was it really so difficult to level with us from the start?



Rubywand