Know anything about dBase II and dBC

[GeoffB17]

Hello,


Way back, during the wild rush with CPCs, PCWs, CP/M Plus etc, someone did release an 'official' version of dBase II for the PCW (and maybe other machines).   I've still got my copy of that, so that's not really part of the question.


I've just discovered dBC, found it in a ZIP file of CP/M 'utilities' for dBase.


dBC is a compiler for dBase II, it takes a program (.CMD file) and turns it into a free-standing program (a .COM plus .OV?) files that will run under CP/M without any need for dBase II.


I've tried it, and it does work.   I've compiled a little test prog.   I need to try to determine if there is any performance benefit, i.e. will the compiled prog run any faster that the same prog would using the dBase II system (i.e. interpreted).   It should?   I understand that the dBC system creates a 'C' prog and then assmebles/links that with libraries, but I'm not sure.


dBC has a few command line options, which are -a, -p, -v and -dx, but I don't know what they are.   I might guess that the -p sends output to the printer?


I've searched the web, but no trace of any info about the system (other than sort of adverts about it from about 1983).


In case you wonder - this is totally and only 'retro'.  In the real world (and PCs etc), I've worked my way through dBase III, +, Quicksilver, Clipper, Codebase (a full dBase/C system) and more recently HMG which is a package around xHarbour.


Geoff

[FloppySoftware]

Hi Geoff,

Sounds interesting. Is a compiler really? Or needs the actual dBase on disk when you execute the generated .COM file?

[GeoffB17]

Yes, very interesting.


Not sure if it is a FULL compiler.   The Clipper system for dBase III was initially not a full compiler, in that the process turned your programs into a highly tokenised form and created a single .EXE that included a sort of run-time engine along with the tokenised program.   So, when I went from Clipper to using the CodeBase C library along with C (which created fully C software right down to the lowest level functions) I certainly noticed a significant performance improvement even over Clipper.   Especially regarding any operation that involved any memory hungry operation, like - say - re-indexing a large file.


However, dBC does appear to be a compiler, and may be a 'full' compiler.   I've run it on some very tiny programs, just a few lines, and it does work.   I still need to try some progs with some timing, so I can compare how it does compared to doing the same thing within (interactive) dBase.


There are two programs involved.   DBC is the 'compiler', which has a number of overlays, and which produces a sort of tokenised variant of the original prog (and is referred to as 'relocatable').   Having run DBC, there is a second stage using DBL80, which is a 'linker' and which has a couple of large-ish libraries.   I assume this process takes the tokenised file from DBC ard extracts the required library routines to create the final prog(s).   These constitute a .COM file, an .OVL, and then smaller .OV1 and .OV2 files.   I've looked inside these files (using DUMP) and I can see that one of the smaller .OV? contains all the fixed text from the original prog.   Not spotted anything meaningful in the other bits yet, but then the exploring is all part of the fun!


As far as I can tell, the process copes with all aspects of dBase, including most of the interactive commands, which may in fact be an improvement over Clipper which did not (or did so in a very limited way) although it was assumed your program would do such things in your own way, which was often necessary anyway.   I'll want to check this out, however one or more of the programs does show lists of commands, and the list seems to be complete.


Yes, any program created with DBC does NOT need dBase II to be present.   I think that was one of the reasons for such systems even back in the 1980s, it allows a developer to create a system and then supply it to clients without needing dBase, and note that back then dBase cost about $700 or so.   The PCW/CP/M version I bought about 1990 cost - I think - less than £30, and that was including the genuine ring-bound full manual.   You could use standard commands to create datafiles, indexes etc, although this part of the job would be more convenient using interactive dBase.


The system, by the way, was produced by WordTech Systems Inc, there was a similar PC system for dBase II and then dBase III, and I think the same company went on to produce the much grander QuickSilver compiler for dBase III+ which was much faster, and a proper compiler, which allowed linking in external routines (C and ASM) - we did use QS for a while, until we went over to Clipper which added so many extra facilities to the language.


You might be interested - dBase II had facilities within the system to load machine code, or put code into a string variable, and run these via a CALL, and separately do POKE and PEEK, all pretty much like you can do within various BASICs.   I don't know if these are replicated within DBC?


The only problem just now is that BOTH DBC and DBL80 have command line parameters, and I don't know what they do.   Or how important they are.   Maybe not too vital, I've done what I've done so far without using them.  WordTech are still there, I've looked at their website.   They refer to their data management background, but they're into different things now.   I could try dropping them a message, to see if they have any docs for DBC on file??


Anything else??


Geoff

[TFM]

A download link would be nice btw.


But... have you heart about the heavily updated and enhanced version of DBase 2.50? Look here:


Z-Base Download

[GeoffB17]

Hmmm!


In the interests of science, as they say?


Put a .DBF on drive M:, with 450 records


Created a small .CMD prog, to create an index to the file, also on M:.


Using dBase II main prog, ran the .CMD file.   Took 47 seconds to generate the index.


Then used DBC etc to compile, etc, the same .CMD prog.   Then ran the compiled (?) prog.  Accessing the same .DBF on M:.   This took 75 seconds, well towards twice as long.


NOT what I expected, or even hoped for.   Must try to work out why this is?


Geoff