I was browsing the web and found out that my application would
probably not work on (win)64bit machines. And that this is due to the fact
that MSVC uses my default 32bit runtime and sets the application to work only
on 32bit machines.
How can i set my simple application to run on x86 machines? thus making 64bit machines
use WoW64 when executing my app?
I'm using MS visual studio 2010 express (kinda short at the moment).
32-bit applications will work on Win64 OS's.
There are some special things you might need to do if your application needs to access the 'true' system32 directory or certain registry keys. However, the vast majority of 32-bit applications don't need to deal with that (some that might include file managers or registry editors). In fact, the redirection was specifically put in place by Microsoft so that the redirections would help the application compatibility.
However, if your application requires a special device driver - that would have to be built for a 64-bit platform (again, this is pretty rare).
You should test your application on a 64-bit platform, but the expectation is that in general it should just work.
Related
I am using Visual Studio 2008 to write applications. When deploying the app, some of the systems are 32bit, while the others are 64bit. Therefore, I plan to deliver both 32bit/64bit version in the installer, then launch the corresponding version based on the bitness of the OS. How to implement the latter, i.e., get the bitness of the OS and launch the corresponding version?
Let me clarify the situation. I already developed both 32bit and 64bit EXE application with C++. Then I want to detect the bitness of the Windows in C++(I don't know .NET) and launch the corresponding version of application.
Thanks
I would recommend looking for a more powerful MSI packaging tool. Most professional tools offer you a built-in bootstrapper that provides this functionality with one click.
The VS setup project is useful for basic application packaging, but never intended to offer you full power.
It depends on what you mean by "launch the corresponding version". This implies that you already have code written that needs to choose, in which case this isn't an installer question at all - you just need to find the bitness of the OS and then install the appropriate MSI file (or VS-generated setup.exe). If it's a C# launcher you'd perhaps use Environment.Is64BitOperatingSystem.
Your question doesn't say if you are delivering code (assemblies, COM Dlls etc) that will be used by client programs. I mention this because your 32-bit setup will install and run on 64-bit OS versions in the 32-bit subsystem. The 64-bit version will presumably contain only native 64-bit code.
Note that your 64-bit setup won't install on a 32-bit OS anyway.
For any VS project it is possible to set the platform target in the build properties of that project. You can set this to Any CPU, x86, x64 or Itanium. My question is, if I set this value to x86 does that mean I cannot run that project on a x64 machine? If so, why is this even used? Is it not better to just always use Any CPU?
if I set this value to x86 does that mean I cannot run that project on a x64 machine?
No, 32-bit applications (x86) run just fine on 64-bit Windows (x64). All 64-bit versions of Windows include a 32-bit compatibility layer called Windows on Windows 64 (WOW64). This is usually what you want, in fact, as most applications do not benefit from being complied for 64-bit.
However, compiling for 64-bit (x64) does mean that your app will not run on a 32-bit (x86) machine. You can go backwards (64-bit can run 32-bit), but you cannot go forwards (32-bit cannot run 64-bit).
Compiling for Any CPU is always an option, as you point out. That will allow the application to run as a 32-bit application (x86) on a 32-bit machine, and as a 64-bit application (x64) on a 64-bit machine. This sounds like a panacea, but there are costs. Most notably, you'll need to test your application extensively in both 32-bit and 64-bit environments, whereas if you only target 32-bit environments (including 32-bit environments on a 64-bit host), you only have to test one build. And the additional workload is rarely worth it—most business applications do not benefit from the extra memory space of a 64-bit environment, and probably end up defeating any potential gains by the increased overhead of 64-bit pointers.
Visual Studio itself is a good example of an application that is fully 32-bit. There is no 64-bit version, yet it runs fine on a 64-bit host. This blog post helps to shed some light on why the decision has been made to keep VS 32-bit. You might find the reasoning helpful in making the decision yourself.
Likewise, although Microsoft Office is now available in a 64-bit package, Microsoft is still recommending that most customers stick with the 32-bit version. There are compatibility problems with the 64-bit version, and there just isn't much benefit.
If you do not specify 32 bit platform the Microsoft application compatibility toolkit cannot determine the app is 32 bit and will not allow you to create a 32 bit solution file to allow an application to run without requiring admin credentials when user account control is turned on
I have a problem related to this question. Two players:
C# application
Mixed assembly used by 1)
The application has to support anything from Windows XP (32bit) to Windows 7 (32 & 64bit). The assembly is complicated in different ways. It contains managed C++/CLI code and some native C++ classes dancing with native DirectX. It also is linked to a few 32bit native dll's w/o source access (containing C++ classes with import libraries).
Things are working well in 32bit environments (XP and 7 tested) including the 32bit subsystem on Windows 7. Havoc happens, as soon as "Any CPU" is used on 64bit systems in order to build the complete solution. The 32bit assembly is unusable than - but seemingly only in debug mode ("cannot load, wrong format" etc.). It seems to work in release. A 64bit assembly build is prevented by the implicit dependencies to the mentioned 32bit third-party dll's.
Is there any way to provide a real native 64bit application able to use the assembly?
Requirement for the assembly isn't that strict. It could be both - 32 or 64bit - but as said above, should be be usable from the application one way or the other.
You are running into a rock hard limitation in the 64-bit version of Windows, a 64-bit process cannot execute any 32-bit machine code in-process. You certainly have a dependency on machine code when you use C++/CLI and work with DirectX. Although it doesn't sound like you could not execute in 64-bit mode, both C++/CLI and DirectX can be compiled/are available in 64-bit.
This then boils down to a build and deployment issue. You have to build the C++/CLI project(s) in 64-bit mode and deploy only 64-bit components on a 64-bit operating system. The main EXE must be built to AnyCPU. Similarly, on a 32-bit operating system you must build and deploy only the 32-bit compiled version. You solve the build issue by adding the x64 configuration to the solution so you build the 32-bit and 64-bit version separately. You solve the deployment issue by creating two installers.
Since you have to support a 32-bit operating system anyway, the simple solution is to change the Target platform setting on your EXE project to x86. Now everything always runs in 32-bit mode and you don't have to bother with the build and deployment headaches. The only thing you miss out on is the larger virtual memory address space that's available in the 64-bit version.
Forget about the C++/CLI project for a minute.
You have third-party 32-bit DLLs. These CANNOT load in a 64-bit process. So your main application will have to be 32-bit. This restriction has nothing to do with the C++/CLI middleman.
The only way you can make use of these DLLs from a 64-bit application is to load them in a separate (32-bit) process and marshal data back and forth.
I have seen that some programs which were written by me and assembled for x86 using ml.exe run fine on my Win 7 x64. I believe this is because of Wow technology.
However, there are some programs (not written by me) which don't run. They give the error that:
The version of this file is not compatible with the version of Windows you're running. Check you computer system infromation to see whether you need an x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher
Is there any way I can modify the EXE of these programs to make it run on Win 7 x64. What is the fundamental difference in these programs which make it different from other programs which run transparently.
They're actually 8- or 16-bit programs. Windows x64 runs in Long Mode, which does not support Virtual 8086 Mode, required for such programs. There is no way to make them work short of recompiling them from source or running them in a virtual machine.
One reason can be combination of .NET and native libraries. .NET libraries are compiled in runtime as x64 (if you don't specify explicitly x86) and native libraries run in x86 mode. it cannot run togehther.
Another reason is access to registry. Depending on used API, x86app in wow64 mode can be forwarded to another part of registry. If the registry access API is inconsistent, it can make a problem.
So I've been developing on Windows XP Visual Studio 2008. I guess it is building my C++ app in 32 bit mode. When I run the program on my new Windows 7 64 bit box, it gets half way through loading a then throws an access violation error. So, I loaded all my development tool and recompiled the project on Windows 7 to find the crash site but it works perfectly! What? How do I make my app work on x64? Do I have to release two seperate versions? I know I can target 64 bit but I don't like two separate executables. I've searched but keep getting the two version solution or everything .net. This is a native C++. is there an x86 flag somewhere?
"Do I have to release two seperate versions?"
It depends on what your app does. The majority of 32bit apps work just fine in WoW mode.
"is there an x86 flag somewhere?"
Yup. Open up the configuration manager (Alt-B, O) and you will likely see a win32 in the platform selection.
Why your app crashes is going to take some debugging. You should be able to attach the debugger to the 32bit version on the 64bit OS.
Have you considered the possibility that you may be trashing memory? From the way that the application happens to be loaded into memory, it may be that the 32-bit app on 32-bit Windows and the 64-bit app on 64-bit Windows "get lucky", i.e. no important memory locations are overwritten, whereas the 32-bit app on 64-bit Windows is less lucky and crashes.
To find out if you are indeed trashing memory, you can use tools such as Purify and Valgrind.
As the others' answers already said, it is very likely that the application has bugs that are being hidden in one environment. A good tool that has a low cost of entry in terms of learning curve is Microsoft's application verifier. That along with the debugging tools can provide a very good start. Take a look at the gflags utility.