[XviD-devel] win32 linking

[Michael Militzer]

Hi,

Quoting Radek Czyz <syskin at ihug.com.au>:

> Hi everyone,
> 
> Allow me please to bring your attention to this point on our TODO
> list:
> 
> * decide on vfw & dshow linking policy. presently we statically link,
>     however this increases the size of zips/packages where both vfw &
>     dshow are included.
> 
> We statically link VfW and DShow, and we don't export xvid_encore()
> and xvid_decore() in either of them.
> 
> Now, let me tell you why this is BAD: we don't allow any application
> to use the already installed core directly, even if the application is
> perfectly GPLed. The only way for such application to use xvidcore is
> to include it in the app itself.
> In particular, THE application that used to use the core directly is
> ffdshow, GPLed directshow decoder filter that we like so much (at
> least I do lol).
> 
> There is also another, more selfish reason - I wouldn't have to
> re-link VfW everytime I recompile the core ;)
> 
> So, is there some good reason not to split the win32 built into
> xvidcore.dll, xvid_vfw.dll and xvid.ax ? It would be pretty clear that
> only GPLed software can link to xvidcore.dll.
> 
> Please note that if you all agree on this, I'll need some instructions
> how to change msvc projects ;)) (yes, I'm that lame).

no objections. BTW: I think we had dynamic linking of the frontends
against a xvidcore dll already in earlier versions of XviD (at least dshow
was dynamically linking). So you could just take a look at how some older
versions did look like...

bye,
Michael