RE: FN-FORUM: problems registering a DLL

date posted 20th January 2004 10:50

>
> just looked at the dependancy, and all the DLL's it depends
> on are there and registered - however they're newer versions.
>
> i've just registered it on my own box with no problems, the
> difference is my box is win2k, theirs is win2003. possibly a
> version issue?
>

It is not necessarily a particular dll that is missing, it is quite
possible that it is one of the com objects that is in one of the dll's.
However I would have expected win 2003 to be backward compatible with win2k.
Depending on how the dll has been written, it is likely that the
registration process is instantiating one of the objects in order to read
configuration information. This object will undoubtedly be creating other
(possibly system) objects. It will be one of these objects that isn't
registered.

There is no real way to find out what the object is without the source or
being able to debug it in some way. You could compare all the classid's on
the win2k machine with the classid's on the win2003 machine but this is a
tremendous task and you will almost certainly find dozen's of different
ones.

When you run the dependancy walker on the dll, I'm fairly sure it will only
tell you which dll's are statically required by your problem dll. Those
that are dynamically required won't appear.

There are better versions of depends - I don't have url's here but you can
google for them. The upshot is that the error message is certainly due to a
missing object of some kind, whether it be a missing dll or a dll that is
there but hasn't been registered properly.

Regards
Keith Giddings
GP Software (Thame) Ltd.
www.gpthame.com & www.whirlingdervishes.com
Specialists in Delphi, COM and dotNET technical and scientific programming
Borland Technology Partner and Microsoft Partner.