No rush...none of the sigtape stuff will be finalized till after the
symposium. If you'd care to write a AAAREADME.TXT file to describe
the material (& advertise your services) it'll save me trying to
write one and undoubtedly be a better job. I plan to mention your
stuff at my talk (which alas is opposite the vms update and probably
won't be heard by many, but I'll put it in the notes also).

It was clear you were thinking about intercepting a bunch of these.
It also occurred to me that something like a pseudodriver could be
handy to control the thing, if you wanted to be able to poke
variables externally, though it could also generate some other
system service, I'd think, or set of unique arguments to an
existing one, to control it. An intercept that would fake the
results of $setprv or $gettim, for example, for certain PIDs,
would need to have some way to set the PIDs that were being
trapped. A more general kind of monitor might use the fact that
you still have process context to signal a server process. You'd
preregister the service process' PID and a mailbox UCB (for
example), store all current context (including, necessarily,
the PSL since you need to get back the previous mode bits after
all), and ship a message to the server using exe$writembox (sp?)_
where the message includes the address of your structure in pool.
Then just enter a waitfor loop...clear and wait for EF 31 and keep
going till some flag YOU cleared in your structure got set.

You also pass a kernel mode address in your code by the message.
Now your process does its thing and fires off a special knl AST
at the address you set in the process (you send the pid too!)
with the address of the structure as the AST parameter.
Inside this AST you set the flag the mainline bit was waiting on,
then set the event flag, then return. The mainline wait loop
then falls thru and restores context including previous mode
and continues (or can generate fake results...you can pass
controls in your structure) after deallocating the structure.
(The ast routine deallocates the special knl ast block). Now
you have inserted user mode code, effectively, into the system
service path. As long as you're careful not to step on yourself
in this, you can pull then all kinds of interesting pranks and this
will work. The motive is of course that it's LOTS simpler to write
journals or the like from user mode. There are some other tricks
needed, but I worked this out about late 1991 to real early '92
though in slightly different context. Hmmm...imagine something that
responds to exit by sending a message "WHO GAVE YOU PERMISSION TO
GO???" or some such nonsense...but it occurs to me that faking
pieces of $getjpi might be easier if the results could be faked.
It occurs to me that one can trap the path just before the return
too, and overwrite the return priv mask if one exists. Maybe that's
the way to approach that problem...just flag the darn thing before
calling the sys service, call it further down the stack, then check
the flag & clobber data if desired. Unfortunately my time for
that kind of internals hacking is limited...maybe I'll just talk
about it some.
Oh well...gotta get back to work. Good to hear from you.
Glenn Everhart