Mail Archives: djgpp-workers/2001/08/08/06:59:54
> > > Alternatively, we could use function 7143h to set file times directly,
> > > without opening it. Since this function is reported to sometimes fail
> > > on Windows 98 and ME, we should use this alternative only on W2K/XP
> > > (detectable by their DOS version, 5.50, together with LFN support).
> > > Assuming that 7143h doesn't have any surprised (a bold assumption, I
> > > know ;-), this would completely avoid the problem with LFN vs non-LFN
> > > handles.
> > Function 7143 works on my Win2K box, but due to buggy Win 9x
> > implementation this does not work on Win98.
>
> We could try 7143 and if that fails and the OS is 98 or ME, fall back
> on the current code.
>
> > Output of testing:
> > -rw-r--r-- 1 AC root 4 Aug 24 2001 new.txt
> >
> > 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.
> > One advantage of this is that it would be probably quicker on NT as it
one
> > interrupt call and does not require any file handlers etc....
>
> Yes.
>
> > Now for the hard question:
> > Which way should we go to fix utime?
> > Use 7143 or use SFN handles? My gut feel is to use the 7143
> > function on Win2K where LFN is set.
>
> I agree. It might be a good idea to use 7143 on Windows 9X as well,
> with the current code as a fallback.
The majority of Windows 9X the 7143 set time is broken so I would use the
existing code as the fix requires you to obtain a realy hot fix from MS
Support, you cannot download from their web site. MS for you!!!
I will work on a patch for utime so it uses 7143 on Win 2000.
> > Not being up to date with NT 4.0 support and the LFN drivers/services
what
> > would occur on NT 4.0? Should LFN bet set or not set?
>
> On NT4, LFN will be set only if the LFN driver is installed.
>
> > No flames please on the next question as I don't like asking, but it
would
> > make the change easier to implement: Does NT 4.0 LFN support matter?
>
> IMHO it matters unless it's too tricky to support.
That was the answer I was hoping for. If it can be done then we should do
it, but if we can't then so be it.
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:
1) Get people to set an environment variable to one of the following and if
we do not find one then assume that 2000 or XP is running. This is under the
assumption that we find a common solution for 2000 and XP with regards to
the issues we find.
OS_VARIATION = NT_4
OS_VARIATION = NT_2000
OS_VARIATION = NT_XP
2) Come up with a series of low level tests allow us to tell the difference
between NT 4.0, 2000 and XP. This sounds like the best bet and could be done
in setup_os function in crt1.c that way it gets run once only on starting
the app. The hard part is finding how to tell the difference and then hoping
that MS don't fix one of the tests that fail (fail a test that used to pass)
in a service pack.
Charles,
What results do you get on XP for the code I sent last night for eaach of
the tests? This may give some help in finding differences between 2000 and
XP.
Andrew
- Raw text -