A little progress made as of last night. It's looking much better.
Here's my basic architecture on August 24, 2011 :
1. C++ code for web server and AJAX web service running on 3 platforms (Win32, Linux, DOS-16/DOS-32) ... compiled with Open Watcom, same source code base.
2. All sensor monitoring is done via mailslots implemented on Windows, Linux and DOS using JSON format to deliver messages.
3. As of this week, my daemons monitoring sensors all run as VBScript, available under all versions of Windows from 95-98-NT-2000-XP-Vista. The Linux daemons for various hardware will have to be written by somebody else. I have found over the past three years that VBScript is the most flexible, easily altered and debugged script available for writing hardware monitoring devices. It's easy to see why it has figured so heavily in industrial embedded work. I also figured out how to run VBScripts as services when the system boots up. For me, this is the quickest easiest way to write all kinds of custom daemons to drive hardware sensors for the web server and has provided excellent abstraction with mailslots. I imagine myself trying to write a new daemon to drive some odd device I have found or scavenged somewhere, possibly without a compiler or development environment set up. VBScript has proven to be the best answer to this dilemma. The great thing about VBScript is that you can write complete forms for utilities or small interface pads to supply terminals with custom features in the Vault, for example, a security keypad for an external device or a custom display for hydroponics ... this is in addition to simply powering daemons with the fewest possible lines of code running as services.
4. Every machine is available to every other machine supporting a browser that is at least HTML 3.2 compatible. This includes Arachne for DOS and Mosaic 2.75b running on Desqview. This permits even the most primitive x86 devices to either monitor or monitor and act as display controllers for all other VOS devices connected to the network. I have been experimenting with SVG GUI interfaces for VOS and a fallback strategy that degrades gracefully to older browsers, this will be ongoing as I get the first version of Vault-OS ready. Version 1.0 will simply feature basic HTML forms and interaction with the user. I have been able to get a display from Desqview-X running on my X-Windows thin clients that monitors the VOS web service in real time using Mosaic. It is proving to be a very flexible way of monitoring and controlling from any terminal anywhere in the Vault at any time. The attraction of implementing gosh-wow SVG interfaces is that they are vector graphics which can scale themselves to any device, including tiny automobile television screens that I use for several displays. HTML pages can be hard to view on these machines on a 4 inch PAL/NTSC dashboard.
Things are shaping up very well to support one fundamental design principle - that whatever the operating system, Vault-OS will run the web server in the background and it's task management without preventing the user from customizing the OS for their own needs - be it DOS with Desqview, Windows 32-bit under NT or Linux running XWin. If the user wants to compose a memo or play a game of Tetris, they should be able to do that, with the obvious caution that a dedicated device running a small critical section (like hydroponics) probably should be stripped to the essentials and not have a lot of junk installed on it.
Lots of stuff is still hardcoded in C++ for web page composition. I have ambitions of getting a fully developed VSP (Vos Server Page) through Lua but I had trouble compiling Lua for memory constrained environments. I am having better success with a language called PAWN which I have down to 10K on a DOS compatible chip that only has 128K to work with. Need more commands to build tables, manipulate HTML documents, etc. Working on it.