Hi Aitor, Preface:
The following holds true for PC-DOS 3.3, though I have no reason to suspect anything I say holds any different for any DOS version from 3.1 onwards. My understanding of what is expected of the redirector interface is due to having disassembled the DOS 3.3 kernel to understand how it works and may not be 100% accurate. Also, DOS 3.0 has some unique quirks but as far as the following is concerned, I suspect it works more or less the same as later DOS versions. DOS versions before that had no redirector interface. DOS has two 128-byte buffers in the Swappable Data Area. Initially, on a file-based request, such as AH=3Dh (OPEN), DOS will parse the passed filename into one of these buffers and place a pointer to it in another SDA variable. This parsing routine expects 8.3 names at all stages in the pathname except at the very beginning where if the pathname begins with \\ DOS understands this as referencing a path on a network machine and allows a valid MS-NET machine name as the first component of the path. FCB functions work like this too, but the way DOS handles them is a bit more convoluted, though you can imagine FCB handling by DOS as converting the FCB request to a normal file request, then proceeding as normal and at the end synchronising the FCB fields before returning control back to the application. Of course, you can only act upon files on drives with drive letters when using FCBs. If the parsing routine ascertains that the request is to be run on a network drive, either due to a \\ pathname specification or due to a drive letter being specified that refers to a registered, mounted network drive (see CDS Flags to see how this is determined), DOS will, at the point of the file operation, redirect the call to the relevant Int 2Fh AH=11xxh Network Redirector function (RBIL has these more or less completely listed) for the DOS call made. For example, for OPEN (AH=3Dh), DOS will call Int 2Fh AX=1116h. Note that most calls don't work with a machine name (as most calls require a CDS and those only exist for drives). For example, OPEN will fail if you pass a filename beginning with a "\\". On the other hand, CREATE (AH=3Ch) works for both cases. Once control is transferred to the network redirector, it is then expected to extract the pointer to the parsed filename from the SDA and use it to do... whatever. Of course, it doesn't _have_ to that as the PSP of the task which made the request is directly accessible to the redirector via the SDA (or via Int 21h AH=62h, a re-entrant DOS function). Crucially, the PSP has a copy of the value of SS:SP of the program which made the request, and it is set by DOS to point to a copy of the callers' registers as they were on entering DOS. That includes the pointer to the original "unparsed" LFN filename in DS:DX. Therefore, a redirector could access the LFN passed by an application by taking the pointer to the path in the method described above, thus allowing the redirector to implement LFN's however it so chooses. This is a hypothetical way for a network redirector to support LFN's without a frontend hook for Int 21h. File sizes however would still be limited though as the SFT would still be used for file management and the file size field therein is a DWORD. Whatever DOS 4.0's IFS did, was probably a more structured version of this line of thinking. Thus, if one was to write a "good" redirector, one could theoretically, absolutely support arbitrary length LFN's with all measure of acceptable characters. I don't know if any tools actually did this. I'm sure someone here knows better than I. I hope that makes sense. Any corrections to the above description are much appreciated. Best, Yll
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
