Installing / Registering MS DLLs on WinXP

Stan_Greene
Stan_Greene used Ask the Experts™
on
Our application requires that MS DLLS be present on WinXP. These are ATL71, GDIPLUS, MSVCP71 and MSVCR71. We have been advised that installing WinXP SP3 will install and register these DLLs. That has not been the case in many isntances.

We have copies of these DLLs. So we tried to register them using REGSVR32.EXE. They ALL failed with the message: "REGSVR32.exe was not able to find the required entrypointin the module specified in the command line. This can occur if the entrypoints are not properly exported from the module or if the module is not a .DLL or .OCX file."

These are valid MS DLLs which were copied from the PCs that did install them using SP3.

Q1. Why did SP3 not istall them on all PCs
Q2. Why can I not register them.

Thanks for any help. Stan
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Lee OsborneSenior Infrastructure Engineer

Commented:
Have you tried unregistering them before re-registering?

Lee
Quid, Me Anxius Sum?  Illegitimi non carborundum.
Commented:
gdiplus.dll does not require registering.  Place it in the same folder as your application.

The other files also may not require registering as well.

Author

Commented:
Thanks for the feedback. However trying to UNregister with /u parameter  I get quote: "msvcr71.dll was loaded but DllUnregisterServer entry point was not found. This file cannot be registered. " unquote. If I try to register now I get same messge but with DllRegisterServer instead.

This is on WinXP SP3.
dbruntonQuid, Me Anxius Sum?  Illegitimi non carborundum.

Commented:
Use a hex editor on the file concerned and see if you can see either DLLRegister or DLLUnregister.

If they aren't there you can't register or unregister the DLL concerned.

See graphic below for an example where these entry points are in the file.
DLLRegister.jpg

Author

Commented:
What gets me is that these DLLs come from MS themselves. Why would they prevent their registration (Unregistration)?
It woulld appear that neither DLLRegister or DLLUnregister are present. I doubt that one can add the entries nor would I feel right about doing it.
Perhaps reinstallationn of WinXP SP3 may get them installed properly.
Did SP3 come out in different versions?
dbruntonQuid, Me Anxius Sum?  Illegitimi non carborundum.
Commented:
Some DLLs are designed NOT to be registered.

You can try inserting the files concerned in the application's folder which should work.  Windows is supposed to look there first I understand before going elsewhere.

Author

Commented:
Cool. We shall try putting the dlls to the app runtiem folder BUT ...Normally I have been copying them to SYSTEM32 folder rather than the app folder.

We runs a Sybase generated MSI which installs and copies Sybase DLLs. The MSI fails when the MS dlls are not present AND registered. Just copying them to SYSTEM32 folder  doews not make them recognisable by the Sybase MSI.  
dbruntonQuid, Me Anxius Sum?  Illegitimi non carborundum.

Commented:
If they don't work in the application folder then try the SYSTEM32 folder.

The idea of using the application folder is to avoid DLL hell with applications installing different versions of the same DLL over each other.

Looking at my own system - Windows 2000 - it has 7 gdiplus DLLS in it (application folders) plus one in the SYSTEM32 folder.  There are at least 2 different versions of gdiplus amongst those.

Author

Commented:
Hi dbrunton
Yes it is a bloatware situation. I shall try that however I should also add the app path to the system environments otherwise the MSI will not see these DLLs.
Sudeep SharmaTechnical Designer

Commented:
Q1. What application are you trying to run?
Q2. Is Path of your XP configured correctly?
Q3. Did you tryVisual Basic 6.0 Run-time Files/ Microsoft  Visual C++ 2008 Redistributable Package (x86) and Service  Pack 6 for Visual Basic 6.0: Run-Time Redistribution Pack  (vbrun60sp6.exe) and installed them on your system?

http://www.microsoft.com/downloads/details.aspx?FamilyID=BA9D7924-4122-44AF-8AB4-7C039D9BF629&displaylang=en&displaylang=en

Hope that would help

thanks
Sudeep
To whoever has advised you that they are installed with the system, refer them to the article http://support.microsoft.com/kb/326922 that gives specific instructions on how these dll's have to be distributed. They belong to  Visual C++ Runtime library; they are not installed with windows xp (though they were in the past, as the article says), and need to be distributed with the application. They are so called run-time assemblies, rather than COM objects, and registering them in the system involves much more than regsvr32.

Author

Commented:
Guys, Thanks for your help so far. I feel that I am getting close.
I have commented out the 4 DLLs - ATL71, MSVCP71, MSVCR71 and GDIPLUS and applied the full XP SP3 package.
Resulet: MSVCR71 & MSVCP71 wee installed. Great.
I was advised in this topic that GDIPLUS.DLL does not have to be regisrted just copied. OK I'll go with that.
Now for ALTL71.dll. I have found that it comes with Visual Studio.NET. Great but we cannot expect the users to purchase VS.net. As ATL71.dll cannot be registered, I'll try just copying it to SYSTEM32.
BTW: This is all part of installing PowerBuilder runtime dlls. These MS dlls are required otherwise the PowrBuilder dlls will be registed successfully.  PowerBuildr has been redeveloped using C#.
Sudeep SharmaTechnical Designer

Commented:
Microsoft  Visual C++ 2008 Redistributable PackageMicrosoft  Visual C++ 2008 Redistributable Package, or Visual Studio Redistributable package (find the latest on Microsoft website)

Hope that helps

Sudeep

Author

Commented:
Sudeep, Thanks. However
Visual C++ 2008 Redistributable PackageMicrosoft   gives me ALT90.dll
Visual C++ 2005 Redistributable PackageMicrosoft  gives me ATL80.DLL
Visual C++ 6 RunTime Components gives me ATL60.DLL

I could not find what fits between C++ 2005 and C++ 6 to give me ATL71.DLL as an insstall package.
Sudeep SharmaTechnical Designer

Commented:
I think you would need Visual C++ .NET 2003 runtime. Though it is not available on MSDN but closet I could find is below:


Visual C++ .NET 2003 Service Pack 1 C runtime DST 2007 update

http://code.msdn.microsoft.com/KB932298/Release/ProjectReleases.aspx?ReleaseId=762

I hope that would help

Sudeep
I'd like to humbly point out the following lines in the article that I already mentioned, but which is apparently ignored by everyone:

"distribute the CRT DLL with any application that relies on it. Because it is no longer a system component, install it in your applications Program Files directory with other application-specific code. This prevents your application from using other versions of the CRT library that may be installed on the system paths"

It seems to me that this discussion is steered exactly in the direction the article warns against.

Author

Commented:
SSharma - Thanks but that link get me the UPDATE. Execution fails as Visual C++ .NET 2003 is not present.. What I need is Visual C++ .NET 2003 howwever it is no longer vailble from MS/downloads.

vadimrapp1: Yes I agree with you that system32 folder is bloated with umpteen versions. I have taken on board and copied the ATL71.DLL and GDIPLUS.DLL. The MSVCR71 & MSVCP71 wee installed automatically into system32 folder by XP SP3.

Although I have a copy of ATL71.DLL from another PC, however what I  ot clear about is
a) will just copying this dll by our client into the app folder or
b) this dll has to be installed through some process.

I appreciate all the input to my issue. An answer to this last question will I trust fit it.
Most likely, unfortunately, the latter - "this dll has to be installed through some process", which is isolation. However, you can easily try out which dll is being used by the application using filemon or Process Monitor. If it's not used, and the developer refuses to do it properly, try to rename every mylibrary.dll in the application folder into mylibrary.dll.local. See article "DLL/COM Redirection on Windows", at http://msdn.microsoft.com/en-us/library/aa375142%28VS.85%29.aspx for details. Note that what the 2nd paragraph of this article tells, is exactly the "proper" way I'm talking about.

The essence of all this is that the application better use not just any version of the dll's mentioned, but the exact ones it was compiled with. And even if it works today with the dll in common folder, tomorrow the dll in common folder may be changed, and new version will become incompatible with this application. Honestly, this is not very likely, but not impossible; but if it happens, it will be _very_ hard to investigate. That's why the recommendation to isolate these DLL's for use with this particular application. The techniques to do that are well known, the article tells to use them, and there's no reason for the professional developer to ignore it.

Correction - not rename .dll into .dll.local, but place additional empty file dll.local. The article above tells how to do it.

Author

Commented:
vadimrapp1. Interesting article about .local. I shall get the users to implement this.

Everyone many thanks for your input. I have found a source for the DLLs in addition to XP SP3 installing two of them.

Author

Commented:
Found the source for DLLs and regarding their placement. Thanks.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial