Initializing IO manager

int StrCmd(int * argc, void * args[],char * str,EntryType *e) {
char src[40];
int base = *argc;
strcpy(src,str);
args[base]="Tokenize";
args[base+1]=src;
ExecCommand(argc,args);
*argc=base;
return(e(argc,args));
}

Simple routine, it executes arbitrary string commands over the Bus, and does not use ExecCommand except to tokenize. There is a conflict if io manager is initialized within a while loop, there is no guarantee the args space is available as Default may have laid out a bunch of executables on args. A protocol to handle this will emerge. Mainly, if the args list is filled, then Default has guarded it with semi colon terminators, but Console loop leave args list available from *argc to infinity, (or 4,096) whichever comes fist.

 It calls the entry point of the snippet directly.  Aftger initialization, the interface is all binary, IO manager carries the box of xcb goodies for the connection, all binary except the short entry point look up in xchars (NewConn,NewWin, etc).  These entry points are all packed char, very fast look up.

In the case of IO manager, the xchars is initialized, and the protocol is simple.  IO manages will creates console rectangle, which defaults to the entire window if o rectangle is supplied.  (All chars are assigned to a rectangle on output, but the window has a default rectangle. So IO manager which manages the cursor and editing functions, is tightly bound to xchars. Neither the console manager nor Default really intervene.

Tokenizing needs to be moved into IO manager from console loop, mainly because we are dumping the xterm, bash window so console loop no longer deals with line editing at all.

What about all the printfs the snippets normally execute? We have choices, leave a default xterm window or pipe all that to the new command window, i dunno yet.

No more xterm

This has to be the next goal, dumping xterm alltogether and going with a xchars console.  No one is bothering to write another xterm line editing function, and editing functions, up to and including mass word processors, all the editing needs to happen in IO manager which get all the raw keyboard input.

Multiple Connections?

IO manager can be threaded on a per connection basis I would think. One Xchars, multiple message loops should work.  Each connection can either be a separate IO manager, or an IO manager that selects the proper handler on a connection basis. The IO manager is where independent threads need to reside.