Adapting linux utilities to linux power screen

Like this:
int main(int argc,char * argv[]) {

becomes:

int Entry(int * argc_new, void * argv_new[]) {
int argc = * argc_new;
etc

.Compile for shared object. Command line, all 100 lines of code, can load you shared object and put your entry point in its list.  Then it is available to whatever script command loop loads. And Xchars, all 500 lines of simple char screen api available to all parties in the full duplex argument list.  The list is executable assembly, one copy kept at each remote location, but they can all share the list, writing and reading it as dangerously as they choose.

The utter simplicity f adding forth, gdb, and xchars makes me cry, ready to buy. The ability to suddenly clear up all the confusion with a development interfaced matched to exactly to the task. Procedural scripts work because, like bash, they can naturally emit well structured defines within the syntax, much easier than inserting assembly into a c compile. The Golang works here, great object format, and open to compiling into linux command format.  Python is there for the big massively parallel queueing markets with thousands of groups entering and leaving; as well as python trader bots.

So simple, none of this is new, all of this I tested in parts, except Forth, noting here that is not a cutnpaste of a few lines elsewhere. I want it perfected, standard on all linux, it fits every niche because of its small footprint and reliance on an already existing mass of utilities. Great tool. I will be looking for it.

Runing xscr from inside the utility.

If the call list is re-entrant in that any subsystem can call the command loop back with ts own arg list, then we get some simplification.  Gcc, for exampled, can be adapted to manage an xchars power screen for results. Easy if gcc made its won window, but gcc would have access to the entire (5 or 6) APIs in xchars, if its loaded.   Or we can do it separately via Forth macros, either way. An -xchars flag should be reserved for those utilities that can put up their own character screen.
gdb output is formatted peculiar to the application and is deferred back to the scriptor to manage screen.  One could design very specific debug environment, one that understood object formats, or understood kernel structure, and so on; adapt gdb to the task, Forth a great tool for that.  Xchars a great tool, how many IDEs go beyond the character resolution? Few, not necessary.  IDE better handled under a simple Xchar format, everything simplified from deployment to enhancement..