Should we change the preprocessor definition from WIN32 to WIN64 while migrating Visual 2012 C++ Projects to Target 64-Bit Platforms.
Now I have built the project with below settigns
MACHINE (Specify Target Platform) is set to /MACHINE:X64.
Target Environment is set to /env x64
in C/C++ project settings -> Code Generation, Struct Member
Allignment to 8 BYtes
Please guide me what else project settings i should target to change.
It's important to note that only the underscore versions of these preprocessor definitions are relevant to the distinction between 32-bit vs. 64-bit machines.
The underscore versions, _WIN32 and _WIN64 are built-ins that relate to the actual physical CPU of the computer that VC++ is running on. On a 32-bit machine, _WIN32 will always be defined (user does not need to define it), but _WIN64 will not be defined. On a 64-bit machine, _WIN64 will always defined and also _WIN32 may be defined but code can rely on _WIN64 to determine if machine is 64 bit.
For Visual Studio 2019 (perhaps other VS versions also):
The non-underscore WIN32 is not well documented and appears to have no bearing on 32 vs 64 machine type. Standard Visual C++ projects for Windows generally don't appear to use it (it may not be in use at all). Thank you to BTJ for making that point.
Another side note for Visual Studio: If you run Visual Studio on a 64-bit machine and select the Win32 vs x64 build configurations, you will notice that WIN32 is defined for the Win32 build configuration but it is not defined for an x64 build configuration. This does not affect the object/binary machine target e.g. 32 vs 64. It's purpose is unclear. It may be for convenience if one wishes to use it to #ifdef certain parts of the source code that are to be compiled differently for X86 vs X64, but again, it has no bearing on the architecture that the compiler targets. For the compiler, the target architecture is determined by the toolset that is selected based on the project target selected "Platform". The linker also has /MACHINE arg e.g. /MACHINE:X86.
Did you mean _WIN32 and _WIN64 macros? If you specified all parameters right (see P.S.) then you don't need change your code. In 64-bit solution must be defined _WIN32 and _WIN64 both. _WIN32 macro specifies that you can use Win32 API and _WIN64 macro specifies that compilation for 64-bit mode. Also you can use different macro for Itanium (_M_IA64) and x86-64 (_M_AMD64). See details in MSDN.
P.S. Did you choose platform parameters manually? You can specify it via VS:
Build Menu -> Configuration Manager.
Select New in Active Solution Platform.
Type or select new platform -> x64 and click OK.
Now in "Platform" row you can simple choose x64.
In VS2015 at least, linker/All Options/Target Machine
this assumes that you're not using a 3rd-party tool (say widget support or hardware driver) that is configured to use x86 code or is built 32-bit while you're trying to build x64, or vice-versa
Related
I am looking for a way to program for MIPS assembly using VS2013 - but there is no assembly type project.
Is there a way to do this and get the .s output files of MIPS so I can later run them on other machines, and if I can't do this on VS2013 than how do I program MIPS on Windows 7?
Thanks
The assembler used in visual studio is Microsoft assembler (MASM), and yes you can program assembly language on it.
select an "Empty Project" then configure the "Build Customizations" of the project to use MASM, after that add a new c++ source file and rename it to any name .asm
Here are the detailed steps:
http://kipirvine.com/asm/gettingStartedVS2013/index.htm
And as for assembling your code to run on MIPS, I guess you can't do that with MASM, because it's a x86 assembler,
here is a list of the supported processor types directives on masm
.386
.386P
.387
.486
.486P
.586
.586P
.686
.686P
.K3D
.MMX
.XMM
Refer to
https://msdn.microsoft.com/en-us/library/vstudio/8t163bt0%28v=vs.100%29.aspx
the processor section.
Nevertheless, there is an option in the project "Properties" > "Linker" > "advanced" that let you chose between different machines, including Mips, but I guess this will merely set the Machine Flag in the PE header to MIPS and when the assembler try to build your module it will find a conflict between the machine type flag and the code in the module. But I'm not sure If you can build codes for MIPS.
To run MIPS programs on Windows 7, you need some type of emulator and a corresponding tool set. In the case of ARM processors, there are emulators that include a source level debugger and tool sets, including compilers, assemblers, linkers, and binary image output utilities for embedded systems. There's also a debugger for embedded systems that is run from Windows and some type of connection to the embedded system. The tool set runs on Windows, but targets the emulator or an actual embedded system. I don't know if there's a equivalent tool set and emulator like this for the MIPS processor.
I'm taking a 32-bit source library and compiling on a 64-bit platform and getting alignment issues (not only 32-bit vs 64-bit but also character set as well).
I want to place all the 64 bit configurations into a "Win64" folder and the 32-bit configurations into a "Win32" directory.
I'm looking into some guidance for modifying the project file so that the target library and dll filenames will be in terms of the configuration.
Examples:
Win64/testrunner_x64d.lib -- Library, debug, 64-bit platform, ASCII
character set.
Win64/testrunner_x64ud.lib -- Library, debug, 64-bit platform,
Unicode character set.
Win32/testrunner_x32d.lib -- Library, debug, 32-bit platform, ASCII
character set.
Win32/testrunner_x32ud.lib -- Library, debug, 32-bit platform,
Unicode character set.
I'm new to using configurations in Visual Studio 2010 and also porting an existing project.
For the character setting, go to "Configuration Properties"->"General"->"Project Defaults"->"Character Set", chose the one as you wish.
For the lib's name for different configuration, you can set it via "Linker"->"General"->"Output File"
I created a new c++ project in VS2010. I added x64 as a new solution platform. I tried setting "copy settings from" to both "Win32" and "empty", but neither worked. _AMD64_ is not defined when I select x64 as the platform. Shouldn't it be? Is there another step I am unaware of for compiling for 64 bit?
In anticipation to questions: I am using VS2010 Ultimate, Windows 7 64bit, x64 compilers were selected during VS installation.
You've got all the steps right. An _AMD64_ symbol is not predefined by default by Visual Studio. You'll need to define it yourself if you want to use it:
#if defined _M_X64 || defined _M_AMD64
#define _AMD64_
#endif
But you're not making up the memory of its existence. The Windows DDK comes with makefiles that define this symbol, in addition to some others. Check in makefile.def. The possibilities are:
_X86_
Variously known as x86, i386, and IA-32
(this is the same as VS's predefined _M_IX86)
_AMD64_
Variously known as AMD64, x64, x86-64, IA-32e, and Intel 64
(this is the same as VS's predefined _M_X64 and _M_AMD64)
_IA64_
Intel Itanium (IA-64)
(this is the same as VS's predefined _M_IA64)
…and some others for architectures nobody targets anymore
Ideally, you would configure your build system to predefine a set of known macros that you will then use in your own code. If you don't have a build system, at least set something up in a precompiled header file. That way, you're not relying on implementation-dependent symbols everywhere, and switching compilers is not a colossal chore—the target architecture symbols predefined by GCC are very different from MSVC, for example.
Does any one know how to generate a VS proj/soln file with both 32-bit and 64-bit configurations using CMake.
You can't. With CMake you can generate separate solution files for 32-bit and 64-bit depending on the Visual Studio generator option you specify upon invoking CMake.
The requirements listed in the 3ds Max SDK state that plug-ins for 3ds Max 2011 must be built with Visual C++ 9.0 (Visual Studio 2008).
If I create a DLL with a different version of Visual C++, won't the binary be identical? Is this simply a matter of choosing the right compiler settings?
What problems will I run into if I try to build a plug-in using Visual C++ 2010 (Visual Studio 2010)?
I don't know specifically for 3ds Max, but the usual reason is the C Runtime library. If the host application uses the DLL version of the CRT, then plugins will also need to use the same version.
Otherwise, imagine the case where your plugin creates some memory using malloc(), and passes it to the host application, which uses it and then calls free(). If your plugin and the host application are using different CRTs, the host's call to free() will fail or crash because it wasn't the host's CRT that malloc()ed that block of memory.
The binary won't be identical but the binary interfaces should be, which is what you need.
The reason you can't use VS2010 is because it is not yet production quality. They think you should wait for VS2010 SP1 at a minimum.
You think they are just being obstinate and stubborn, eh? Ruining all your fun. They have reasons. Good ones.
Because of bugs like this:
https://connect.microsoft.com/VisualStudio/feedback/details/565959
I use both visual studio 2008 and 2010 for plugin development.
Only difference I've seen is that the user need the vs c++ runtime version for 2010\2008.
But there might be pitfalls - but I have not encountered any problems with it yet.
C++ doesn't have a standardised binary interface. The compiler "mangles" each symbol name (i.e. each function or static data) to include information about namespaces and signature, so that namespaces, argument overloading, &c. can work. Each compiler is free to decide how to do this. Different MSVS compiler versions do name mangling in different ways, so in general you can't link a C++ library compiled with 2005 and a library compiled with 2008 together: this includes loading a 2008 DLL from a 2005 executable (for example). You can do this if the interface between the libraries is C, as long as the relevant functions are marked with extern "C" to prevent name mangling. And in practice the differences are not always that great: for example, I never had trouble using VS2005 SP1 to compile a library for 3ds Max 9, which supposedly requires VS2005 with no service pack.
Microsoft is trying to fix this incompatibility, so in VS2010 they introduced an option, so VS2010 can produce binaries compatible with VS2005 programs or VS2008 programs (maybe some earlier versions too, I forget). If you have to create a plugin to work with multiple 3ds Max versions, and you don't get caught out by any VS2010 bugs, this is probably a good option. Also, the Intel C++ compiler has a mode where it produces binaries that are compatible with an MSVS version of your choice, which might be a better option for you if it's for hobby use or you can afford the slightly expensive price tag. (They achieve this by copying the way MSVS does name mangling.)