[Xvid-devel] Patch for XVID MPEG-4 DirectShow/MediaFoundation filter

[Jerker Bäck]

Hi Edouard,

I knew that requests of changing the main library header would cause reactions. But it is a standard solution present in almost all portable libraries, the one suggested is a simple one. The most extreme variant would be the PNG library.

Note1: The XVID_IMPEXP macro does absolutely nothing other than mark the function visually as an exported function. Unless you define XVID_BUILD_DLL, the current code is unchanged (extern is defined). As I said, this is only for convenience. Using __declspec(dllexport) when building the xvidcore DLL is not required (a DEF file is favourable), but can be useful for some developers in the format of the import library. It could also be useful for some new shared library solutions (just add #elseif (SHARED_CONDITION)).

> secondly, your patch is wrong in regard to the use of declspec
> (dllexport). If one uses the xvid.h file for using the xvid dll, the macro
> you introduce should be declspec (dllimport). So either your patch is
> incomplete or you rely on some specific compiler/linker behavior declaring
> missing symbols at link time as declspec (dllimport) when presented some
> archive with their import symbol variant.
No I'm not, __declspec(dllimport) is a totally different thing and sometimes make more of a mess than helps. It's not needed, the current extern define works just fine.

> It also doesn't cope with possible cases such as a static windows lib.
What do you mean? A static library doesn't deal with exported functions.

Note2: The XVID_CALL macro only adds the __cdecl calling convention to xvidcore exported functions and only to interested compilers. This to make it clear for implementations of Xvid how the exported functions should be used. Without this statement an Xvid application compiled with e.g. __stdcall would expect xvidcore exported functions to also be __stdcall, which is wrong and results in linking errors. 

If I interpret your view on this right, your opinion is that it should be dealt with by the individual developers and that the xvidcore team should concentrate on the source rather than messing with header changes. How is that supposed to help? What could the individual developers do other than make local changes to xvid.h? This was actually one of the first things I had to do in the xvid source.

Finally we got the question whether libxvidcore could be compiled with another calling convention than __cdecl. I just mentioned this as a background in the patch.

> xvid.h file exposes just an api whose code is implemented in pure c files.
> It should be no problem for these files to be compiled using other calling
> conventions. If need be for functions to be marked using an explicit
> calling convention, these should be the assembly functions, marked as
> cdecl. This would definitely consolidate xvid source code builds against
> different calling convention usage.
You're wrong and you would know this if you had tried it. You will need to mark all assembler implemented functions with XVID_CALL and the macro would have to be defined in a global header which is forced included. Even this is not enough since there are additional function pointers that also needs to be marked. My conclusion was that is not worth the effort and you've got the potential risk of bugs not noticed by the compiler. libxvidcore is to be considered to have an requirement for __cdecl unless the source changes.

Regards
Jerker