> JdeBP> For another, even if the device driver *could* make
 > JdeBP> application-level API calls to perform file I/O, there's no
 > JdeBP> guarantee that the process, one of its parents, will not have
 > JdeBP> closed the file handle concerned an possibly opened another one
 > JdeBP> in its stead.  There are no "system" or
"reserved" file handles.
 > JdeBP> Each process is sovereign as far as its ope file handles are
 > JdeBP> concerned.
 >
 > But I don't agree with this.  You don't have the right to close arbitrary
 > file handles.  You're only allowed to close files that you
 > yourself have opened.  That's a bit like saying that the
 > device driver shouldn't rely on being able to access memory
 > it just malloc'ed, because "the user might have run a
 > program to go and deliberately clobber that memory".

JdBP> Wrong on both counts.

JdBP> First count :  An OS/2 process can do what it likes with *any* of the
JdBP> file handles that it has open.  There's *nothing* that stops it from
JdBP> closing any or all file handles that it has open.  As far as its file
JdBP> handle table is concerned, each process is sovereign.

JdBP> Ever written a daemon process ?  What's the first thing that a
JdBP> well-written background daemon process does ?  That's right.  It closes
JdBP> any open file handles that it may have accidentally inherited.

Ok, so how do you do this properly?  for (x = 0; x < ULONG_MAX; x++) DosClose(x);

???  And there's definitely nothing wrong with closing file handles that
have NEVER been opened?  And nothing wrong with closing a file handle which
may have been fopen'd by a previous process, and still has data in the
buffer, which needs to be flushed to disk?

 > BTW, if you see a message from me at 5AM, it's NOT because
 > I'm an earlybird.  :-)

JdBP> Why is it then ?  (-:

Any such thing as a latebird?  I've tried sleeping tablets, but they either
do nothing, or keep me asleep for something like 16 hours, either way a
disaster.  In the last week, I might have gotten back on track, time will
tell.  BFN.  Paul.
@EOT:

---