Hi,
I want to compile a user exit that was developed using vc++ 6.0 with vc++ express edition. The compile works fine, but the application crashes. My 'trial and error' experiments with linker options, especially with manifest files, resulted in much confusion...
The app itself is written (not by me) using vc++ 6.0. The user exit (written by me) is a simple win32-dll where some math is done (no MFC at all, simple standard c++ code). The error message is "an application has made an attempt to load the c runtime library incorrectly" if i do not embed the manifest. If I embed the manifest, the app says that it can't find the dll (but this must be a default message, because the path is the same as before...)
Since I have no influence on how the app calls my dll, I need a dll that behaves as if it has been compiled using vc++ 6.0. Is this possible
I'm familiar with c++, but not with vc++, therefore I have no idea how to tackle this problem. Since I'm probably not the first one facing such problems, maybe there's some documentation dealing with this topic Or any helpful suggestions
Thanks in advance!
porting vc++ 6.0 user exit to vc++ express edition
Mido#
First, I copied the msvcr80.dll manually. The dependency walker than gives the error message 'the side-by-side configuration information in <my dll> containes errors. (14001)" on the target machine, but no errors on the development machine. All dll's were found, I've checked the version number.
After installing the redistributable for the vc++ runtime, the dependency walker does not give any errors. Nevertheless, the application still can not call the dll.
The only difference that I've found using dependency walker is that some functions in msvcr80.dll on the development machine begin with std:: whereas they begin with 0 on the target machine.
What does this mean
Thanks a lot
Detlef
the beginner
Good calls those.
The C++ runtime not loading though is just a red herring. The only reason it was happening was because you didn't embed the manifest. If the manifest is embedded then it should be working fine.
LProgrammer
Name decoration might be your problem here, I'd expect the app to try to find an export in the DLL with a specific name. If you have a DLL compiled with VC6 that works, you can use the DumpBin tool to see the decorated names. Run "Visual Studio Command Prompt". Type bin\dumpbin pathtothedll /exports | more. Do this both on the VC6 DLL and your DLL and compare the names. If you're getting mismatches, play with declspec(dllexport), extern "C", stdcall, etc.
Sean Hederman
Umm, are you talking about a "user exe" rather than a "user exit"
I think you need to give some more specific info.
What exactly is the crash error you are getting
What is the exact error when it can't find the DLL
By the way, you definitely need to embed the manifest.
Jonty303
He said 'win32-dll' so I suspect he means 'user extension'.
Since it's failing to load the DLL I would guess that you're not using the DLL on your development machine and that you don't have the VC++ runtime installed correctly in WinSxS on the other machine. In VS2005 Pro you can find a redistributable for the VC++ runtime under the Microsoft Visual Studio 8 directory in SDK\v2.0\BootStrapper\Packages - try running this on the end machine. (You may need to upgrade to Windows Installer v3.1 first if you haven't already - or that might just be for the merge-modules version of the runtime, I can't remember.) Alternatively you can try copying the runtime DLLs into the same directory as your new DLL - that (IIRC) ignores any problems with the manifest.
If you're still having problems a good way to diagnose DLL load problems is to use Dependency Walker (in the tools with VC++ or the platform SDK, or from www.dependencywalker.com) to see if you're missing any dependencies or try running regsvr32 on the DLL to get the error message from LoadLibrary() - you can use this to try loading a DLL even if it isn't a COM DLL! However IIRC it isn't easy to see SxS manifest problems in Dependency Walker, or wasn't in the last version I tried.
[edit] I meant to add -
http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=398802&SiteID=1
[edit2] Oops, I've remembered it's the single-threaded statically-linked runtime they've done away with and not static-linking entirely.