Date: Mon, 13 Aug 2001 22:04:32 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: sandmann AT clio DOT rice DOT edu
Message-Id: <6503-Mon13Aug2001220431+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com
In-reply-to: <10108131551.AA16903@clio.rice.edu> (sandmann@clio.rice.edu)
Subject: Re: Windows 2000 io testing
References:  <10108131551 DOT AA16903 AT clio DOT rice DOT edu>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Mon, 13 Aug 2001 10:51:39 -0500 (CDT)
> 
> > > 5) _chmod (__file_exists) is true with lfn active on devices, returns 0x20
> > >    (this is different than w95 for example).
> > 
> > Windows 9X should return 0x40; is that what you see?
> 
> Actually Win 95 fails (returns -1) on nul or con

Yes, I forgot: `access' has a special code to deal with that.

> > What happens with handles beyond the 5 standard ones, which are open in a
> > parent program--can the child successfully call _get_dev_info for those?
> 
> If they were opened with SFN calls - yes.
> If they were opened with LFN calls - no.
> 
> But we don't have code (that I know of, maybe you have an idea) which
> would look at the text string for file to open and know before trying
> if it is a device or not.

Bash does lots of trickery with handles 5 and 6, inheriting them to
child programs (you will see this in every configure script).  DJGPP
ports routinely call isatty on inherited handles, to see if they are
connected to disk files or devices (the console device).  I was
thinking about these cases when I asked that question.  Looks like we
will have to run many configure scripts to see whether there is a
problem and to test any LFN/SFN trickery we decide to pull.

> How much code actually opens devices (nul,con,aux,prn) instead of using
> pre-opened handles?  When they do, what calls need to be supported?

Some programs reopen CON (Less is one, IIRC).  In the case of Less,
that handle is fed to `select', and `select' uses every trick in our
bag to do its thing ;-).

There's also the FSEXT feature which opens NUL and then dup's its
handle whenever it needs one more handle.

But it's true that there are not many programs which reopen devices.