installing .dll files in Win XP

[Silvia]

Hi:
I need to install a .dll file in my PC, can someone tell me how to do it,
please?
I use Windows XP Professional.
Thanks for your help

 

[The Real Truth MVP]

Go to Start> Run and type:

regsvr32 <path & filename> of the dll


--
The Real Truth http://pcbutts1-therealtruth.blogspot.com/
*WARNING* Do NOT follow any advice given by the people listed below.
They do NOT have the expertise or knowledge to fix your issue. Do not waste
your time.
David H Lipman, Malke, PA Bear, Beauregard T. Shagnasty, Leythos.

 

[John Inzer]

Hi:
I need to install a .dll file in my PC, can someone tell me how to do
it, please?
I use Windows XP Professional.
Thanks for your help

=============================
Maybe it goes in the C:\Windows\System32
folder and you'll probably have to register it.

Example...lets say it was shimgvw.dll
you would go to...Start / Run and enter:

REGSVR32 SHIMGVW.DLL
(Yes, there's a space between 2 and S)

Click...OK.

A dialog box should report the following:

"DllRegisterServer in SHIMGVW.DLL succeeded"

Hope this helps...

--

J. Inzer MS-MVP
Digital Media Experience

Notice
This is not tech support
I am a volunteer

Solutions that work for
me may not work for you

Proceed at your own risk

 

[PA Bear [MS MVP]]

What DLL file? Do you get an error message saying that NAME.DLL is missing
or cannot be found?

 

[Jim]

Hi:
I need to install a .dll file in my PC, can someone tell me how to do it,
please?
I use Windows XP Professional.
Thanks for your help

What is the problem ?

 

[Tim Meddick]

Despite all the advice to 'register' .dll files, only some .dll files
will register with the regsvr32 command. In fact, only those dll's that
have a self-register resource section will register with this command.

You should say what makes you think that you need a .dll file 'installed'?

Sometimes, it can be as simple as copying the file to your 'system'
directory (c:\windows\system32).

Again, what file is it you think you need?

==

Cheers, Tim Meddick, Peckham, London.

 

[Silvia]

Thanks for your help, but now I have a new error.
The name of the .dll file is: dac32.dll
I downloaded from different places
when I do: start, run, regsvr32 dac32.dll
I get: " dac32.dll was downloaded, but it couldn´t find the entry point
DllRegisterServer This file couldn´t be registered "
Could you tell me, what can I do to solve this problem ?
Thanks for your time

 

[PA Bear [MS MVP]]

Does "Cubase" or "Magix Music Monitor" mean anything to you?

 

[Tim Slattery]

Thanks for your help, but now I have a new error.
The name of the .dll file is: dac32.dll
I downloaded from different places
when I do: start, run, regsvr32 dac32.dll
I get: " dac32.dll was downloaded, but it couldn´t find the entry point
DllRegisterServer This file couldn´t be registered "

In that case it probably doesn't need to be registered. Not all DLLs
do.

A DLL is just a collection of functions that can be called by any
program. DLLs that need to be registered are ActiveX servers. They
will export a couple of standard functions that can be called in the
same way that any other DLL function is called. One of those is
DllRegisterServer. Others will enumerate other functions within the
DLL and provide some information about how to call them. The
"DllRegisterServer" function will make an entry in the registry
enabling other programs to find the ActiveX server DLL by searching on
its name.

Since your DLL (apparently) doesn't have a "DllRegisterServer"
function, I'd guess that it's not an ActiveX server. Put it in the
same directory as the application that will use it, or in
c:\WinNT\System32, or someplace on the PATH.

 

[Bill in Co.]

In that case it probably doesn't need to be registered. Not all DLLs
do.

A DLL is just a collection of functions that can be called by any
program. DLLs that need to be registered are ActiveX servers.

Is that true for all the ones that need to be registered (i.e., that those
DLLs are ALL "ActiveX servers")? I guess I need to look up the defn of
ActiveX.

They will export a couple of standard functions that can be called in the
same way that any other DLL function is called. One of those is
DllRegisterServer. Others will enumerate other functions within the
DLL and provide some information about how to call them. The
"DllRegisterServer" function will make an entry in the registry
enabling other programs to find the ActiveX server DLL by searching on
its name.

I'm curious as to (broadly) which class of DLLs would fall into that camp,
and which would just be standalone DLLs with no registry references. It
seems like you're saying if ActiveX is involved many of those DLLs will
often be registered.

 

[Tim Slattery]

Is that true for all the ones that need to be registered (i.e., that those
DLLs are ALL "ActiveX servers")? I guess I need to look up the defn of
ActiveX.

I'd say yes, or COM servers which comes to the same thing.

I'm curious as to (broadly) which class of DLLs would fall into that camp,
and which would just be standalone DLLs with no registry references. It
seems like you're saying if ActiveX is involved many of those DLLs will
often be registered.

I write web systems for a living. Any DLL that's invoked from an ASP
page is an ActiveX (or COM) server. You give ASP its name, that's
looked up in the registry, and the system knows where it lives and can
then find what functions are within it, what arguments they expect,
and what kind of value they return. VB programs tend to use this kind
of thing a lot.

When you write a Windows C++ program, you always include windows.h.
That describes entries in many DLLs that are not COM servers. They do
things like create windows or menus, allocate or release space, paint
the screen ... all the zillions of things a Windows program needs to
do. These DLLs are in \WinNT\System32 (or someplace like that), where
the OS will find them with a normal search. With this kind of library,
the OS can find a list of function names, but no other information
about them. The program has to know the calling sequence. That's what
the windows.h entries do.

 

[Bill in Co.]

I'd say yes, or COM servers which comes to the same thing.


I write web systems for a living. Any DLL that's invoked from an ASP
page is an ActiveX (or COM) server. You give ASP its name, that's
looked up in the registry, and the system knows where it lives and can
then find what functions are within it, what arguments they expect,
and what kind of value they return. VB programs tend to use this kind
of thing a lot.

When you write a Windows C++ program, you always include windows.h.
That describes entries in many DLLs that are not COM servers. They do
things like create windows or menus, allocate or release space, paint
the screen ... all the zillions of things a Windows program needs to
do. These DLLs are in \WinNT\System32 (or someplace like that), where
the OS will find them with a normal search. With this kind of library,
the OS can find a list of function names, but no other information
about them. The program has to know the calling sequence. That's what
the windows.h entries do.

Thanks for the explanation, Tim - most fascinating. I'm still trying to
understand it, as follows.

The last paragraph makes sense to me, as I've done some programming before,
but it's always been more "local" (i.e., for the PC it is running on, or
"client based", I guess you would call it), and not for an ASP web page, or
anything like that).

So I guess I don't understand the reason for the different DLL methodology
used in the ASP thing very well, unless it would be near impossible (or too
restricted) for an ASP page server host to simply store all the DLLs in one
convenient stable location (just like they would on a PC), and use the same
techniques. Is that it? (I don't have any experience with "server-based
scripting", or writing ASP web pages, or anything like that, so that's
probably why I don't understand it).

 

[Tim Slattery]

So I guess I don't understand the reason for the different DLL methodology
used in the ASP thing very well, unless it would be near impossible (or too
restricted) for an ASP page server host to simply store all the DLLs in one
convenient stable location (just like they would on a PC), and use the same
techniques. Is that it? (I don't have any experience with "server-based
scripting", or writing ASP web pages, or anything like that, so that's
probably why I don't understand it).

Let's see.....DLLs were first developed with the C (C++ wasn't around
yet) methods I talked about. There are two ways to get your program to
access a library like that: static and dynamic. The first means
supplying the linker with the name of your DLL, so that it's in the
*.exe file and is loaded when the *.exe file is. The second means that
you call a system API function in your program and pass it the name of
the DLL. In either case, you supply only the name of the library, not
a path to it. The OS searches for it in the normal places: current
directory, directory where the EXE lives, \windows, \windows\system,
directories in the PATH environment variable, I forget the exact spec.
Once the library is found, the program has to know the names (or
numbers) of the functions in it, the parameters expected by each, and
the values that will be returned. As I said before, the core windows
libraries (user32.dll, system32.dll, kernel32.dll) work this way and
have since at least Windows 3.0, when they didn't have the "32"
suffix.

ActiveX/Com servers let the calling program find out a lot of this
stuff for itself. The caller calls an API specifying the name of the
server DLL. That's looked up in the registry, which yields the
library's location. It doesn't have to be along the search hierarchy
that I gave in the previous paragraph, the registry entry will point
to it wherever it is. There are a couple of functions that each COM or
ActiveX server must have, the caller will invoke those to get names,
arguments, and return values for all included functions. ASP pages are
written in VBScript (sometimes Javascript, but usually VBScript). This
kind of self-documentation makes it easier for a lightweight,
dynamically interpreted language to use libraries.

 

[Bill in Co.]

Let's see.....DLLs were first developed with the C (C++ wasn't around
yet) methods I talked about. There are two ways to get your program to
access a library like that: static and dynamic. The first means
supplying the linker with the name of your DLL, so that it's in the
*.exe file and is loaded when the *.exe file is. The second means that
you call a system API function in your program and pass it the name of
the DLL. In either case, you supply only the name of the library, not
a path to it. The OS searches for it in the normal places: current
directory, directory where the EXE lives, \windows, \windows\system,
directories in the PATH environment variable, I forget the exact spec.
Once the library is found, the program has to know the names (or
numbers) of the functions in it, the parameters expected by each, and
the values that will be returned. As I said before, the core windows
libraries (user32.dll, system32.dll, kernel32.dll) work this way and
have since at least Windows 3.0, when they didn't have the "32"
suffix.

ActiveX/Com servers let the calling program find out a lot of this
stuff for itself. The caller calls an API specifying the name of the
server DLL. That's looked up in the registry, which yields the
library's location. It doesn't have to be along the search hierarchy
that I gave in the previous paragraph, the registry entry will point
to it wherever it is. There are a couple of functions that each COM or
ActiveX server must have, the caller will invoke those to get names,
arguments, and return values for all included functions. ASP pages are
written in VBScript (sometimes Javascript, but usually VBScript). This
kind of self-documentation makes it easier for a lightweight,
dynamically interpreted language to use libraries.

Thanks Tim. And I'm still digesting this.

I guess the main advantage of the dynamic method then is that only when some
special DLL functions are needed is that relevant DLL code loaded, vs with
the static method, all the DLL code is always loaded, whether it is needed
or not.
I suppose the static method would generally utilize way too much memory and
resources to be very efficient or even practical, in many instances.