Thursday, February 01, 2007

Back to the future - using 16 bit OS/2 as a development platform

My ongoing coding project hit a couple of rough spots recently. There were a couple of really nasty memory/pointer bugs that were proving stubborn because they weren't surfacing immediately in the DOS, Win32 or 32 bit OS/2 builds of it.

Let me state this up front - I HATE 32 bit "flat" development environments. Page granular memory protection allows far too many off-by-one bugs to slide by unnoticed for too long. Its really sucks. Not much better than old DOS in practical terms.

The old OS/2 1.X 16 bit environment OTOH, is is tremendous ally. Step off the end of a segment by as much a one byte and the hardware's segment limits let you know the instant it happens. Those segment limits are a diamond hard edge, and they're byte granular, not page granular. There is no fuzziness.

So I do a 16-bit OS/2 build of the app using an ancient 87' vintage IBM/MS C compiler and the nasty bugs shook out right away. As an added bonus, I make the thing a FAPI application, and now I've got a build that works under DOS, any version of OS/2 (in protected mode), and under Windows NT/W2K (in protected mode).

What is FAPI you say? FAPI was a mapping layer scheme IBM and MS came up with to map a significant subset of the OS/2 16 bit protected mode API onto DOS, so a 16 bit protected mode application could run under DOS. The FAPI code only adds 20-30K to the size of an application. 16 bit protected mode OS/2 apps run native under NT/W2K in their OS/2 subsystem, so in those environments the app has access to large amounts of memory. Running real mode under DOS, the app will have DOS's memory limits.

FAPI is really quite cool and lets you produce a near universal binary that automatically adapts to whatever environment it happens to be running under.

No comments: