Paul Rider wrote in a message to Peter Fitzsimmons:

 PR> Remember, this is a dos program, and to the best of my
 PR> knoledge Borland does not simply put a process to sleep and
 PR> wait for a keyboard interrupt (as there is only supposed to
 PR> be one process). Any way you look at it (unless you explain
 PR> otherwise, I'm open minded) there is a loop.

 PR> here is basically what I was doing...(I allways welcome
 PR> better code.) while( Interested )
 PR> {  if( kbhit() )  {
 PR>      TakeApropriateAction()
 PR>    }else if ( the_window.SizeHit() )  {
 PR>       TakeDifferentAction()
 PR>    }
 PR>    ReleaseTimeSlice(); //added this  [ thanks Mike Bilow
 PR> ]... }

 PR> Only way I could think of to call a function that doesn't
 PR> return until a keystroke, or mouse message (under dos) would
 PR> still have a loop. 

You are right in that there is no easy way to handle this in a DOS program
that runs under OS/2, since there is really no way to have a
single-threaded DOS program block on BOTH keyboard and mouse input. 
Blocking on keyboard input is easy -- fgetc() will do it -- but any program
which needs to be responsive to both keyboard and mouse input should not be
a DOS program.  Short of doing rather vicious tricks in DOS, such as
synthesizing a semaphore by using the mouse driver callback facility,
releasing the timeslice is probably better than nothing.

What you really seem to want is a GUI.  Under either Windows or OS/2 PM,
you register a function that is called by the operating system to send
messages to your program.  You then sort out these messages about mouse and
keyboard actions and dispatch the appropriate routines.  Windows
applications are co-operatively multitasked, however, so you would not get
any real benefit out of porting to Windows as opposed to just releasing
timeslices as above.

In a native OS/2 PM application, you have a whole new opportunity.  Your
message processing loop is, as with Windows, only called by the operating
system when it actually has messages, but now the dispatcher can create new
threads on the fly to do the real work.  If done properly, an OS/2 PM
application will consume no system resources except when actually doing
work, that work will mostly be done by independent threads which die when
they are done, and the user will have the feeling of instant
responsiveness.

 PR> BTW, why did you choose WATCOM C++ ? is it in you opinion
 PR> supperior to borland? If so, why? I just bought Borland's
 PR> C++ for Os/2, but I'm not on a budget so... 

Just my opinion, but the Watcom compiler generates far superior code
compared to Borland.  The Watcom IDE is pretty lame, but it does work. 
Also, the Watcom compiler is a lot cheaper than the Borland compilers to
get the same capabilities, since the Watcom compiler will make DOS, DOS
extended, Windows, Windows NT, OS/2 16-bit, and OS/2 32-bit targets right
out of the box.  The Borland OS/2 compiler only makes OS/2 32-bit targets,
while the Borland DOS and Windows compiler is sold separately, and Borland
does not have a product that makes OS/2 16-bit targets.

I have not used the newest Borland OS/2 compilers, but the earlier ones
were afflicted by serious bugs, and people here still often complain about
them.  Several of my colleagues use the Borland compiler, and it is not
unusual for very mysterious things to happen in the Borland run-time
library functions that we end up fixing by coding explicit calls to the
OS/2 API without ever really knowing what went wrong.
 
-- Mike


---