Maron@LLL-MFE.ARPA (06/10/83)
I have an idea to create a patch to the BDOS file open function which would allow searching a search list consisting of Disk,,User# elements. The purpose of this patch would be to allow more than just .COM files to live on a sys: type area, but also the MINCE swap file, FORTRAN compiler error message file, BDS-C's various files etc. Would this be of use to anybody else? Does anybody know of any pitfalls? Has this already been done? I realize that this will require some code space in the CBIOS area to have enough room to accomodate the changes. I pretty much have the flowchart--what-have-you--developed but any info that someone would like to pass along would be appreciated. I believe that this would not cause any trouble with ZCPRx but I am not sure. --Neil [ MARON@LLL-MFE.ARPA]
RGF%mit-mc@sri-unix.UUCP (06/10/83)
From: Ronald G. Fowler <RGF@mit-mc> There is indeed a gotcha: as you read (or write) a file opened in this manner, eventually you're gonna come to the end of extent #0. The BDOS automatically closes that extent and opens the next. The problem is that the 2nd extent will be opened in the CURRENT user area; and will not be found (since the file was opened in some other user area along the search path). Hence, premature EOF. Two additional steps would have to be taken to get around this: 1) When the file is opened, the user # of the file would have to be recorded somewhere; either in a table (not very desirable since a fixed-size table implies a limit to the number of open files -- although the table could be made arbitrarily large) or in the fcb itself (much better insofar as # of open files is concerned, but WHERE in the FCB do you store the user #? Look at the S1 byte; I'm pretty sure it's unused). 2) The read-sequential, read-random, write-sequential and write-random system calls must be intercepted to allow the setup of the user # the REAL system calls get control; the intercept routines must get control back immediately after the real routines execute, in order to restore the user #. Note that there is no problem with default drives, since the FCB has a DR field to record the drive number, and this may be changed easily. Both TurboDOS and MP/MII allow opens to default to user #0 if a file is not found in the current user area; rather than recording the user #, both set an attribute bit in the in-memory FCB to flag the fact that the file was opened under user 0 (this technique limits you to only one public user area, however). Finally, this change will not impact ZCPR or ZCPR2 at all; it will think it has found its file in the current user area, and will not continue the search. (this will not be true of any programs that do functions 17/18 searchfirst/next before opening the file, since you can't apply this mod to them -- such programs simply won't find their files). I would like to get a copy if the mod if you proceed with this; it's something I've thought about doing for some time, and never had the time. --Ron Fowler
Maron@LLL-MFE.ARPA (06/10/83)
This message is empty.