So my boss asked me to test code on VS2012(x86) and VS2012(x64) redistributable package,
but when I look at the configuration manager>platforms... the only options on testing VS2012 are x64 and Win32.
So my question is when I build my code with Win32, is that the same as building for x86?
Yes. Win32 was the name used in old versions of VS, before 64-bit processors where available. Back when it could also build 16-bit DOS and Windows 3.x programs, Win32 distinguished targeting Windows 9x and Windows NT.
Picking "x86" would not have been a good choice back then, those 16-bit programs also ran on a x86 processor. It only recently became synonymous with "32-bits". They just never changed it.
So my question is when I build my code with Win32, is that the same as building for on x86?
Yes. In this context x86 is synonymous with Win32.
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.
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.
Is it any way in QtCreator for windows to build a 64-bit executable? (I need to use a COM object as INPROC and this object is only available for 64 bit architecture)
I do not see any reason why not. You would need:
To be working on a 64-bit processor,
Ensure you have the Visual Studio 64 bit edition
Compile Qt on that 64 Bit setup
Compile QtCreator on that setup
The email says that debugging tools would also need to be compiled. I am not sure which debugger QtCreator uses but I would image it would be open source and you could compile it on that setup anyway.
Qt probably do not do it by default because they already produce loads of different builds for all the platforms they support and there has not yet been a large demand for 64bit windows desktop applications.
Pekka Gaiser correctly pointed to an email from Trolltech. Basically, that's it :)
Specifically: Seemingly there is no 64 bit cross-compiler for Windows (due to that, there is no 64bit VLC for Windows). Therefore, the Microsoft compiler must be used. Unfortunately, Creator's support for Microsoft's toolchain is limited (although they make big steps towards supporting it fully).
Again: The email pointed to by Pekka Gaiser contains the information and links for using Qt Creator with Microsoft's 64bit toolchain.
I'm wondering if I can still develop 32-bit apps using a 64-bit machine (64-bit Windows Vista with Visual Studio 2008 SP1)? Because I am planning to buy a laptop with 64-bit Vista. Im asking just to make sure. Thanks!
64-bit Windows runs 32-bit Visual Studio just fine. Unless you specify you wish you use the x64 development tools, it will still compile 32-bit applications.
Straight from the page:
Visual Studio uses the 32-bit cross
compiler even on a Windows 64-bit
computer. You can, however, use devenv
commands to create a command line
environment to call 64-bit hosted
tools.
Further Information: http://msdn.microsoft.com/en-us/library/ms246588(VS.80).aspx
With Visual Studio you are able to target what platform. By default it will run on "Any CPU" (read 32 or 64 bit), but you can specify if you desire. Look under Project>Properties>Build and look for the "Platform Target" property.
Yes. 64-bit vista will run 32-bit executables, so if you have a 32-bit compiler, it will still work.
Within visual studio you can tell it what to compile to under the Configuration Manager - (Build Menu - Configuration manager) - this allows you to target 32 or 64 bit.
64bit of consumer hardwares is usually "amd64" architecture which can run both 32bit apps and 64bit ones natively. Windows Vista 64bit edition supports both 32bit and 64bit system libraries, so basically you can run both type of applications as well. (Note that IA-64 architecture does not allow this.)
Compiling a program in 64bit is not much related to the platform that the compiler runs. But, of course, to run and test the result binary requires the corresponding architecture.
As many mentioned above, VS2008 let you choose the target architecture, so there's no problem.
I've found that just the setup.exe created by Visual Studio 2012 Express won't work on XP, but if you go ahead load MS 4.0 .NET Framework from the Microsoft Website then the *.application will load and install without using the setup.exe at all.