All the assumptions I put in my initial architecture for Vault-OS were based on the assumption that TCP-IP programming in a multitasking realtime environment is really complicated and require a knowledge of the IEEE 802.3 protocol that I simply don't have. I have programmed a bit with TCP-IP sockets but I assumed that doing this in a multithreaded RTOS was beyond the grasp of somebody who had not spent their life in a toolshed surrounded by Ethernet manuals.
Like all adaptive programming, it is the act of actually experimenting that modifies everything. That's why corporate environments that insist you proceed with the original design no matter what you discover are almost incapable of ever producing anything really good from that approach. They refuse to "incorporate" new knowledge that changes everything, especially their mistaken assumptions about the problem.
So I compiled in WATTCP-32 with FreeRTOS and tried a couple of experiments using my test bed, which consists of an old Pentium 486 connected to a cruddy old 386 laptop with a network cable plugged into a PCMCIA card. This is with everything else compiled in okay under Open Watcom ... the little GUI library (which appears to be a super high tech real time windowing system), the Metakit database libs and even my licensed John Miles Sound System for DOS code. I tried starting two processes, each of them sending and receiving a 512 byte stream over the sockets at the same time.
All I can say is, wow. If I knew this stuff was this easy I would have written this thing ten years ago. It's a cinch. The thing is, this experiment proved to me that every machine can be both a server or a client. That's absolutely fantastic because that is the dream I have had for Vault OS for TEN YEARS while I have worked on several detours (CD Commander Versions 1, 2 and 3, etc, in Java, VB-DOS and C++ Builder 4.0) and I just was not happy with anything because it was like a crappy watered down version of the real vision I had for the application I really wanted.
The application I dreamed of would have these qualities:
1. It would have to be decentralized, the way the internet was engineered - to survive a nuclear war and EMP. There should be no "massive central brain" on which everything depended - if one terminal crashed, another terminal could be directed to mirror the former and take over for it altogether without skipping a byte. (Vault OS can be hardened enormously via opto-isolated Ethernet ports or even magnetic cable grounds, that can be added to a system later.)
2. Would be totally standalone terminals based on a proprietary comms protocol (in this case, TCP-IP) and work at the true performance levels that all 32 bit machines really have when they run in protected mode. Microsoft has convinced the world that it takes a 4 ghz supercomputer to run a system like this - and under Windows 98 or XP or Vista, it does.
3. Would be dirt cheap (somehow, in 1998 this didn't seem likely) and composed of junk that could be sourced anywhere and hooked up so easily that I would have no problem maintaining it, replacing parts and starting new terminals with salvaged junk after TEOTWAWKI.
4. Would somehow route completely around the entire Windows paradigm and later, I realized, the whole Linux paradigm as well! Can't any of these companies do anything with these machines with less than 100 megs and five million layers of proprietary software? When you look at www.menuetos.org, you get some idea of how badly we are all getting screwed in this "computer revolution." You have to take a second mortgage out on your house if you want to run a spreadsheet at the same speed as an XT in 1985! I wanted Vault OS to boot instantly, work directly to the metal at 32 bits and have only one abstraction to deal with at a time in the programming. There is no way that I want to have to install Service Pack SP3376347634_9A every 3 months after they drop the bomb. It's just not realistic.
For the layman ... you can have a machine that sits physically in your inventory room/silo/drum/shelter/shed/shack/tunnel and where the database for your inventory physically resides. That machine can serve up the same application ("Inventory Manager") to all the machines in your shelter from anywhere, as if they held the database themselves. You can have another machine that sits in the outdoor shed with say, your water supply. Now you can have an ethernet chip that transmits water levels independently to any other machine on your network all the time on request ... but ... because this is TCP-IP powered by sockets, you could also just run a simple serial cable from that machine to your water tank to some kind of serial device you have there and that machine can be both a server and a client, only it serves up reports on water levels. So you don't have to build a separate ethernet board for your sensors if you don't want to. You can hook up devices to your parallel or serial ports and transmit that data via Vault OS to any machine that asks for it, anywhere on the internet. Configuring that to make it as flexible as possible based on your installation will probably be through some kind of embedded scripting language like Angelscript, an excellent byte coded script that looks identical to C++ for the most part. I've already had success compiling this before for a game engine so I will likely include it.
I think I can do this correctly as a result of this useful feedback. Although the capacity to answer requests from browsers running on XTs with Lynx or Arachne will be supported, (as read-only pages served up) I think I am shifting the paradigm from HTTP to TCP-IP as the backbone of the client-server relationship for Vault-OS.