Using Visual Studio, I have built an C++ application running in 32bit. It will be deployed both to 32-bit and 64-bit Windows servers. It won't be run in 64-bit mode (but rather under WoW).
Should I include both the 32-bit and 64-bit Visual C++ redistributable, and install 32bit on 32bit Windows and 64bit on 64 bit Windows, or is it enough to just install the 32bit redistributable?
It is enough to install the 32bit redistributable.
EDIT: I commented below on a misleading answer, but the answer is you only need the 32-bit redistributables, as Karel Petranek answered first.
This is not an answer. It should only be a comment, but since I don't have the required reputation for that...:
I just wanted to warn people against Ruel's provided information. No, the 64-bit Visual C++ redistributable packages don't also include the 32-bit DLLs.
I have even tested that (his) theory. I tried to run an application that requires Visual C++ 2010 32-bit redistributables and it prompted me that it needs that. I then installed the 64-bit one, and it still prompted it needed the 32 bit version of Visual C++ 2010. After installing the 32 bit one, it worked.
Why people come up with theories and provide them as answers beats me. Or maybe he was also "encouraged" by the reputation system to give not only superfluous, but also false information. Or maybe he just confused C++ with DirectX 9 redistributables (that one does install both 32-bit and 64-bit DLLs).
Both are Microsoft products, but don't let that fool you.
Your C++ application creates a 32 bits EXE, linking to 32 bits DLLs. As it happens, one or two of those DLLs are Microsoft CRT DLLs, but the OS still uses the same rules. Therefore, you don't need the 64 bits DLLs.
Compile it using /MT option and VC++ runtime library will be compiled into your exe, so you don't have to worry about distributing it.
Project > Properties > Configuration Properties > C/C++ > Code Generation > Runtime Library > Multi-threaded (/MT).
The 64-bit Visual C++ redistributable package includes both 32-bit Visual C++ redistributable and 64-bit Visual C++ redistributable.
Related
Any set of guidelines or pointers to compile and run existing applications that use Java 32 bit version for linking native code in C++ and Java, as from Java9(JDK9) only 64 bit versions of java will be available.
Any ways to migrate JNI layer(32 bit) and C++ code to 64 bit architecture.
Note: Using Visual Studio 2012 IDE for C++ code compile and execution.
Did update the configuration parameters(Linker properties, VC++ directories, C/C++ properties), in VC++ to point to 64bit JDK version. This did get compile but while debugging giving access violation errors on access to built-in C++ methods.
Recently i upgraded my visual studio 2008 installer project to InstallShield Limited Edition project into Visual Studio 2013. I was able to build the solution from visual studio and from my Nant build script. My solution build platform is x86/Release and my installshield limited edition project build platform is singleimage without specifying any platform. My computer is Win32 and i installed installshield limited edition for 32 bit.
Now i added one merge module in the InstallShield Limited Edition project which can be run in both Win32 and Win64. The signature of the merge module specifies that it can be executed in both Win32 and Win64.
But as long as i added the merge module and built the solution, i got the following error
ISEXP : error : -5008: This 32-bit package cannot include 64-bit data. The 64-bit data may come from a merge module.
My merge module is developed by other party and they said it should be worked in both Win32 and Win64.
When working with Windows Installer, you have to choose between making a 32-bit or a 64-bit package. The 32-bit package can install on a 64-bit system but can only access 32-bit locations; the 64-bit package cannot install on a 32-bit system, but can access 64-bit locations on a 64-bit system.
The error you quote is to avoid letting a merge module change your whole package from 32-bit to 64-bit, as that can cause you compatibility problems that are difficult to diagnose. If you want to use that merge module as is, you must do something in your project to indicate you want a 64-bit package, such as adding a file or registry key that installs to a 64-bit location. Alternately, if you need to support 32-bit systems, you should request the other party properly separate their 32-bit and 64-bit merge modules.
I built a C++ based COM object using Visual Studio 2012. It registers and works fine on 64-bit machines (called by 32-bit code and calling a 32-bit out-of-process COM server) but does not register on 32-bit machines (neither XP nor Win7 32-bit). The message from regsvr32 is
LoadLibrary("comobj.dll") failed - The specified procedure could not be found.
The project was originally built with Visual Studio 6 (7 years ago). It uses ATL macros such as BEGIN_COM_MAP and BEGIN_SINK_MAP to declare its implementation of various interfaces. It had to be re-compiled because the COM server it was invoking changed (new ProgID, new GUID, new type library, etc). Other than making those adjustments, and using current VS, there were no (intentional) changes -- there certainly was nothing in the old equivalent of the project file that would have pointed to 64-bitness.
Examining the DLL with the 64-bit version of DEPENDS.EXE shows "64" icons next to the standard referenced DLLs like KERNEL32 and USER32. Other than having built the DLL on a 64-bit machine, there is nothing "64-bit" about the DLL that I can find. The target is explicitly Win32 (not X64).
Examining the DLL with the 32-bit version of DEPENDS.EXE (on Windows XP running under Virtual PC) shows KERNEL32.DLL with a red icon, apparently because there are references to FlsAlloc FlsFree FlsGetValue FlsSetValue that do not exist in the 32-bit KERNEL32.DLL. (I have no idea what those are and don't know where those references come from -- perhaps from the copy of MFC on the 64-bit machine where the compile was done?)
Could it be that I have to install VS2012 on XP and re-compile there? How could that really be what needs to be done to build a Win32 COM object in C++ using current Visual Studio?
Does anyone know where I might look? I've checked all the project and solution options and nothing seems set to 64-bit. The option under "Use of MFC" is set to "Use Standard Windows Libraries" -- that's probably the answer but if that's not portable to 32-bit Windows it's hardly using only "standard libraries". (I will be trying changes to that after sending this.)
Thanks in advance for any advice.
Default toolset coming with Visual Studio 2012 produces output incompatible with Windows XP, through using certain APIs introduced only later with Vista.
In order to both utilize the power and feature richness of the latest Microsoft C++ compiler, and be still compatible with Windows XP, you need to use an alternate toolset codename "v110_xp" introduced with Visual Studio 2012 Update 1. At the moment the latest update available is Visual Studio Update 3, and you might want to simply install latest available updates for Visual Studio.
You have the setting available under Project Settings:
See more here: Configuring C++ 11 Programs for Windows XP.
I have an old VC++ 6 code compiled as DLL, I used it for many years without problems, now i need it in a x64 application, can i recompile the old code to produce a X64 DLL?
Am I need the same VC++ 6 IDE or another compiler?
Unfortunately, the answer to both of your questions is: maybe.
I have had good luck taking VC++ source code for old 32-bit DLLs and recompiling it for 64-bit. Sometimes it is a simple recompile. Other times, minor adjustments have to be made. My biggest concern would be if the 32-bit DLL relies on other 32-bit DLLs that you may not have source code for. In that case, unless you have 64-bit copies of the other DLLs, you are probably out of luck.
Now, I have never tried to do this with VC++ 6. I've done it with Visual Studio 2010. However, the windows platform SDK used to support compiling for 64-bit with VC6. My understanding is that the last version of the SDK that supported this was the February 2003 version. I just checked MSDN and I do not see this available for download. That doesn't mean you cannot get a copy (and you may already have one). It does mean that getting a copy won't be as easy as going to MSDN and downloading it.
Now, having said that, my recommendation is to use a newer compiler to make your 64-bit DLL. Assuming Windows, all recent Visual Studio compilers (2008, 2010, 2012) will do 64-bit, provided you've installed the 64-bit tools.
Is the package type (x86 or x64) dependent on my application type or on the OS type it is installed on?
I.e., if I develop a 32-bit application do I need to
deploy the x86 package only or
deploy both packages and install x86 on 32-bit windows and x64 on 64-bit windows?
The answer to this question 32-bit VC++ redistributable on 64 bit OS? suggests that it's only the x86 package, so it would be dependent on my application but it doesn't give any explanation/links.
The MS download sites are also not specific on this.
When you compile, all use of the standard library creates references that must be resolved at link time. The linker bakes in the import library for the matching runtime DLL(s), which must be matched completely at load time. That means matching the compiler version, service pack, and bitness.
Also remember that a 32-bit process cannot load 64-bit DLLs. Because the 64-bit redist only contains 64-bit DLLs, it is of no help when loading a 32-bit executable.
it depends on the application if you need to maximize the potential of 64-bit OS, you may deploy both for handling 64-bit and 32-bit processing. However, if your application did not exceed the limits of 32-bit, you may deploy the application on x86 only, anyway it should also work on 64-bit OS via 32-bit virtualization.