LS> WRT Cset, I have to say that I won't aquire it, unless it also
 LS> supports 16bit object code as well as 32bit code. Sorry, it's due to
 LS> preserving an investment, and reducing the learning curve.

 Learning curve ?  From ISO Standard C to ISO Standard C ?  What
 learning curve ?

 LS> Any answers for me on my compiler problem? Don't ask me to use WATCOM.

 Well, if you want a 32-bit compiler that still supports legacy 16-bit
 code, you have no other choice.  WATCOM C++ is the compiler to use.

 Certainly, IBM isn't going to introduce *more* 16-bit support into a
 32-bit compiler, because that is going backwards not forwards.

 ( I say "more" because CSet++ can write 32-bit code callable from
   16-bit code, convert pointers, and generate calls to 16-bit code,
   which is more than enough for most purposes, and unnecessary if a
   whole application is being converted in one go.  )

 From experience, I'd say look long and hard at the amount of time (and
 money) you are wasting preserving a legacy 16-bit system with legacy
 16-bit tools compared to the amount of time it would take to convert to
 using a 32-bit compiler.

 If your code has strong dependencies on a segmented memory model, then
 feel free to kick yourself for not coding it better in the first place. (-:

  ¯ JdeBP ®

... OS/2, The Rolls Royce on the Information Superhighway  
--- Blue Wave/Max v2.12 OS/2 [NR]