Hi, Well, thanks to all that contributed to this interesting topic (there are quite a few interesting mails in the thread).
I could find very little extra information, like this: https://www.os2museum.com/wp/dos/dos-4-0/ Also I found references on IFSFUNC: in 2Fh (AH=11h), IFSFUNC functions seem to be entangled with the network redirector functions: http://www.ctyme.com/intr/int-2f.htm Apparently, these functions would be made available by IFSFUNC.EXE (curiously not provided by kernel itself). So I suppose the current only way to know more would be to acquire a MS-DOS (or IBM-DOS) 4.0, disassemble this file. My conclusion would be that it looks like an alternative functionality update to the network redirector itself (and not something entirely unrelated), that tried to solve some of the previous problems and/or tried to be more abstract and less tied to internal DOS structures, that was implemented only in DOS 4.0, probably to try and make HPFS available for DOS, but that was later abandoned (due probably to high memory requirements) in favour of maintaining the old redirector). Aitor On Wed, 22 Feb 2023 at 19:25, C. Masloch <pus...@ulukai.org> wrote: > On at 2023-02-22 01:05 +0000, Yll Buzoku wrote: > > 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. > > The LoL, SDA, CDS, and SFT layouts differ somewhat between MS-DOS > versions 3.x, 4.x, and 5.x I believe. And a few calls (like the 2F.11 > service to implement 21.6C Extended Open/Create) are version-specific. > > > 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. > > I believe there exists an SDA field (or two) pointing to the user stack > frame created by the DOS call. But yes, this is also accessible in the > PSP, though usually the only reader of *that* pointer is DOS process > termination (to regain the parent process's stack). > > > 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. > > That is imaginable, but comes with problems like DOS applications not > allowing to enter pathnames that contain blanks. An application that > uses the LFN interface (21.71) will usually allow for some escape method > such as double quotes to enter long names that may include blanks. > > > 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. > > A redirector can readily store additional file handle data outside the > SFT, using some cookie in the SFT to remember a reference to its > additional file data. Such a data structure is probably needed for any > nontrivial redirector because the available SFT fields may not suffice > to hold all file handle Meta data. > > I added 64-bit file size support to dosemu2's MachFS, by storing the > size and seek position in uint64_t fields in the redirector's private > file structure and syncing this with the 32-bit SFT fields throughout > the redirector's code. > > In particular, if DOS modifies the seek (which it can do without the > redirector's awareness, refer to the comment in [1]) then it will > usually end up at a number that isn't all-ones (0FFFF_FFFFh) and the > redirector will heed this value before using a seek position anywhere. > This is done using the update_seek_from_dos function [1], which is > called before reading, before writing, or before 64-bit-seeking from the > current seek offset. > > The reverse syncing is done using the set_32bit_size_or_position > function [2] which sets a 32-bit field either to the true value of the > 64-bit quantity, if it fits, or else to the maximum unsigned 32-bit > value 0FFFF_FFFFh (4 GiB - 1 B). This happens when opening a file (size > only), after a non-zero-length write or read changes the seek position, > or when a (32-bit) "seek from EOF" or a 64-bit seek has concluded, or > when passing directory entries to the (SFN) FindFirst/FindNext results. > > > 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 > > Regards, > ecm > > > [1]: > > https://github.com/dosemu2/dosemu2/blob/2a0b157ae7c13431b71bedefc1de6f5060bd7957/src/dosext/mfs/mfs.c#L3876 > [2]: > > https://github.com/dosemu2/dosemu2/blob/2a0b157ae7c13431b71bedefc1de6f5060bd7957/src/dosext/mfs/mfs.c#L3559 > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel >
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
