From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10109281641.AA15140@clio.rice.edu>
Subject:	Re: fixpath patch (rev 2)
To:	eliz AT is DOT elta DOT co DOT il
Date:	Fri, 28 Sep 2001 11:41:14 -0500 (CDT)
Cc:	djgpp-workers AT delorie DOT com
In-Reply-To:	<9791-Fri28Sep2001183738+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Sep 28, 2001 06:37:38 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

> > What's currently in the code is if it sees a UNC it just decides to
> > return the absolute path that getcwd returned.  (My reasoning: this
> > code can only be activated if lfn=y and ver=0x532.
> 
> I thought you are coding this for Windows 9X under LFN=n as well, no?

It is a separate case.  It does not silently return root, so I don't
use this code there.  I only use the 7160 call, and only use it when
lfn=y and ver=0x532.  Yes, my earlier prototype did use it everywere,
but you easily convinced me this was a bad idea without lots of testing
and diagnosing exactly what bugs appear where.

I found under win9x that if getcwd fails that truename also fails, so
there is no reason to call this code (I just return relative path).

> > By the way, this section of code will never call AH=60
> > truename call, it will always call the 7160 version (does it ever
> > return UNC?)
> 
> I don't know.
> 
> One (tedious) way to try is to see if MSCDEX in DOS mode returns a UNC
> with AH=60h.  If it does, you could fire up Windows 9X but disable its
> 32-Bit File Access.  This should cause it to call down to DOS,
> including MSCDEX (which should be loaded in this case).

But this still wouldn't be under ver=0x532, which is the only way to
reach this code.

- Raw text -