[net.micro.cpm] File Open BDOS patch

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.