home *** CD-ROM | disk | FTP | other *** search
- SafeGIRPort 1.0
-
- Written by Osma Ahvenlampi with changes by Mark Thomas
- Public Domain (please, let it be free)
- There is no warranty of its usefulness, fitness, or whatever.
- Please use at your own risk.
-
- BACKGROUND
-
- First there was PatchOGR. It has some bugs, noted below.
-
- Next there was NewObtainGIRPort. It has a bug, noted below.
-
- Now, we have SafeGIRPort, a small patch to the Intuition
- ObtainGIRPort() call, making certain BOOPSI gadgets and hacks such
- as MagicMenu and CycleToMenu work together nicely.
-
- After writing textfield.gadget, some people began to notice a
- lockup condition (deadlock) when used with MagicMenu and
- CycleToMenu. I at first had a fix worked into a beta version of
- the textfield gadget, but discussions with other programmers made
- me realize my code was right, and the hacks were wrong.
-
- I wanted an external program to fix the problem, but I couldn't
- see how it could be written from these hacks' point of view. Then
- after talking with someone (Marcel I think was his name, a fellow
- developer) I realized I could do what I was doing inside the beta
- gadget, but in a patch of an Intution function. This was the key.
-
- USAGE
-
- To install the patch, run SafeGIRPort from a CLI. To keep the size
- to an absolute minimum, it cannot be run from Workbench.
-
- You should add the line "Run <>NIL: SafeGIRPort <>NIL:" to your
- S:User-Startup, to use this patch.
-
- After installing the patch, SafeGIRPort will stick around, waiting
- for a CTRL-C signal, after which it will (if possible) remove the
- patch and exit. If another program has patched over SafeGIRPort,
- it will flash the screen and refuse to quit until the other patch
- has been removed and you send a CTRL-C again.
-
- EXPLANATION
-
- This patch adds a safety check in the ObtainGIRPort() call, by
- checking whether the layer of the GadgetInfo structure is already
- locked. If it is, the patch will simply return NULL (a valid
- response from ObtainGIRPort() mind you).
-
- PatchOGR by Mark Thomas had two major problems. First, it did not
- check whether the GadgetInfo had a valid layer, but simply called
- AttemptLockLayerRom() with a NULL layer. This is not necessarily
- illegal since GadgetInfo structures should always have a valid
- layer, but it does help to check it anyway since there is some bad
- code out there. Secondly, it subsequently called ObtainGIRPort()
- while while the layer was locked. This is not illegal, but the RKM
- recommends that Intiution functions not be called when layers are
- locked. It does not say it's strictly illegal. (An illegal
- Intiution function to call is one that causes renders or locks
- itself.)
-
- (If anyone notices, PatchOGR was a modification of WBTitle, and
- as with WBTitle was written in C to show how to use SetFunction()
- from C. It's pointless when you have a small patch, but it is
- informative, I think.)
-
- NewObtainGIRPort by Osma Ahvenlampi fixed those two problems in
- PatchOGR and was released in assembly (my absolute favorite).
- However, it leaves a minimal window for a lockup condition, as the
- GadgetInfo layer is unlocked before obtaining the RastPort from the
- original ObtainGIRPort(). The probability of another task locking
- the layer in between these two operations is small, and may not
- warrant enclosing the patch inside Forbid()/Permit(). Only time and
- use will tell if they'll be needed. If you need to install the
- safety blanket, the code is available to all three programs.
-
- SafeGIRPort is yet another attempt to fix bugs, and make the code
- smaller and faster. Actually the bug it fixes is not that great of
- a problem and only occurs when you try to uninstall the patch. If
- you have a processor that has both data and instruction caches
- turned on, NewObtainGIRPort would potentially crash since the caches
- were not flushed after the patch was uninstalled. Also, the patch
- code itself has been optimized (and the other code too), with the
- benefit of less impact on any system performance. At the same time
- the small chance of the lockup condition mentioned above has been
- made even smaller. Finally, due to all the optimizations, there
- was a total savings of 72 bytes of memory (gee aren't we all happy).
-
- I hope that the optimization and space savings continues. This
- program was designed to be exactly functionally equivalent to the
- NewObtainGIRPort program, while being safer to use.
-
- AUTHOR
-
- Email: <mthomas@zilker.net>
-
- Snailmail: Mark Thomas
- 1515 Royal Crest Drive #3259
- Austin, TX 78741
-