Using "network redirector" (int 2Fh) to implement filesystem drivers

[JJ]

Hello.

Perhaps this is not very important nowadays, but...
Can one use the network redirector DOS feature to write (sortof)
filesystem drivers for DOS?
I'm looking at the sourcecode of SUSHCDX (i.e. FreeDOS version of
MSCDEX), and it calls some functions from int 2Fh.

JJ

[Rod Pemberton]

My understanding is: "Yes."

Apparently, Int 2Fh was extended for network filesystems, but was
eventually used for CDROMs with ISO9660 and MSCDEX. I've not done
anything with this. There were some posts to comp.os.msdos.programmer
by a few guys working on such thing a few times over the past
eight years, as well as other groups such as alt.msdos. There is
also a variety of resources available on the internet or was.
The DJGPP C compiler, GCC based, also has a filesystem driver
interface API. I don't know if it uses Int 2Fh or something else.


I posted info and some links to redirectors with source code in
past post of mine to other newsgroups circa '06 and '09, but
some of the links are dead or missing. Here is updated info:


CPHANTOM by Thomas F. Divine
(as CPHANTOM.zip or CPHANTOM1.zip)
CPHANTOM.zip http://www.decuslib.com/decus/vmslt99a/nt/
CPHANTOM1.zip (same link)

A "ramdrive" by Davin McCall to comp.os.msdos.programmer
http://groups.google.com/group/comp.os.msdos.programmer/msg/36b34f208807076b

CMU's Mach DOS emulator i386.mdos.src.tar.Z from here:
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/src/

CDROM.C by Jim Harper
http://www.drdobbs.com/database/a-dos-redirector-for-scsi-cd-rom/184408958

IHPFS (An HPFS Driver for DOS) by Marcus Better
(as IHPFS115.zip or IHPFS128.zip or IHPFS129.arj)
IHPFS115.zip http://cd.textfiles.com/hobbesos29503/32BIT/DOS/
IHPFS128.zip http://www.student.nada.kth.se/~f96-bet/ihpfs/
IHPFS129.arj http://kannegieser.net/veit/programm/

RIFS (Remote Installable File System) by Kyle A. York
(as DOSRIF.zip or DOSRIFS.zip or DOSRIFS2.zip)
DOSRFIF.zip http://cyberside.net.ee/files/util/system/
DOSRIFS2.zip (same link)


Rod Pemberton

[JJ]

On 04-11-2014 08:55, Rod Pemberton wrote:
> The DJGPP C compiler, GCC based, also has a filesystem driver
> interface API. I don't know if it uses Int 2Fh or something else.

Where can I get information on this interface? I couldn't find it in the
website.

> CPHANTOM by Thomas F. Divine
> (as CPHANTOM.zip or CPHANTOM1.zip)
> CPHANTOM.zip http://www.decuslib.com/decus/vmslt99a/nt/
> CPHANTOM1.zip (same link)

That directory sounds cool.... Especially those ntdll.txt and defrag.txt
stuff... Crazy stuff for crazy people!...
But, I didn't quite understand what that CPHANTOM thing does. It's a
redirector, right, but what FS does it implement, if any? Looks like a
skelton to build upon ("Reads just retuns the specified number of bytes
of garbage.").

Thkx.

JJ

[Rod Pemberton]

On Sun, 23 Nov 2014 19:27:38 -0500, JJ <j...@nospicedham.jj.org> wrote:
> On 04-11-2014 08:55, Rod Pemberton wrote:

>> The DJGPP C compiler, GCC based, also has a filesystem driver
>> interface API. I don't know if it uses Int 2Fh or something else.
>
> Where can I get information on this interface? I couldn't find
> it in the website.
>

1) if you've installed DJGPP, libc.info in the
'info' directory, has a section called
"File Sytem Extensions" which explains things.
That section has about 18 functions that begin
with "__FSEXT_", which I'm *guessing* get called
for your handler. There are another 7 control
functions that begin with "__FSEXT_" elsewhere
in libc.info, which I'm *guessing* install the
handler. They are all listed in DJGPP's include
"fsext.h" in the 'include/sys' directory.

2) On delorie.com, the same info is available on
a number of webpages:

http://www.delorie.com/djgpp/doc/libc/libc_321.html
http://www.delorie.com/djgpp/doc/libc/libc_356.html
http://www.delorie.com/djgpp/doc/libc/libc_357.html
http://www.delorie.com/djgpp/doc/libc/libc_358.html
http://www.delorie.com/djgpp/doc/libc/libc_359.html
http://www.delorie.com/djgpp/doc/libc/libc_360.html
http://www.delorie.com/djgpp/doc/libc/libc_361.html
http://www.delorie.com/djgpp/doc/libc/libc_362.html

>> CPHANTOM by Thomas F. Divine
>> (as CPHANTOM.zip or CPHANTOM1.zip)
>> CPHANTOM.zip http://www.decuslib.com/decus/vmslt99a/nt/
>> CPHANTOM1.zip (same link)
>
> That directory sounds cool....

I have no idea what's in the rest of the directory.
I found the directory when searching for an online
copy of CPHANTOM since my old link was bad.

> Especially those ntdll.txt
> and defrag.txt stuff... Crazy stuff for crazy people!...

It appears the items you mentioned where from guys
who got hired by M$ Research for doing such things.

> But, I didn't quite understand what that CPHANTOM thing does.

Uh, yeah ... I don't know what CPHANTOM does.
I never really had a chance to look at any of this.
I tracked this stuff down when I was working on a
creating assembly source for a Public Domain, DOS
device driver, which only had a binary. That was
some years ago now.

> It's a redirector, right, but what FS does it implement, if any? Looks
> like a skelton to build upon ("Reads just retuns the specified number of
> bytes of garbage.").

A quick read of CPHANTOM.C seems to indicate it's
just a template or "skeleton". The author didn't
implement any routines to perform a useful driver.

Harry Potter on comp.os.msdos.programmer, where you've
posted in the past too, is asking about device drivers
also. E.g., if you haven't seen it, see my 2nd reply in:
"some old DOS programming articles online", Nov 15


Rod Pemberton

[JJ]

On 24-11-2014 22:07, Rod Pemberton wrote:
>> Especially those ntdll.txt
>> and defrag.txt stuff... Crazy stuff for crazy people!...
>
> It appears the items you mentioned where from guys
> who got hired by M$ Research for doing such things.

I have some interest in NT APIs, also. And... many other things!

> Harry Potter on comp.os.msdos.programmer, where you've
> posted in the past too, is asking about device drivers
> also. E.g., if you haven't seen it, see my 2nd reply in:
> "some old DOS programming articles online", Nov 15

Not the same guy! I'm João Jerónimo.

JJ (João Jerónimo)

[João Jerónimo]

On 24-11-2014 22:07, Rod Pemberton wrote:

> 1) if you've installed DJGPP, libc.info in the 'info' directory, has
> a section called "File Sytem Extensions" which explains things. That
> section has about 18 functions that begin with "__FSEXT_", which I'm
> *guessing* get called for your handler. There are another 7 control
> functions that begin with "__FSEXT_" elsewhere in libc.info, which
> I'm *guessing* install the handler. They are all listed in DJGPP's
> include "fsext.h" in the 'include/sys' directory.

Rod, Thanks for the information. As far as I have found out, these
__FSEXT_ stuffs only work inside the current DJGPP program (i.e. they
don't convert the program into as TSR that can be called by other functions.
It becomes clear from what says in:
http://www.delorie.com/djgpp/doc/libc/
!Quoting that Webpage:
> This function can be hooked by File System Extensions (see section
> File System Extensions). If you don't want this, you should use
> _dos_creat (see section _dos_creat) or _dos_creatnew (see section
> _dos_creatnew).

It says that _dos_creat always calls the non-LFN version of DOS file
creation system call, and that the __FSEXT_ hooks don't affect it. So,
the __FSEXT_ hooks are not related to the kernel at all, otherwise they
would be valid for _dos_creat as well.

JJ

[Rod Pemberton]

On Wed, 21 Jan 2015 22:50:24 -0500, João Jerónimo
<joao.jer...@nospicedham.gmail.com> wrote:
> On 24-11-2014 22:07, Rod Pemberton wrote:

>> 1) if you've installed DJGPP, libc.info in the 'info' directory, has
>> a section called "File Sytem Extensions" which explains things. That
>> section has about 18 functions that begin with "__FSEXT_", which I'm
>> *guessing* get called for your handler. There are another 7 control
>> functions that begin with "__FSEXT_" elsewhere in libc.info, which
>> I'm *guessing* install the handler. They are all listed in DJGPP's
>> include "fsext.h" in the 'include/sys' directory.
>
> Rod, Thanks for the information.

...

> As far as I have found out, these
> __FSEXT_ stuffs only work inside the current DJGPP program

They'll only work for your current DJGPP program.
Of course, you can use them in as many programs as you like.

> (i.e. they don't convert the program into as TSR

DJGPP shouldn't be used for DOS TSRs.
(And, I think you're not using "TSR" correctly.)

> (i.e. they don't convert the program into as TSR that can be
> called by other functions.

They'll only work for the application where you've coded them.
You can't extend DJGPP or DOS to use the functions you've installed.

You really don't want to use DJGPP for coding TSRs for DOS.
The reasons why DJGPP is bad with TSRs is off-topic for
comp.lang.asm.x86. You can post to comp.os.msdos.programmer.

> It becomes clear from what says in:
> http://www.delorie.com/djgpp/doc/libc/
> !Quoting that Webpage:
>"This function can be hooked by File System Extensions (see section
> File System Extensions). If you don't want this, you should use
> _dos_creat (see section _dos_creat) or _dos_creatnew (see section
> _dos_creatnew)."
>
> It says that _dos_creat always calls the non-LFN version of DOS file
> creation system call, and that the __FSEXT_ hooks don't affect it. So,
> the __FSEXT_ hooks are not related to the kernel at all, otherwise they
> would be valid for _dos_creat as well.

I'm not sure what you mean by "the kernel" in context of DJGPP.

DJGPP is a GNU C compiler with a custom DOS library in C. DJGPP's C
library calls about 170 DOS functions and subfunctions.

DJGPP creates a DOS DPMI application. This application is comprised
of 16-bit code and 32-bit code. The 16-bit code when executed checks
for XMS, VCPI, DPMI, and other methods of obtaining DOS memory or for
switching to PM. It then conditionally loads a DPMI host. It loads
a DPMI host when none are already installed. Windows 98/SE console
has built-in DPMI, so that's one environment where it would use Windows
98/SE DPMI host instead of CWSDPMI or PMODEDJ. It then loads the
32-bit DJGPP COFF portion of the executable and executes it.

So, DJGPP's C library calls many DOS functions, but DOS isn't completely
reentrant. Only some DOS functions can be called while DOS is executing.
This basically limits DOS to only executing one application at a time.
What this means is if you're executing both a DOS application and a DOS
TSR, the TSR can't use DOS while the application is calling DOS, for most
DOS functions. This problems affects DJGPP TSRs and non-DJGPP TSRs such
as in assembly or for TurboC, etc. It's a DOS issue.

One critical issue with DJGPP TSRs is that you can only lock memory
for your code and data. You can't lock memory for code used by DJGPP's
C library or the DPMI host such as CWSDPMI or the XMS host. This is a
problem because the interrupt wrappers DJGPP uses don't lock memory and
there is no method to determine what memory needs to be locked. This
is what I believe cause more complicated TSRs in DJGPP to simply fail.

So, there are many, many problems with using DJGPP for TSRs, including
a dozen or more I haven't gone into. That's in addition to the usual
problems with coding TSRs in assembly. However, the main problem isn't
the coding errors or problems. The main problem is lack of people who
can or will help who have the knowledge to do so. What I've found that
the three knowledgeable contributors to DJGPP never help anyone when
they have a problem implementing a TSR using DJGPP. They simply tell
everyone to read the documentation. It's my belief that they understand
that DJGPP is very limited or faulty in the functionality to create TSRs.

Basically, you can do very simple TSRs with DJGPP, such as timer
interrupts or keyboard characters. However, thses TSRs will fail 1% to
3% of the time when used. More complicated TSRs, which is why most
people want to code a TSR in C, such as a LFN driver in DOS, basically
can't be implemented using DJGPP, or it requires custom assembly to
fix DJGPP's issues. Essentially, no one is going to help you with this.


Rod Pemberton