From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike McCarty Subject: Re: documentation for fs redirector Date: Thu, 15 Nov 2007 11:34:55 -0600 Message-ID: <473C833F.7000408@sbcglobal.net> References: <200711122300.05659.zswi@pers.pl> <200711151726.57487.zswi@pers.pl> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <200711151726.57487.zswi@pers.pl> Sender: linux-msdos-owner@vger.kernel.org List-Id: Content-Type: text/plain; charset="windows-1252"; format="flowed" To: =?UTF-8?B?UmFmYcWCIEN5Z25hcm93c2tp?= , FreeDOS Rafa=C5=82 Cygnarowski wrote: > Hi! >=20 >> int21/ah=3D6c is the one to use for a DOS app. IIRC DJGPP programs u= se >> this one for straight C programs; otherwise you'd have to call it >> manually. >=20 > > INT 2F CU - NETWORK REDIRECTOR (DOS 4.0+) - EXTENDED OPEN/CREATE FILE > AX =3D 112Eh > SS =3D DS =3D DOS DS >=20 > [cut] >=20 > 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 act= ion > code is 11h, > the result code in CX is not passed back to the applicati= on. > >=20 > and: >=20 > > INT 21 - DOS 4.0+ - EXTENDED OPEN/CREATE > AX =3D 6C00h >=20 > [cut] >=20 > BUG: this function has bugs (at least in DOS 5.0 and 6.2) when use= d with > drives handled via the network redirector (INT 2F/AX=3D112E= h): > - CX (attribute) is not passed to the redirector if DL=3D= 11h, > - CX does not return the status, it is returned unchanged= because > DOS does a PUSH CX/POP CX when calling the redirector. > >=20 > I wanted make workaround for this while I use DOS versions affected b= y this=20 > bug. I found CX value on the stack and changed this value so int21 co= uld pop=20 > it. Unfortunately CX still contains file attribute instead of my repl= aced=20 > result. Why? Is my idea completely wrong or I just missed sth? Maybe = I should=20 > use some TSR witch could catch int21 inside DOS and do the thing? - I= 'm not=20 > an assembler guru and I really don't know what if and what I can do m= ore... 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 --=20 p=3D"p=3D%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