Kevin Ring wrote in a message to Mike Bilow:

>  KR> Alright, maybe I will buy that then.  Do these include files
>  KR> also contain the necessary info for PM programming?
> 
> Yes, Watcom gives you all of the header files and libraries you need to
> do 32-bit or 16-bit OS/2 programs from device drivers to PM 
> applications.  Some of this may not work out of the box, but most of it
> does.

 KR> Alright, this all sounds good..  Just one more stupid
 KR> question for you.  :)

I was sent a netmail correction to my earlier comment that is worth
mentioning, since I am one of the people who has griped most about the
issue.  Watcom does give you the header files needed to do PM programming,
but does omit many of the header files needed to do 16-bit programming to
certain non-PM subsets of the API, especially Vio -- although the
"missing" header files are available from IBM on the DevCon CD as
part of the OS/2 1.3 Toolkit. I would strongly recommend against doing a PM
program in 16-bit, anyway.

 KR> I'm currently working on DOS based
 KR> game in 100% ASM, using DPMI Protected Mode.  How difficult
 KR> will it be to port this to OS/2?  (not considering any PM or
 KR> multithreading stuff we mgiht want to add..)

You would probably have to do a total rewrite unless you have carefully
modularized your program with the intention to do this port.  The main
reason for doing game programming in ASM is to speed up the video routines,
all of which are inapplicable to OS/2 since you really do not want to
require your program to have direct access to video memory.  If you have
encapsulated all of your video primitives, then you would need only to
rewrite the encapsulated primitives to work with OS/2.

DPMI will actually work for you instead of against you in the port.  A
32-bit OS/2 program sees essentially the same flat memory model as a DPMI
program, so your code should be rather easily exchanged provided that you
never depend upon specific memory addresses and similar accidental oddities
of DPMI.

Any device support, involving the mouse, IRQs, or DPMI callbacks, would
have to be completely rewritten.  As with the video routines, the best case
would be if you have the device-specific primitives properly encapsulated.

By encapsulation, I mean that the code should have been isolated at a
source code level, not necessarily at an execution level.  In the case of
assembly language, you could encapsulate the necessary primitives as
macros, in which case you would avoid the overhead of function calling.
 
-- Mike


---