Darin McBride wrote in a message to Mike Bilow:

 MB> 2. Change all "far*" pointer arguments to "_far16*".

 DM> Shouldn't that be *_Seg16?  I found the following in
 DM> OS2DEF.H in the \WATCOM\h\os21x directory:

 DM> typedef VOID   * _Seg16  PVOID16;

As far as Watcom is concerned, "_far16" and "_Seg16"
are similar but different operators.  What is really going on here is that
the "_far16" keyword provides source-level compatibility with
Microsoft C, while the "_Seg16" keyword provides source-level
compatibility with IBM CSet/2.

The "_Seg16" keyword is more limited in function and uses a
slightly different syntax, binding to the "*" operator on its
left:

   void * _Seg16 ptr;         /* a 16-bit pointer to void */

The "_far16" keyword binds either to a function name or a
"*" operator on its right, and can also do more:

   void _far16 * ptr;         /* a 16-bit pointer to void */

   int _far16 func(int a);    /* a function in 16-bit code space */

Note that a function declared as "_far16" will automatically
adjust the "int" back and forth between 32-bit and 16-but code as
needed.

 DM> However, when using:

 DM> typedef PVOID16 HSEM16;
 DM> typedef HSEM16 * _Seg16 PHSEM16;
 DM> typedef const char * _Seg16 PCSZ16;

 DM> and linking with \WATCOM\lib386\os2\os2286.lib, and running
 DM> the executable, I got SYS3175 errors.  My assumption, of
 DM> course, is that I was misusing something.  So I loaded in
 DM> the debugger.  I got a task exception fault BEFORE I hit the
 DM> 'execute line' button.  

 DM> Changing to

 DM> typedef void _far16 * HSEM16;
 DM> typedef HSEM16 _far16 * PHSEM16;
 DM> typedef const char _far16 * PCSZ16;

 DM> doesn't seem to help any.  :-(

 DM> And, yes, the functions *are* surrounded by 'extern "C"
 DM> {'... :-) 

Your problem is in the function declarations.  You need to tell the
compiler that the functions must be accessed by a thunk into 16-bit code,
and the proper use of the "_far16" keyword is the best way to do
that.

Peter Fitzsimmons' suggestion about writing a 16-bit DLL to handle this is
a good one, actually, although not really necessary.  If you goal is to get
this done as simply and quickly as possible, then his approach should be
used.  On the other hand, if you are trying to do this as a learning
experience, you may as well keep plugging on getting the compiler to thunk.
 
-- Mike


---