Ron Copeland, associate editor for DDJ, is the coordinator for this review section. He welcomes your feedback on products worth reviewing.
Product: PC/Forms, Version 1.21b
Target: IBM PC, IBM PC AT, IBM PS/2, and compatibles
Requirements: DOS 2.0 or later; one floppy drive; 256K
Pricing: C version $149.95; Turbo Pascal version $99.95
Vendor: Golden Solution, P.O. Box 22216, Cleveland, OH 44122; 1-800-338-6754
Let's face it, screen layout and data validation are a drag. Most serious PC applications probably devote over half the code---and well over half the development effort---to tweaking displays and protecting the user from the GIGO syndrome.
Golden Solution's PC/Forms was designed to reduce this tedium and it does! In 15 minutes to half an hour, you can design a display, set up elaborate input validation criteria, test the form interactively, and generate the code to implement it. Writing and testing the equivalent source code from scratch could easily take several days.
The Turbo Pascal and C versions of PC/Forms are comprised of different sets of tools. We tested the C version, so that's what we'll talk about here.
The heart of the product is a stand-alone editor called FORMS. You run it to set up the display and validation and to generate the files used by your application. FORMS has bouncing-bar menus la Lotus 1-2-3. It's a highly visual environment, with windows popping up all over the place and pick lists and such, all of which have an intuitive feel. In layout mode, you paint your form on the display using function keys and the usual editing commands. There are commands for centering text, drawing boxes and lines, highlighting, rearranging, and so on.
When you're happy with the layout, you pick Attributes from the main menu, then cycle through the fields assigning validation parameters. Figure 1, below, shows the extent of the options available: picture, data type, decimal precision, mandatory response, and so on. A particularly intriguing option is aux edit, which ties a user-supplied routine to a field so that you can provide validation above and beyond the capabilities offered by PC/Forms.
The test selection from the utilities menu simulates a data entry session. You can step through the form, making sure the validation criteria work and that the order of fields is right. If not, you can jump back to the editing tools and fix it without leaving FORMS. This is a particularly handy feature.
When all is well, you generate two files. One is a .FRM file, a descriptor file for the form, which we'll discuss later. The other is an application shell in generic C. It's by no means a complete application, but it contains a data structure for the fields and all the code to load and execute the form (which is only about six lines). The shell is suitable for editing and insertion into a program as a function.
The other major component of the software is a header file and a runtime library. PCFORMS.H defines the data structures, function prototypes, and what not used by PC/Forms. You include it in your source program and link the object code with the runtime library.
There are actually three runtime libraries, one for each supported C compiler (Borland, Lattice, and Microsoft). You copy the one you need from the delivery diskette. They're all small models. Golden Software includes source code for the runtime system, so if you need a different model, you can recompile appropriately.
Everything your application needs in order to use PC/Forms is linked into the .EXE file. There's no separate runtime support package. TSR, interrupt-diddling, or other nuisances to clutter the environment. Only the runtime routines actually used are linked, of course, and the manual contains a table showing the code and data size for each routine. The average size is about 1K in a range of 14 to 3,974 bytes.
All identifiers have the form pcf_fname, where fname is something like "display_form" or error." The pcf prefix makes them distinctive. It takes about half a dozen functions to load and display a form, initialize it, and get the validated input. Other functions among the 17 available do things such as altering validation attributes on the fly and releasing a form no longer needed. There are an additional 23 functions for such things as video and string management.
The .FRM descriptor produced by the FORMS editor is an ASCII file containing information specific to a given form. The runtime system needs it to implement the form and perform validation. Opening a form is a matter of loading this file. You can have several forms open at one time, and any given form can span up to ten pages (display panels). But watch out: the forms go on the stack, and you'll need a mighty big stack if you have several open at once. The FORMS editor has a utility that sizes a form and tells you how much stack space it will require.
The crucial runtime function is pcf_get_form(). When called with a form displayed, it manages user input and validation. The results are placed in a data structure corresponding to the form, whose fields can have user-assigned names. Your program then fetches data from the structure and does its thing with it. This makes the data entry portion of a loop almost ridiculously simple:
do {
pcf_display_form (name, page);
pcf_clear_form_buffer(&buf defaults);
pcf_put_form (&buffer);
pcf_get_form (&buffer, &Term);
/* then do data processing */
while (some condition);
The vendor ought to include a function key template. Each function key has a purpose and some have an Alt command as well. I finally printed out the function key layout screen from the help system (which is very good, by the way).
The manual needs work. With the C version, you get the Pascal manual and a C addendum. The addendum is printed on yellow paper and you need a magnifying glass to read it because the print is so small. And there's no index, an omission that's hard to forgive even though the overall quality of the documentation is good.
These quibbles notwithstanding, PC/Forms is a real gem. It can truly save countless hours of programming, which makes it a contribution to productivity that will pay for itself many times over.
by Kent Porter
Product: DE, Version 1.2
Target: IBM PC, IBM AT IBM PS/2, and compatibles
Requires: One floppy; 256K
Pricing: $75
Vendor:
David Livshin 26 Niles Rd. Randolph, MA 02368 617-986-7491
I don't know what DE stands for, the manual doesn't say. Were I to hazard a guess, however, I'd say it means "deluxe EMACS."
DE is a stretched version of the standard EMACS editor. It delivers a host of impressive features that make it a macro-programmable, customizable editor with an unlimited number of overlapping and/or tiled windows.
Unlike competing editors such as Brief, DE doesn't require a bunch of support files. It comes as a single 69K .EXE file on the delivery diskette, and installation is as simple as copying that file to your hard disk or work floppy. To invoke the editor, just type DE. Up to two command-line arguments are allowed: a -NOBAK switch to tell the program not to make a backup copy of the edited file[s], and the name of a file to be edited.
If you want to pull several files into different windows, you can fetch them after DE is up and running. The command ^X^W causes the program to prompt for a filename, then creates a new window and loads the file into it. You keep doing this until all the files you want are loaded.
Initially the windows are tiled. Each one has an information line at the bottom showing the associated filename, cursor position, number of lines, and so on, and most significantly, the window number. Various keystroke combinations let you move sequentially forward and backward among windows or jump directly from one to another. Other commands resize and drag windows so that they overlap like pieces of paper: the now familiar desktop metaphor. In overlapping mode, the current window is always on top.
If you don't like the hierarchy of windows, you can change the sequence numbering. This is a nice touch. You can make the modules you're working on neighbors in the hierarchy; it takes fewer keystrokes to move among adjacent windows than to make jumps.
The command ^X 1 does a thing called zoom and rise to the currently selected window. This changes the operation of DE by expanding each window to full-screen size and placing the current window on top. Oddly, the jump-to-next and jump-to-previous commands (^X n and ^X p) don't work any more in this mode; you have to jump to a specific window. And there's no way that I found to undo the zoom-and-rise mode. Once you're in it, you're there to stay.
EMACS commands in general are less than intuitive, and DE continues the tradition by adding still more to the repertoire. All DE commands except those dealing with editing and cursor movement begin with either ESC or ^X, followed by a keystroke denoting the command. Some make sense (^X ^I to insert a file, ^X^W to write to a file, and so on), but most have no discernible connection with anything. Examples are ^__ to invoke the DOS shell, and ^X^z and ^X^Z to enlarge and shrink a window, respectively.
Consequently, the vendor includes a cheat sheet showing all the keystroke commands. There's also a limited help function: type ESC ^A, then a keystroke combination, and DE tells you what function the combination performs.
Each keyboard command is mapped to a DE macro through what the vendor calls "default binding." For example, ^X^S is bound to the macro w_cfil, which writes to the current file.' This association of keystrokes to macros opens the way to two features of DE: customization of the keyboard and programmability.
DE comes with 84 different macros, of which 73 are bound to default keystrokes and the other 11 (all of them related to window management) are unassigned. If you don't like the default bindings, or you want to add some bindings of your own, the command ESC ^@ runs an embedded utility that maps keystrokes to macros.
You can build your own more complex macros by combining those built into DE, thus creating editor programs invoked by a keystroke. Seldom needed programs can be stored in separate ASCII files and run with the ESC e command, which asks for the filename, loads it, and treats the contents as commands. Unfortunately, the manual barely glances at this useful feature.
Also alluded to but never explained in the manual is something called the DE.INI file. It presumably contains initialization commands that permanently map macros to keystrokes and perform other fixed set-up tasks.
It's a pity that the DE manual is not up to the quality of the software it purports to describe. A slim 26 pages, it contains terse descriptions of the macros, a little about windows and commands, and not much of anything else. The author assumes that you already know EMACS, and so leaves it to your imagination how to use the editor and its features. There isn't even a hint of a tutorial. The best part of the documentation is the cheat sheet, which puts most of the manual's contents on a card providing at a glance reference.
Overall, DE is a good editor with a lot of capability per buck.
by Kent Porter
Product: Soft-ICE. Version 1.01
Target: 80386-based MS-DOS computers
Requires: DOS 2.0 or later; AT BIOS
Pricing: $386
Vendor:
Nu-Mega Technologies P.O. Box 7607 Nashua, NH 03060-7607 603-888-2386
Soft-ICE is a product any MS-DOS developer serious enough to own a 386 machine should have. As the name implies, it provides the capabilities of an in-circuit emulator via software. For those of you not familiar with in-circuit emulators, a brief description is in order.
An in-circuit emulator (ICE) is a tool that replaces the CPU in a microprocessor-based product with a "pod" that plugs into the CPU's socket. This pod is normally connected to a box containing a control computer and some special hardware. The special hardware is used to detect user-specified conditions and to stop the processor when they occur. Another feature commonly found in ICEs is trace memory, so that when the processor stops, you can see where it has been recently, ICEs are normally expensive, and often designed more for debugging hardware rather than debugging software.
Soft-ICE gives 386 owners all of this capability, except trace memory, when debugging MS-DOS programs. It does this by using special features of the 386 normally used in writing operating systems (see February, 1988 DDJ for more details). Note that you can't use Soft-ICE to debug protected mode programs.
Soft-ICE can be used either stand alone or in conjunction with your favorite debugger. As a stand-alone debugger, it includes all of the necessary commands to disassemble, dump, and edit memory; to display and change registers; to peek and poke at I/O ports; and to manage breakpoints. A very useful help facility is also included, as well as a command to display the DOS system memory map. As you type commands, Soft-ICE displays a list of options.
Perhaps more than any other debugger, Soft-ICE lets you control breakpoints. You can set breakpoints to occur when any byte, word, or double word is read, written, read or written, or executed. For read/write breakpoints, you can include a qualifying value that must be matched or not matched. Breakpoints may be configured against a larger address range such that a breakpoint occurs on any read, write, or read or write in the range. I/O port accesses can cause breakpoints, qualified by values if desired. Execution of either a hardware or software interrupt (qualified by a value in AL, AH, or AX if desired) can cause a breakpoint. Of course, each of these breakpoints may be qualified with a count so that you can ignore the first 100 times you do any of them. You can even combine breakpoints so that a breakpoint only occurs after all of the selected breakpoints have individually occurred. Finally, breakpoints may be qualified with the location of the breaking instruction, to guarantee that the instruction is either inside or outside a range. All in all, a very comprehensive set of breakpoint capabilities, all of which can be used either stand alone or with another debugger.
If all of this isn't quite enough, you can configure Soft-ICE to generate a software interrupt when it detects a breakpoint. This user-provided interrupt gets all of the registers as they were when Soft-ICE got control, allowing the interrupt handler to do anything it likes.
When used with another debugger, SoftICE can be configured to trigger the other debuggor when a SoftICE detected breakpoint occurs. It can cause an interrupt 1 or 3, or an NMI. Soft-ICE normally passes interrupt 3 onto whatever awaits it, but it can also be configured so that an INT3 returns control to SoftICE.
SoftICE is very flexible. It may be installed in normal memory, in extended memory, or in COMPAQ extended memory. If SoftICE finds extended memory, it will automatically load there requiring none of the lower 640k. In a machine with only 640K, the program demands between 56 to 60K, rendering this segment 60K invisible to DOS.
Soft-ICE can share extended memory with other drivers, such as VDISK or RAMDRIVE. It emulates the necessary parts of the LOADALL instruction for RAMDRIVE. You can change the keystrokes used to invoke Soft-ICE. It can even boot up stand-alone code and debug it because SoftICE doesn't require any DOS services. SoftICE can also be used to debug MS DOS device drivers. And, joy of joys, you can even debug Intel interrupt handles, including the keyboard interrupt while SoftICE is using it.
The documentation is solid and tells you everything you need to know in about 100 pages. A tutorial chapter takes you through debugging, a simple program and is highly recommended for both beginners and those already experienced in debugging. [It does however require an IBM or equivalent for the BIOS routines. ED]
All in all, Soft ICE is an excellent tool for debugging 8086 programs. Compared to a true in line emulator, (even if you have to buy a 386 machine to run it on) it's cheaper and provides superior breakpoint facilities; the only thing missing is a trace memory.
by Richard Relph