- Forum
- Windows Programming
- a question about regsvr32
a question about regsvr32
a stupid question..because I encountered a problem in register a dll in window.
my questions is should we register all the dll ? when a dll should be registered, when not ?
my understanding is the dll client will search the dll in windows directories (current dir --windows system dir - path) (refer to the link)
http://msdn.microsoft.com/en-us/library/7d83bc18(v=VS.71).aspx
then why run regsvr32 ?
thanks
my questions is should we register all the dll ? when a dll should be registered, when not ?
my understanding is the dll client will search the dll in windows directories (current dir --windows system dir - path) (refer to the link)
http://msdn.microsoft.com/en-us/library/7d83bc18(v=VS.71).aspx
then why run regsvr32 ?
thanks
A COM component is identified by a unique number (called a GUID). When a program wants to use a COM component, it uses the GUID. The COM system looks up the details matching that GUID and uses it to instantiate and connect to the COM object. The object can run withing the hosting process (in proc server), as a seperate program or on another host (using DCOM).
When you install a COM component, the object must be registered. regsvr32 registers an in proc server. Not all DLLs are COM in proc servers, so it follows that not all DLLs should be registered in this way.
When developing a COM in proc server, it's helpful if you register it as you are expected to want to test it.
When you install a COM component, the object must be registered. regsvr32 registers an in proc server. Not all DLLs are COM in proc servers, so it follows that not all DLLs should be registered in this way.
When developing a COM in proc server, it's helpful if you register it as you are expected to want to test it.
RegSvr32 was designed to place very specific information in the registry to support Microsoft's Object Linking and Embedding Technology and its Component Object Model. Alternately, programs linking explicitely or implicitely to dlls and calling functions in them do not need registry information to do so - as you suggested. When a program attempts to load a dll the specified dll search path will be attempted.
thanks kbw and freddie.. your comments are really helpful.
the problem I am facing is registering an old dll freezes the windows login process. our customer's policy is everytime a user login to windows, a script which registers all dll will be called.
this dll seems not a COM type. but the old dll has no problem in register. recently I need recompile this dll. that gives me this problem.
when I recompiled the dll (in VS2003), I got many compilation eorrs, therefore I had to changed some project macros and setting. compiplation succeeded. but produces a different dll size.
there is any way to avoid this "hang" issue ?
thanks thousands.
the problem I am facing is registering an old dll freezes the windows login process. our customer's policy is everytime a user login to windows, a script which registers all dll will be called.
this dll seems not a COM type. but the old dll has no problem in register. recently I need recompile this dll. that gives me this problem.
when I recompiled the dll (in VS2003), I got many compilation eorrs, therefore I had to changed some project macros and setting. compiplation succeeded. but produces a different dll size.
there is any way to avoid this "hang" issue ?
thanks thousands.
Don't use regsvr32 on a DLL unless you know that it's a COM object.
All sorts of things are implemented as DLLs, not just COM objects.
All sorts of things are implemented as DLLs, not just COM objects.
Depending on how the script was done and what you mean by "freezes", it could be simply that a messagebox appears and script execution pauses until you dismiss the message box (maybe it is appearing in the services desktop and therefore invisible to the end user?), or it could be something more complex.
Anyway, you clearly don't know about COM/ActiveX, so I doubt that you were tasked to update and recompile the DLL if it was a COM/ActiveX dll, so most likely the DLL is not COM/ActiveX? Anyway, if the DLL can be registered using regsvr32, then it must have an entry point called DllRegisterServer(), and possibly another called DllUnregisterServer(). If at least the former is not present, the DLL cannot be registerd via regsvr32 and it will tell you so.
What you can do: Run regsvr32 on this DLL to see if you get an error message. Remember to run this command elevated if on Windows Vista or 7.
Anyway, you clearly don't know about COM/ActiveX, so I doubt that you were tasked to update and recompile the DLL if it was a COM/ActiveX dll, so most likely the DLL is not COM/ActiveX? Anyway, if the DLL can be registered using regsvr32, then it must have an entry point called DllRegisterServer(), and possibly another called DllUnregisterServer(). If at least the former is not present, the DLL cannot be registerd via regsvr32 and it will tell you so.
What you can do: Run regsvr32 on this DLL to see if you get an error message. Remember to run this command elevated if on Windows Vista or 7.
thanks webJose
for sure it is not com or ActiveX. there is no DllRegisterServer().. only DllMain as entry point. we got "No DllRegisterServer entry point" error in both new and old dll. but we new dll, I can see a pending regsvr32 process in the taks manager or Process Explorer. but none with the old dll.
the script is to register all dlls. but since it can't end with this dll, therefore it can't proceed with the rest.
anyway thanks for your comment.
for sure it is not com or ActiveX. there is no DllRegisterServer().. only DllMain as entry point. we got "No DllRegisterServer entry point" error in both new and old dll. but we new dll, I can see a pending regsvr32 process in the taks manager or Process Explorer. but none with the old dll.
the script is to register all dlls. but since it can't end with this dll, therefore it can't proceed with the rest.
anyway thanks for your comment.
If I'm not too late I'm curious to know what the reason for wanting to "register" the DLL is? Also why it is necessary to do this EVERYTIME a user logs in? To me at least this seems like somebody who issued this policy got their terminology mixed up, this happens, we all have our "Off Days".
My bet is that they meant for you to use "Rundll32" so that you can take advantage of some exported function or another. It makes a lot more sense then just registering it because registration should only need to be done once.
My bet is that they meant for you to use "Rundll32" so that you can take advantage of some exported function or another. It makes a lot more sense then just registering it because registration should only need to be done once.
Last edited on
Topic archived. No new replies allowed.