delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/08/08/09:35:07

Date: Wed, 8 Aug 2001 16:30:00 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Andrew Cottrell <acottrel AT ihug DOT com DOT au>
cc: sandmann AT clio DOT rice DOT edu, djgpp-workers AT delorie DOT com
Subject: Re: Fw: Windows 2000 /dev/null permission query
In-Reply-To: <006801c11ff8$1a39ca70$0a02a8c0@acceleron>
Message-ID: <Pine.SUN.3.91.1010808161133.25973C-100000@is>
MIME-Version: 1.0
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

On Wed, 8 Aug 2001, Andrew Cottrell wrote:

> > > 5700 call time cx = 0xB733 date dx = 0x2B18 r.x.flags = 0x0002 r.x.ax =
> > > 0x5700
> > > 7143 call time cx = 0xB734 date di = 0x2B18 r.x.flags = 0x0002 r.x.ax =
> > > 0x7143
> >
> > Did 7143 really returned a different value in CX than 5700?  They
> > should return the same value for the same file.
>  I checked the code and re-compiled and re-run the test and you bet it they
> are different.
> 
> Could someone else please check this on Win2K or XP to see if the Redmond
> programmers got it again!!! Read - wrong.

This is actually something that I know for quite some time.  Veterans of 
this list might remember a long message I posted, like, 2 years ago about 
subtle problems with file timestamps reported by Windows.  The details 
are complicated and vary from one Windows version to another, but the 
upshot is that file's last-write time is set by Windows to be up to 3 
seconds into the future relative to the system clock at the time the file 
is written to.  (I started investigating this because GNU Make would 
complain about time mismatch.)

The two results you reported for two different functions differ by 2 
seconds (the time is reported in DOS format with 2-second granularity), 
so this is probably another manifestation of the above-mentioned 
phenomenon.  What you see is different from what I saw on Windows 9X, 
where 5700 and 714304 reported the same value.  I'm guessing that this 
is another quirk of Windows 2000's implementation of the LFN API, 
whereby the LFN functions use some separate path into the native OS 
calls, and thus don't pick up the 3-second increment that the legacy DOS
calls see.  (I'm quite sure that this increment is something Windows does 
specifically for DOS programs, to overcome some problem, real or 
imaginary, caused by the fact that creation time is recorded with much 
higher resolution than the last-write time.)

> I can think of two options so that we can add conditional code to support NT
> 4.0, 2000 and XP. Thw two options are:

I think we should postpone the decision about this until we have a better 
idea about the differences between these three systems.  Ideally, we 
won't need to make any distinction if we manage to write code that does 
TRT on all of them.

> 2) Come up with a series of low level tests allow us to tell the difference
> between NT 4.0, 2000 and XP.

From what I know, this will be tricky, as all members of the NT family 
deliberately try to pretend to be the same system for DOS programs.  One 
possible way to try to distinguish between them is to call DPMI function 
0401h (Get Capabilities).  NT4 is known to fail it, W2K supports it, but 
returns a slightly garbled vendor string.  If XP fixes the bug and 
returns non-garbled string, perhaps we have hope.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019