🚀 go-pugleaf

In article <13731@gryphon.COM> you write:
>Hi.  Could somebody give me some code on patching a dos.library function? 
>(ExNext to be more precise)  I would like to write a patch to make files with
>the hidden bit invisible (Gee I thought it was supposed to do that already) 
>I've tried SetFunction, and also something that stuffed my address into the
>library directly, but neither worked, so I guess I'm not doing it right.
>Thanks.
>

The problem:  For each call to Examine()/ExNext() you wish to filter out
 files that have a certain file attribute bit that you have decided to
 call HIDDEN.  How do you patch AmigaDOS?

Possible Solution:  For each call to Examine()/ExNext, after DOS calls
 the device handler, you check if a certain HIDDEN bit is set.  If yes,
 then retry the Examine operation.  If after many attempts at finding a
 non-hidden file, DOS returns IOERR_NO_MORE_ENTRIES_IN_THIS_SEARCH, then
 you finally return to the caller.

The dos.library is not a common library the way Carl would like to see
it.  Each vector entry contains code like:
        moveq  #9,D0               <--- offset into GlobVec table(?)
        bra.s  common_hanlder
I told this to Andy Finkel a few years back, and he nope, you're wrong--
doesn't even happen.  To patch a function I recommond tracing through
it and find where it loads  DosLib->dl_A2.  This is GlobVec.
The code soon indexes through this pointer, I believe,  like:
        jmp   0(A2,D0)
This address is the _real_ function in BCPL.  At this point you are in 
the BCPL environment, and all its register conventions now apply.  Any BCPL
code (like DIR and LIST) call through the Global Vector Table, completely
bypassing dos.library, which is around mostly for "C" programmers.  The
code you jump to here just finds the handler, formats a packet, sends
it off, then waits for the reply.

Inside of BCPL, you can find two parameters in registers, and the rest
are on the stack (A7).  After your routine has checked for the HIDDEN
bit, perform  JMP (A6)  to return to your caller.  Remember the stack
grows toward high addresses.

When patching any library jump vector, you should create a WEDGE of
sorts sothat your loading program may unload itself, and also sothat
the vector may be restored at a later time.  The "true and unadultered
facts about SetFunction()'ing library vectors" is revealed in the 
Washington DC DevCon notes.  For register conventions, check some
Fred Fish disks for BCPL interfacing routines.  Good Luck  :-) :-)

>     ddave@pnet02.CTS.COM ddave@pnet.gryphon.COM killer!gryphon!pnet02!ddave

"Sometimes doctor, when I wake up in the morning, I just don't know who I am..."
               --- confessions of an Abstract Data Type

--- brian witt
--- USNET:  well!aleks@ucbvax.berkeley.edu