[XviD-devel] win32 linking

[suxen_drol]

hi radek & michael,

On Mon,  8 Dec 2003 11:06:14 +0100 Michael Militzer <michael at xvid.org>
wrote:
> Quoting Radek Czyz <syskin at ihug.com.au>:
> > 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.

yep, i added this recently. the directshow filter was dynamically linked
to xvid.dll, which was a no no.

> > 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.

i totally agree, however there are a number of ways to do it. so i
started the TODO statment with  "decide on vfw & dshow linking policy".

do we have a "libxvidcore.dll" or a "xvidcore.dll"?
do we keep the vfw codec as "xvid.dll"?
do we keep the dshow codec as "xvid.ax"?
do we require the library dll to be stored in a particular location?

what if we want to create a dshow encoder? how can we re-use the configuration gui
code from the vfw inside dshow?

> 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...

note: the directshow decoder was dynamically linking _at runtime_.

-- pete