🚀 go-pugleaf

In article <169@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes:
>In article <530@nikhefh.hep.nl>, gert@nikhefh.hep.nl (Gert Poletiek) writes:
>> If Atari would do things this way (and I doubt there is any look/feel
>> involved) you could easily work with different versions of Malloc() in the
>> same system.
>
>Gert, you have missed the point.  You can easily patch GEMDOS, BIOS, or
>XBIOS functions on the ST - the new routine saves the original trap
>address, installs itself as the trap handler.  Whenever it is called, it
>checks to see if the function number is the one it handles, and if not,
>passes the call off to the original vector.  This can be done via a
>program in the \AUTO folder, even.
>
>This is not quite as elegant as the Line A trap, but it does work, and
>the Line A & F traps were designed for other reasons.  On the '020 and
>'030, Line A opcodes are MMU ('851 for the '020, built-in on the '030)
>instructions, and Line F opcodes are FPU ('881 or '882) instructions.
>
>-- 
>                     {hpda, uwmcsd1}!sp7040!obie!wes
>           "Happiness lies in being priviledged to work hard for
>           long hours in doing whatever you think is worth doing."
>                         -- Robert A. Heinlein --

NO NO NO NO NO NO, installing a trap handler is exactly what I DON'T want
to happen. I pointed out already several times that when one bug is fixed,
one extra traphandler is installed, when two bugs are fixed two extra trap
handlers are installed, and so forth. 

All these trap handlers checking for the correct system call number to fix
take TIME. Fixing things in a way a la the Mac does not take ANY extra time.

Bugs are generally not discovered all at the same time. So its reasonable to
assume that several fix files would be present. Installing these by taking
the original 68000 trap handler over just takes too much time while
performing lots of system calls.


Gert Poletiek

NIKHEF-H, Dutch National Institute for Nuclear and High Energy Physics
          Kruislaan 409, P.O.Box 41882, 1009 DB Amsterdam, The Netherlands
UUCP:     {decvax,cernvax,unido,seismo}!mcvax!nikhefh!gert
bitnet:   nikhefh!gert@mcvax.bitnet, U00025@hasara5.bitnet

From september 1st 1988:

Gert Poletiek  Dept. of Math. and Computing Science, University of Amsterdam,
               Kruislaan 409, NL-1098 SJ  Amsterdam, The Netherlands
UUCP:          {decvax,cernvax,unido,seismo}!mcvax!uva!gert
bitnet:        uva!gert@mcvax.bitnet, U00025@hasara5.bitnet