HookFunc (was AnchorPath
2 messages in this thread
Looking for a compassionate teacher again (Shraddhan?).
I am still having problems translating filehook.c (ROM KRM: Libraries, p.
426-8) into assembler language. (I am trying to do the reverse: namely
exclude, rather than include, .info files, due to a user complaint.)
ParsePattern() seems to work, with "#?.info" as source, and 20 bytes for
destination length–copying the model with the latter; 16 bytes should do?
AslRequest() obediantly calls my hook function, but matches ALL files.
I.e., the requester lists only Drawers. Here is my hook function:
hkfnc: move.l infpat,d1 where infpat is dest of ParsePattern()
move.l #AnchorPath,d2 where AnchorPath is label for 282 bytes
addi.l #28,d2 D2 should now point at FileName's location
move.l DOSbase,a6
SYS MatchPattern(a6)
rts No need to change D0 from TRUE to FALSE
I am not at all surprised to discover that D2 points at a null string. (I
AM surprised that null gives a pattern match.) How would AslRequest()
know that I have set up a block for it to store the real AnchorPath in?
I think the heart of my problem is my inability to properly interpret two
things. The first comes from asl.library/AslRequest, NOTES: "Your
function will be called as follows:
ULONG rf_Function(ULONG Mask, CPTR Object, CPTR AslRequester)"
The second is a line of filehook.c, top of p. 428:
CPTR HookFunc(ULONG type, CPTR obj, struct FileRequester *fr)
One guess was that maybe I had to provide the Mask, the Object, and the
AslRequester to AslRequest() on the stack. Arguing against this was the
fact that AslRequest() should already know the first and last of these,
and since the beginning I have had the impression that IT decides where to
put the Object and should tell ME, rather than vice versa. Nevertheless,
I tried this two ways, once at the beginning of my hook function and when
that didn't work, in advance of my call to AslRequest(). Neither had any
effect. (The good part is that hardly anything I have done has resulted
in a crash.)
As I mentioned before, filehook.c does not seem to allocate AnchorPath in
advance. the "CPTR obj" above is the first oblique reference to it,
followed by
"… MatchPattern(pat,((struct AnchorPath *)obj)->ap_Info.fib_FileName)"
a few lines later. I believe this is the same as my hook function…
Bart
Bart,
Having just returned from yet another holiday, I see that your question
about filehook.c on 28 July remains unanswered.
If you still need help, I suggest you send me the relevant code, and I
will take a look at it for you.
Regards,
Shraddhan (via AP from Hertfordshire, England)