It's unfortunate that there's no 32-bit console API in OS/2 Warp 4, and it's
equally unfortunate that there's no standard DLL for thunking down to the
16-bit VIO, KBD, and MOU subsystems. As a consequence, most C/C++
implementations either generate thunking code on the fly (Borland C++, Watcom
C++, IBM VisualAge C++), or have in their libraries pre-written thunks for the
VIO16, KBD16, and MOU16 subsystems that are statically linked into executables
when needed (MetaWare High C++, EMX C++).
And as a consequence of that, many otherwise purely 32-bit OS/2 applications
contain 16-bit code statically linked into them, simply because they want to
do fancy things in text mode.
Of course, there *is* such a 32-bit DLL: the DLL in the 32TEXT package on the
DevCon CD-ROMs. However, it is beta-level code as the documentation states,
highly unlikely *ever* to become a standard part of OS/2 (going by the lack of
movement in this direction over the past 5 or so years), and, as I found out,
it contains some rather vicious bugs that make it practically useless. One
cannot run two processes simultaneously that use that DLL and that call
KbdCharIn(), for example. The processes die with a SYS3175 somewhere inside
the DLL.
If anyone wants a 32-bit wrapper around the most generally used portions of
the 16-bit VIO and KBD subsystems, I've now rolled my own, CON3216.DLL, which
*does* work when used simultaneously in multiple processes. I can provide an
import library and a replacement header. I've followed the 32TEXT
API as faithfully as I can (given how little documentation there is -- there's
no description of *what* VK_ codes are returned by KbdCharIn for each key, for
example), even going so far as using the same ordinal numbers for the function
entry points.
Better yet, I have also written a proper, 32-bit, Unicode, console API,
CONCALLS.DLL, and a header.
Consider it just one more 16-bit vestige in OS/2 Warp that can now be
eliminated.
¯ JdeBP ®
--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish (2:257/609.3)
|