The name and location of the registerable DLL is not important. The COM
objects do not work with the names of the DLLs but using their guid entries
in the registry which point to the DLL implementing that object. For more
details about this mechanism see the MSDN site under various topics related
to COM (look for "self-registering DLLs")
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/htm/custintf_1pm4.asp
Well, I disagree quite strongly with that.....(Having created quite a few com
objects in my time, that is) Below are the definitions of the various aspects
of a COM object
COM Interface
The way in which an object exposes its services externally to clients. A COM
object provides an interface for each set of related methods (member functions)
and properties (data members and or content).
COM server
A module, either an EXE, DLL, or OCX, that contains the code for a COM object.
Object implementations reside in servers. A COM object implements one or more
interfaces.
COM client
The code that calls the interfaces to get the requested services from the
server. Clients know what they want to get from the server (through the
interface); clients do not know the internals of how the server provides the
services. The most common COM client to implement is an Automation controller.
Delphi eases the process in creating a client by allowing you to install COM
servers (such as a Word document or Powerpoint slide) as components on the
Component Palette. This allows you to connect to the server and hook its events
through the Object Inspector.
With regard to Self Registering DLL's that is a completely different subject
which MAY include a com object....but does not ALWAYS include com objects, and
not relevant to the question asked.
If another named DLL registers the same guid key with their own version of
DLL then that DLL gets used instead by the whole system.
Not correct, it has nothing to do (directly) with a key as you describe it and
in any case the key does describe where the file is AND what its name is. All
DLL's have an internal interface. Some of them provide an ID that is published
into the OS...in this case that interface is identified by the name IDVEn which
has just two functions (Short version...GET and PUT) when the dll posts the
name IDVEn to the system at power up it becomes available to all programs
capable of recognizing it. Simply by linking to IDVEn gives you the black box
functionality that Movie Maker is based on. The ONLY way another DLL could
interfere with this is if it publishes the same Identity together with the same
internal functions....the name of such a dll would be of CONSIDERABLE interest
to Microsoft, which is why I asked the question about its name/location etc.
I rather suspect that (in the case of the OP) a broken registry entry relating
to qdv.dll was repaired by calling the function regsvr32 and had very little to
do with WinAVI....Broken links in the registry occur for all sorts of reasons
including XP crashing for ANY reason at an important moment.
I have downloaded WinAVI, installed it, used it and uninstalled it...everything
still works here. In addition I will be recommending WinAVI to others....it
seems to be an excellent program (Even the free version) I will be reinstalling
WinAVI (thank you for bringing it to my notice) and running some Symantec stuff
to watch what it does, I will report back if any exe or ActiveX or Com object
does try to perform a masquerade, but having watched quite closely the first
install I do not expect to find anything.....so we can rule out WinAVI as the
culprit.
John Kelly
www.the-kellys.org
www.the-kellys.co.uk