NEWBAS11.ASM, by Gene Head, is an assembly language file that lets you
"patch" several useful features into dBase II. These patches will work on
versions 2.3B, 2.4, 2.41, 2.41Z, and the current 2.43*. (Note the asterisk
in 2.43*--versions 2.43 and 2.43Z have been dropped.)
Two of these patches come under the heading of timesavers. One allows
you to skip the opening request for today's date, while the other allows
you to skip the lengthy sign-on message, except for the two-line Ashton-
Tate copyright notice.
A third patch gives dBase II a KEYIN function that allows you to check
the last key pressed on the console keyboard by PEEKing at a memory
location. You could use this function, for example, to allow a user to
break out of a DO loop by hitting a key.
A fourth patch makes dBase II compatible with ZCPR and other similar
CP/M modifications so that you can leave DBASE.COM and DBASEOVR.COM on
drive A while you're logged into drive B (or C or D) where your command and
data files are. With this patch, dBase II will still be able to locate
DBASEOVR.COM when it needs to. It won't, however, be able to locate the
help file, DBASEMSG.TXT, unless you have it on the default drive.
The final three patches can be very useful if you're setting up a
dBase II application to be used by someone else. The FORCE patch keeps a
user from getting to the dot prompt by forcing a warm boot if a valid
command file isn't specified at startup. The PREDEFINED patch goes even
further by forcing the execution of a predefined command file on startup.
And the ESCAPE patch prevents a user from aborting to the dot prompt by
hitting the ESCAPE key. (The command SET ESCAPE OFF does the same thing,
except that it doesn't take effect until after dBase II is loaded and
starting to run, leaving the system vulnerable for a short time.) Taken
together, these patches can help you build a more secure application that
will prevent an untrained (or hostile) user from breaking out of your
program and wreaking havoc at the dot prompt.
[DB2&3MAX.INF]
DB2&3MAX.INF isn't a program or a patch file. It's actually an
electronic reprint of the article "Maximizing Performance with dBase II and
III," by Alan Simpson, originally published in _Personal Systems_, put out
by the San Diego Computer Society.
Simpson concentrates on getting the fastest performance out of dBase
for various kinds of sorts, searches, reports, edits, and so on. He
doesn't resort to any patching or poking of dBase itself. Instead, he
points out that dBase often offers more than one way to perform a
particular task and goes on to compare these different ways to show which
is the fastest in a given situation. He runs these speed comparisons on a
typical mailing list of 1000 names (MAIL), and the results are remarkable.
To give just one example, Simpson compares times for copying all
entries for "Miller" (10 of them) from MAIL to a new file (TEMP). The
command
USE MAIL INDEX NAMES
COPY TO TEMP FOR LNAME = "Miller"
took 200.6 seconds. But the command
USE MAIL INDEX NAMES
FIND Miller
COPY TO TEMP WHILE LNAME = "Miller"
took only 18.7 seconds, less than one-tenth the time.
If you haven't already discovered such tricks yourself, this file
makes interesting reading.
[DTUNE23]
DTUNE23, by James Gronek, is a sort of file processor you can use to
"tune" your dBase II command files. Its main function is to reduce the
size of the CMD file by removing all comment lines and trimming all dBase
II reserved words to four letters (that's all dBase II needs to see). This
processing does shrink your files noticeably (I used it to reduce one
heavily commented file from 14K to 4K). As a side benefit, the smaller
file should run at least a little faster since dBase II won't have to spend
as much time reading it. In this process, DTUNE23 does not destroy your
old command file (with its valuable comments); it just renames it from
filename.CMD to filename.SRC.
DTUNE23 does some other useful things, too. It can produce a
structured version of either the original source file or the new trimmed
file. (Structured files are indented to set off program loops, making the
file much easier to read, especially if it has nested loops.) DTUNE23 can
also produce a line-numbered version of the source file together with a
cross-reference file that lists the occurrences of all non-reserved words
used.
[VDBTYPE]
Though not everyone knows it, it's possible to add functions to dBase
II through assembly language routines. VDBTYPE.ASM, by Norman Strassner,
is an assembly language file that adds a neat file-viewing function to
dBase II. With it, you can view a normal text file, a squeezed text file,
or even a squeezed text file inside a library (LBR) file--all without ever
leaving dBase II.
It's handy enough to be able to scan a file on your disk (a DOC file,
for example) without having to exit dBase II, but VDBTYPE has greater
possibilities. You could, for example, create a dBase II application, and
then work up a dozen or more help files to go along with it. If you
include VDBTYPE in your application, you could squeeze all the help files
and store them in a single library file (saving considerable disk space)
yet still give users quick access to them when needed.
To use VDBTYPE, you must turn the ASM file into a HEX file (using
CP/M's ASM.COM or the public domain LASM.COM). Once dBase II is running,
you use the LOAD command to get the HEX file into memory and the SET CALL
command to let dBase II know where VDBTYPE is. The only thing you may need
to alter in the assembly language source file is the memory address at
which VDBTYPE will load (it comes set to load at the lowest possible
address, 41984 or A400h). Once loaded, VDBTYPE will coexist happily with
dBase II, which doesn't normally use any memory above 41984. If you do any
sorts, however, VDBTYPE will be wiped out, and you'll have to reload it
after the sort is complete.