TD>
  > If your using C, there is probably some help for text mode available
  > in the standard libraries. Borland [...] CONIO.H [...] these functions
  > are not ANSI [...] vary from compiler to compiler [...]
  >
  > If you really want to use the VIO calls, it is certainly possible to
  > compile a code segment and see how the compiler assembly language
  > looks with the debug facility or by having the compiler output as
  > assembly language if it has that feature (Borland does).
TD>

  This is a fallacy.

  For portability across compilers, the VIO subsystem is the *BEST*
  idea, not an afterthought as you seem to imply.

  The reason for this is that the VIO subsystem is part of the system
  API, and thus is available across all compilers, and all languages
  (that support calling the system API directly).

  I don't know what you are thinking of when you suggest looking at the
  generated code for a call to a VIO function.  That's hardly going to
  be much help, since that is just a (thunked) function call.  Looking
  at code to push parameters onto the stack is hardly going to tell you
  what the function being called does.

  Watcom C++ 10.5a users have the VIO API documented in the on-line
  reference (\WATCOM\BINP\HELP\PRCP.INF), along with the rest of the
  system API.  Users of other C++ compilers for OS/2 have to obtain the
  1.3 Toolkit (where VIO is documented) separately if they want
  documentation, but they nevertheless can *all* call the VIO subsystem
  without problem.

  And to round off, you may care to note that the VIO API is also
  available for DOS using either the libraries in the 1.3 Toolkit, or
  the libraries in FAMAPI.ARJ (which is a port of the 16-bit Family API
  for OS/2 1.x to DOS, complete with full source, that is available on
  quality FIDONET files sites worldwide).

  > JdeBP <
___
 X MegaMail 2.10 #0:

--- Maximus/2 3.01