[XviD-devel] patch for dshow inf installer

[Reini Urban]

Edouard Gomez schrieb:

> Selon Reini Urban <rurban at x-ray.at>:
> 
>>> - do we have two .inf files (one for dshow and another for vfw)
>>>   Pros: users can install two components
>>>   Cons: maybe it's harder to decide when to replace the
>>>         common xvidcore.dll
>>
>>Convinced. This is probably the easiest way.
>>But I don't really understand the dowsnside of the common xvidcore.dll
>>dependency. Either vfw or dshow will update the common file(s). As long
>>as the modularization is good enough... Older xvidvwf.dll should work
>>with newer xvidcore.dll and the other way round also. Anyone tested this?
> 
> 
> It's hard because to know the dll version you have to either trust the ctime
> file field (creation time field), or an easy version number retrievable from
> the DLL (iirc, it's possible to include this in a dll ressource, but i dunno if
> they are intelligent functions in windows that advertise the user he's trying
> to replace a version1 lib that is newer than version2)

not with regular DLL. just for COM modules they invented two versioning 
schemes.

Well, the only DLLHELL problem I see is with the step from 1.0. to 1.1, 
when various xvid.h structs were extended, but there is no versioning 
problem so far, since the core dll was renamed also.
I don't know how the inter-dll api changed with the 0.9x versions.

But for the future to avoid such dllhell problems 
(http://www.perldesignpatterns.com/wiki.cgi?DllHell)
one should name the core dll properly.
such as xvidcore.dll (for 1.0.1), xvidcore11.dll and so on.
same for the other dll's: xvidvfw11.dll and xvid11.ax

or forget modularization,

or check the API version at runtime with new API functions.
(ressource string checking is too cumbersome IMHO)
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/