I'd like to configure visual studio 2005 to copy .dll's based on whether the OS is 64-bit or 32-bit during a build.
I do not want to specify what the platform target is.
My first attempt was to use a batch file to lookup the Windows version, but some 32-bit and 64-bit versions of Windows share the same version number.
Anyone know of any way to check this?
Thanks!
You should be able to read the environment variable %PROCESSOR_ARCHITECTURE%. Here is some great information on it.
http://blogs.msdn.com/david.wang/archive/2006/03/26/HOWTO-Detect-Process-Bitness.aspx
Check out isWow64, I think that shopuld give you what you are after.
Determines whether the specified process is running under WOW64.
Jon's link is a total hack because it relies upon no new processor architectures being added.
See: http://support.microsoft.com/kb/556009 for the "official" batch file method.
Related
We are shipping application, that is 32b, and, therefore, put into ProgramFiles(x86) directory. There is x64 'plugin' for it, running as a separate process (service), and now we're deploying it into the main application's subdirectory. The plugin isn't deployed on x86 systems.
Now, the question - isn't this (having x64 exectuable in x86 ProgramFiles) considered as bad idea? Can this solution have negative impact on (something)?
Thanks!
It has no negative impact, and in fact, Visual Studio also does this (it installs its 64-bit native compilers into the (x86) directories).
This is only problematic if it's a "real" 64-bit application that expects to be where it's supposed to be (wrt "Program Files"), as certain WinAPI functions that give you this directory work differently for 64-bit and 32-bit applications.
For an x64 program, the %PROGRAMFILES% environmental variables and their analogues are pointing to the Program Files (no x86) directory. So there may be some problems with locating the files that were put in the wrong directory.
Since your app is 32bit, there shouldn't be any problems.
Just out of curiosity, if I am creating a program installer, how should I decide in which "Program Files" directory to install to? On 32-bit systems, the environmental variable "%programfiles%" is good enough. However, on 64-bit systems, 32-bit programs should not install to that folder and instead to "%programfiles(x86)%", which as I understand points to "C:\Program Files (x86)". My question is: How should the installer decide which environment variable to use? Will the value of "%programfiles%" change for a 32-bit application, or should I always check first whether "%programfiles(x86)%" exists before using "%programfiles%", or should I do something entirely different?
Thanks! This is just out of my own curiosity, as I try to get used to 64-bit operating systems.
When the 32-bit program (installer in your case) asks the system to resolve the ProgramFilePath constant (check the exact name in MSDN), the system does not return C:\Program files, but C:\Program files(x86). So it's the system that decides, not the application.
I'm pretty certain that I read somewhere that Windows did this for you automagically. In other words, if your installer was 32-bits, it would be routed to the x86 directory variant even though you were trying to install into Program Files.
I'm sure I read this on The Old New Thing but here's a link that supports the contention until I can find that one.
Ah, yes, here it is, from the ever useful Raymond Chen.
Commenter Koro is writing an installer in the form of a 32-bit program that detects that it's running on a 64-bit system and wants to copy files (and presumably set registry entries and do other installery things) into the 64-bit directories, but the emulation layer redirects the operations into the 32-bit locations. The question is "What is the way of finding the x64 Program Files directory from a 32-bit application?"
The answer is "It is better to work with the system than against it." If you're a 32-bit program, then you're going to be fighting against the emulator each time you try to interact with the outside world. Instead, just recompile your installer as a 64-bit program. Have the 32-bit installer detect that it's running on a 64-bit system and launch the 64-bit installer instead. The 64-bit installer will not run in the 32-bit emulation layer, so when it tries to copy a file or update a registry key, it will see the real 64-bit file system and the real 64-bit registry.
I recently received a 64-bit crash dump from a customer.
Our processes are all 32-bit, but the customer's machine is running x64 Server 2008.
Visual Studio (both 2008 and 2010 Express) is telling me that I have to use the 64-bit version of MSVSMON.EXE, which I can't because I don't have a 64-bit machine.
I'm pretty sure there's a way to do this in WinDbg, but I find WinDbg to be hostile.
Is there any way to debug a 64-bit dump on a 32-bit machine, preferably using Visual Studio?
You need to make sure that customer uses 32 bit tools (adplus or DebugDiag) to capture crash dumps for your 32 bit processes. Then you can use your 32 bit machine to debug the dumps.
Link
Though Isalamon's comment is technically correct, nobody would like to execute that as the stack trace is horrible.
Let your customer know that this is necessary, and hope that he/she cooperates.
If you are not familiar with dump analysis, Microsoft is always there for you, http://support.microsoft.com
I worked around the problem by using 32 bit task manager (C:\Windows\SysWOW64\Taskmgr.exe) to capture the dump.
I have gotten excellent results using the advice on switching to x86 mode using !wow64exts.sw as advised here:
http://blogs.msdn.com/b/ntdebugging/archive/2008/06/03/how-to-debug-wow64-applications.aspx
Same advice figures here:
http://blogs.msdn.com/b/msdnforum/archive/2010/03/14/how-do-i-switch-to-32bit-mode-when-i-use-windbg-to-debug-a-dump-of-a-32bit-application-running-on-an-x64-machine.aspx
And background and related commands over here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384163(v=vs.85).aspx
Hope this serves as a compilation of decent inputs on this topic in addition to what already exists in this thread. Thanks.
Is it Userdump or kernel dump? It looks like you got the system dump. If that is the case, then you can take help of !wow64exts extension on windbg and can root cause the problem.
I agree with anwer you should get dmp file captured correctly, but recently did some experiments with this type of incorrectly captured dmp file. I used WinDbg to patch SOS.dll to remove the arch check. I'm not 100% sure if what I'm getting is valid, but at least some it appears so... https://chentiangemalc.wordpress.com/2015/04/17/experimental-use-of-64-bit-dump-of-32-bit-net-process-in-windbg/
We're running our unit tests as a post-build step in our builds. Now I've run into a problem with this on our autobuild machines that automatically pull and build every revision in svn.
The autobuild script pulls down a revision, does some setup and then calls devenv.exe /build on it. This, in turn, will build everything and then try to run the tests. The build gets stuck and never completes.
If you build the solution manually, what happens at the run tests point is a popup dialog box saying the test executable is not a valid Win32 application. I'm assuming the autobuilds somehow get this box as well, but hidden away in a non-interactive session somewhere.
I've had two ideas for a solution this far:
Check in a test-runner application which tries to run the tests and detects the failure. This is undesirable though since this would mean creating this extra kludge of code and adding it to be used only on windows builds etc.
Somehow test if windows is 32-bit or 64-bit in the build scripts (we're running cmake), and simply don't run the tests if they wouldn't work. This is preferable, but requires a way of checking if windows is 32-bit or 64-bit, preferably without having to check in another "test-windows-type" helper tool.
Any further ideas or hints on how to implement suggestion 2 would be much appreciated.
Update: Note here: This is a cross-compile running on a 32-bit machine but compiling a 64-bit exe. If I could just check properties of the compiler, there wouldn't have been a problem. But I'm after properties of the build machine, not of the build itself, which is clearly 64-bit.
Check the %PROCESSOR_ARCHITECTURE% environment variable :
x86 on a 32-bit machine.
AMD64 on a 64-bit machine (cf. here).
You should be able to check the CMake generator which I think is different for 32/64 bit windows.
Not an answer to the the specific question you asked, but you should perhaps consider building your app on an x64 machine, which could run 32-bits tests as well as 64-bits tests...
You can check the CMAKE_SIZEOF_VOID_P variable in your build script to detect the type. See documentation here. Then you can skip running the tests if this variable is 32.
Update: Sorry I overlooked your real issue. I think the best approach may be to apply a try-run test and use the RUN_RESULT_VAR to determine if the app ran successfully.
I found out one way to identify if the system is 64-bit or not, which should be possible to access from cmake. It feels as a rather ugly hack though that could break on any random version of windows, so I'd still rather find another way.
The %ProgramFiles(x86)% environment variable only exists in 64bit OS versions.
We have an installation program that runs in Perl 32-bit. This program needs to get information on cluster resources, so it runs cluster.exe (using backticks) and parse its output.
On Windows Server 2003 this went well, as a 32-bit version of cluster.exe existed under syswow64. However, such a 32-bit version does not exist on Windows Server 2008, so the backticks run of cluster.exe says it can't find such an executable, as 32-bit process look for it under syswow64.
Can someone think of a way we can bypass this problem and get the cluster resource information?
One manual way is to copy the 64-bit version of cmd.exe from system32, and then run it with "/c cluster.exe" which will start the 64-bit cluster.exe under system32. (Copying the cluster.exe won't work well, as it can't find the cluster cache.) However, this is only good as a manual workaround, and not as a solution to all users.
Is there another way to cause windows to start the 64-bit cluster.exe?
Thanks,splintor
PS
A similar question was asked on technet a month ago, but didn't get a real answer.
I found two possible solutions:
One is to write a small 64-bit application named cluster.exe that simply calls %SystemRoot%\System32\cluster.exe (using system()), and put it under %SystemRoot%\syswow64. Since it is a 64-bit application, the correct 64-bit cluster.exe application will be called.
Another solution is to use the sysnative redirection (as explained here), so now we check - if %SystemRoot%\System32\cluster.exe exists, we use it, else if %SystemRoot%\Sysnative\cluster.exe exists we use it, else we use plain cluster.exe.
Note: this is very similar to this telnet.exe problem that just got answered.