delorie.com/archives/browse.cgi | search |
From: | sandmann AT clio DOT rice DOT edu (Charles Sandmann) |
Message-Id: | <10110011813.AA16336@clio.rice.edu> |
Subject: | Re: fixpath patch (rev 3) |
To: | wojciech DOT galazka AT polkomtel DOT com DOT pl |
Date: | Mon, 1 Oct 2001 13:13:25 -0500 (CDT) |
Cc: | djgpp-workers AT delorie DOT com |
In-Reply-To: | <250B3114DA16D511B82C00E0094005F8023FC1B9@MSGWAW11> from "=?windows-1250?Q?Wojciech_Ga=B3=B9zka?=" at Sep 30, 2001 09:02:54 PM |
X-Mailer: | ELM [version 2.5 PL2] |
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 |
I've found some very disturbing behavior with the fixpath and getcwd patches. They always seem to work when working with my patched 2.03 but seem to often (not always) fail under cvs builds. When they fail the 7160 truename call for "D:." also returns D:\ I'm not sure if this is a DTA location issue, or some order of interrupts. But it is really irritating. I'm suspecting that the getcwd call either messes up something in the NTVDM or is cached and I need to make some other DPMI call to clear it. The V2.03 version calls the get true version call between the two since it doesn't have a global _os_trueversion.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |