Risks

There are two major risks in using the XBRA protocol as described above: As described above we put a jump instruction in the XBRA structure that points to our exception handler. Normally, C compilers will allocate this structure in the data section, so when control is passed to our handler, an instruction will be fetched from the data section. Normally, this does not cause problems on the atariST/TT architectures beacuse there is no protection. But, if protection was ever enforced by TOS we would be in trouble, and we would end up with a segmentation violation as code would be fetched from a a non-text section. Putting the XBRA structure in the text section is worse. Since we patch in the next address, it would be akin to self modifying code. On the 68030/40 machines this will not work if the instruction cache is read-only. For now, putting the header in the data section seems to be the most reasonable and portable solution. But be aware that on the 030/040 you may have to force a cache flush after changing contents to patch the next address, otherwise the system will crash.

On the subject of overzealous useage of XBRA Allan Pratt had the following words of advise:
``It's just that I would have big banners all over it saying that vector stealing is a bad idea in the first place. There are just a few vectors that you can legally steal, and a few more that you can reasonably steal. I would use only legal vectors and legal uses in the examples. One kind of legal use for a legal vector is a RAMdisk using hdv_rw (and _bpb and _mediach). Also, talk about unhooking vectors needs a whole raft of warnings about what a bad idea this is.

The right way to do almost anything that involves vector stealing is to use a TSR in the AUTO folder as a driver, and have a foreground program communicate with that driver, usually through a trap it's stealing or through the cookie the driver left in the cookie jar. Then there's never a question of unhooking. The driver is generally small enough that you don't mind having it around even when you're not using the program in question.

I guess I would just like to see more in the way of caveats, so people won't read this document and think that vector stealing is the best way to do something. It often isn't. But that's all gravy on top of the actual stated goal of the document, which is to describe XBRA itself.''