Mail Archives: djgpp-workers/1998/12/08/08:27:26
Hello.
On Tue, 8 Dec 1998, Eli Zaretskii wrote:
> 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.
Sorry if you have discussed this before. BTW is there some kind
of mirror for the mailing list archive because the DJGPP web site is
really slow from here (UK) most of the time (i.e. after 10am GMT).
The way I have currently implemented it, the file system
extension modifies the file name directly on opening. So, you can't do
things like finding the file's attributes without opening it first, etc. I
suppose this partial support would be better as an add-on library (which
I'm preparing anyhow) than an integral part of DJGPP.
> mapping of network shares to drive letters can change while the
> program runs
<snip>
> 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.
From my code testing, there does seem to be a delay when first
querying the functions sometimes, but after that it is very fast (on
Win95 anyhow). I think Win95 caches the information. So there may not be
as much overhead on each function as you imagine.
You can actually enumerate the UNC shares currently mapped using
NetUseEnum() (the name used in Ralph Brown's Interrupt List, INT 0x21
subfunction 0x51?? I think, maybe 0x50??). This provides you with the
device name for each mapped share.
> 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.
Could one not avoid all this overhead by emulating it at the
file system extension level?
Am I correct in thinking _put_path() puts the pathname into the
transfer buffer?
> 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.
Definitely. The more seemless DJGPP programs are with Windows,
the better.
> > 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.
Probably. However, after the initial open call, file functions
use file descriptors, and I do not know how to find the filename given a
file descriptor. If a way exists then this would be possible.
An alternate way would be for the file system extension to
pretend that it has emulated the call by calling the lower level open
function itself. Then it would have the file descriptor.
[ Currently it pretends it hasn't emulated anything - it just modifies
the filename. ]
==============================================================================
Rich Dawe - 4th-year MSci Physicist @ Bristol University, UK
richdawe AT bigfoot DOT com, http://www.bigfoot.com/~richdawe/
==============================================================================
- Raw text -