PR> PF> Same as windows (ax=1680h,  int 2Fh).

PR> PF> why are you in a loop waiting for something to happen?  If you
PR> PF> were to call one of the functions that does not return until a
PR> PF> key is pressed,  you wouldn't have this problem.

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

In this case you have the source code, and can re-compile the program.
Sometimes you don't, or can't.  In these cases, you can use the DOS
Settings to help solve the problem.  Run the PULSE utility (from
the Productivity Folder), and adjust the IDLE_SECONDS and
IDLE_SENSITIVITY of your DOS program while it is waiting for input,
until the CPU usage graph drops, then adjust it 10 or so below that
point.  Make the changes permanent in the Program Object you use to
start your DOS program.

dBase III+ works well (on my machine) with an IDLE_SENSITIVITY of 48,
FoxPro works well at 60, Borland Turbo Vision apps work well at 1.

This solves the DOS problem with minimum effort, and you can put the
main thrust where it's really needed:  the native OS/2 version!

___
 X SLMR 2.1a X 

--- Maximus/2 2.02