Re: documentation for fs redirector

[Mike McCarty <Mike.McCarty@sbcglobal.net>]

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