Conference noted::hackers_v1

    
    I believe the answer is "yes". The Kenah and Bates book discusses
    this in chapters 6 and 7. You could also check on the description
    of $FORCEX and optionally, look at the source.
    
    /pjh
    

    $FORCEX signals an exception in another process. It is quite easy
    (from kernel mode) to queue an AST to another process. Just allocate
    a piece of non-paged pool, fill in the ACB$ fields and call SCH$QAST
    (at the right IPL). You can make the AST happen in any mode, and
    can have your control block deallocated or not afterwards as you
    please. The most useful thing is to put some code in the control
    block and execute that (in kernel mode or with a 'special kernel
    mode' AST) as you will typically not know what address to send the
    AST to in the user process.
    
    Andrew Palka

I've got various (poorly) written  bits of code to do just
this sort of thing   (change another users prompt, recall his
commands to your terminal, force a (single) command to another
process  etc etc) let me know if you want to see some 'odd'
code   :_)




Peb

    Thanks for the replies. Any demonstartion code would be greatly
    welcomed !
    
    
    Thanks in Advance

    �	John

You can also look at the FILES tool in the toolshed.  This was hacked up
from the example user-written system service template and returns all
files opened by another process.

tom_p

    On a recent DECUS tape there was a program that changes the prompt
    of another user by declaring an AST for the other process.

    A word of warning, however.  Use of sch$qast has been beaten about
    ad nauseum in the VMS notes file as to whether or not it's supported
    and whether or not you should ever write code that uses it for use
    on a customer's system.  The consensus is generally that this is
    a dangerous routine which may change at a the drop of a rev level.
    There is typically an easier or more 'supportable' way to accomplish
    whatever you want to do with qast (mailboxes, global sections, etc).
    If your goal is to hack, sch$qast is a kick.  I have code that changes
    everything from prompts to process names and I enjoy writing that
    sort of code strictly for enjoyment.  Doing this on a customer's
    system is another thing however.
    
    	I'm not trying to start the whole argument over again, so please,
    no flames.
    
    								Dave()

    re .7:

    Well, yes and no. Realistically, SCH$QAST is not going to change. VMS
    itself makes heavy use of it, and VMS developers don't like creating
    work for themselves. It survived the shift to SMP, and it will probably
    survive the next one. Now mind you, I'm saying this with VMS hacker hat
    on, not my VMS developer's hat. If it does change, my response will be,
    "Oh well, sorry about that. I got bit too" and I'll probably explain
    why it happened. It won't unless there's a good reason. If you want to
    hear about good reasons for a routine's disappearance, ask me about
    IOC$ALLOSPT, which I made disappear a few months ago. :-)

    There are plenty of good reasons for queuing ASTs. The examples given
    in this note are good ones (changing process names, prompts, etc.)
    There are lots of things that can be done with mailboxes and global
    sections, but none of the things mentioned are among them.

    Queuing ASTs is system-level stuff. You have to be careful. You can
    crash the system easily. However, this is true *any* time you go into
    kernel mode. Kernel mode is what does it. ASTs are a side issue.

    There are also times when queuing the AST is the best way to do the
    problem. For example, take changing another process's process name. I
    wrote a program to do this long ago that did not use ASTs. I recently
    re-wrote it to use ASTs because the AST in the other process
    synchronizes with the database better than doing it in a different
    process. Before SMP, this was a "yeah, but" sort of objection, but come
    SMP, and the code that doesn't have the AST is sleazier than queuing
    the AST.

    Running privileged code on a customer's system is a different issue.
    Again, the real issue is privileged code, not ASTs. What should be done
    about this should be dealt with by the individual person. This is
    Digital, and we're all supposed to do the right thing. If the right
    thing is to queue an AST, then do it. If not, don't.

    When I was a software specialist, many customers paid Digital to have
    me write privileged code for them. Sometimes I queued ASTs, sometimes I
    didn't. The process name-changing program I mentioned above was written
    for a customer while I was a resident. I didn't use ASTs, and probably
    should have -- 20/20 hindsight is a wonderful thing.

    The bottom line on this is the old DEC motto, do the right thing. If
    the right thing is to write privileged code that queues ASTs, not a lot
    else can be done.

    	Jon

    Because there was no way to make it work with the same semantics
    that it had before. 
    
    	Jon
    
             <<< SQM::DISK$TSDPERF:[NOTES$LIBRARY]V5INFO.NOTE;1 >>>
            -< VMS Version 5.0 Information for Software Develpers >-
================================================================================
Note 16.2             Obsolete routines in the Modular Exec               2 of 7
ERIS::CALLAS "So many ratholes, so little time"      18 lines   2-MAR-1987 18:01
                       -< We have a replacement for you >-
--------------------------------------------------------------------------------

    re using IOC$ALLOSPT: 
    
    There is a new routine to allocate SPTs: LDR$ALLOC_PT. There is also a
    LDR$DEALLOC_PT. These can be found in [SYS.LIS]PTALLOC.LIS on current
    result disks. 
    
    The new routines have different register conventions and different
    semantics. Most users of ALLOSPT assumed that multiple calls to the
    routine would give you contiguous SPTs. This is not true with the new
    routines, you have to allocate a bunch of SPTs with a single call. We
    don't want to make an IOC$ALLOSPT jacket around LDR$ALLOC_PT because
    most users of ALLOSPT assumed that multiple calls would give contiguous
    SPTs. Since the two routines are not bug-for-bug compatible, it will
    cause many people subtle headaches if we make a jacket routine. 
    
    Note that IOC$ALLOSPT was never documented. 
    
    	Jon

        <<< VAXWRK::NOTES$DEVICE:[NOTES$LIBRARY]V5FT_VMSNOTES.NOTE;1 >>>
                     -< VMS V5 FIELD TEST SITE CONFERENCE >-
================================================================================
Note 20.0                     LDR$ALLOC_PT routine                     3 replies
DOOBER::DOOB "DOOBie, DOOBie, DOOB"                   6 lines   8-SEP-1987 12:52
--------------------------------------------------------------------------------

    I am supporting a V5 field test customer who needs documentation
    on the new V5 routine LDR$ALLOC_PT.
    
    Where can I get this information?
    
    Peter
================================================================================
Note 20.1                     LDR$ALLOC_PT routine                        1 of 3
ERIS::CALLAS "Strange days, indeed."                 43 lines   9-SEP-1987 17:48
                    -< Right here -- or check PTALLOC.MAR >-
--------------------------------------------------------------------------------

;++
; LDR$ALLOC_PT  - Allocate page table entries
;
;	This subroutine allocates system page table entries.
;
; Calling Sequence:
;
;	JSB LDR$ALLOC_PT
;
; Input Parameters: 
;
;	R2 -> Requested PTE count
;
; Implicit Input:
;
;	Linked list formats for free PTE entries:

;	  For 2 or more PTEs
;			 21 20				0
;	+---------------+---+---------------------------+
;	|		| 0 |  link (PTE  offset)	|
;	+---------------+---+---------------------------+
;	|			total count		|
;	+-----------------------------------------------+
;
;	  For a single free PTE
;			 21 20				0
;	+---------------+---+---------------------------+
;	|		| 1 |  link (PTE  offset)	|
;	+---------------+---+---------------------------+
;
;	  List header:	LDR$GL_FREE_PT
;
; Output Parameters: 
;
;	R0 -> Completion Status
;	R1 -> Starting PTE address
;	R2 -> Preserved
;
; Implicit Ouput:
;
;	The pool of available PTEs is altered to reflect the allocation.
;--