Wednesday, January 18, 2017

CD-OS Progress

CD-OS doesn't look like it is running in the browser! It looks like a real operating system with floating windows, toolbars, taskbar and file explorer! Screenshots coming soon! It can set itself to full-screen on the browser and runs with some caveats on anything going back to IE6 !!! (The reason I do not put up screenshots now is that I am working on the theme designer and want a proper PIP-BOY green VDT terminal theme for my first shots of the new CD-OS!!)

This thing has come a long, long way in almost 20 years since I wrote the first version in Java with an AWT interface.

I have finally succeeded in writing cross-platform code for :

1. Launching a web browser as localhost ( on any operating system at startup from configuration option.
2. Launching all attached services (including ones that have been run cold, connected themselves and then registered themselves as autolaunch at next startup) in a separate minimized console process window of their own.
3. Terminating all attached services at server shutdown.

I have all kinds of IPC messaging working between the server and it's booted services, whether they are hardware controllers or speech annunciators or cron job utilities. It's kind of amazing to me to see this all happen as an automated process - server boots up, launches it's services, contacts them with a dialogue over the IPC particular to them and then begins transactions ... for example, feeding real time data from a weather station or from Modbus network.

At my client sites where I have installed different varieties of this architecture, I configured this manually in order to get it working ... but my goal was always to automate the entire thing end-to-end with as little configuration as possible for the server to auto-discover and run hardware and applications services of any kind.

I am getting onto the cron jobs tonight, I have a special JQuery control that allows you to author a cron job in a sophisticated fashion from the web interface and schedule it.

The biggest coolest service of them all would be a VOIP desk that is configured and controlled through the CD-OS server so that anybody could wire their shelter/retreat completely with free salvaged IP phones. I have found boxes of these things thrown out in the city and connected them with very little fuss. Combined with Power-Over-Ethernet this means a single network cable in a shelter or redoubt could carry all communications and control, voice traffic and power for lights, fans and just about anything else that runs on low voltage. They have extremely good EMF and EMP protection devices for these networks now that are designed to survive lightning strikes - which is the worst thing you will ever encounter as long as you keep your network insulated from any connections to the external grid.


Ave said...

Sam said...

I can't help but think that if you used Rebol or one of the Rebol successors you could knock this thing out in no time. Especially if you're running it in a browser. All the tools you're using are jammed up with complexity.

Original Rebol with and without GUI(newly included ARM)

R3 with and without GUI from Atronix where they use it for Program Control Logic machines in industrial plants.

RED-I' not sure if RED has all the networking in yet. It might be using Rebols for that as it compiles the source.

I can't help but think with your background you could crank out code super fast with Rebol. If you could bid by the job you could clean up.

Texas Arcane said...


In some configurations using the architecture I have now, it may be possible to compile CD-OS for very tiny devices with 128K the way I am going. Increasingly, there isn't a byte wasted in my code. Whereas Rebol is a brand new language to me, I have been working on my web server in C code now for over 12 years (!) and don't want to switch at this stage. Recently I have proved my architecture works on two (three?) different industrial sites and do not want to start over again. My client end is also approaching maximum integration with the server back end and I have debugged and perfected an entire API for my model in C. Duplicating this in Rebol might take me who knows how long. It's easy to decide to switch but then I could get bogged down for six months in debugging web sockets, discovery, who knows what.

If you want to write a parallel architecture in Rebol after you have seen how CD-OS works I am all for it. I would gladly host it on my Github site if you wanted. If you were successful in getting the same features to work cross platform in Rebol that would be fantastic and I would really like to see that running. It could be an excellent alternative.

Texas Arcane said...


I was just thinking if you duplicated the web API in Rebol you might actually be able to use my front end client script unchanged. That would be very cool to see it running.

Sam said...

"...I have been working on my web server in C code now for over 12 years (!) and don't want to switch at this stage..."

HA HA I get that. I like Rebol and try to promote it. I fully understand you're position. No doubt that while Rebol is good nothing beats the portability and tweakyness of C. I wouldn't be able to do the work you're doing. Way to deep for me.

I looked further into RED and the networking is not there yet. I think the next version0.7.0, it's 0.6.1 now, will have it. I think I would do it with a built in GUI as it might be easier than writing script to display in a browser.

Rebol GUI backend is just a small functions library. In the original Rebol it was the AGG graphics library I showed you. In Rebol3(R3), the open source Rebol, I think it's the same library but I'm not sure. In RED they're using the platforms low level GUI commands. What's interesting about this is since all high level GUI functions, kind of like GTK for unix or WinForms, are all done internally in the language, that means you can use javascript as a low level library and have a high level DSL language to write the gui's.

You need to look at this. It totally reminds me of the interface that you made for the VaultOS. Atronix made it with R3 the open source version.

Here's a video where you see it in action. It zooms in on factory functions. It's way cool.

Sam said...

"I was just thinking if you duplicated the web API in Rebol you might actually be able to use my front end client script unchanged."

I'm not sure I understand this. I get the general gist of your article. The steps you posted #1, 2 and 3 above. Makes sense. I don't understand exactly what you mean by tying Rebol to your client script.

Maybe I understand. When you say web API you mean the actual instructions that the server sends to the browser you opened? So that would mean Rebol talking directly to the browser?

Or do you mean that Rebol could use the web API (used as a IPC) to talk to your main server that controls every thing which in turn displays results on the browser?

My confusion is over the terminology. I get that you have a script(specific set of commands formatted a specific way to communicate data, state, or operations), that you use for IPC. I'm assuming it's some set of text type commands used to pass information between the various services whose responses are sent back to the main server. The server uses AJAX methods through XMLHttpRequest to display an interface that can change with conditions.

Now I get confused by AJAX. I'm guessing it's XMLHttpRequest tied in with Representational state transfer (REST).

The basic idea doesn't seem to be all that difficult but the way people have implemented it is a nightmare of huge libraries that I have no idea what they do. They have so much complication as to be at the limit of humans to absorb (or most humans anyways).

Where I'm lost is you say scripts, ok I get that I could use the same communication scripts to talk to your server but then you say "web API" now I'm lost as I think of that as talking directly to the browser. Now that I think of it your server is just like the net so Rebol cold talk to it like a browser but I'm not sure. To talk to your server what IP address would I use and what port?

Sam said...

I'm thinking about this a little more and if your "web server in C code" is compiled into library Rebol could call it. Whether that's of any use or not is a different question. Probably not.

"..., I have been working on my web server in C code now for over 12 years (!)..."

Low level communication stuff is complicated. The main complication, it seems to me, is there's not much in the way of documentation or tutorials on this stuff. Programs make sense but tying together programs with the operating system and services gets into a lot of confusing stuff. If it wasn't complicated you wouldn't have been working on it for 12 years.

Texas Arcane said...


The most complicated part of CD-OS now is the front end Javascript, which is not only providing a single page application but a true windowed desktop which looks for all intents and purposes like a real OS running in a browser window. I have the start icon just like Windows 98-XP-7 in lower left corner. There is real dynamic loading and unloading of applications in windows. There is a taskbar, status icons, the works. You would not know it is running in a browser.

As long as the backend API (AJAX REST) was a duplicate, it could power this front end JS JQuery application with no changes, whether written in Node.js or REBOL or any other language. I serve up different forms of content with Lua Server Pages but theoretically any other server side could provide the necessary content to the browser running this Jquery SPA.

Rushing to get team organized and first cut of this source code up on Bitbucket before the end of this month.

Sam said...

Ok I know I provide too many links and they don't always work out but of course here's one more. I was prompted by "The most complicated part of CD-OS now is the front end Javascript...". Everything is done with Javascript libraries these days and a guy named Nick Antonaccio who runs a Rebol forum and is really, really sharp wrote a tutorial on a library that he likes a lot. Well if he likes it you can generally bet it's worth looking at. He's been programming since he was child. He's using rebol but rebol has nothing to do with it. You can call it the same way you would call any JavaScript library. This,

Building Mobile and Web Apps with jsLinb, Sigma Visual Builder, and Rebol Server Code

Quote,"...Not only do the created client apps run in virtually any JavaScript enabled browser (from Firefox 1.5 and IE6 to just about every modern mobile and desktop browser in existence), but the entire IDE, documentation tools, and everything needed to create apps, also run on all those same platforms...".