Mail Archives: djgpp-workers/1998/12/08/06:43:09
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 -