Date: Tue, 8 Dec 1998 13:42: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: > 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'.