| ★ APPLICATIONS ★ BUREAUTIQUE ★ MICRO APPLICATION - DB/COMPILER + DB/LINKER ★ |
| DB/Compiler + DB/Linker (c) MICRO APPLICATION | DB/Compiler |
dB/Compiler is a compiler designed for dBASE II rather than the newer dBASE III or III Plus. Created by WordTech Systems, whose dB IIII Compiler is reviewed on the following pages, dB/Compiler doesn't produce native code like Clipper does. Your source code is converted to an intermediate form called “d-code” and linked to a library of necessary support routines with a proprietary linker supplied with the package. The resulting executable program is actually run by a low-level interpreter. An automatic memory-management scheme optimizes the PC's memory usage without requiring any complicated instructions from you. This gives dB/Compiler a big advantage over products that need large amounts of RAM in the computer that runs your application or require you to design an overlay structure and wade through the complicated commands usually necessary to implement the structure. dB/Compiler is available for CP/M-86 and CP/M as well as MS-DOS and standard IBM PC-DOS. You can use Word-Tech crosslinkers to prepare an application on a PC, for example, and link it to run on any of these other operating systems. The 8-bit version of dB/Compiler has several restrictions and operating differences because of the limited memory available in a 64K environment. The ability to create applications for different systems may be important if you develop commercial software for a variety of target machines. MANEUVERING AROUND LIMITATIONS dB/Compiler accepts standard dBASE II code with very few restrictions. WordTech takes great pains to point out the differences between dB/Compiler and dBASE II, but they aren't terribly significant. For example, most interactive dBASE I I commands aren't supported, but they're not generally needed in the compiled environment. WordTech supplies detailed suggestions on working around the limitations if you need EDIT, BROWSE, or similar interactive commands. The compiler can't support all forms of macro substitution, but here again, maneuvering around the limitations is relatively easy if you haven't been tot) carried away with exotic macro manipulation. dB/Compiler's data and index files are completely compatible with those created by dBASE II. dB/Compiler supports multiple-key sorting (with a few restrictions on the nature of the various key fields), which is much more powerful than the single-key limitation in dBASE II. You can't specify ascending or descending order on a field-by-field basis, though, as you can in dBASE III Plus. The compiler also maintains more precision in numeric calculations, which has obvious benefits but may cause some operational differences from dBASE II if you're doing numerical comparisons. FOLLOW THE LEADER In general. dB/Compiler strays very little from standard dBASEII syntax. Both data and index files are completely compatible with those created by dBASE II. Unlike many dBASE clones, there aren't too many significant extensions or new commands or functions. The sample programs I wrote to generate the two Project Database II test reports in dBASE II worked with no changes other than modifying SORT to take advantage of the dB/Compiler multikey sort capability. Its compilation speed is very good, and the WordTech linker is quite fast. Its execution speed is significantly faster than dBASE II's, even when dBASE II's DSORT utility was used to speed sorting. dB/Compiler s documentation isn't as polished as the software. It's reasonably well written, especially the sections that explain the developers' philosophy and the problems they faced in designing a compiler that accepts code from a language intended for interpretive execution. My copy of the manual was badly printed, with front and back pages scattered around almost randomly, so that following the narrative was an exercise in increasing frustration. The manual isn't typeset, and several different type elements are used throughout, one of which is nearly unreadable. I understand that a revised manual will be released soon. Incidentally, the copy of dB/Compiler I used isn't copy protected, even though the manual says it is. Since the current dB/Compiler release was issued in October of 1984, I have to question WordTech's commitment to this product and whether it is still being developed actively. I can't blame WordTech much if its priorities are focused on its dBASE III-compatible compilers. dBASE users have responded decisively to the advantages offered by the level-III programs, but many productive applications are still coded in dBASE II that would benefit from dB/Compiler s speed increases. If you still do your work in dBASE II, and if you've already made a big investment in dBASE II programming energy and expertise, consider dB/Compiler—it has plenty of performance advantages to offer you. dB III/COMPILER dBIII/Compiler is a dBASE III-compatible compiler that makes your dBASE applications run faster. Like Clipper, its main competitor, dBIII/Compiler is easy to use and highly compatible with the original Ashton-Tate product. You don't need dBASE III itself to run the finished application, although you'll probably want to have it for program development. As with other similar systems, you compile your source codc and then link in a library of support routines. Both large-and small-memory model libraries are provided. The small model for the PC requires only 128K of free RAM (after DOS and any memory-resident programs are loaded) at runtime, but it allows only 64 fields in the file definition and either 256 or 128 memory variables in the program (which of these limits applies depends on whether the compiler's FLASH mode is activated to display screens instantly). The large model needs 192K but allows the full 128 fields and 256 memory variables with FLASH active. |
|  |
|
