ISDS - SOME WATCOM COMPILER TIPS FROM DUDE USERS

 [IBM Solution Developer Support][Image] [Image] [Image]

SOME WATCOM COMPILER TIPS FROM DUDE USERS -

Subject: Watcom C/C++ 9.5 for DD I just wanted to follow up on using the Watcom C/C++ 9.5 compiler to write OS/2 device drivers. I have got it working with both the sample code from 'Writing OS/2 Device Drivers in C' and with the DHCALLS.LIB (?) library from the DDK (v1.0) and thought I'd pass this information back should anyone else ask.

1) Instead of _acrtused, the Watcom C runtime library looks for  cstart_. This should be declared as public in the .asm file.

2) Watcom provides a special pragma, cdecl, for specifying the  calling convention used by MSC.  They also provide a _Cdecl   keyword, as in 'word _Cdecl main(...);'.   The runtime library   always wants to look for the main function, however, and   it looks for main_ (per Watcom calling conventions) instead of   _main (MSC) at link time.  I defined a special pragma which   follows the MS calling convention but used the Watcom naming   convention :      #pragma aux MSC_Compat "*_"         parm caller []         value struct float struct routine [ax]         modify [ax bx cx dx es]   which can be used to define main thusly :      #pragma aux (MSC_Compat) main;

3) The compiler flag -Zu must be used for SS!=DS, etc. I believe this   is equilavent to the MS -Aw flag.

Anyways, I just wanted to pass this along if anyone else should ask about the Watcom compiler. It does seem to produce better code than the MS package, and is much better supported i.e. they still support it!

The last time we 'chatted' you expressed your interest in my accomplishments with the Watcom compiler. These are the things I have found when compiling with WATCOM 10.0:

1) The "_Seg16" keyword is not legal when compiling with WCC(Watcom 16bit),  therefore in all declarations "_Seg16" must be replaced with "_far".   Because of this some of the toolkit headers like OS2DEF.H must be changed.   All function declarations type _Seg16 are not valid with the Watcom   compiler. I personally added an #ifdef WATCOM16ONLY ...  #endif construct.

2) The Watcom compiler uses the _FunctionName name mapping. Therefore in all   the headers I had to include the following:

#pragma aux MSC Compat "_*" \ parm caller [] \ value struct float struct routine [ax] \ modify [ ax bx cx dx ex ]; Also after each function declaration in the header(s) the following line must be used: #pragma aux (MSC Compat) FunctionName;

3) The "PASCAL" keyword must be changed to "pascal".

4) The declaration "PUBLIC acrtused" must be changed to "PUBLIC cstart_". The  Watcom compiler will look for this symbol(cstart_) instead of the "acrtused"   that MSC is looking for.

5) Also very important that in the startup.asm module all "_FunctionName" is  replaced with "FunctionName_".(Watcom is looking for '*_' rather than '_*')

There are other small odds and inns that have to do with certain differences between the MSC and the WATCOM compiler. These however are not major and are almost self explanatorry.

> Please note that according to Watcom technical support, there are some     < > problems with using NMAKE with the Watcom compilers/linkers. Despite some  < > really bad documentation on WMAKE, I still suggest that appropriate time   < > is invested in order to use WMAKE.

[Image] [Contacts, feedback, help, and search functions] [Image] [IBM main site information]

