Peter Fitzsimmons wrote in a message to All:

 PF> I know zero about SES.  Can anyone help this guy?

This isn't really an SES question.  It's a device driver question.

 PF> * Original Area: Netmail
 PF> * Original From: Werner Baar (1:250/238.10)
 PF> * Original To  : Peter Fitzsimmons (1:259/414)

 PF> From: WBaar{at}ibm.net (Werner Baar)
 PF> To:   sol3{at}olc.gvc.com

 PF> Servus Peter!

 PF> I don't know if you can remember me - from ColoradOS2 or
 PF> Fidonet (2:310/14). I am a friend of Mario Semo and he is a
 PF> Point of me.

 PF> Whats my problem - I'm sitting here in Vienna, the weather
 PF> is wonderfull and there are a lot of other nice things to
 PF> do, than writing a device driver for ses callouts :-)

 PF> The problem is not the device driver. He's working fine.
 PF> Now my problem...

 PF> How to create (32 bit ?? function) a function for the
 PF> setimport struct (DHSES_SETIMPORT)
 PF> typedef struct {
 PF>  USHORT ...
 PF>  PFN OPEN_PRE (PSZ pszPath, ULONG, .....);
 PF>  ...
 PF>  }
 PF>  This structure will be transfered from the device driver to
 PF> the kernel with a special DevHelp-Call.
 PF>  After this *registration*, every DosOPen from the
 PF> System/User/... will cause a call to the specified (PFN
 PF> OPEN_PRE) function.

To summarize, the device driver needs to register a callback address for
the kernel to call to make notifications.  This address has to be Ring 0
accessed.

 PF>  Can I use a DLL?
 PF>  Have I to code everything into the device driver?
 PF>   How can I obtain the PFN if the code reside outside the
 PF> device driver (see 1. question DLL, ect).

You cannot have the kernel call directly into a DLL.  You must register a
stub routine in the device driver as the callback address, and then have
the stub routine pass control to the DLL.

However, the stub routine in the device driver cannot call into the DLL. 
Instead, the DLL must call into the device driver using DosDevIOCtl(),
after which the device driver blocks until it has something for the DLL to
do.  When the stub routine receive a callback notification from the kernel,
it must set up the appropriate buffers, block the thread in device context,
and unblock the DLL call-down thread.

Note that the DLL, which is commonly called an Ancillary Control Process,
is under very severe restrictions on what it can do without deadlocking the
whole system.  For example, if the DLL must be called every time a file
access attempt is made, then it could not access any files.
 
-- Mike


---