PE>
  > PE>
  >   > I would have thought that device drivers were validly using those
  >   > file handles.
  > PE>
  >
  > JdeBP> Any device driver that assumes that an arbitrary process will have
  > JdeBP> a specific open file handle is badly broken.
  >
  > I didn't mean that, I meant that the device driver opened a
  > file for a good reason, and doesn't expect a child process
  > to close it on it's behalf.
PE>

  I checked the time on your post, and it was 04:37, so you're excused for
  not making any sense.  (-:

  Just to make sure, though :

  Device drivers are initialised in the context of the first process.
  Their init routines run at ring 3 privelege and can use kernel services
  to open files, print messages to the screen, and so forth.  Any file
  handles that they open will be inherited by any child process of the
  first process (and their children, unless they explicitly close any open
  file handles that they have inherited).

  HOWEVER, that does *not* mean that the device driver can USE those
  inherited file handles when it is invoked in the context of any
  arbitrary child process.  For one thing, only certain portions of a
  device driver, such as the INIT routine, can use application-level
  kernel APIs, since most parts of a device driver run at ring 0, not ring 3.

  For another, even if the device driver *could* make application-level
  API calls to perform file I/O, there's no guarantee that the process, or
  one of its parents, will not have closed the file handle concerned and
  possibly opened another one in its stead.  There are no "system" or
  "reserved" file handles.  Each process is sovereign as far as its open
  file handles are concerned.

  So, having covered the ground more explicitly this time around, I'll
  repeat the point that I made above.  Any device driver that assumes that
  an arbitrary process will have a specific open file handle is badly
  broken.

  > JdeBP <
___
 X MegaMail 2.10 #0:

--- Maximus/2 3.01