askrid@netmbx.UUCP (Dirk Ahrens) (05/25/90)
In article <759@imada.dk> micro@imada.dk (Claus Pedersen) writes: > I have just started to use the XBRA protocol to intercept system >vectors. I want this standard to spread in order to keep my programs >running [-keep it selfish else they don't believe you ;-)]. > Ok, I know that there are problems with the XBRA protocol - It's >for assembly programmers only... [ description of the library package deleted ] >There are 4 entry points: > XB_isinstal(), XB_install(), XB_remove(), XB_kill(). How do you remove and kill when you already have done a Ptermres? > There is one minor short coming - the pack is for Borland TC only, >but you are free to modify the source to run with your favourite C >compiler. > - Klaus (micro@imada.dk). if you want a version which doesn't depend on a specific Compiler, and you don't like Assembler (like me) try following definition. typedef struct { char xb_magic[4]; char xb_id[4]; void *xb_vec; short xb_jmpCode; /* has to be 16-Bit. contents: 0x4EF9 */ void (*xb_newVec)(); } XBRA; XBRA xBra = { 'X','B','R','A', '_','i','d','_', 0L, 0x4EF9, /* Code for jmp */ NewFunktionName }; Now you have to do only two things: Put the old Contents in xb_vec, and write the adress of xb_jmpCode in the System-adress. Everything in Super- visor mode of course. I wrote my own library for install. I remove with an external tool. This results in very small installing code, which is important for me for resident tools. Dirk Ahrens -- Askrid netmbx, Jabba the Hutt. askrid@netmbx.UUCP dirk@opal.cs.tu-berlin.de AHRENS@TUBVM.CS.TU-BERLIN.DE Dirk Ahrens - Danckelmannstr 46 - 1000 Berlin 19 - Federal Republic of Germs
micro@imada.dk (Claus Pedersen) (05/29/90)
In article <692@netmbx.UUCP> askrid@netmbx.UUCP (Dirk Ahrens) writes: >In article <759@imada.dk> micro@imada.dk (Claus Pedersen) writes: > [ description of the library package deleted ] > >>There are 4 entry points: >> XB_isinstal(), XB_install(), XB_remove(), XB_kill(). >How do you remove and kill when you already have done a Ptermres? 'xb_remove' uses the ID in the XBRA struct to locate the routine. -ie you simply passes the ID and which vector to 'xb_remove'. > >> There is one minor short coming - the pack is for Borland TC only, >>but you are free to modify the source to run with your favourite C >>compiler. >> - Klaus (micro@imada.dk). > >if you want a version which doesn't depend on a specific Compiler, and >you don't like Assembler (like me) try following definition. If your routine is looking like this : void interupt(void) {...lotsa things... (*xb_vec)(); /*call next routine in the chain*/ } - you are depending on a _very_ nice compiler... o Nearly none compilers makes strings word- aligned (to preserve space), but the ID & magic _must_ be word-aligned because the strings really is LONGs!! You get bombs if you fail to make the strings word-aligned. o TC and all other compilers I know of, uses *free* registers. Free registers is the ones which need not be saved, when entering a fun- ction. D0 is one of these - it better be free or you could not return anything... (old value would overwrite returned value). o In TC D0-D2, A1 and A2 is free and anything in these is destroyed before you know of it. In case you don't get the picture, consider what would happen if one of your pointers to a function were replaced with anything (NULL). _You have to save every register your compiler consider *free*!!_ If you uses the *all_wrong* routine given ^, have you considered that you call all the other routines in the chain with your stack-frame? - What if the other routine uses the return address on the stack? (like TOS to return) - EX: if you took the trap #1 vector - then GEMDOS would be called from your stack-frame, which would give some interesting results, when it tries to find the opcode (in your stack-frame)... [struct deleted] > >Now you have to do only two things: Put the old Contents in xb_vec, and >write the adress of xb_jmpCode in the System-adress. Everything in Super- >visor mode of course. Don't you check if you allready is in the chain?? -My routines allways does. >I wrote my own library for install. I remove with an external tool. >This results in very small installing code, which is important for me for >resident tools. My routines is less than 500 bytes inc. reloc. and symbol table. Removing the routines to remove and kill from the pack, would save you 14 bytes each (10 lines of assembler for both). My routines is written in assembler for size (and speed). If size is of that much importance to you - why don't you do the same? By the way how do you free the memory, your program used? - is there a standard way of doing this?? I am using a dummy vector from lowmem to point to a decriptor looking: struct { void *nextJack; void *Basepage; char magic[8] = "JACK_id_"; } I have called this struct Jack after a very well known man (to us)... note that the pointers is in the start to make 'magic' word aligned, Anybody in for something like this??? > Dirk Ahrens >-- > Askrid netmbx, Jabba the Hutt. > askrid@netmbx.UUCP dirk@opal.cs.tu-berlin.de AHRENS@TUBVM.CS.TU-BERLIN.DE > Dirk Ahrens - Danckelmannstr 46 - 1000 Berlin 19 - Federal Republic of Germs [you do have assembler in your struct (some call it a Jump), you could replace it with : xb_entry: MOVEM.L RegList, -(A7) JSR new_vec: xxxx.L MOVEM.L (A7)+, RegList MOVE.L xb_vec(PC), -(A7) RTS ] -Klaus (micro@imada)