nanogui: Thread: new idea for microwindows client architecture

Gang,
	I've been studying a truly interesting piece of code lately, cross-elf v-0.2,
which allows linux, windows and dos programs to load 32 bit ELF code sections
compiled on linux and run them on other platforms.  This is realized through
cross-elf implementing an ELF relocatable loader, and resolving all imported and
exported symbols.

	After having reviewed this great piece of work (highly technical I might add)
I've come to the conclusion that it would be *perfect* for the multiple client/single
server architecture that we've been discussing on the nanogui list.  This solution
completely solves the problem of multiple clients on one machine communicating
with a graphics server on the same machine.  I think that this is where microwindows/nano
should be concentrating (let X handle the multiple machine cases for now).
In particular, this solution has the following advantages:

	o high speed
	o client binaries are *identical* on linux, win32 and DOS!
	o no network overhead or network needed (even UNIX sockets)
	o ELF format fully supported by linux tools
	o all modules seperable into .so shared objects if desired (this means
that the nano-X vs microwindows engine could just be separate .so files in the same
server...)

	To get this to run on ELKS, I would have to modify the ELF loader to support
16 bit binaries (small task) and modify the bcc/ld86 tools to support ELF format
or add the import/export info (very large task).

	With the appropriate implementation, this architecture would allow static-linking
of clients if desired, which would allow the extremely small binaries microwindows
supports today.  

	I plan on building a strawman implementation of this, so that we can move
towards separate "applications" in microwindows being loaded/unloaded as desired.
Note that we don't have to allocate another process for each application.  Ideally,
only a thread.

Comments?

Greg