Essentially, Vault-OS needed to be seamless. Whether a program is running the PowerBasic DOS program, the VB-DOS Client or the Win32 C++ Builder front end, everything needed to communicate happily via two formats : DB4 database files and IPX messaging over an Ethernet connection. I own a copy of the BULLET database for PowerBasic and it writes DB4 compatible files, very quickly I might add. You can write out terabytes of food storage records in the time it takes MS-SQL server just to open a handle to a database. (I would never use MS-SQL, of course)
I think I've been faffing about with this for at least six years or more trying a lot of different approaches, usually with mixed results. :(
I tried a lot of stuff to wedge the 16 bit DB4 database files written by Vault-OS DOS into the Win32 system, including writing an NT service to copy them forward into an SQLLite database whenever the DB4 file has been written to.
Crap. Crap solution. Just doesn't have the elegance I was desperately seeking. I always felt kind of queasy, because I could not find a pass-through solution between shared databases in DB-IV compatible formats, in either 16 or 32 bit. This problem has been depressing me, actually.
Many of you who downloaded the CD Commander source code a couple years back probably noticed I was using SQLLite DB to store the files in. That was not going to happen. SQLLite is a totally proprietary format and not easily shared between different operating systems at all. I would never make that the universal database format.
Then I found the tool at the link above and compiled it into my Win-32 Vault-OS version. I was immediately able to surf from my Win NT Box to a connected MS-DOS box and open the database it was using to store all it's I2C sensors and data, as well as inventory and personnel records. Things like this make me pee my pants with excitement when they work out.
Once you've got the database handles shared freely and lockable across the network, the IPX common protocol was a snap. The inventory and other databases can be located on any machine, even scattered out on anything running, including the DOS client. Participants lock that file if they need to write to it.
I must have maybe a half dozen embedded x86 PCs that only have 2 megs or so of memory. These devices are intended to be dedicated to things like generator power and battery charging management - as a kind of cloud "service" to all participating devices they can see and share transparently. They are never going to be running anything more than MS-DOS, Powerbasic client and MS Lan Manager for DOS.
So that's good.
Of course, once all the data used by Vault-OS is in DB4 format, it's no longer "tethered" to the application. There are tons of abandonware applications that can be used to surf, repair, edit and modify these databases. In the event of a crash or a corruption (it can happen), you don't have to hang yourself in a Post-Apocalyptic funk. Instead you can get on your machine and have a look at the DBs, repair them, rebuild your box with any x86 device (let's say a radioactive ghoul tore it down and completely smashed it up) and go back to operations as usual. The important thing is that if you cannot get in touch with Texas Arcane following the bomb or magnetic reversal, it's not the end of the world. Your data is there in a generic enough format you don't need to get me in as a consultant to fix it for you or get support from me on the phone. Vault-OS is about independence, indestructibility and open standards. If the finished program doesn't require anything but some elbow grease to fix anywhere, anytime for the next 100 years, I will have succeeded beyond my wildest dreams. Even if Homunculus has me tied to the hood of his hot rod, I will be smiling thinking about all the Vault-OS systems out there running on forever.
I am working on the web site for Vault-OS. It looks pretty good, built on top of WordPress. Nice presentation. Should go public as soon as I can get it ready.