Date: Wed, 9 Dec 1998 12:30:51 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: "Rich N.S. Dawe" cc: djgpp-workers AT delorie DOT com Subject: Re: UNC filename support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com 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'.