Thread: 32 bit versus 64 bit dll paradox

I have compiled simple visual basic C++ form application that works on the machine that compiled it in visual c++ 2012 express. However, upon transferring the application exe to a different machine, it says that a certain dll is missing, that is, the MS visual c++ 2012 dll called "msvcr110.dll". Bear in mind I DONT want to download this onto the NEW machine from microsoft but rather package this dll as part of the installation file of the application. The reason for this is I don't want the end user to run a separate MS run-time 2012 installations. I also wouldn't like to statically link anything beforehand.

First I made sure it was compiled as a release and not a debug exe and it was. So then what I did is found "msvcr110.dll" on the compiled machines system 32 windows folder (as MS visual C++ did a run time installation on this host machine already and hence why it runs okay). I took this dll and copied it to either the new machines system 32 folder and/or the new machines e same folder that the application runs in. Upon doing so, I was prompted with the error: "The application was unable to start correctly (0xc000007b)". After researching this it seems the culprit is most likely a 32 (x86) to 64 bit compatibility issue.

I ran the tool dependancy walker (Dependency Walker (depends.exe) Home Page) on the original machine and nothing came up ofcoarse as it obviously runs fine there. On running dependancy walker on the new machine I see that the msvcr110.dll has "64" written next to it which was flagged as red.

Questions: 1) I think this is the problem and don't know how to resolve it. Im assuming I just download the run time VC++2012 and package that as part of the installation folder? But this has technically been done as I already have the dll on the compiled machine as VC++ has already been installed there and thats the dll I sopied across. 2) Further I don't know WHY it is a problem in the first place. Both machines have 64 bit CPU's. Both machines run windows 64 bit. The MS Visual C++ that installed and hence ran the run time installation could have been EITHER 32 or 64 bit because a 32 bit can run on 64, and, anyway, the same dll ran fine on the host machine and not on the new machine.

Originally Posted by brewbuck

This is why Microsoft requires you to use the runtime redistributable package to install the runtime... I have no idea what you did wrong, but you can't just dig around in system32 and expect to get the right stuff. Remember that Windows automagically redirects file accesses between system32 and syswow64 depending on the accessing process's bitness.

Brewbuck, suppose I want to take this .exe of mine and sell it to a client. It would look ridiculous for the installation package to run a MS express run time first and then the actual program itself. I know not of one professional proprietary software that does this. UNLESS during installation the MS express run time doesnt actually show up as installing and runs in the background.

How do I go about distributing this without the client doing seperate run time installation?

Originally Posted by brewbuck

You install the runtime on the user's system using the "vcredist" installer. Google it.

Yes, it's a separate installer, but the user doesn't notice it. It is automated.

If this is indeed the case, that would be great.

Is it possible to explain to me how I do this? i.e. how can I make an installation file so that the user doesn't notice the run time being installed seperately?

Originally Posted by brewbuck

It's been a while since I did it. I'm not sure if VS Express can do it, actually. But with a pro version of VS, you just create an installer project and one of the settings you can configure is to have the installer automatically install the runtime. Like I said, it's been a while... But I remember it being easy to do.

Any other takers on this one?

Originally Posted by freddie

I'll take. Couldn't you just go into Project Properties for your project and specify that you want to create a stand alone exe rather than one requiring the runtime? Or have you already done that? Personally, I never create any executables that aren't stand alone programs. Have never had any trouble with that.

Just checked on my VS 2008 Pro and its under C/C++ >>>> Code Generation

Hi Freddie,

By standalone you mean statically linked correct?

Yep, I tried that and followed exact instructions from a proffesional:
Under the folder you mentioned C/C++ code generation, runtime library I selected from Multi Threaded Debig DLL to Multithreaded (i.e. without the dll bit)
I then get an error message:

Error 1 error D8016: '/clr' and '/MT' command-line options are incompatible C:\...\Visual Studio 2012\Projects\Project15\Project14\cl Project14

So I then under C++ general I select from common language runtime support(CLI) to no common language runtime support but then the whole project gets bombed with errors on practically every single line.

Im doing something wrong.

Well then, is this project of yours set up as a CLR project, or a Win32 project? This language here is extremely confusing, its kind of like saying "I have a black thing that is white" ...

I have compiled simple visual basic C++ form application that works on the machine that compiled it in visual c++ 2012 express.

There is no such a thing as a Visual Basic C++ form application, same way as there isn't anything black that is white! Visual Basic and C++ are two completely different languages. Might I politely suggest that you'll get better answers to your questions if you use correct terminology?

Personally, I don't do any coding against the CLR, so if you are doing that I can't help you. From my limited understanding of it though, I'll say this ...

Using the CLR you will inevitably need to provide to others who use your executable the required dependencies. That is one reason I don't use it. The beuaty of a Win32/64 application - statically linked, is that you can provide your users just the executable, and it will work - provided you haven't created any other external dependencies.