hyc@math.lsa.umich.edu (Howard Chu) (08/31/90)
Why is it that every time someone comes along to patch one of the TOS functions, they have to intercept the trap handler? I've been thinking about writing an AUTO folder program that basically copies all the BIOS, XBIOS, etc. jump tables to RAM, so you don't have to duplicate all the effort of intercepting the call, testing the function number, etc. (i.e., the program has a functional duplicate of the current BIOS/XBIOS trap handler, but it uses a jump table in RAM. When you want to replace a function with your own, you just need to change the jump table, not install a brand new trap handler.) Why didn't anyone ever do this before? The program could be very stupid, and just have the jump tables for each version (1.0, 1.2, 1.4) of TOS hard coded, or it could be very incredibly smart, and walk thru the existing trap handler until it encounters the magic jump instruction, and duplicate things that way. Either way it would make later changes much more convenient, no? -- -- Howard Chu @ University of Michigan one million data bits stored on a chip, one million bits per chip if one of those data bits happens to flip, one million data bits stored on the chip...
7103_2622@uwovax.uwo.ca (Eric Smith) (08/31/90)
In article <1990Aug30.225713.24233@math.lsa.umich.edu>, hyc@math.lsa.umich.edu (Howard Chu) writes: > Why is it that every time someone comes along to patch one of the TOS > functions, they have to intercept the trap handler? I've been thinking > about writing an AUTO folder program that basically copies all the BIOS, > XBIOS, etc. jump tables to RAM, so you don't have to duplicate all the > effort of intercepting the call, testing the function number, etc. > (i.e., the program has a functional duplicate of the current BIOS/XBIOS > trap handler, but it uses a jump table in RAM. When you want to replace > a function with your own, you just need to change the jump table, not > install a brand new trap handler.) > Good idea. In fact, MiNT provides something like this -- if you call the BIOS, XBIOS, or GEMDOS with function code -1, you get back the address of the appropriate function table. Changing this table lets you patch into system calls. > Why didn't anyone ever do this before? > See above; although MiNT is perhaps overkill if you only want to be able to hook into system calls easily, and don't care about multitasking, IPC, etc. If you do decide to write your AUTO folder program, you might want to consider using the same scheme (i.e. gemdos(-1) gets the address of the GEMDOS function table). The other problem is that no one can be sure that the AUTO folder patch is available on every machine; hence, the constant re-invention of the wheel. -- Eric R. Smith email: Dept. of Mathematics ersmith@uwovax.uwo.ca University of Western Ontario ersmith@uwovax.bitnet London, Ont. Canada N6A 5B7 ph: (519) 661-3638
fischer-michael@cs.yale.edu (Michael Fischer) (08/31/90)
In article <6848.26dd860f@uwovax.uwo.ca> 7103_2622@uwovax.uwo.ca (Eric Smith) writes: >The other problem is that no one can be sure that the AUTO folder patch >is available on every machine; hence, the constant re-invention of the >wheel. But that's what the cookie jar is for. A program that wants to patch the jump table can test to see if the patch is there already. If not, it can install it itself or else install its own trap handler the old way. -- ================================================== | Michael Fischer <fischer-michael@cs.yale.edu> | ==================================================
rehrauer@apollo.HP.COM (Steve Rehrauer) (09/01/90)
In article <25952@cs.yale.edu> fischer-michael@cs.yale.edu (Michael Fischer) writes: >In article <6848.26dd860f@uwovax.uwo.ca> 7103_2622@uwovax.uwo.ca (Eric Smith) writes: >>The other problem is that no one can be sure that the AUTO folder patch >>is available on every machine; hence, the constant re-invention of the >>wheel. >But that's what the cookie jar is for. A program that wants to patch >the jump table can test to see if the patch is there already. If not, >it can install it itself or else install its own trap handler the old >way. And I suppose one must be a registered developer to learn how to use the cookie jar? Pfagh. -- >>"Aaiiyeeee! Death from above!"<< | (Steve) rehrauer@apollo.hp.com "Spontaneous human combustion - what luck!"| Apollo Computer (Hewlett-Packard)
7103_2622@uwovax.uwo.ca (Eric Smith) (09/01/90)
In article <25952@cs.yale.edu>, fischer-michael@cs.yale.edu (Michael Fischer) writes: > In article <6848.26dd860f@uwovax.uwo.ca> 7103_2622@uwovax.uwo.ca (Eric Smith) writes: >>The other problem is that no one can be sure that the AUTO folder patch >>is available on every machine; hence, the constant re-invention of the >>wheel. > But that's what the cookie jar is for. A program that wants to patch > the jump table can test to see if the patch is there already. If not, > it can install it itself or else install its own trap handler the old > way. > But if you need to be able to install it yourself, you're not really saving anything :-(. I suppose you could check the cookie jar and if the 'TRAP' or 'MiNT' cookie is not there, print a message telling your user to get the appropriate software. Seems a bit ugly; unless the trap handler provides some really nice services (or you need some MiNT specific facilities). If you've got to have the code in your program for installing the trap handler yourself, you've had to re-invent the wheel again. -- Eric R. Smith email: Dept. of Mathematics ersmith@uwovax.uwo.ca University of Western Ontario ersmith@uwovax.bitnet London, Ont. Canada N6A 5B7 ph: (519) 661-3638
kbad@atari.UUCP (Ken Badertscher) (09/03/90)
hyc@math.lsa.umich.edu (Howard Chu) writes: |I've been thinking |about writing an AUTO folder program that basically copies all the BIOS, |XBIOS, etc. jump tables to RAM [...] ARRRRRRGGGGGGGGGGHHHHHHHHHHH!!!!!!!!!!!!! thank you, i feel much better now. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>