cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1998/12/08/06:43:09

Date: Tue, 8 Dec 1998 13:42:51 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Rich N.S. Dawe" <rd5718 AT bristol DOT ac DOT uk>
cc: djgpp-workers AT delorie DOT com
Subject: Re: UNC filename support
In-Reply-To: <Pine.SGI.3.95q.981201135429.1073F-100000@irix.bris.ac.uk>
Message-ID: <Pine.SUN.3.91.981208132543.19465D-100000@is>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com

On Tue, 8 Dec 1998, Rich N.S. Dawe wrote:

> 	I was wondering if anyone has thought about incorporating UNC
> filename support into DJGPP 2.02.

This was discussed before, several times.  The problem with supporting 
UNCs is that, unless you run on Windows 9X, where UNCs are supported by 
the OS kernel, the low-level libc functions need to map the UNCs to the 
usual DOS x:\foo\bar form, before they are passed to DOS functions.
Such a mapping probably needs to be done in the function _put_path.

The single most important problem with this is that mapping of network
shares to drive letters can change while the program runs (e.g., somebody
types a "net use ..." command in another DOS box, or even from a shell
spawned on plain DOS from your running DJGPP application).

Thus, you cannot cache the mapping between drive letters and network 
shares, you need to query the system about the mapping each time the 
program references a UNC.  Such a query is quite slow (may take as much 
as several seconds on a large network), because AFAIK there is no DOS
function that returns the drive given a UNC, only a function which does 
the opposite.  So you need to loop through all possible 32 drives each 
time asking the network about the associated share name, and compare the 
returned string to what you have in the UNC passed by the application.  
A related problem is that you need to deal with two different mappings 
that point to the same machine, like this:

	f: -> \\server\share
	z: -> \\server\share\subdir

Handling all this for every file-oriented function would slow down DJGPP 
programs tremendously, because _put_path is called by every libc function 
which calls DOS.

If you have solutions for these problems, please describe them.  
Personally, I'm very uneasy about the lack of support for UNCs, so if it 
can be done without significant slow-down, I'm for it.

> 	The only undesirable side-affect is that the filename is
> actually modified by the extension.

You could modify a copy and keep it internally, I presume.

> Also, I'm not too sure about how the extension would be set up initially.

The usual way is to define a static function with 
__attribute__((constructor)) which causes the startup code to call it
before `main'.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019