Re: OpenWatcom 1.6 passes tests with DLL build

[Ross Johnson <Ross.Johnson@homemail.com.au>]

Hi Marc,

This is good news.

Sending a small patch via the list is fine I think and if in doubt you 
can send direct to me. I'll endeavour to get it into the next release, 
which is long overdue. Could you please include your Wmakefile - I'm 
sure I had one at some point but I can't find it here anywhere.

Regards.
Ross

Marc Peter wrote:
> Hi,
>
> I've managed to build a DLL version of the library with Open Watcom 1.6
> which passes all tests after only slight modifications to the source.
>
> I used the CVS sources.
>
> Here is a short summary of the changes I made:
> - use the -br compiler switch for both the library and the tests
>     This is necessary so both, library and application, use the same
>     run-time library instance. This fixes the errno problem mentioned
>     in README.Watcom.[1]
> - enable inclusion of <stdint.h>
>     Open Watcom has int64_t in this header.
> - define PTW32_CDECL to be empty
>     This prevents compilation errors in tests, where calling conventions
>     for callbacks don't match. This could also have been fixed by using
>     proxy functions for the callbacks in the tests, but I went for the
>     quick fix.[2]
> - use #pragma aux syntax for inline assembly
>     This is more efficient then _asm { ... } syntax and doesn't require
>     to disable any compiler warnings.
> - fix Wamekefile in the "tests" directory
>     Some extensions in the PASSES variable were missing.
>
> The patch is 225 lines long, my experimental make file has another 22
> lines. If it is okay with the policy of this list, I can attach them in
> another message.
>
> Note:
>   The "Wmakefile" mentioned in README.Watcom was nowhere to be found.
>
> I have not performed any regression tests with other compilers, but I
> don't expect any incompatibilities.
>
>
> best regards
> Marc
>
>
> [1] As soon as a thread is started, the CRT must behave slightly
>     different, for instance lock concurrently used resources such as
>     the heap during malloc/free calls. This is the reason why new
>     threads must be created with a CRT function like _beginthread(ex),
>     and not by calling the Win32 API directly.
>
> [2] __cdecl was only chosen so a DLL created with Open Watcom can be
>     used with different compilers. But mixing runtime libraries of
>     different compilers is another step further towards "interesting"
>     behavior than using two instances of the same CRT - see errno
>     problem. So, if we restrict the DLL to be only used with Watcom
>     generated applications, we can safely use register based calling.
>
>
>