* Original Area: comp.os.os2.programmer.tools
Originally From: awu{at}freenet.edmonton.ab.ca

Watcom Tech Support has sent me a file detailing the major differences
between 10.5 and 10.0. Unfortunately, a sense of community spirit has
possessed me and so I'm posting it for your perusal. ;-)

Now that there exists at least a (semi-) official acknowledgement of some
of the problems 10.0 has (they wouldn't admit to me that the OS/2 debugger
has problems), perhaps we should add to this list a section that details
bugs that haven't been fixed, plus any new bugs that show up in 10.5. In
other words, I'm calling for the creation of a non-Powersoft sponsored FAQ
for Watcom C/C++.

I'm willing to be the maintainer (though we'll need volunteers for ftp
sites) if everyone chips in. To get things rolling please:

- look over the list below and try out the examples and think about your
own problems before verifying or disputing the items, or adding a bug to
the list
- post verifications, additions, disputes, etc. for the list and FAQ to the
newsgroup comp.os.os2.programmer.tools ONLY for the moment - I'd like to
start out slowly to find out how much interest is in an FAQ before I spread
it out over other newsgroups
- opinions on whether there should be an FAQ or not should also be placed
in the newsgroup
- please either respond to this posting OR use the header
"[WatFAQ]" in your subject line so I don't have to wade through
all of the threads

Just a few things to think about:

- is the bug list and fixes comprehensive?
- what current work arounds exist?
- what problems do the tools have?
- what utilities, tools, and libraries work well with Watcom? - what
problems do utilities, tools and libraries have with Watcom? - overall,
what is Watcom suited for and what are the better alternatives?

Any changes to the text that I've made are enclosed in "[ ... ]".
Otherwise, I've tried to keep the document as close as possible to the
Watcom original. My apologies for any mistakes that have slipped through.
--------------------------------------------------------------------------
MAJOR DIFFERENCES from Version 10.0

-   New installation program
-   Visual Programmer for Windows (MFC) applications
-   MFC 3.0 support
-   Native C++ exception handling support
-   Improved language compatibility with Microsoft
-   Browser can now be used to browse C code
-   OS/2 3.0 Warp support
-   Toolkit for OS/2 1.3
-   Windows NT 3.5 support
-   Toolkit for Windows NT 3.5
-   Windows 95 (Chicago) support
-   Source Revision Control System hooks in editor
-   TCP/IP remote debug servers for OS/2 and Windows NT/95

In addition to these new features, we have also made a number of
improvements to the software.

1.  The editor is more tightly integrated with the IDE.

2.  It is now easier to select your own favourite editor from the IDE.

3.  The keyboard interface in the Integrated Development Environment (IDE)
    has been improved.

4.  The "fr" option, which is supported by the compilers &
assembler, can
    be used to name the error file drive, path, file name and/or extension.

5.  We have added the "t" option to the C++
compiler to set the
    number of spaces in a tab stop (for column numbers in error messages).

6.  The C compiler now supports {at}filename on the command line like the C++
    compiler currently does.

7.  The "__stdcall" linkage convention has changed. All C symbols (extern
    "C" symbols in C++) are now suffixed by "{at}nnn"
where "nnn" is the sum
    of the argument sizes (each size is rounded up to a multiple of 4 bytes
    so that char and short are size 4). When the argument list contains
    "...", the "{at}nnn" suffix is omitted. This was done
for compatibility
    with Microsoft. Use the "zz" option for backwards compatibility.

8.  The 32-bit "__cdecl" linkage convention has changed. Watcom C/C++ 10.0
    __cdecl did not match the Microsoft Visual C++ __cdecl in terms of the
    binary calling convention; Visual C++ saves EBX in a __cdecl function
    but Watcom C/C++ 10.0 modified EBX. Watcom C/C++ has been changed to
    match Visual C/C++.

    If you wrote a "__cdecl" function in an earlier version of Watcom
    C/C++, the EBX register was not saved/restored. Starting with release
    10.5, the EBX register will be saved/restored in the prologue of a
    "__cdecl" function.

    Another implication of this change is that "__cdecl" functions compiled
    with an earlier version of Watcom C/C++ don't match the calling
    conventions of the current version. The solution is either to recompile
    the functions or to define a "__cdecl_old" pragma that matches the old
    calling conventions.

        #pragma aux __cdecl_old "_*" \
                    parm caller [] \
                    value struct float struct routine [eax] \
                    modify [eax ebx ecx edx];

        #pragma aux (__cdecl_old) foo;

        extern int foo( int a, int b );

        void main()
        {
            printf( "%d\n" , foo( 1, 2 ) );
        }

9.  We now allow:

        extern "C" int __cdecl x;

    It must be extern "C" for __cdecl to take effect since variables have
    their type mangled into the name for "C++" linkage.

10. In C++, we have removed the warning for "always true/false" expressions
    if the sub-expressions are constant values.

11. We have added support for:

        #pragma pack(push,4);
        #pragma pack(push);
        #pragma pack(pop);

12. We have added support for:

        #pragma comment(lib,"mylib.lib")

    which has the same semantics as:

        #pragma library( "mylib.lib" )

13. We have added support for expanding macros in the code_seg/data_seg
    pragmas:

        #define DATA_SEG_NAME "MYDATA"
        #define CODE_SEG_NAME "MYCODE"

        #pragma data_seg( DATA_SEG_NAME )
        int x = 3;

        #pragma code_seg( CODE_SEG_NAME )

        int fn() {
            return x;
        }

14. We have fixed the 16-bit compiler so that it matches the Microsoft
    16-bit compiler for the following cases:

    -   If a pascal function is defined when compiling for Windows 3.x, use
        the fat Windows 3.x prologue in the function.

    -   If a cdecl function is defined when compiling for Windows 3.x, use
        the fat Windows 3.x prologue in the function.

15. We have fixed the compiler so that

        #include 

    works as expected (it was searching along the INCLUDE path only).

16. In C++, we have fixed a problem where an import was generated in the
    object file for a virtual function call. This will reduce the size of
    executables under certain circumstances.

17. In C++, we have removed the prohibition of pointer to array of unknown
    size declarations.

    EXAMPLE:

        int (*p)[];

18. In C++, we have fixed the diagnosis of lexical problems during macro
    expansion to remove spurious warnings.

    Example:

        #define stringize( x )  #x

        stringize( 2131231236172637126371273612763612731 )

19. We have corrected the check for too many bytes in #pragma for assembler
    style aux #pragmas.

20. Undeclared class names in elaborated class specifiers are now declared
    in the nearest enclosing non-class scope. Undeclared classes are also
    allowed in arguments now.

    Example:

        struct S {
            // used to declared ::S::N but now declares ::N
            struct N *p;
        };

        void foo( struct Z *p );    // declares ::Z

21. We have fixed unduly harsh restriction on virtual ...-style functions.
    They are now allowed in single inheritance hierarchies as long as the
    return type is not changed when the virtual function is overridden. In
    multiple inheritance hierarchies, an implementation restriction is
    still present for generating a "this" adjustment thunk for virtual
    functions.

22. We have fixed line number information for multi-line statement
    expressions in some weird cases.

23. We have fixed function template parsing of user-defined conversions
    that use an uninstantiated class in their operator name.

    Example:

        void ack( int );

        template 
            struct S {
                S( T x )
                {
                    ack( x );
                }
            };

        template 
            struct W {
                operator S();
            };

        template 
            W::operator S() {
                return 0;
            }

24. We have fixed a compiler problem that caused a linker warning "lazy
    reference for  has different defualt resolutions" in cases
    where the compiler or programmer optimized virtual function calls to
    direct calls in modules that also contained virtual calls.

    Example:
        T.H
            struct S {
                virtual int foo() { return __LINE__; }
            };
            struct T : S {
                virtual int foo() { return __LINE__; }
            };

        T1.CPP
            #include "t.h"
            struct Q : T {
                virtual int foo() { return S::foo() + __LINE__; }
            };

            void foo( T *p )
            {
                Q y;
                y.foo();
                p->foo();
            }
        T2.CPP
            #include "t.h"

            void foo( T *p );

            void ack( T *p ) {
                p->foo();
                foo(p);
            }

            main() {
                T q;
                ack( &q );
            }

25. When a class value is returned and is immediately (in the same
    expression) used to call a member function, the value may not be stored
    in memory.

    Work around: introduce a temporary

    Example:

        struct S {
            int v;
            int member();
        };

        S foo();

        void example( void )
        {
            // foo().member();  // replace this line with:
            S temp = foo();
            temp.member();
        }

26. Throwing pointers to functions did not work when the size of a function
    pointer is greater than the size of a data pointer.

    Word around: place the function pointer in a class and throw the class
    object.

27. We have fixed default argument processing for const references to an
    abstract class. The following example would not compile properly:

    Example:

        struct A {
            virtual int foo() = 0;
        };

        A &foo();

        void ack( A const &r = foo() );

        void bar() {
            ack();
        }

28. We have made "DllMain" default to extern "C"
linkage for Microsoft
    Visual C++ compatibility.

29. We have duplicated a Microsoft Visual C++ extension that was required
    to parse the Windows 95 SDK header files.

    Example:

        typedef struct S {
        } S, const *CSP;
             ^^^^^- not allowed in ANSI C or current WP for C++

30. We now do not warn about starting a nested comment if the comment is
    just about to end.

    We also fixed the code that figures out where a comment was started so
    that a nested comment warning is more helpful.

    Example:

                /*/////////*/
                           ^-

31. We have fixed a problem where extra informational notes were not being
    printed for the error message that exceeded the error message limit.

    Example:

        // compile -e2
        struct S {
            void foo();
        };

        void foo( S const *p )
        {
            p->foo();
            p->foo();
            p->foo();
            p->foo();
        }

32. We have fixed a problem where the line number for an error message was
    incorrect.

    Example:

        struct S {
            void foo() const;
            void bar();
        };

        void S::foo() const
        {
            bar();

            this->bar();
        }

33. We have fixed output of browser information for instantiated function
    template typedefs.

34. We have upgraded the C++ parser so that casts and member pointer
    dereferences can appear on the left hand side of the assignment
    expression without parentheses.

    Example:

        p->*mp = 1;
        (int&)x = 1;

35. In several cases, when a function return or a construction was
    immediately dotted in an expression, the generated code was incorrect.

    Example:

        struct S {
            int x;
            int foo();
        };

        extern S gorf();

        void bar()
        {
            gorf().foo();
        }

    The work around was to break the statement in two:

    Example:

        S temp = gorf();
        temp.foo();

36. In several cases, when a function or a construction was immediately
    addressed in an expression, the generated code was incorrect.

    Example:

        struct S {
            int x;
        };

        extern void fun( S* );

        void bar()
        {
            fun( &gorf() );
        }

    The work around was to break the statement in two:

    Example:

        S temp = gorf();
        fun( &temp );

37.

    We have added support for:

        #pragma error "error message"

    Use the ANSI method because it is more portable and acceptable
    (Microsoft header files use the less portable #pragma when there is a
    perfectly fine, portable way to issue a message).

    The portable, acceptable method is:

        #error "error message"

38. We have added support for __declspec(dllexport) and
    __declspec(dllimport) for Win32 (i.e., WinNT 3.5 and Win95) programs.
    Here are some examples:

    Example:

        __declspec(dllexport) int a;        // export 'a' variable
        __declspec(dllexport) int b()       // export 'b' function
        {
        }

        struct __declspec(dllexport) S {
            static int a;                   // export 'a' static member
            void b();                       // export 'b' member fn
        };

        extern __declspec(dllimport) int a; // import 'a' from a .DLL
        extern __declspec(dllimport) int b();// import 'b' from a .DLL

        struct __declspec(dllimport) I {
            static int a;                   // import 'a' static member
            void b();                       // import 'b' member fn
        };

39. The C++ compiler generates better error messages for in-class
    initializations and pure virtual functions.

    Example:

        struct S {
            static int const a = 0;
            static int const b = 1;
            void foo() = 0;
            void bar() = 1;
            virtual void ack() = 0;
            virtual void sam() = 1;
        };

40. We have fixed macro processing code so that the following program
    compiles correctly. The compiler was not treating "catch" as a keyword
    after the expansion of "catch_all".

    Example:

        #define catch(n) catch(n &exception)
        #define xall (...)
        #define catch_all catch xall

        main()
        {
            try{
            }
            catch_all{
            }
        }

41. We have fixed a problem where #pragma code_seg caused a page fault in
    the compiler when the code_seg was empty.

42. We have fixed a rare problem where a #include of a file that was
    previously included caused the primary source file to finish up if the
    CR/LF pair for the line that the #include was on, straddled the C++
    compiler's internal buffering boundary.

43. We have added support for #pragma message( "message text" ). It outputs
    a message to stdout when encountered. It is used in Microsoft SDK
    header files to warn about directly including header files and obsolete
    files.

44. We have fixed #pragma code_seg/data_seg to properly set the class name
    of the new segment in the object file.

45. We have fixed a problem with the -zm -d2 options that caused a compiler
    fault in some circumstances.

46. We have fixed default library records in .OBJ file so that user
    libraries are ahead of default compiler libraries in the linker search
    order.

47. We have fixed handling of intrinsic math functions so that the code
    generator will treat functions like sqrt as an operator.

48. We have added support for using OS-specific exception handling
    mechanisms for C++ exception handling during code generation. Enable it
    with the new -zo option.

49. __stdcall functions now have Microsoft Visual C/C++ compatible name
    mangling.

50. We have added a number of new functions to the C Library. These have
    been added to improve Microsoft compatibility.

        dllmain (nt only)
        libmain (nt only)
        _access
        _dos_commit
        _dup
        _ecvt
        _fcvt
        _fstat
        _fstrdup
        _gcvt
        _itoa   [repeated in list]
        _locking
        _lseek
        _ltoa   [repeated in list]
        _memicmp
        _set_new_handler
        _stat
        _strdate
        _strdup
        _stricmp
        _strlwr
        _strnicmp
        _strrev
        _strtime
        _strupr
        _tolower
        _toupper
        __isascii
        __iscsym
        __iscsymf

51. In version 9.5, the linker used to include LIBFILE object files in
    reverse order (i.e., the last one listed was the first to be included).
    We have corrected this behaviour so that they are included in the order
    listed.

        Directive           Old Order       New Order
        -------------       ---------       ---------
        FILE    obj_a           3               3
        LIBFILE obj_b           2               1
        LIBFILE obj_c           1               2
        FILE    obj_d           4               4

    In the above example, the object files will be included in the order
    indicated (LIBFILE object files are always included first).

----------+------------------------------+--------------------------------
   Alex   |  awu{at}freenet.edmonton.ab.ca  | "Old C programmers never die -
    Wu    |  alexw{at}worldgate.com         |  they're just cast into void."

--- Maximus/2 2.02