From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DJGPP and Windows 2000
Date: Fri, 10 Aug 2001 09:14:40 +0300
Lines: 23
Message-ID: <3B737BD0.C5CF353B@is.elta.co.il>
References: <09D1E9BD9C30D311919200A0C9DD5C2C03E0898A AT mcaexc01 DOT msj DOT maxtor DOT com> <3b71da94 DOT sandmann AT clio DOT rice DOT edu> <9kuogu$ndb$1 AT pippin DOT nask DOT waw DOT pl> <3B72EAF3 DOT FFF6CCB0 AT is DOT elta DOT co DOT il> <3b72d3ec DOT sandmann AT clio DOT rice DOT edu>
NNTP-Posting-Host: 192.116.55.139
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: fu-berlin.de 997424099 7238497 192.116.55.139 (16 [61365])
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Charles Sandmann wrote:
> 
> > In a nutshell, the LFN-aware functions are not to be trusted on W2K.  In
> > particular, handles created by an LFN variant of _open fail some important
> > functions of Int 21h that take a file handle, such as functions 5700h and
> > 5701h, and all subfunctions of function 44h (IOCTL) seem to return zero
> > instead of valid info.  The latter problem is the reason why ">/dev/null"
> > doesn't work on W2K.
> 
> Eli's mostly correct here, but the actual reason why >/dev/null fails is
> because a write of zero bytes to NUL or CON fails under Windows 2000 if
> the handle was opened with an LFN function but works just fine if opened
> with a standard DOS function.

I think this is a consequence of the more general problem: the LFN API of
W2K doesn't go through the emulation of devices.  That's why the same
write-zero-bytes code works on disk files opened with LFN functions, but
fails on devices.  For the same reason, findfirst doesn't set the character
device bit in the attribute byte it returns for devices such as NUL.

In other words, write-zero-bytes failure is a symptom; the disease is that
the DOS device driver layer is not properly emulated when LFN functions are
used.