[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now


DLL compiled in XP works in Win2000 but not in WinXP

Posted on 2007-10-17
Medium Priority
Last Modified: 2013-12-04

We have a DLL that is developed as a customization to a software we use and is supposed to be loaded when you logon to the software.

The library is written in C and compiled using MS VC++.  Even though all the compilation and linking is done in Windows XP the library is loaded successfully in Windows 2000 clients but fails to load in Windows XP clients. The software's log file contains errors such as "The specified module could not be found" (even though the path it shows is correct), "Invalid library" and "Could not load the Custom Library <TAI_custom_handlers> and/or Function Ptr <TAI_custom_handlers_register_callbacks>".  The libraries that succesfully load are registered in the log file as "Successfully loaded the Entry Point Function Ptr <custom_TAI_register_callbacks> for Custom Library <custom_TAI>"

Considering there might be an OS library difference I ran depends.exe on the same DLL, on both W2000 and XP. The only difference seemed to be where the library MSVCR80.DLL was read from.

Windows 2000 uses
Windows XP uses

Any ideas why XP would reject our library (event though all the work is done on XP) while W2000 accepts it?


Question by:TAI-
LVL 86

Expert Comment

ID: 20092961
I'd suggest to check the whole thing using the DependencyWalker (www.dependencywalker.com). Verify two things:

- are any DLLLs reported as "missing" when you openend your module with the app?

- what errors are reported when you use "Profile" with an app that uses your DLL?
LVL 29

Expert Comment

ID: 20094779
Go to menu Project -- Properties (Alt+F7) -- Configuration Properties -- C/C++ -- Code Generation and change the Runtime library setting from "Multi-threaded Debug DLL (/MDd)" to "Multi-threaded Debug (/MTd)" for the Debug configuration. Then do similar actions for Release configuration, i.e. "Multi-threaded DLL (/MD)" replace by "Multi-threaded (/MT)".

After that, your dll should not be dependent on msvcr80.dll.
LVL 29

Accepted Solution

pepr earned 1500 total points
ID: 20094835
You can find the explanation also on "C Run-Time Libraries" http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx

The MSVCR80.DLL resp. MSVCR80D.DLL libraries are imported via msvcrt.lib resp. msvcrtd.lib. The *80*.dll came with Visual Studio 2005 (also known as Visual Studio version 8). They are not distributed with Windows XP.

The alternative is to keep linking DLL and distribute the MSVCR80.DLL resp. MSVCR80D.DLL with your application.
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

LVL 29

Expert Comment

ID: 20094851
It is likely that the MSVCR80.DLL and MSVCR80D.DLL were installed into your Windows 2000 with some other application or with some service pack.
LVL 86

Expert Comment

ID: 20094873
>>change the Runtime library setting from "Multi-threaded Debug DLL (/MDd)" to
>> "Multi-threaded Debug (/MTd)"

I'd like to add that this is not a good idea, since it will statically link the CRT, which defeats the purpose of using DLLs in the first place. As an additional impact, this introduces an additional allocator for the app and therefore another heap, which may cause cross-module allocations to leave memory leaks.
LVL 29

Expert Comment

ID: 20095353
It depends on purpose and on the intention. It may be easier to distribute a single dll instead of distributing of two dll's. The truth is that linking statically the runtime to DLL may be strange. It makes more sense to use static linking when building .exe.

It is also a question if your dll should use functions implemented in CRT.
LVL 39

Expert Comment

ID: 20099601
>>>> Even though all the compilation and linking is done in
>>>> Windows XP the library is loaded successfully in Windows 2000
>>>> clients but fails to load in Windows XP clients.

We experienced similar things regarding XP and NT4 clients. There were a few main reasons we found out:

1. Some common controls were installed and registered at NT4 but not on XP. In our case it was a 'date picker' control, but we had things to do for nearly any custum control e.g. flexgrid, e. g. license issues or version issues.

2. Normally user's at a XP have lesser rights often controled by system policies. If using controls or components that need access to system part of the registry (HKEY_LOCAL_MACHINE), such access may work a W2K but not at XP. Also, updating ini files located in system or windows folder may work at older OS (and for a developer) but not for a XP user.

3. If developing on XP you might have a .manifest file for your application. .manifest files are a means to have specific registry setting for an executable but do not need to register them in the local registry. That is a good thing but may rise compatibility issues when installing at XP clients and Win2K clients. Assume you are installing without .manifest files your XP installation may fail for this reasons if for example the equivalent registry information was not available at all XP clients. If installing with .manifest it could work on Win2k cause it ignores .manifest files while it fails on XP clients cause the .manifest refers to items which were not available at the target system.

Regards, Alex

Author Comment

ID: 20128820
It seems compiling and linking with MS VC 8 is causing an incompatibility with the software we are customizing. It only supports MS VC 7.

Thanks for the suggestions everyone.
LVL 29

Expert Comment

ID: 20128923
TAI: "It seems compiling and linking with MS VC 8 is causing an incompatibility with the software we are customizing. It only supports MS VC 7."

It is difficult to say the reason. The truth is that it is usual to compile the libraries using the same version of the compiler (if you have sources). On the other hand, the skip from VC 6 to VC 7 was bigger than from VC 7 to VC 8. The VC 7 compiler comes with Visual Studio 2003 and it is likely that a lot of Microsoft applications were compiled with that compiler -- the dll's were distributed with many "standard" applications, like Internet Explorer. It may be the reason why it seems that your application compiled with VC 7 runs everywhere and application compiled with VC 8 has some problems.

I do not know your DLL, but you could try to minimize dependency of your DLL on libraries. Try tomenu Project -- Properties (Alt+F7) -- Configuration Properties -- Linker -- Input  and set the "Ignore All Default Libraries" to Yes. Then compile and follow the errors to learn what function implementations were not found, what libraries do implement them and if you really need them.

Learning the hard way is hard but you will learn more after a while. Solving the problem the easy way (i.e. fast) satisfy customers. The compromise is the answer. Keep ballance ;)

P.S. And try to split the points next time, please. jkr and itsmeandnobodyelse also gave you usefull hints.

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Have you thought about creating an iPhone application (app), but didn't even know where to get started? Here's how: ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Important pre-programming comments: I’ve never tri…
This is a short and sweet, but (hopefully) to the point article. There seems to be some fundamental misunderstanding about the function prototype for the "main" function in C and C++, more specifically what type this function should return. I see so…
Video by: Grant
The goal of this video is to provide viewers with basic examples to understand and use nested-loops in the C programming language.
The goal of this video is to provide viewers with basic examples to understand and use switch statements in the C programming language.

872 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question