Re: Problem with library images on Windows (again)

[Juanma Barranquero]

> It's the issue with both: the prototypes in the header files should be
> consistent with how the functions were compiled, since those
> prototypes are the only way for the compiler to know how the functions
> were compiled.  If it doesn't know that, it might produce wrong code.

Yes, in general, for static linking (either with static libraries, or
with stubs to dynamic ones). But in this case, MSVC is not
compiling/liking statically against any function as defined in the
header. There are no TIFF functions, as far as it knows, just a bunch
of variables of type FARPROC that we're assigning and calling, so
whether there's

 FAR CDECL TIFFOpen(...);

or

 FARPROC TIFFOpen(...);

on the header should be irrelevant. MSVC knows nothing about TIFFOpen;
it just knows there's a variable fn_TIFFOpen which gets initialized
with a call to GetProcAddress() and called afterwards. And it's the
type of fn_TIFFOpen which counts.

> That seems to be the problem.  What I still don't get is how come the
> same declaration that uses FARPROC works for the MinGW build?  Can you
> figure this out?

Perhaps Jason's right and the bug is just not noticeable.

Think of this: if lookup_image didn't use a temporary variable that
gets assigned to a register and accidentally clobbered by tiff_load,
we wouldn't see the problem with MSVC either.

> This doesn't say anything about the calling conventions, just about
> the inner workings of the functions.  So I'm not surprised that both
> versions have the same effect.

Well, I hoped that the Win32 version would use the more common
convention for DLL exports on Windows (that is, pascal). But it
doesn't.

-- 
                    /L/e/k/t/u