I couldn't find your original message, but by tracing through what I
do have, I'm under the impression that you're accessing 16 bit code
from an otherwise 32 bit application. Each time you make a 16 bit
system call (and all Vio and Kbd calls are 16 bit), your code has to
go through a "thunking" process. Basically, this entails:
  1) translating all of your data pointers from 32 bit offsets to
     16:16 segment:offset values,
  2) pushing parameters to the stack using word size values rather
     than double word values,
  3) preserving certain registers (ebp, ebx, edi, esi, es),
  4) translating the stack to 16:16 format,
  5) calling the actual code (Vio_whatever),
  6) using 16 bit code, translate any 16:16 return values to 32 bit
     offset addresses,
and finally,
  7) using 32 bit code, restore the registers.
Additionally, while objects smaller than 64K can be alligned to the
64K boundries, making translation to 16:16 a mere seven intructions,
if the compiler is not _aware_ of this possibility, OS/2 provides
two system calls for translating to and from. So your code could
become not one system call, but one for each parameter, plus two for
the necessary pushed registers (to and from), and one for the
returned value. That's why it's soooooo sloooow!

There would appear to be only two ways around this. Either write all
of your own screen manipulation routines to affect a buffer, and use
fewer calls, or compile your application to 16 bit code, if you have
that option. If your code does not contain objects larger than 64K,
and data manipulation can be done on word rather than double word
values, and _if_ your compiler and linker support the generation of
16 bit code, this latter option may be your easiest (and possibly
even fastest) option.
___
 X SLMR 2.1a X 

--- Maximus/2 2.02