Is there a Registry setting that I can look for to determine whether or not the Visual C++ redistributable is installed, whether standalone or as part of Visual Studio 2008? I know that I could launch the VC++ 2008 redistributable installer and let it handle the detection, but it would look cleaner if I can check for it and not bother launching the installer if the redistributable is already on the system.
It's no biggie if there is no setting to search for, as this is just for the preliminary installers that we have for the new version of our software. We won't need it for the new Windows Installer-based installers that we are working on that will replace the old tech ones and will use the merge modules.
I don't think any of those solution can help when your using different OS ! For ex, MsiQueryProductState will always returned -1 using Vista VC8.0
while -1 for VC8.0/8.0 SP1/9.0 with Windows 7 ! So the GUID solution that microsoft provided, doesn't work in all cases
so i guess i'm forced to stuck with the %windir%\winsxs approach and search for
x86_Microsoft.VC80.CRT*
x86_Microsoft.VC90.CRT*
For those who are looking for all GUIDs, Here is a list i created:
Visual C++ 2005 runtime files
* VC 8.0 (x86) - {A49F249F-0C91-497F-86DF-B2585E8E76B7}
* VC 8.0 (x64) - {6E8E85E8-CE4B-4FF5-91F7-04999C9FAE6A}
* VC 8.0 (ia64) - {03ED71EA-F531-4927-AABD-1C31BCE8E187}
Visual C++ 2005 SP1 runtime files
* VC 8.0 SP1 (x86) - {7299052B-02A4-4627-81F2-1818DA5D550D}
* VC 8.0 SP1 (x64) - {071C9B48-7C32-4621-A0AC-3F809523288F}
* VC 8.0 SP1 (ia64) - {0F8FB34E-675E-42ED-850B-29D98C2ECE08}
Visual C++ 2005 SP1 ATL Security Update runtime files
* VC 8.0 SP1 ATL Patch (x86) - {837B34E3-7C30-493C-8F6A-2B0F04E2912C}
* VC 8.0 SP1 ATL Patch (x64) - {6CE5BAE9-D3CA-4B99-891A-1DC6C118A5FC}
* VC 8.0 SP1 ATL Patch (ia64) - {85025851-A784-46D8-950D-05CB3CA43A13}
Visual C++ 2008 runtime files
* VC 9.0 (x86) - {FF66E9F6-83E7-3A3E-AF14-8DE9A809A6A4}
* VC 9.0 (x64) - {350AA351-21FA-3270-8B7A-835434E766AD}
* VC 9.0 (ia64) - {2B547B43-DB50-3139-9EBE-37D419E0F5FA}
Visual C++ 2008 SP1 runtime files
* VC 9.0 SP1 (x86) - {9A25302D-30C0-39D9-BD6F-21E6EC160475}
* VC 9.0 SP1 (x64) - {8220EEFE-38CD-377E-8595-13398D740ACE}
* VC 9.0 SP1 (ia64) - {5827ECE1-AEB0-328E-B813-6FC68622C1F9}
Visual C++ 2008 SP1 ATL Security Update runtime files
* VC 9.0 SP1 ATL (x86) - {1F1C2DFC-2D24-3E06-BCB8-725134ADF989}
* VC 9.0 SP1 ATL (x64) - {4B6C7001-C7D6-3710-913E-5BC23FCE91E6}
* VC 9.0 SP1 ATL (ia64) - {977AD349-C2A8-39DD-9273-285C08987C7B}
Check the registry:
VC++2008 (sp1):
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{3C3D696B-0DB7-3C6D-A356-3DB8CE541918}
or
VC++2008 (original):
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{FF66E9F6-83E7-3A3E-AF14-8DE9A809A6A4}
Latest one for VC2005:
Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update
* VC 8.0 SP1 MFCLOC Patch (x86) - {710F4C1C-CC18-4C49-8CBF-51240C89A1A2}
* VC 8.0 SP1 MFCLOC Patch (x64) - {AD8A2FA1-06E7-4B0D-927D-6E54B3D31028}
* VC 8.0 SP1 MFCLOC Patch (ia64) - {C2F60BDA-462A-4A72-8E4D-CA431A56E9EA}
8.0.50727.6195
http://www.microsoft.com/downloads/details.aspx?familyid=AE2E1A40-7B45-4FE9-A20F-2ED2923ACA62
Quick and dirty:
if (LoadLibrary(L"msvcrt80.dll")!=NULL)
{
// it is installed
}
Loadlibrary will handle searching the paths for you.
looks like there is another solution proposed by a Microsoft-Developer, using MsiQueryProductState API, alas also relying on the GUIDs.
Update: The code went live yesterday and seems to be working fine. Here is what is beeing done: It is checked for the latest-known-to-me GUID AND the path² to-where-it-is-supposed-to-be-installed. If both fails, it is installed. This seems to work fine.
Additionally, it is installed with the command line arguments "/qb" which means "unattended but not invisible". See this other blog post about those params.
FWIW, GUIDs for Microsoft Visual C++ 2008 / VC90 SP1 Redistributable - x86 9.0.30729
64bit 30729.17: 8220EEFE-38CD-377E-8595-13398D740ACE
32bit 30729.17: 9A25302D-30C0-39D9-BD6F-21E6EC160475
32bit 30729.01: 6AFCA4E1-9B78-3640-8F72-A7BF33448200
² The path:
$WINDIR\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729*
Check for $WINDIR\WinSxS\x86_Microsoft.VC90.CRT_* if, for example, you're checking for the Visual Studio 2008 redistributable.
I open-sourced a Visual C++ project on Github that checks for VC++ redistributable DLLs specifically and made it available under the Apache 2.0 license.
It has three different methods for checking for the availability of VC++9 and VC++10 runtimes:
Checks the MsiQueryProductState APIs;
Inspect the contents of the WinSxS folder for matching product directories; and
Checks the current working directory for any local versions of the VC++9 and VC++10 runtimes (and inspects their contents.)
edit: Here's a sample of what using it actually looks like:
wcout << _T("Checking for the availability of VC++ runtimes..") << endl;
wcout << _T("----------- Visual C++ 2008 (VC++9) -----------") << endl;
wcout << _T("Visual C++ 2008 (x86) ? ") << (IsVC2008Installed_x86() ? _T("true") : _T("false")) << endl;
wcout << _T("Visual C++ 2008 (x64) ? ") << (IsVC2008Installed_x64() ? _T("true") : _T("false")) << endl;
wcout << _T("Visual C++ 2008 SP1 (x86) ? ") << (IsVC2008SP1Installed_x86() ? _T("true") : _T("false")) << endl;
wcout << _T("Visual C++ 2008 SP1 (x64) ? ") << (IsVC2008SP1Installed_x64() ? _T("true") : _T("false")) << endl;
I licensed the crt-detector project under Apache 2.0, so feel free to use it in your own applications.
Update for anyone else hitting this problem:
1) If you have Visual Studio installed, the required DLLs will be present, but the "redist package" is not, so the registry keys are missing. (i.e. this will give a false negative). However, installing the redist over the top in this situation is harmless.
2) Every major release of the redist (Any combination of VS2005/VS2008, x86/x64/IA64, and service packs: SP1,ATL security update) has a different GUID. Take care if you are expecting to deploy your application on both x86 and x64 PCs.
3) If you use LoadLibrary or a check for Dll files, make sure you target the correct version. If you look for "any" copy of msvcrt80.dll (etc) then you won't be able to tell if it is the version your program was linked to.
Product code for "Microsoft Visual C++ 2008 Service Pack 1 Redistributable Package MFC Security Update (x86)" is {9BE518E6-ECC6-35A9-88E4-87755C07200F}
You can check for the files under the WINDOWS\WinSxS directory to see which versions you have installed. Often many versions can be installed at one time so you might need to check the specific versions you have installed.
I'd like to extend the GUID list with the following values:
32bit 30729.17
{9A25302D-30C0-39D9-BD6F-21E6EC160475}
32bit 30729.01
{6AFCA4E1-9B78-3640-8F72-A7BF33448200}
64bit 30729.17
{8220EEFE-38CD-377E-8595-13398D740ACE}
64bit 30729.01
{0DF3AE91-E533-3960-8516-B23737F8B7A2}
VC++2008 (sp1)
{3C3D696B-0DB7-3C6D-A356-3DB8CE541918}
VC++2008 (original)
{FF66E9F6-83E7-3A3E-AF14-8DE9A809A6A4}
IA64 30729.01
{22E23C71-C27A-3F30-8849-BB6129E50679}
32bit 30729.4148
{7B33F480-496D-334A-BAC2-205DEC0CBC2D}
Visual Studio 2008 Professional SP1
{D7DAD1E4-45F4-3B2B-899A-EA728167EC4F}
32bit 30729.01
{F333A33D-125C-32A2-8DCE-5C5D14231E27}
So please decide, whether it's a good idea to check the presence of VCredist by GUIDs.
The surest way is using the MsiQueryProductState API with the GUID of the different vcredist versions.
It works!
Regards.
Found registry entry for VC2008 redistributable. Here is my solution:
BOOL IsVC2008RedistInstalled(LPCTSTR pLogFile)
{
TCHAR szLogEntry[256];
memset(szLogEntry, '0', sizeof(szLogEntry));
HKEY hKey;
LONG lErr;
TCHAR csid[256];
_stprintf( csid, _T("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\{9A25302D-30C0-39D9-BD6F-21E6EC160475}"));
lErr = RegOpenKeyEx(HKEY_LOCAL_MACHINE, csid, 0, KEY_QUERY_VALUE, &hKey);
if (lErr == ERROR_SUCCESS)
{
_stprintf(szLogEntry, _T("VC2008 Redistributable was installed before.\n"));
toFile(pLogFile, szLogEntry);
return TRUE;
}
else
{
_stprintf(szLogEntry, _T("VC2008 Redistributable was not installed before. %ld\n"), lErr);
toFile(pLogFile, szLogEntry);
return FALSE;
}
}
Related
How can I compile my program using the x64 toolset from the Visual Studio IDE? By default the IDE invokes the 32bit toolset when I press the "Build" button.
Additionally, how can I tell CMake to use the x64 toolset instead of the 32bit toolset?
Please set your target property like this:
set_target_properties(MyTarget PROPERTIES COMPILE_FLAGS "-m64" LINK_FLAGS "-m64")
The Visual Studio project generator for CMake needs to be told to generate a project for the 64-bit compiler toolchain. Use cmake -G "Visual Studio 2013 Win64" for VS 2013 and x64 toolchain. See the CMake documentation on generators like Visual Studio 2013.
I am trying use cl from Visual Studio 2010 to build the 32-bit version of Mixxx. Mixxx uses SCons to build. My computer is Windows 7 64-bit with too many versions of Visual Studio installed.
Following these instructions, I have tried all sorts of combinations and variations of setenv and vsvars but no matter what I do, I end up on the command line in this situation:
> cl
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
OK, so cl is pointing to "version 16, x86" - great.
> scons toolchain=msvs force32=1 winlib=%cd%\winlib\x86 sqlitedll=0 staticlibs=1 asmlib=0
[... bunch of output truncated, until we start using the compiler ...]
cl /Fores\qrc_mixxx.obj /c res\qrc_mixxx.cc /TP /Zc:wchar_t- /GL /MP /fp:fast /G
[truncated]
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
(Note - I hacked SCons to remove the /nologo) What? How does cl now mean "version 18, x64"? Did it change my environment? Let's find out:
Terminate batch job (Y/N)? y
>cl
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
So cl still means "version 16, x86" to the terminal. But SCons always uses "latest version, x64".
(Based on my understanding of the Windows shell, this should not even be possible. I killed the script, so it didn't do any cleanup. How can the meaning of cl change like that?)
I've found a couple hints:
http://scons.1086193.n5.nabble.com/Using-32-bit-MSVC-compiler-on-64-bit-Windows-td28062.html
http://www.scons.org/wiki/MsvsMultipleVersions
Forcing scons to use older compiler?
Based on this, I've added
Environment(MSVC_VERSION = '10.0')
Environment(TARGET_ARCH = 'x86')
print 'hello world'
to the SConstruct. I don't know SCons, and the build scripts are non-trivial, so it's likely that I'm doing this wrong. Regardless, SCons still always uses "newest version, x64".
The Environment kwargs you posted work for me (Scons 2.3.4):
env = Environment(
MSVC_VERSION='12.0',
TARGET_ARCH='x86')
env.Program('src.cpp')
The value for a 64-bit program should be TARGET_ARCH='x86_64' according to http://scons.1086193.n5.nabble.com/32-and-64-bit-builds-on-MSVC-td25425.html. Other values of MSVC_VERSION also work.
I turned on logging per dirkbaechle's comment (set SCONS_MSCOMMON_DEBUG=-). This was very helpful. When I added Environment(MSVC_VERSION='10.0') to SConstruct, I could see in the output
get_default_version(): msvc_version:10.0 msvs_version:None
msvc_setup_env: using specified MSVC version '10.0'
[ ... truncated ... ]
get_default_version()
get_default_version(): msvc_version:None msvs_version:None
installed_vcs:['12.0', '10.0', '10.0Exp', '9.0']
msvc_setup_env: using default installed MSVC version '12.0'
Oops - by the time we call get_default_version for the 2nd time, it seems we are using a different environment. I don't understand the Mixxx build scripts well enough to know why, but I'm pretty sure that is the reason.
The Easy Workaround
For people like me who are too lazy to fix their build scripts, there's an easy (but ugly) way to force SCons to do what you want. You just need to intentionally break your newer versions (temporarily, of course). For example, I want to use 2010, x86. First, I rename all the "VC" directories of higher versions.
C:\Program Files (x86)\Microsoft Visual Studio 12.0\ VC rename to _DISABLED_VC
C:\Program Files (x86)\Microsoft Visual Studio 11.0\ VC rename to _DISABLED_VC
And now SCons will use 2010 (aka "Microsoft Visual Studio 10.0"), because all higher versions are unavailable. Selecting the target architecture is similar.
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\ amd64 rename to _DISABLED_amd64
do the same for ia64, x86_amd64, x86_ia64, etc.
I tried setting TARGET_ARCH using env = Environment(blabla), but it didn't help
So I searched for 'TARGET_ARCH' in Scons directory (...\PythonDir\scons-3.0.1\Scons).
In my case it was in Environment.py file that has a section with default values.
I changed None to 'x86'
# Now set defaults for TARGET_{OS|ARCH}
...
# self._dict['TARGET_ARCH'] = self._dict.get('TARGET_ARCH',None)
self._dict['TARGET_ARCH'] = self._dict.get('TARGET_ARCH','x86')
Then I removed previously compiled Environment.pyc, causing it to be regenerated
And it worked!
I want to use nvcc -ptx from windows command line, but I always get this error message:
nvcc : fatal error : Microsoft Visual Studio configuration file 'vcvars64.bat' could not be found for installation at 'C:\Program Files (x86)\Microsoft Visual S
tudio 11.0\VC\bin/../..'
I'm using vs 2012 express edition. What can be the solution?
I have managed to solve the issue and make work with MS Visual Studio Express 2012, here what I did:
Installed MS Visual Studio 2012 Express
Installed cuda_5.5.20_winvista_win7_win8_general_64, the latest version as of 2014-01-16
From this directory: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin, I have copied x86_amd64 to amd64
In the new directory: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64, I have created a file vcvars64.bat
In the file vcvars64.bat, just added: CALL setenv /x64
The compilation worked great:
C:\CUDA>nvcc -o square square.cu
Creating library square.lib and object square.exp
C:\CUDA>square.exe
0.000000 1.000000 4.000000 9.000000
16.000000 25.000000 36.000000 49.000000
64.000000 81.000000 100.000000 121.000000
144.000000 169.000000 196.000000 225.000000
From NVIDIA CUDA Compiler Driver document
1.2. Supported Host Compilers
nvcc uses the following compilers for host code compilation:
On Linux platforms
The GNU compiler, gcc, and arm-linux-gnueabihf-g++ for cross compilation to the ARMv7
architecture
On Windows platforms
The Microsoft Visual Studio compiler, cl On both platforms, the compiler found on the current
execution search path will be used, unless nvcc option -compiler-bindir is specified (see File and Path Specifications).
Your visual studio install is asking for .NET v3.5 framework:
http://www.microsoft.com/en-us/download/details.aspx?id=21
Got this info from this: Where can I find Microsoft.Build.Utilities.v3.5
When in your project go to Configuration Properties > CUDA C/C++ > Device and change Code Generation to the following: compute_11,sm_11
Below is a simplest C++ program:
x64test.cpp
int main()
{
char * p = new char[0xffffffffff];
}
My intention is to allocate a big buffer greater than 4G. In a native 64-bit process, it should be OK; but Visual Studio 2011 Beta rejects to compile x64test.cpp and resports: "error C2148: total size of array must not exceed 0x7fffffff bytes".
I have googled and found a useful article at http://blogs.msdn.com/b/windowssdk/archive/2007/09/08/updated-windows-sdk-visual-c-cross-compilers.aspx
According to the article, I should use a native 64-bit compiler to compile x64test.cpp. However, Visual Studio can only be launched as a 32-bit process so that msbuild.exe and cl.exe are always running as 32-bit processes.
I have tried to configure the solution platform to x64, but no effect.
I have used the so-called native 64-bit compiler to successfully compile x64test.cpp by the following steps:
1, start cmd.exe as an administrator;
2, cd C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64;
3, cl x64test.cpp
My question is:
Is there a way to enable the native 64-bit compiler in Visual Studio IDE?
My compile environment is windows xp and vc 6.0.
Now I have a c source file(msgRout.c), def file(msgRout.def), link file(msgRout.link), then I use commands below to get a 32 bit dll:
1.cl /I ../include -c -W3 -Gs- -Z7 -Od -nologo -LD -D_X86_=1 -DWIN32 -D_WIN32 -D_MT -D_DLL msgRout.c
2.lib -out:msgRout.lib -def:msgRout.def -machine:i386
3.link /LIBPATH:../../Lib -nod -nologo -debug:full -dll #msgRout.link -out:msgRout.dll
But the dll I got cannot be loaded on X64 application. it required a 64 bit dll.
So here is my question:
Can I get a 64 bit dll with vc 6.0?
Using only above 3 commands alike, how can I get 64 bit dll?
Many GREAT THANKS!!!
Allan
Visual C++ 6.0 does not include 64-bit compiler/libraries. You will need either a more recent version of Visual C++ or a Windows Platform SDK that has the 64-bit support. The earliest one is the Windows Server 2003 Platform SDK.
Once you have that installed, cl /? and link /? will have info on how to build 64-bit apps.
Update: If you have VS2005, you can build 64-bit binaries with the x86-amd64 cross-compiler (a 32-bit cl.exe that produces 64-bit code) or with the x64 compiler (a 64-bit cl.exe). To do that, you need to:
Make sure you've installed the 64-bit tools support during VS installation.
Open a command line and set it for x86-amd64 builds using C:\Program Files\Microsoft Visual Studio 8\VC\Vcvarsall.bat x86_amd64 or
(on 64-bit Windows) Open an x64 command line and set it for 64-bit builds using C:\Program Files\Microsoft Visual Studio 8\VC\Vcvarsall.bat amd64.
Once you do that, you should be able to use the same command line as above (with tcouple small changes - for cl you'll have to define /D:X64=1 or /D_AMD64_ and for link you'll have to change the /machine:x86 to /machine:x64) to produce 64-bit version of your program.
Here are some links with more information:
Installing Visual Studio 64-bit Components
HowTo: Enable a 64-Bit Visual C++ Toolset at the Command Line
Use Visual Studio to build 64-bit application
64-bit Applications
Seven Steps of Migrating a Program to a 64-bit System
You cannot. Microsoft does not have time machines.