🚀 go-pugleaf

I have used C-tools from Ashton Tate with Dbase III plus, and the 
Lattice C compiler.  I found the package unsatisfactory for a couple of 
reasons:  
         Your compiled routines must be pre-loaded BEFORE DBIII starts, and
         consequently they remain resident after DBIII terminates.  

         It is very easy to hang DBIII if you pass an incorrect parameter
         (or inappropriate number of parameters) to the C-routines.
 
         I don't think that their memory allocation stuff works as well as
         they'd like; following their examples, I had problems with some
 	 trashing of memory when I attempted to do math operations on 
         array elements.  ( I was attempting to multiply the members of one
         array by elements of another array, then summing the results).
         
         
So, consequently, I rev-engineered the format of .mem files, and passed a
mem-filename to a compiled TURBO program (which I ran from dbaseIII - you
can include parameters in the command, like "run turbo1 data1.mem")
which wrote it's results to a .mem file which I passed back into my
DBaseIII program when the turbo pascal program finished.  Seems kludgy, but
it is rock solid, and easily changeable without re-linking everything and
rebooting.  

Also, if you want structures of the DbIII records, there was something posted
in net.sources a while back (or was it net.micro.pc?) which gave either
pascal or c source for data structures for DBiii.  Something funny? well,
I rev-engineered the formats for dbiii+ enough to do db access from turbo 
pascal, and had emulated alot of the functions of dbiii.  My routines ran
only slightly faster than dbaseiii+ (for operations that were i/o 
intensive), which makes me wonder if the data structures that Ashton Tate
used impede hi-speed performance.  Of course, the people doing the commercial
DBIII+ compilers probably do "clever" things, or at least have some "clues"
that we mortals don't. (Come to think of it, I think I had all checking 
turned on in the turbo compiler - that easily makes programs slower by 
a factor almost equal to  2).  Oh well, I didn't mean this to be so long...

brian moran
----
Brian K. Moran  brian@mirror.TMC.COM	
               {mit-eddie, ihnp4!inmet, wjh12, cca, datacube}!mirror!brian
Mirror Systems	2067 Massachusetts Avenue  Cambridge, MA, 02140
Telephone:	617-661-0777 extension 141

"Won't somebody tell me, just who and what I did...
 Why's this ring on my finger, and who's that screaming kid? " 
   From "Lost Weekend" by the Beat Farmers
---