Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!amiga!cbmvax!andy
From: andy@cbmvax.UUCP (Andy Finkel)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Patching dos.library
Keywords: BCPL moveq #9,D0 SetFunction()
Message-ID: <6439@cbmvax.UUCP>
Date: 29 Mar 89 17:44:18 GMT
References: <13731@gryphon.COM> <11110@well.UUCP>
Reply-To: andy@cbmvax.UUCP (Andy Finkel)
Organization: Commodore Technology, West Chester, PA
Lines: 68

In article <11110@well.UUCP> aleks@well.UUCP (Brian J. Witt) writes:
>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

Correct.  By this I mean, the BCPL programs do not go through the
C interface; instead they go through their own table (called
the global vector).  The move/branch to a common routine stuff
is what Tim implemented to wrap a BCPL environment around
the AmigaDOS calls.  Eventually, a call on the library vector
goes through the global vector.  However, the BCPL programs
go directly to the global vector.

This is why, after you patch dos.library, your patch will only
seem to function sometimes.

BTW, turned out that, according to the Exec manual, any 6 bytes
will do for a function.  Including functions that aren't even
jumps, like:

moveq#0,d0
rts

So Tim's branches are legal, at least according to Carl's design.

>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.

Now for the rest of the bad news :-)  Sure, we'd prefer people don't
patch the global vector, since (I hope) that code will break under 1.4...
but that's not the bad news.  The global vector is regenerated
(from the rom table) every time a new cli process gets created.  So
any GV patch is temporary; until the next newcli.

		andy
-- 
andy finkel		{uunet|rutgers|amiga}!cbmvax!andy
Commodore-Amiga, Inc.

"Give me a Standard large enough, and a Committee to discuss it,
 and I will prevent the Earth from moving."

Any expressed opinions are mine; but feel free to share.
I disclaim all responsibilities, all shapes, all sizes, all colors.