SETDRU.DOC Page 1 Copyright 1983 Michael M Rubenstein Permission is granted to distribute this software and documentation provided no fee is charged and the copyright notice is retained. Credit where credit is due. SETDRU was written in C and Z80 assembly language. It was compiled with the Software Toolworks C80 compiler and Microsoft M80 assembler. CP/M and CP/M Plus are trademarks of Digital Research. WordStar, MailMerge, and SpellStar are trademarks of Micropro International Corporation. Microsoft, Multiplan are trademarks of Microsoft Corporation. The Word Plus is a trademark of Oasis Systems. Perfect Writer is a trademark of Perfect Software. Z80 is a registered trademark of Zilog, Inc. What is it? Ok, you got a hard disk for your CP/M system. It's great having all that disk space, but then there are the problems. The directories get pretty big; even with a sorted listing (as from SD) it's pretty hard to keep track of what you've got. So, you start putting things in different user areas. CP/M sure doesn't make that easy though. Fortunately, there are a number of programs (SWEEP for example) which make it easy to move things around. Now that things are in different user areas, you can keep track of them, but there's another problem -- you end up with lot's of copies of some of those programs because CP/M doesn't let you access a program from more than one user area. So you search around and find some program which will let you access a program from any user area (and from any disk, so you don't always have to specify the disk). ZCPR by Richard Conn works nicely. That helps with a lot of your programs, but not with all. What's the problem? Well, a lot of the programs you want to use need overlays. Many -- too many -- don't allow you to specify where those overlays will be. So you need copies, of the overlays at least, on each user number. Others need data files or swap files. A system can get pretty cluttered just with WordStar overlays. SETDRU allows you to use most (unfortunately, not all) programs with some of the files used by the program redirected to standard drive and user areas. When combined with something like ZCPR it allows a single copy of a program to be accessible from any drive and user area. SETDRU.DOC Page 2 What's it need? SETDRU requires CP/M 2.2 Z80 processor. It will run with a minimum of memory. SETDRU will probably not be very useful unless the system contains a hard disk. I have reports that SETDRU also works under CP/M Plus. An 8080 version of SETDRU is being prepared by another person and should be available soon. How does it work? SETDRU installs a "filter" in high memory which monitors file accesses and modifies them, if necessary, to use standard drive and user areas. This filter is a temporary thing; it will disappear as soon as the program terminates. When you apply SETDRU to a program, you tell it which files need to be redirected to another drive and user number. SETDRU may be installed as a modification to the program (integrated) or as a separate program which loads and executes the desired program. Advantages of integrating SETDRU with the program: 1. There's one less file to keep track of. 2. In many cases, because of the allocation unit of CP/M, no extra disk space is required. Advantages of separating SETDRU from the program: 1. This technique may be used with programs, such as WordStar, which verify the program on disk. (WordStar does this when you try to use MailMerge or run a program.) 2. Since the program is unchanged, installation procedures are not affected. Also, some programs may modify themselves. This is only possible with separate installation. 3. If you haven't installed a system to make programs accessible to any user area, you only have a small program (about 1k) to make multiple copies of in different user areas. When won't it work? There are several things a program might do which will make it impossible to use SETDRU with it. SETDRU cannot handle programs which: 1. Require the CCP to remain resident (e.g. EX or SYNONYM). SETDRU.DOC Page 3 2. Use the BDOS entry address (at location 6) to determine addresses in the BDOS. 3. Modify the device field in the FCB after the file is opened. (This should never happen, but, of course, it does. This is the problem with applying SETDRU to MultiPlan.) There are, undoubtedly, other situations which will make SETDRU unusable. SETDRU makes some assumptions as to what is intended. These assumptions are usually valid, but may not always give the desired result. Installing SETDRU. When SETDRU is run, a summary of the instructions is displayed and you will be asked a series of questions. At any point in the procedure, you may terminate without installation by typing control C (^C). Upper or lower case may be used. The first question is Do you want SETDRU integrated with the program (y or n)? Respond "y" or "n" (and press return). SETDRU will then ask for the name of the program to which it is to be applied. The file type (usually .COM, but it may be different for special situations) must be specified. If SETDRU is to be integrated with the program, a copy must be accessible. The drive must be specified if it is not on the default drive. Make sure you have another copy (several others!!!) as backup in case you have to reinstall SETDRU or you find it won't work. If SETDRU is not to be integrated, the program need not be available. The drive specified is the drive from which the program is to be loaded when invoked. In this case, you will be asked for the user number from which the program is to be loaded. SETDRU then asks What is the name of the program to be created? Enter the name you wish to use to invoke the program. Again, the file type (usually .COM) must be specified. The drive on which the output is to go may also be specified. Note that this name may be the same as the name of the program to which SETDRU is applied. This is fairly normal when integrating and may occasionally be useful when not integrating. You will then be asked for a list of up to 8 files which are to be redirected. If you don't need to use all of them, just press return to terminate. SETDRU.DOC Page 4 If the drive is specified, it is the drive where the program will look for the file at run time. The user number is the user number where the program will look. If not specified, the current (AT INSTALLATION TIME) drive and/or user number is used. Now comes the hard part -- deciding on the file redirection. The order in which the files are specified is important. File names may be ambiguous (using "?" or "*") or unambiguous. When a the program attempts to open, search for, create, rename, or delete a file, the list of files will be scanned. For an open or search, the file will match the first ambiguous or unambiguous name on the list. If the name on the list is ambiguous, an attempt will be made to open the file on the drive specified by the program. If this fails, the open will be attempted on the drive and user specified in the list. If the name on the list is unambiguous, the file will always be redirected. For the other operations, only unambiguous names in the list may match. If there is a match, the file will be redirected. In any case, if there is no match, the file will not be affected. Examples. The rules for redirection look more complicated than they really are. For most practical purposes, you may just assume that an input file matching an ambiguous name will be redirected only if it cannot be otherwise found, and that an input or output file which matches an unambiguous name will always be redirected. There are a few things to watch out for. Remember that most programs do not create files with the name you finally see. It's common to use the same name with a file type of .$$$, but other schemes are sometimes used. You will have to specify the name actually used for creation of the file. Also, it's possible to really confuse a program if the order of the files in the list is not correct. For example, if you have the names foo.* foo.bar in the list, the program may write foo.bar to a redirected drive and user number, but then read a copy on the current drive (or the drive specified by the program) and the current user. It's almost always best to put unambiguous file names first in the list. Example 1: CAT (public domain catalog program). This is a simple case. The program uses a file called MAST.CAT, SETDRU.DOC Page 5 normally on the current drive and user. There is no reason not to use an integrated installation. If you wish to keep MAST.CAT on drive A: user 0, the file list consists of A:MAST.CAT user 0 Example 2: Perfect Writer This is only a little more complicated. If you use an integrated installation, you will have to use a plain copy of the program if you wish to modify Perfect Writer, so a separate installation of SETDRU should be considered. Let's assume we decided to use an integrated installation and put up with a little more work to modify the program. Perfect Writer uses a file PW.SWP as a virtual memory work area. It may use a file PW.HLP for help. Again assuming both files are on drive A: user 0, the list A:PW.SWP user 0 A:PW.HLP user 0 will work. Example 3: WordStar When a program is run is or SpellStar is invoked, WordStar must load another program and run it. Before doing this, WordStar checks to make sure that a valid version of WordStar is available. It will not recognize a copy which has been integrated with SETDRU, so a separate installation is called for. In order to keep WordStar accessible, one could include in the file list the WS.COM, but one probably has other .COM files that one might wish to run, so *.COM should be included. WS.COM need be included only if it is not on the same drive as the other .COM files. WordStar also uses overlays. Just which overlays, depend on the options used with WordStar, so it's probably best not to specify the unambiguous names. Let's assume that WS.COM and the overlays are on drive B: user 15, but that other .COM files that one might run are on drive A: user 0. The list B:WS.COM user 15 B:*.OVR user 15 A:*.COM user 0 would be appropriate. Note that this would not work properly if *.COM were before WS.COM. The program generated by SETDRU could have the name WS.COM if it were put elsewhere than drive B: user 15, but that could get confusing. It should have a different name, or one could reinstall WordStar with a SETDRU.DOC Page 6 different name. Example 4: The Word Plus This final example is rather complex. The Word Plus is a spelling checker which is implemented as a collection of programs with a master program controlling them. The programs use various files with file types .TXT and .CMP. The master program, TW.COM, may modify itself under certain options. Furthermore, logical updates to the main dictionary are actually put in a file UPDICT.CMP. When this file is updated, a new version is created as UPDICT.$$$ and then renamed. One could make this even more complex, as special dictionaries can be updated by the program also. We'll assume that any special dictionaries will be accessible though. If all these files are on drive b: user 4, an appropriate file list would be TW.COM user 4 UPDICT.CMP user 4 UPDICT.$$$ user 4 *.CMP user 4 *.COM user 4 Removing installation of SETDRU. Sometimes it will be necessary to remove SETDRU from a program. This is only a problem if SETDRU has been integrated with the program, as if it is separate, all that's required is to delete the separate program generated by setdru. To do this, the program UNSETDRU is provided. It is invoked with the command unsetdru where is the name of the program from which SETDRU is to be removed. The file type (usually .COM) must be specified. Make sure you have a backup before doing this. For the hacker. The source code of SETDRU and UNSETDRU have been released. The installation program source code won't be that useful without quite a bit of work since it uses a private run time system. It should be possible to modify it for your flavor of C, or to rewrite it in whatever language you prefer -- it's not a very complicated program. SETDRU.DOC Page 7 The filters themselves SDRU1 and SDRU2 (which are used when not integrated or integrated respectively) are much more interesting. These are coded for Microsoft's M80 assembler using Z80 mnemonics. The principles involved are quite simple, though the implementation is a bit tricky in places. The filter intercepts all BDOS calls. For certain file calls (open, make, etc.) the table of file names is searched for a match. In some cases (make, delete, rename) only unambiguous names in the list may be matched. If no match is found, control is simply passed to the BDOS to process the request. If a match is found, the request is modified to the desired drive and user and tried (for open and search, the request is first tried unmodified and only modified if not found). Assuming the modified request is satisfied, the drive in the fcb is then changed to 17 plus the address (relative to the start of the table) at which the match occurred. This is an otherwise illegal drive specification which will be detected on other operations. On any other file operation, the drive is checked and if illegal is modified to the desired drive and the user number is changed to the desired value. Of course, these must be changed back before returning to the program. There are some details to take care of to install the filter. If integrated (SDRU2), the required program must first be loaded. Otherwise (SDRU1), the program must be moved down to the start of the TPA (0100H). In either case, the filter must be moved up to just below the BDOS. Moving it is easy enough, but there are a number of locations which must be relocated. This is done in a very simple manner. When modifying either of the filters, care must be taken to preserve the relocation. Because relatively few people will have any need to modify the installation program and because it is written using a nonstandard run time library, a relocatable version (SETDRU.REL) is provided containing all needed routines except the filters themselves. There are a few things which must not be changed if this installation program is to be used. The start of each filter must contain Bytes Usage ------- --------------------------------------------------- 0- 2 A jump to the executable code. 3- 4 The length of the filter. 5- 6 The length of the program to be loaded will be put here by the installation program. This is only used by SDRU2. It is not set or used for SDRU1. 7- 19 The drive, user number, and name of the program to which SETDRU is being applied. This is only SETDRU.DOC Page 8 significant for SDRU1, though it is set for SDRU2 also. 20-123 The table of file names to be redirected. Each entry contains the drive (A=1, B=2, ...), the user number, and the file name (as it appears in an FCB). Asterisks are expanded to question marks. 123-135 Identification for the filter. This is only significant for SDRU2, where it must be "***SETDRU2***" for unsetdru to work. Note that the only parts of SETDRU which is dependent on the Z80 are the filters themselves (SDRU1 and SDRU2). The installation program and run time system will run on an 8080. After modifying either of the filters, a new version may be linked with the command l80 setdru/n,setdru,sdru1,sdru2/e I'm not sure what modifications anyone would want to make for general use, but it might be necessary to change some things for specific programs. The following variations have been found useful in the predecessors to SETDRU. These are not so much recommendations as suggestions for things to look at. SETDRU will not work with Multiplan. The problem is that Multiplan contains code to 1. Open the overlay file on the current drive and user number. 2. Get the current drive. 3. Change the FCB (while it's open!!) for the current drive. Horrible isn't it? Well, it doesn't do much good to complain about turkeys writing programs; we're stuck with them. If the filter is modified so that the first call to BDOS function 25 (get current drive) lies and actually returns the drive the overlay file is on (and the help file; they must be on the same drive), Multiplan will work fine with SETDRU (I think. This has not actually been tested, but it works in another such filter.) The filter might also be modified to correct deficiencies in the program or operating system. For example, on a CP/M lookalike which supposedly supported incremental backups through an archive attribute, I found that the system would allow the archive attribute to be set by the rename BDOS call. Unfortunately, WordStar renames the temporary (.$$$) file with the same attributes as the original file. This resulted in modifications made by WordStar not being detected for backups. It was a simple matter to always clear the archive bit on a rename. (Again, this was not actually done with SETDRU, but with another, similar filter -- still, it should work here too.) SETDRU.DOC Page 9