The 32-bit Unicode Console API is not fully supported by IBM OS/2. This is because of the differences between TAU and IBM OS/2. The TAU console model is mapped onto the IBM OS/2 KBD, VIO, and MOU model in the IBM OS/2 implementation of the 32-bit Unicode Console API. IBM OS/2's notion of screen groups does not match the TAU console model.
In the TAU model, used by the 32-bit Unicode Console API, there are potentially many input queues, screen buffers, and console file objects. On IBM OS/2, such functionality is not available. Each process is in a single "screen group" and cannot access other screen groups, or even multiple screen groups. In the TAU model, even GUI processes can use consoles. This is not possible in IBM OS/2.
In the TAU model, input can only be obtained via the Console API from file handles for input queues, console file objects, and "CON" device objects.
In IBM OS/2, there is only one input source for any process, and the underlying VIO/KBD/MOU system does not operate in terms of ordinary file handles. The 32-bit Unicode Console API as implemented on IBM OS/2 makes few checks on file handles for validity.
Applications must not rely upon this aspect of the IBM OS/2 implementation. For maximum portability from IBM OS/2 to TAU, applications should use one of two file handles for console input: the standard input file handle, or a file handle that has been opened to the "CON" device.
In the TAU model, output can only be sent via the Console API from file handles for screen buffers, console file objects, and "CON" device objects.
In IBM OS/2, there is only one output buffer for any process, and the underlying VIO/KBD/MOU system does not operate in terms of ordinary file handles. The 32-bit Unicode Console API as implemented on IBM OS/2 makes few checks on file handles for validity.
Applications must not rely upon this aspect of the IBM OS/2 implementation. For maximum portability from IBM OS/2 to TAU, applications should use one of two file handles for console output: the standard output file handle, or a file handle that has been opened to the "CON" device.
Console mode flags have no effect on IBM OS/2.
IBM OS/2 does not generate console window size, menu, or focus events. Nor does it provide access to the internal input queues for the KBD and MOU subsystems.
On IBM OS/2 the number of events returned from
DosQueryConsoleInputEventCount()
will never be greater than 1, even if more than one keystroke is actually
queued in the keyboard buffer.
IBM OS/2 does not support the shift state flags for the "Windows" keys or the "fake CTRL" key, and will always report them as not depressed. It will also ignore attempts to set the shift state flags for these keys to the pressed state.
IBM OS/2 will ignore attempts to modify any shift state in a windowed console.
IBM OS/2 places restrictions on the sizes and locations of console windows and screen buffers for full-screen TUI consoles. For such full-screen consoles, the console window is forced to always be the size of the screen buffer and located at (0,0); and the screen buffer itself may only have sizes as permitted by the display hardware.
The exact range of sizes available is determined by the console hardware and the Base Video Handler (which can be found by inspecting the value of the VIDEO_DEVICES environment variable). It will vary from BVH to BVH. Most drivers will support 12, 24, 25, 28, 30, 40, 48, 50, or 60 rows; and 40 or 80 columns.
Unfortunately, the range of available full-screen console sizes is not
available from the Base Video Handler, so fixed values are returned for
DosQueryConsoleMaximumSize()
.
IBM OS/2 furthermore does not maintain the console window size for GUI consoles.
The Console API functions all operate in terms of Unicode (strictly speaking, UCS-2). IBM OS/2 only has 8-bit VIO and KBD functionality.
The VIO subsystem in IBM OS/2 operates in terms of an 8-bit character set. Each "screen group" has a current "VIO code page", denoting which 8-bit character set is being displayed.
The IBM OS/2 implementation of the 32-bit Unicode Console API maps the Unicode character values in its screen buffer to the nearest 8-bit character available in the current code page, and maps the 8-bit characters in the VIO sybsystem's screen to Unicode values using the same current code page value.
The console's output code page can be set and queried via the DosSetConsoleOutputCodePage() and DosQueryConsoleOutputCodePage() API functions.
This mapping is "lossy", in that the original Unicode values of the character cells are potentially modified as 32-bit console programs see them, as they are mapped to 8-bit characters and back.
TAU is not implemented on top of an 8-bit subsystem, and provides a USC-16 screen buffer.
The KBD subsystem in IBM OS/2 operates in terms of an 8-bit character set. Each "screen group" has a current "KBD code page", denoting which 8-bit character set is being displayed.
The IBM OS/2 implementation of the 32-bit Unicode Console API maps the 8-bit characters in the KBD sybsystem's input events to Unicode characters using the current code page value.
The console's input code page can be set and queried via the DosSetConsoleInputCodePage() and DosQueryConsoleInputCodePage() API functions.
This mapping is "lossy", in that the original Unicode values of input characters sent to the input queue are potentially modified as 32-bit console programs see them, as they are mapped to 8-bit characters and back.
TAU is not implemented on top of an 8-bit subsystem, and provides a USC-16 input queue.