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
