HiI want to build my solution with VS 2013 64 bits, do I have to rebuild the latest version in 64 its or I can use the 32 ???thanks
What matters is the target. If you have a project for Platform Win32, all referenced libraries must be compiled for Win32 and if you have a project for Platform x64, all referenced libraries must be compiled for x64 (and with compatible compiler settings; visual studio has several project options that when changed make the libraries incompatible). Particular variant of VS 2013 does not matter.
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.
I'm trying to compile a program as 64 bits, it works perfectly with a simple console program but if I use my directX program it says me: error LNK1181: cannot open input file 'd3dx9.lib'. When I compile my directX program as 32 bits it works but in x64 it doesn't. I think visual studio 2013 has a default directory of directx with is x86 but I don't know if I'm right or not. I need to use x64 directX libs. How could I link them? Thanks for read.
VS 2013 comes with the Windows 8.1 SDK, and as of the Windows 8.0 SDK the DirectX SDK is considered deprecated. All versions of D3DX (D3DX9, D3DX10, and D3DX11) are also deprecated and are only available with the legacy DirectX SDK. You can use the legacy DirectX SDK in combination with the Windows 8.x SDK, but it requires the reverse path setup of VS 2010 or earlier. See MSDN and this blog post.
In your case, you probably don't have your project's VC++ Directories properties set up correctly for the x64 configurations:
Executable path:
Win32 configs: $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x86
x64 configs: $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x64;$(DXSDK_DIR)Utilities\bin\x86
Include path
Both configs: $(IncludePath);$(DXSDK_DIR)Include
Library path
Win32 configs: $(LibraryPath);$(DXSDK_DIR)Lib\x86
x64 configs: $(LibraryPath);$(DXSDK_DIR)Lib\x64
Note: If you were using the v120_xp Platform Toolset for Windows XP support, you'd actually be using the Windows 7.1A SDK, and would go with the same path order as VS 2010 which is the reverse of the ones shown here--i.e. the DirectX SDK paths would go first, then the standard paths. See this post if you are trying to target Windows XP.
This all said, unless you are specifically targeting Windows XP the recommendation is to (a) use Direct3D 11 instead of legacy Direct3D 9, (b) avoid using the legacy DirectX SDK at all, and (c) avoid using D3DX9/D3DX10/D3DX11.
See also:
Living without D3DX
DirectX SDK Tools Catalog
DirectX SDK Samples Catalog
DirectX SDKs of a certain age
let's say that DLL A as the CRT 8.0.50727.762 as dependency. This DLL is used in a exe project that is linked dynamically (/MD) with "Use Of MFC" = "Use Standard Windows Libraries".
Both the DLL and the project using the DLL are using VS 2005, yet the project building machine has a newer CRT. So the exe itself has a dependency to 8.0.50727.6195 in its manifest.
Now I have two question:
Is my understanding correct that the CRT versions are backwards compatible?
So when I deploy the project and add the CRT assemblies version 8.0.50727.6195 to the exe's working directory it should work on any client no matter what is in his WinSXS cache right?
No. CRT or MFC is not backward compatible. You must install appropriate Visual C++ Runtime on client's machine, ensuring that:
The version should match (VC7, VC8,.. VC14 etc.)
The bit-ness should match. If your application is 32-bit, you need 32-bit redistributable, and same for x64.
The service pack version must also match!
It should be noted that all of them can co-exist! VC10 RTM, VC10 SP2, VC10 x64 RTM.. all can co-exist.
I am converting some 32-bit .Net apps to x64. Enterprise Library 5 (32-bit) is used in a bunch of our apps, so I am under the impression that when we re-compile those in x64, then we will need to pull in a x64 version of EntLib. Does anyone know if that exists? I keep searching and I can't seem to find a straight answer - I find burbs about x64 configuration manager tool, but no info about a installable 64-bit version of EntLib5.
The entlib assemblies are architecture neutral. They can be loaded by either 32 or 64 bit processes with no changes.
On a 32-bit process, they'll run as 32-bit. On a 64-bit process, they'll run as 64 bits. No changes needed.
Remember, they're IL, not native code, and don't call into anything native, so there's no bitness dependencies.
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.