Mail Archives: djgpp-workers/1998/12/09/05:33:03
On Tue, 8 Dec 1998, Rich N.S. Dawe wrote:
> 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.
AFAIK, Windows 95 doesn't need your library at all, it supports UNCs
already. Try writing a short test program that uses UNCs to open
files, and I think you will see that UNCs are already supported on
Windows 9X.
I thought you meant to support UNCs on every platform where DJGPP
programs can run, including DOS and Windows 3.X.
> 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.
I don't see any functions except 0x5f02 which returns a single
redirection list entry on each call, untill the list of all networked
devices is exhausted. You need to call this function in a loop for
all the 32 possible drive letters, until the return value has the at
its beginning the \\server\share string you are looking for.
> Could one not avoid all this overhead by emulating it at the
> file system extension level?
I don't see how. The problem is that the mapping can be changed while
a program runs, and you need to query the current mapping each time
you need to translate a UNC into a DOS-style x:\foo form.
> Am I correct in thinking _put_path() puts the pathname into the
> transfer buffer?
Yes.
> 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.
Keep a table of file names and associated handles, and install
filesystem extension handlers to hook calls to `open' and `close', so
you could add and delete such pairs as appropriate.
> [ Currently it pretends it hasn't emulated anything - it just modifies
> the filename. ]
If the file name modification is propagated back to the caller of the
library function, then this is a bad idea indeed. Applications don't
expect file names to be changed by library functions like `fopen'.
- Raw text -