Date: Wed, 8 Aug 2001 16:30:00 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Andrew Cottrell 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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.