Date:	Wed, 22 Aug 2001 20:29:54 +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:	<3099-Wed22Aug2001202953+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:	acottrel AT ihug DOT com DOT au, djgpp-workers AT delorie DOT com
In-reply-to:	<10108221532.AA12511@clio.rice.edu> (sandmann@clio.rice.edu)
Subject:	Re: Fseek on STDIN problem on Win 2K
References:	<10108221532 DOT AA12511 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

> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Wed, 22 Aug 2001 10:32:11 -0500 (CDT)
> 
> > It looks like 4200 reports that it did move the file pointer, but the
> > subsequent 3F00 still continues from the position before the lseek.
> 
> Yes, it appears NT has cached the location of the pointer (incorrectly)
> and treats the a second call to set the absolute pointer position to
> the same place as the previous call a no-operation.  A get of the pointer
> or a move to a different location fixes it.

It's kinda weird, isn't it: they cache the location, but querying
about the (cached) location fixes the invalid cache?

> 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.

> > Thanks, trying this with different shells might indeed shed some light
> > on this problem.
> 
> 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.

> 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.

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.

- Raw text -