MB>
  > I seem to recall reading somewhere, that the handles returned
  > by the API calls weren't the same as the handles used in
  > the C RTL... but that must have been an earlier version, or
  > I'm thinking of a different OS...
MB>

  It's completely up to the C++ compiler, but since OS/2 hands out file
  handles to a process starting from 0 and working upwards most reasonable
  RTL implementors use OS/2 file handles directly for `file descriptors'
  (for the POSIX 1003.1 library functions read/write/open/close &c.).

  Other operating systems use different schemes.  QDOS used an interesting
  scheme that combined the system file table index with a sequence number
  to provide a file handle to processes, yielding handle values that
  jumped about all over the place.  A C/C++ runtime library on such a
  platform would have to have a mapping between the file descriptors used
  in the POSIX 1003.1 library functions and the system file handles.

  It's unfortunate that neither the ISO C standard nor the POSIX 1003.1
  standard require implementations to document how the respective library
  functions relate to the underlying system API functions.  Although since
  OS/2 has most of the same concepts in its system API as in the POSIX
  1003.1 library, the mapping is usually straightforward.

MB>
  > Next task, is to find ppp sources somewhere, so I can see
  > if I can modify it to produce a ppp that will accept hot
  > com handles, instead of insisting on opening the port
  > itself. :)
MB>

  I remember someone saying a year or so ago that an FTN mailer program
  was specifically designed to administer and control the use of a COM
  port (scheduling events at certain times, altering the usage throughout
  the day/week, and answering calls and invoking the necessary service
  programs) and that it was a damned shame that IBM didn't take advantage
  of this and make its SLIP/PPP implementations compatible with the way
  that most FTN mailers work.

  > JdeBP <
___
 X MegaMail 2.10 #0:

--- Maximus/2 3.01