Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!uunet!mcvax!nikhefh!gert From: gert@nikhefh.hep.nl (Gert Poletiek) Newsgroups: comp.sys.atari.st Subject: Re: To Fix or Not To Fix (Really: applying patches to OS) Summary: Sorry to say but YOU ENTIRELY MISSED THE POINT Message-ID: <533@nikhefh.hep.nl> Date: 28 Aug 88 21:46:33 GMT References: <635@ihnet.ATT.COM> <383@snjsn1.SJ.ATE.SLB.COM> <1224@netmbx.UUCP> <530@nikhefh.hep.nl> <169@obie.UUCP> Reply-To: gert@nikhefh.hep.nl (Gert Poletiek) Organization: Nikhef-H, Amsterdam (the Netherlands). Lines: 51 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