nanogui: Thread: A few process-related questions about uWin vs. nano-X

Now that I have a barebones sample of Microwindows up and
running on our system (I was really rather amazed; after the screen
driver and very basic input drivers were put together it Just Worked)
I'm starting to take the steps towards making it 'production-quality' for
us.  In particular, one of our primary goals is to have multiple FLTK apps
up and running on the system.  To this end, I've got a couple of questions...

1) Has any thought been given on uWin side of things to things like a shared
library, application loaders, etc?  At the moment it seems like there can
only be one application actually running, though that application can open
as many windows as it would like.  Is this a pretty fair summary of the
situation?
Are there any plans for this to change or thoughts on the best way to go about

changing this?

2) Alternately -- as far as I understand, at least, currently the FLTK port is
only
targetting the Microwindows side of nanogui.  Is anyone working on a nano-X
port of FLTK, or is the expectation that gdk/gtk will fill things in
acceptably on
that side?  It seems as though nano-X has much better support for a
multiple-app
sort of model right now.

Any suggestions or thoughts other people have on this would be really
welcomed.
Thanks!

Steven Stadnicki
Equator Technologies, Inc.
####@####.####

: 1) Has any thought been given on uWin side of things to things like a
shared
: library, application loaders, etc?  At the moment it seems like there can
: only be one application actually running, though that application can open
: as many windows as it would like.  Is this a pretty fair summary of the
: situation?

I had some initial plans to add application loading capability to
Microwindows,
which would be alot easier than adding the client/server RPC marshalling to
every API entry point. I think we need to address and solve this problem
fairly soon.



: 2) Alternately -- as far as I understand, at least, currently the FLTK
port is
: only
: targetting the Microwindows side of nanogui.  Is anyone working on a
nano-X
: port of FLTK, or is the expectation that gdk/gtk will fill things in
: acceptably on
: that side?  It seems as though nano-X has much better support for a
: multiple-app
: sort of model right now.

Nano-X definitely has better support for a multiple-app model right now.
It would be fairly straight-forward to hack FLTK towards Nano-X from
win32.  Shane originally started the port to FLTK, but has been rather
silent on the port lately...

The other problem is that FLTK is very badly written in the OS-interface
area, and there's lots of kludgy code that's #ifdef'd all over the place
between X and Windows.  GTK+ uses GDK as the graphics device
interface layer and is very clean.

Regards,

Greg

On Thu, 13 Apr 2000 16:45:02 -0600 "Greg Haerr" ####@####.#### wrote:
>: 1) Has any thought been given on uWin side of things to things like a
>shared
>: library, application loaders, etc?  At the moment it seems like there can
>: only be one application actually running, though that application can open
>: as many windows as it would like.  Is this a pretty fair summary of the
>: situation?
>
>I had some initial plans to add application loading capability to
>Microwindows,
>which would be alot easier than adding the client/server RPC marshalling to
>every API entry point. I think we need to address and solve this problem
>fairly soon.

I suggest you look at Cross Elf. It's a library that allow you to handle
portable application loading via ELF shared objects under any OS that 
supports libdl (dlopen(), dlsym() etc.), Windows, and DOS (so it shouldn't
depend on too much OS support....). Under Windows it also allows the app.
to link to Windows DLLs. I've used it earlier to successfully write a network
server that ran from the same binary under both Windows and Linux with only
a very small (less than 1KB) shared object with a minimal compatibility layer
to make Winsock look like berkeley sockets.

Of course Cross Elf alone doen't guarantee you binary portability, but it
makes it possible... And since it also has a DOS loader it should be a fairly
managable task to port it to other platforms with little OS support available.

Regards,
Vidar Hokstad


-- 
Get your firstname@lastname email for FREE at http://NamePlanet.com

: I suggest you look at Cross Elf. It's a library that allow you to handle
: portable application loading via ELF shared objects under any OS that 
: supports libdl (dlopen(), dlsym() etc.), Windows, and DOS (so it shouldn't
: depend on too much OS support....). Under Windows it also allows the app.
: to link to Windows DLLs. I've used it earlier to successfully write a network
: server that ran from the same binary under both Windows and Linux with only
: a very small (less than 1KB) shared object with a minimal compatibility layer
: to make Winsock look like berkeley sockets.

Thanks - actually, I'm quite familiar with CrossELF.  I have already
used it and had a version prepared for Microwindows about six months
ago, but someone talked me out of it (for reasons of portability across
different CPU platforms)

After getting into CrossELF, I wrote a 16 bit loader for ELKS that
essentially did the same thing, but used the bcc .o object file format
as the image format...

Regards,

Greg