Link to home
Start Free TrialLog in
Avatar of dredg
dredg

asked on

Why a DLL has to be self-registered?

This is more of a curiosity question than anything.

Does every dll you create have to be made with the self-register option?  What's the difference with making a dll non-self registerable?  What's the downside to that?

Thanks.
Avatar of drichards
drichards

Only COM dll's need to be registered, though I suppose you could use this feature for other reaons in your dlls.

You can make them without the ability to self-register.

A dll that cannot self-register lacks the DllRegisterServer entry point.  This is the function that is called if you try to run regsvr32 on the dll.

The DllRegisterServer method should build all the necessary COM registry entries for the dll.

The downside of not doing it is that you will need to provide an alternate means of registration or no one will be able to use your COM dll easily (maybe not at all depending on what else you provide).
A self register DLL exposes the well defined method DllRegisterServer - as drichards has detailed well.

A non-self registerable usually has an associated type library (could either be embedded within the DLL or stand-alone). Registration is then performed via the API RegisterTypeLib.

It's becoming more and more frequent whereby a self-registering DLL simply calls RegisterTypeLib on an embedded type library.

Who knows, registration could be performed by an installation package/program.
Avatar of dredg

ASKER

^^^So when you make a dll in Visual Studio, and you don't use the self-register option.......is that why a .lib file usually will come with the dll?  So if I make the dll self-registerable......there will be no .lib file with it?

Do I have this right?

BTW, thanks guys for the info.
ASKER CERTIFIED SOLUTION
Avatar of _ys_
_ys_

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of dredg

ASKER

sorry....forgot to do that.

Some related info about VB6 DLL's

VB6 generates the DllRegisterServer entry point by default, when building a project that has a publicly instantiable object (in VB6, a "Class") but having it is one thing, you don't have to register an ActiveX dll to use it, the entry point is there should you care to use it.

There are techniques by which VB ActiveX dll's can be invoked via the API, and can self-instantiate, or be instantiated by a client, without  going through the registry.  A kind of private COM service,  although the primary objective from a VB6 systems programmer is to enable a VB dll to be used as a "normal" DLL (ie. via API), but still provide a VB GUI service!

One approach to this is to build the ActiveX dll and replace the normal entry point with a  DllMain function that can automatically do the required COM initialisation as part of the normal LoadLibrary() startup procedure.....

Theoretically an "EveryMan's" VB6 ActiveX DLL might be perfectly capable of being all things (COM and API)  to all callers (VB, and not VB) ...

Jim White
MathImagics Software Engineering
Surrey UK

I forgot to add the observation, that knowing these things can be done in VB6 would suggest that a similarly exotic DLL could also be done in Visual C,  or any language, where it would actually be easier to implement, I would imagine.  We have some extra hoops we must jump through with VB6 ;)

Cheers