Mail Archives: djgpp-workers/2001/08/08/09:35:07
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 -