Date:	Tue, 28 Sep 1993 09:41:51 -0400
From:	hines-michael AT CS DOT YALE DOT EDU (Michael Hines)
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Porting large InterViews program (abandoning it).

Thanks to the people who gave advice on how to tunnel through some of the
brick walls I came up against in attempting to port my neuron simulation
program to dos with desqview. Unfortunately the number of problems which
didn't have a clear solution was sufficient to cause me to abandon the port
to cut my losses (purchase price of desqview, their X11 toolkit roadmap,
and about 50 hours of effort). The alternative was merely to make random
guesses/attempts about what to do next.

Here are the problems I came up against. By the way, my machine is
a 16MB gateway 486 with microsoft 2 button mouse.

1) 7 minute link step with gcc
How to get gcc to use more available memory instead of paging to disk
seems to be a recurrent question that the experts are undoubtedly getting
very tired of answering. Let it suffice that when I run the gcc link step
using a batch file (no make) under dos (no desqview but with qemm)
the link time is the same as using Borland 2.0 make in a desqview dos window
with the default limit on memory given to each dos window.
This problem was very serious to me because it is often necessary for
users of my program to compile and link in extra object modules that describe
unusual nerve membrane properties. Eventually I would have wanted to
make use of dll files but I don't have the documentation about how to do that.

2) select() system call.
This was the real killer. I start my application in a dos window and
communicate with a c-like interpreter via stdin/stdout. The user writes
interpreted procedures by invoking a built in microemacs editor and loads
interpreted libraries from disk.
The interpreter is used to construct a graphical user interface using
the InterViews C++ graphics library. The user creates graphs and panels
to view only the information that is of interest and is therefore constantly
creating and dismissing windows. The problem then is to
get console input when the mouse is over the original dos window and
to get gui input when the mouse is over an InterViews controlled X-window.
This should be nicely done witht the select system call which blocks till
input and then calls the right handler depending on which socket was active.
No such luck with desqview's select().

Of less importance but adding to my despair:

3) Could never get simultaneous presses of both buttons of my two button
mouse to send a middle mouse button event. This made it difficult to
use programs like idraw which for multiline drawings used the first button
to add a vertex and the middle button to end the multiline and the third
button to delete the last added vertex. Thus the only way out of that
state was to kill the whole process.

4) When I tried to close any interviews window either by the window manager
menu or by a DISMISS pushbutton I place in every window, the window would
never unmap. 

5) My graph windows include in the title bar the dimensions of the
scene in model coordinates. Thus the title changes whenever the graph
is zoomed, translated, or the window is resized. Apparently desqview
caches all these requests when dragging the mouse because its only after
completing the dragging/zooming and releasing the mouse button that
title bar gets a series of now meaningless changes.

Maybe I'll try again when the next version of go32 comes out.
--Michael Hines

- Raw text -