documentation for fs redirector

documentation for fs redirector

[Rafał Cygnarowski]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

Hi!

I'm trying to write samba fs redirector but I have problems with correct 
documentation of fs redirector. I found some example codes (including this 
one in dosemu) and residual documentation and these all contains 
contradictory informactions :(

I'm especially interested now in open/create/truncate/share modes and 
MULTIPURPOSE_OPEN (2E) subfunction. In case of later I need also know where I 
really need to place result (I found two versions one says that EDX is right 
place and second says about ECX).

There's also one more thing. Maybe it's stupid, but I can't find way to test 
this 2E subfunction. I found some programs witch use it in some cases but 
some c/c++ dos program would be the best in my case - if someone could point 
me how force dos to use this function I would be gratefull. 

Thanks in advance for every (correct ;)) piece of information.
-- 
Rafał Cygnarowski
rafi@pers.pl

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: documentation for fs redirector

[Bart Oldeman]

Hi,

> I'm trying to write samba fs redirector but I have problems with correct
> documentation of fs redirector. I found some example codes (including this
> one in dosemu) and residual documentation and these all contains
> contradictory informactions :(

Yes, that's the problem with undocumented interfaces... Ralf Brown is
good but not complete.
There are registers, the stack, fields in the SDA, and fields in the
SFT, and different redirectors use different fields.

> There's also one more thing. Maybe it's stupid, but I can't find way to test
> this 2E subfunction. I found some programs witch use it in some cases but
> some c/c++ dos program would be the best in my case - if someone could point
> me how force dos to use this function I would be gratefull.

int21/ah=6c is the one to use for a DOS app. IIRC DJGPP programs use
this one for straight C programs; otherwise you'd have to call it
manually.

Bart

Re: documentation for fs redirector

[Rafał Cygnarowski]

[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]

Hi!

> int21/ah=6c is the one to use for a DOS app. IIRC DJGPP programs use
> this one for straight C programs; otherwise you'd have to call it
> manually.

<quotation>
INT 2F CU - NETWORK REDIRECTOR (DOS 4.0+) - EXTENDED OPEN/CREATE FILE
        AX = 112Eh
        SS = DS = DOS DS

[cut]

BUG:    this function is not called correctly under some DOS versions
          (at least 5.0 and 6.2):
            the file attribute on the stack is not correct if the action
              code is 11h,
            the result code in CX is not passed back to the application.
</quotation>

and:

<quotation>
INT 21 - DOS 4.0+ - EXTENDED OPEN/CREATE
        AX = 6C00h

[cut]

BUG:    this function has bugs (at least in DOS 5.0 and 6.2) when used with
          drives handled via the network redirector (INT 2F/AX=112Eh):
            - CX (attribute) is not passed to the redirector if DL=11h,
            - CX does not return the status, it is returned unchanged because
              DOS does a PUSH CX/POP CX when calling the redirector.
</quotation>

I wanted make workaround for this while I use DOS versions affected by this 
bug. I found CX value on the stack and changed this value so int21 could pop 
it. Unfortunately CX still contains file attribute instead of my replaced 
result. Why? Is my idea completely wrong or I just missed sth? Maybe I should 
use some TSR witch could catch int21 inside DOS and do the thing? - I'm not 
an assembler guru and I really don't know what if and what I can do more...

Regards,
-- 
Rafał Cygnarowski
rafi@pers.pl

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: documentation for fs redirector

[Mike McCarty]

Rafał Cygnarowski wrote:
> Hi!
> 
>> int21/ah=6c is the one to use for a DOS app. IIRC DJGPP programs use
>> this one for straight C programs; otherwise you'd have to call it
>> manually.
> 
> <quotation>
> INT 2F CU - NETWORK REDIRECTOR (DOS 4.0+) - EXTENDED OPEN/CREATE FILE
>         AX = 112Eh
>         SS = DS = DOS DS
> 
> [cut]
> 
> BUG:    this function is not called correctly under some DOS versions
>           (at least 5.0 and 6.2):
>             the file attribute on the stack is not correct if the action
>               code is 11h,
>             the result code in CX is not passed back to the application.
> </quotation>
> 
> and:
> 
> <quotation>
> INT 21 - DOS 4.0+ - EXTENDED OPEN/CREATE
>         AX = 6C00h
> 
> [cut]
> 
> BUG:    this function has bugs (at least in DOS 5.0 and 6.2) when used with
>           drives handled via the network redirector (INT 2F/AX=112Eh):
>             - CX (attribute) is not passed to the redirector if DL=11h,
>             - CX does not return the status, it is returned unchanged because
>               DOS does a PUSH CX/POP CX when calling the redirector.
> </quotation>
> 
> I wanted make workaround for this while I use DOS versions affected by this 
> bug. I found CX value on the stack and changed this value so int21 could pop 
> it. Unfortunately CX still contains file attribute instead of my replaced 
> result. Why? Is my idea completely wrong or I just missed sth? Maybe I should 
> use some TSR witch could catch int21 inside DOS and do the thing? - I'm not 
> an assembler guru and I really don't know what if and what I can do more...

Without actually seeing the defective code from DOS and your
attempted workaround, it's impossible to tell. I am an old hand
at MSDOS and assembler, though not much with the undocumented
I/Fs. However, if you want you can shoot me some code and I'll
have a look. Perhaps we can work this out via e-mail.

A TSR may not be able to do what you want, unless it is rather
"smart". CX may be clobbered so far up that there's no way
for you to fix it, except in a DOS version specific manner,
if at all. One possibility is to patch DOS at install. IOW,
find the defective code, and patch over it, possibly jumping
out into your own code in a couple of places. It may not be
possible to fix this w/o clobbering something else that DOS needs,
so the patches might be significant. IOW, you might need to
trap multiple interrupt vectors and save information for more
than one level of DOS, along with flags indicating what was
taking place at the time CX got clobbered, and restore the
values the various levels of DOS need.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: documentation for fs redirector

[Rafał Cygnarowski]

[-- Attachment #1: Type: text/plain, Size: 3130 bytes --]

Hi!

Dnia czwartek, 15 listopada 2007, Mike McCarty napisał:
> Without actually seeing the defective code from DOS and your
> attempted workaround, it's impossible to tell. I am an old hand
> at MSDOS and assembler, though not much with the undocumented
> I/Fs. However, if you want you can shoot me some code and I'll
> have a look. Perhaps we can work this out via e-mail.
>
> A TSR may not be able to do what you want, unless it is rather
> "smart". CX may be clobbered so far up that there's no way
> for you to fix it, except in a DOS version specific manner,
> if at all. One possibility is to patch DOS at install. IOW,
> find the defective code, and patch over it, possibly jumping
> out into your own code in a couple of places. It may not be
> possible to fix this w/o clobbering something else that DOS needs,
> so the patches might be significant. IOW, you might need to
> trap multiple interrupt vectors and save information for more
> than one level of DOS, along with flags indicating what was
> taking place at the time CX got clobbered, and restore the
> values the various levels of DOS need.

This is fragment of dosemu code called after int2f AX=112E (just before 
quitting):

if (LOW(state->eax) == MULTIPURPOSE_OPEN /* 2E */) {
	u_char *stack_ch, *stack_cl;

	// original CX value when int21 ah=6c00 is called
        u_short in2e_fileattr = sda_ext_attr(sda); 

	// normally this should be enought
	SETWORD(&(state->ecx), out2e_result);

	// but I try to modify pushed CX on stack
	stack_ch = (u_char *) (Addr(state, ss, esp) - (784 + 6));
	stack_cl = (u_char *) (Addr(state, ss, esp) - (784 + 7));
	if (
        	((in2e_fileattr & 0x00ff) != *stack_cl) &&
		((in2e_fileattr & 0xff00) != *stack_ch)
	) {
                // sanity check
		error("Wrong stack offset for MULTIPURPOSE_OPEN!"			
			"Expected value: 0x%04x. Value on stack 0x%02x%02x\n",
                        in2e_fileattr, *stack_ch, *stack_cl);
		leavedos(1);
	}

        *stack_ch = (out2e_result & 0xFF00) >> 16;
        *stack_cl = out2e_result & 0x00FF;
}

I use this program to test if CX was set correctly:

#include <stdio.h>
#include <io.h>
#include <dos.h>
#include <conio.h>
#include <errno.h>

#define u_short unsigned int
#define u_char unsigned char

int open2e(u_short openmode, u_short fileattr, u_short fci, char *filename, 
int *respond)
{
	int __fd = -1, res;

	asm {
		mov ax, 0x6c00
		mov bx, openmode
		mov cx, fileattr
		mov dx, fci
		mov si, filename
		int 0x21
		jc blad
	}

	asm	mov res, cx;
	asm	mov __fd, ax;
	*respond = res;
	return __fd;

blad:
	asm	mov errno, ax;

	return -1;
}

int main(void)
{
	int fd, res;
	char *filename = "F:\\TEST.TXT";

	clrscr();

	fd = open2e(0x0042, 0x002a, 0x0001, filename, &res);

	if (fd == -1) {
		perror("open2e");
	} else {
		printf("2e respond: 0x%04x\n", res);
		printf("fd == %d\n", fd);
		write(fd, "write test", 11);
		close(fd);
	}

	getch();

	return 0;
}

If you need more do not hesitate to ask.

Best regards,
-- 
Rafał Cygnarowski
rafi@pers.pl

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]