Remote filesystem implementation in DOS
Jonathan Thomas
I have a file storage device that contains it's own internal
filesystem and driver software, and therefore may not be accessed as a
block device. Rather, it expects to be issued commands such as "create
file", "seek file location", "write to file" and so on - commands that
correspond to those provided by INT 21 filesystem calls.
Does DOS provide a device-driver framework for such devices? I know
it's possible to implement device drivers for block devices, but I'm
obviously looking for something that works at a higher level. I guess
it's in a similar vein to an NFS or Netware driver for DOS, but
without all the networking code.
I'd also appreciate some pointers on where to find examples of driver
source code.
Thanks in advance for any help.
Jon
Tapio Kelloniemi
>Hypothetical situation:
>I have a file storage device that contains it's own internal
>filesystem and driver software, and therefore may not be accessed as a
>block device. Rather, it expects to be issued commands such as "create
>file", "seek file location", "write to file" and so on - commands that
>correspond to those provided by INT 21 filesystem calls.
>
>Does DOS provide a device-driver framework for such devices? I know
>it's possible to implement device drivers for block devices, but I'm
>obviously looking for something that works at a higher level. I guess
>it's in a similar vein to an NFS or Netware driver for DOS, but
>without all the networking code.
I would hook INT 21 and if some of file access functions is called, then
check, if drive number is correct. If it is not, then pass registers to
next handler, otherwise handle it your self and convert the INT 21
commands to some ios calls.
I don't know wheter there is a better way, I would do it like this.
I'd have an additional question to folks:
How can I allocate drive letter, ie. how eg. interlink does it?
--
Tapio
Jonathan Thomas
> I would hook INT 21 and if some of file access functions is called, then
> check, if drive number is correct. If it is not, then pass registers to
> next handler, otherwise handle it your self and convert the INT 21
> commands to some ios calls.
> I don't know wheter there is a better way, I would do it like this.
>
Thanks for the quick response.
The problem is - if I hook int21, I also need to take over the "file
open" and "file close" functions, which means using my own algorithm
to return file handles for the external file system that co-exist with
those provided by DOS. Although I could dig in and look at MS-DOS's
implementation of file handle allocation, then allocate file handles
accordingly, this may prevent my driver from working with DR-DOS,
FreeDOS etc.
I also can't use DOS to provide file opening and closing services (and
therefore file handles) for my remote device, as it doesn't "know"
about the files on my remote file system.
I wonder if DOS provides an lower-level function call to allocate a
file handle that it then won't use for it's own purposes (at least
until I tell it that the handle is no longer in use) ? I'll take a
look in Ralf Brown's interrupt list.
Any further comments or suggestions much appreciated in the meantime!
Cheers
Jon
Dosius
> The problem is - if I hook int21, I also need to take over the "file
> open" and "file close" functions, which means using my own algorithm
> to return file handles for the external file system that co-exist with
> those provided by DOS. Although I could dig in and look at MS-DOS's
> implementation of file handle allocation, then allocate file handles
> accordingly, this may prevent my driver from working with DR-DOS,
> FreeDOS etc.
>
> I also can't use DOS to provide file opening and closing services (and
> therefore file handles) for my remote device, as it doesn't "know"
> about the files on my remote file system.
>
> I wonder if DOS provides an lower-level function call to allocate a
> file handle that it then won't use for it's own purposes (at least
> until I tell it that the handle is no longer in use) ? I'll take a
> look in Ralf Brown's interrupt list.
>
> Any further comments or suggestions much appreciated in the meantime!
>
> Cheers
>
> Jon
The phrase is "network redirector", but unfortunately that's all the
help I can provide. Interlnk, mscdex, etc., use the network
redirector interface to provide drive letters to DOS.
Matthias Paul
> Hypothetical situation:
> I have a file storage device that contains it's own internal
> filesystem and driver software, and therefore may not be accessed as
> a block device. Rather, it expects to be issued commands such as
> "create file", "seek file location", "write to file" and so on -
> commands that correspond to those provided by INT 21 filesystem
> calls.
Not so hypothetical situation at all. Most network drives work
this way. The interface you are looking for exists since DOS 3.3+,
is undocumented, and is known as "redirector interface".
See Ralf Brown's Interrupt List and "Undocumented DOS" for
details. (DR DOS 5.0+ has a full implementation of it as well.)
> Does DOS provide a device-driver framework for such devices?
> I know it's possible to implement device drivers for block devices,
> but I'm obviously looking for something that works at a higher level.
>
> I guess it's in a similar vein to an NFS or Netware driver for DOS,
> but without all the networking code.
Exactly. MSCDEX/NWCDEX or DRFAT32 are examples for such drivers.
> I'd also appreciate some pointers on where to find examples of driver
> source code.
See the "Phantom" RAM disk driver in "Undocumented DOS", 2nd edition.
Hope it helps,
Matthias
--
<mailto:Matthi...@post.rwth-aachen.de>; <mailto:mp...@drdos.org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
"Programs are poems for computers."
Jonathan Thomas
I'll source a copy of Undocumented DOS (which must be a good book
judging by the amount of usenet coverage it gets!) and look into it.
Wojciech Galazka
Go, grab a source code for a cdrom redirector from www.pcausa.com
Matthias Paul
> I'll source a copy of Undocumented DOS (which must be a good book
> judging by the amount of usenet coverage it gets!) and look into it.
This is really one of the "must have" books for any serious system
programming under DOS.
Andrew Schulman, Ralf Brown, David Maxey, Raymond H. Michels, Jim Kyle:
"Undocumented DOS - A programmer's guide to reserved MS-DOS functions
and data structures - expanded to include MS-DOS 6, Novell DOS,
and Windows 3.1", 2nd edition, 1993-11, Addison & Wesley,
ISBN 0-201-63287-X. Be sure to actually get the "red covered"
2nd edition with floppy disk, original price was USD 45,-.
Although no longer in print, Amazon still has new copies of this
book, occasionally.
(Not related to the original topic, but the latest issue of
Jim Kyle's DEVLOD device driver loader from this book can be
officially found as DEVLOAD in the DR-DOS 7.02+ distribution.
It comes without sources, though.)
Another "must have" book of this category is Geoff Chappell's
"DOS Internals", 1994-01, Addison & Wesley, ISBN 0-201-60835-9.
Barnes & Noble still had new copies recently.
The current issue of Ralf Brown's Interrupt List (RBIL62) can be
found at Ralf's homepage at:
http://www.pobox.com/~ralf/files.html.
For the redirector interface, have a look at: INT 2Fh/AX=11xxh.
The next issue of RBIL may add some more details on this interface
I found out in the meantime.
Greetings,
Ralf A. Quint
<Matthi...@post.rwth-aachen.de> wrote:
>
>The current issue of Ralf Brown's Interrupt List (RBIL62) can be
Well, is that with the "62" still wishfull thinking or is the new
version actually out?
>found at Ralf's homepage at:
>
> http://www.pobox.com/~ralf/files.html.
>
Beside that this link actually redirects to
http://www-2.cs.cmu.edu/afs/cs/user/ralf/pub/WWW/files.html,
the files available for download are still RBIL61 as of 21:20 PST....
:-(((
Ralf
Matthias Paul
>> The current issue of Ralf Brown's Interrupt List (RBIL62) can be
>
> Well, is that with the "62" still wishfull thinking or is the new
> version actually out?
It's still RBIL61. Thanks for correcting me. Sorry, if I have caused
any confusion. It seems I slowly start getting confused myself with
all these different file versions still in the queue for more than
two years now... ;-)
I don't know when Ralf will release RBIL62 eventually. According
to him, RBIL62 was scheduled for early summer this year, but then
it got delayed again, probably due to lack of his time. I guess,
the project needs way more contributors and (preferably natively
English) proof-readers, who are willing to pre-process and validate
(where possible) the incoming stuff and convert it into RBIL format
to make the actual list editing easier for Ralf.
Jonathan Thomas
I'll await my copy of Undocumented DOS and draw upon all the resources
you've suggested.