🚀 go-pugleaf

Date sent:  3-SEP-1992 11:13:44

Glen Everhart suggested a standardizing method for stealing DDBs,
FDT entries, and which could also be modified to steal any other
referential vector:

>   The notion is to produce a UCB extension that looks like this:
>
>        .long   ident-pattern
>        .long   previous-DDB-address
>ucb$a_victimddb:
>        .blkl   nnnn    ;however long this needs to be, look it up
>
>   With such a standard in force, if I find the DDB from ucb$l_ddb
>of the victim device, I can check ident-pattern against my
>own program's pattern, and if it matches I just go ahead and use
>offsets from there to find my driver's UCB and thus its data
>(e.g. the CDdriver UCB). If it does not match, I chain using
>the previous-DDB-address and keep looking for my pattern, and
>when I find it (in usually one or two tries at most), I have
>found my UCB and can go on from there.
>   The pattern choice is arbitrary, and I have no great objections
>to making it two longs, but I think one is enough by prejudice.

Agreed.

>   It is necessary of course that this chain never be removed
>or broken once established, though the contents of the DDB copy
>in the area labelled "ucb$a_victimddb" above could of course
>be altered if one wanted to turn off a program.

Yes! :)
...
>   I would suggest a similar strategy be used for stealing
>FDT table bits also. These can be made to coexist rather nicely
>if one has a structure somewhat along these lines for FDT routines
>to be added to a driver's FDT chain.
[code suggestion removed]

Yup!

>   What say the rest of the forum?

I didn't see anything else along this line from anyone - these sound
like good suggestions.  Why not write up a white paper... I'll be happy
to help out if you need any, and I'm sure there are others.

>Glenn Everhart
>Everhart@Raxco.com
>215 358 5875
>


        Ehud

--
Ehud Gavron        (EG76)
gavron@ACES.COM
The world consults with you when you're cool.