From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10108221842.AA14832@clio.rice.edu>
Subject: Re: Fseek on STDIN problem on Win 2K
To: eliz AT is DOT elta DOT co DOT il
Date: Wed, 22 Aug 2001 13:42:24 -0500 (CDT)
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <8361-Wed22Aug2001201124+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Aug 22, 2001 08:11:25 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

> What _are_ the burning issues that are left unsolved, btw?

Finishing _creat*, commit, doing some integrated builds and testing.
I'd like to find the no dos memory problem, but it's about the
same frequency out of selectors used to be on other platforms.

> > Library change.  We shouldn't be getting magic numbers on pipes.
> 
> How can we detect that a particular handle is a pipe?  Handle zero is
> not special: some program could close it and open some file on it.

If get_dev_info returns zero and OS is NT, 99% of the time this will
be a pipe or weird handle.  Potentially additional calls might be able
to filter diskette file handles from weird handles.  

> > So far in testing, doing a 4201 call with zero relative offset
> > (i.e. get position) seems to fix it.  Probably putting this call in
> > _is_executable (and maybe lseek) would fix the problems.
> 
> If this solves the problem, I'd suggest to put the extra call into
> lseek, not only in _is_executable.

I hate to add extra calls all over the place when we're not sure of 
the extent of the problem.  More testing.

> > This problem does not happen under bash on NT4.0.  This indicates to me
> > even more the problem is only on NT opened handles.
> 
> But the NT opened handles are really open by the shell, which is just
> another application.  The only difefrence between, say, cmd.exe and
> Bash is that the latter is not a native Windows program.

Yes, but this indicates to me the problem is only on pre-opened 
handles when the image is launched from a Win32 executable and
we want to seek on those handles.  If libc treated those handles as
pipes (devices) instead of files, nothing breaks.

Calling extra seeks seems to make lseek() work on all pipes, up to
some point.  This makes me really nervous.

> > Also remember, that NT 4.0 and DJGPP have co-existed for 5 years, and
> > no one has reported this until now
> 
> I'm not sure this is something we can rely on.  I suspect that the
> number of people who used DJGPP on NT is very small.  That's the only
> way I can explain to myself how come I see the nuisances of DJGPP use
> on NT (see section 3.3 of the FAQ) reported so infrequently on
> c.o.m.d.

The LFN TSR is a really cool thing - I'll bet if we pushed it more 
heavily NT 4 would get more usage.  Maybe it just needs marketing :-)

> Windows 2000 and XP will be used much more, since the 9X series is
> being phased out.  But since W2K had a couple of show-stoppers until
> now, it, too, was not used enough as a DJGPP platform to let users see
> the problems such as this one.
> 
> In other words, I think that this problem wasn't seen because no one
> was seriously running DJGPP on affected platforms, not because the
> problem is not a grave one.

I still think most applications treat stdin as a character/pipe device
instead of fstat()ing it then trying to seek on it (thus the rare bug).

We could enhance is_executable, lseek, and anything that use the same
call.  We could fix lseek and make everything in the library call it
or a common primative.  We could make fstat smarter about NT pipes,
so we don't return it as ISREG and don't call is_executable on it at all.