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.




"Silvia" <Silvia@discussions.microsoft.com> wrote in message
news:47EB9B2D-EE8D-4AB1-BDAE-F47F3CF15350@microsoft.com...
> 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

[pa bear [ms mvp]]

What DLL file? Do you get an error message saying that name.dll is missing
or cannot be found?
--
~Robear Dyer (PA Bear)
MS MVP-IE, Mail, Security, Windows Client - since 2002

Silvia wrote:
> 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

[jim]

On Sat, 30 May 2009 19:49:01 -0700, Silvia
<Silvia@discussions.microsoft.com> wrote:

>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 ?

[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?Ǭ

[pa bear [ms mvp]]

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

Silvia wrote:
> 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?Ǭ

[tim slattery]

Silvia <Silvia@discussions.microsoft.com> wrote:

>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

[bill in co.]

Tim Slattery wrote:
> Silvia <Silvia@discussions.microsoft.com> wrote:
>
>> 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

[tim slattery]

"Bill in Co." <not_really_here@earthlink.net> wrote:

>Tim Slattery wrote:
>> Silvia <Silvia@discussions.microsoft.com> wrote:
>>
>>> 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

[bill in co.]

Tim Slattery wrote:
> "Bill in Co." <not_really_here@earthlink.net> wrote:
>
>> Tim Slattery wrote:
>>> Silvia <Silvia@discussions.microsoft.com> wrote:
>>>
>>>> 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

[tim slattery]

"Bill in Co." <not_really_here@earthlink.net> wrote:


>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.

--
Tim Slattery
MS MVP(Shell/User)
Slattery_T@bls.gov
http://members.cox.net/slatteryt

[bill in co.]

Tim Slattery wrote:
> "Bill in Co." <not_really_here@earthlink.net> wrote:
>
>
>> 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.

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.