Sign in to follow this  
Vincent_M

Compiling 64-bit Applications in Visual Studio Express 2013

Recommended Posts

Vincent_M    969

Does anyone know if it's possible to compile 64-bit C++ binaries for VS 2013 Express, or do I need to buy the full version? I've looked around for a solution, and I've come across this MSDN article:

http://msdn.microsoft.com/en-us/library/x4d2c09s.aspx

 

32-bit-native desktop-class CPUs since mid-2007. It seems that Windows is still holding onto its 32-bit past for some reason...

Share this post


Link to post
Share on other sites
SmkViper    5396
As indicated by the table linked on that page VS Express does include a compiler that can target x64 architecture. It does not include a 64-bit toolchain. In other words, it can make 64-bit programs but it itself is not a 64-bit program.

The page you linked is about switching the 32-bit compiler for 64-bit compiler, not about making 64-bit programs.

To build a 64-bit program, you need to make a new project and solution configuration that targets x64. To do this, click the dropdown for selecting debug/release and click the "Configuration Manager..." option. Then click the dropdown under "Active solution platform" and select "<New...>". Then select "x64" from the top dropdown, and pick a platform to copy settings from. Make sure "Create new project platforms" is checked. Then you'll be able to set up and build for both 32-bit and 64-bit programs.

(Instructions are from MSVC 2013 Pro, as I don't have Express on hand, but it should be the same or similar)

Converting a project to build for x64 by hand is harder, as you'll have to fix up all the library paths, settings, and preprocessor settings to build for x64.

Whether or not you need to make a 64-bit app is a whole other discussion, as most indie games and personal projects won't get any advantage.

Edit: Ironically, the instructions that I just typed up are listed on MSDN right above the page you posted on the left-hand sidebar. Edited by SmkViper

Share this post


Link to post
Share on other sites
MJP    19753

VS 2012 and 2013 express includes the x86-x64 cross compiler, and not the full x64 compiler. Like SmkViper already explained, this essentially means that the compiler and linker are 32-bit executables, but ultimately they can produce a 64-bit executable. For the most part this isn't a big deal, unless you start working on a huge project that can cause the linker to exceed its 4GB virtual address space. I have no idea why they only include the cross-compiler and not the full x64 compiler, it doesn't seem to make much sense to me.

Edited by MJP

Share this post


Link to post
Share on other sites
Jason Z    6434

VS 2012 and 2013 express includes the x86-x64 cross compiler, and not the full x64 compiler. Like SmkViper already explained, this essentially means that the compiler and linker are 32-bit executables, but ultimately they can produce a 64-bit executable. For the most part this isn't a big deal, unless you start working on a huge project that can cause the linker to exceed its 4GB virtual address space. I have no idea why they only include the cross-compiler and not the full x64 compiler, it doesn't seem to make much sense to me.

One has to assume that the full 64-bit version is coming sooner or later, but it is curious why it isn't available already...

Share this post


Link to post
Share on other sites
TheChubu    9446


I have no idea why they only include the cross-compiler and not the full x64 compiler, it doesn't seem to make much sense to me.
So they can charge people for the other editions of VS that do have them?

 

Its like asking why Windows Vista Starter only supports 1Gb of RAM (hint: It isn't a limitation of the NT kernel).

Share this post


Link to post
Share on other sites
SimonForsman    7642

VS 2012 and 2013 express includes the x86-x64 cross compiler, and not the full x64 compiler. Like SmkViper already explained, this essentially means that the compiler and linker are 32-bit executables, but ultimately they can produce a 64-bit executable. For the most part this isn't a big deal, unless you start working on a huge project that can cause the linker to exceed its 4GB virtual address space. I have no idea why they only include the cross-compiler and not the full x64 compiler, it doesn't seem to make much sense to me.

One has to assume that the full 64-bit version is coming sooner or later, but it is curious why it isn't available already...


Microsoft is giving away the express edition for free and allows people and companies to use the express edition commercially, They need to save some stuff for the more expensive editions otherwise noone would buy them. Edited by SimonForsman

Share this post


Link to post
Share on other sites
Vincent_M    969

As indicated by the table linked on that page VS Express does include a compiler that can target x64 architecture. It does not include a 64-bit toolchain. In other words, it can make 64-bit programs but it itself is not a 64-bit program.

The page you linked is about switching the 32-bit compiler for 64-bit compiler, not about making 64-bit programs.

To build a 64-bit program, you need to make a new project and solution configuration that targets x64. To do this, click the dropdown for selecting debug/release and click the "Configuration Manager..." option. Then click the dropdown under "Active solution platform" and select "<New...>". Then select "x64" from the top dropdown, and pick a platform to copy settings from. Make sure "Create new project platforms" is checked. Then you'll be able to set up and build for both 32-bit and 64-bit programs.

(Instructions are from MSVC 2013 Pro, as I don't have Express on hand, but it should be the same or similar)

Converting a project to build for x64 by hand is harder, as you'll have to fix up all the library paths, settings, and preprocessor settings to build for x64.

Whether or not you need to make a 64-bit app is a whole other discussion, as most indie games and personal projects won't get any advantage.

Edit: Ironically, the instructions that I just typed up are listed on MSDN right above the page you posted on the left-hand sidebar.

I tried changing the build configuration, but the x64 option wasn't appearing. I was able to type in whatever I wanted, which I typed in x64, but I'm sure that's not a magic string that'll set my new build configuration's settings to use the 64-bit compiler.

 

What really gets me is Microsoft's interest in continuing to push 32-bit development on their developer base when both the hardware and their own operating system have been largely a 64-bit world for quite some time now. I don't think you could find a 32-bit Intel or AMD CPU anymore. This will only promote the 32-bit/64-bit compatibility issues in the future if Microsoft ever wanted to get rid of 32-bit support altogether, which makes sense now that XP is no longer supported by them. Then again, 32-bit Vista...

 

EDIT: Ok, I think I've got it. Typing "x64" into the platform name even though it doesn't show up in the drop down (nothing does except a blank field) was a magic string. I went through my Linker settings for my project, and found that my "Target Machine" field in "Linker->Advanced" has changed to "/MACHINE:X64". I checked my directories, and all VS's environmental variables have changed to have an "x64" suffix to it, or something similar to that.

 

My 32-bit libraries are no-longer recognized because I get "unresolved external symbol" linker errors. I swapped GLEW and GLFW's 32-bit libraries out for the 64-bit versions, and everything built correctly. When building the application, I get a run-time error: "The application was unable to start correctly (0xc000007b). Click OK to close the application." I've done some Googling, and it looks like maybe some directories aren't setup properly. I have no project dependencies just yet.

Edited by Vincent_M

Share this post


Link to post
Share on other sites
Vincent_M    969

I narrowed it down to GLEW. My code builds and runs with just the GLFW's API calls in it, but as soon as I made a GLEW call, I get that run-time error. I store the includes and libs to GLEW and GLFW are in my own personal include and lib directories I created in my Documents/Projects folder (assuming all other projects will use these, for now). Each project's "Additional Includes/Dependencies" have those directories added for all configurations. I even downloaded GLEW's source, and build it from scratch after switch its "Target Platform" over to x64. No luck there.

Share this post


Link to post
Share on other sites
Alessio1989    4634

VS 2012 and 2013 express includes the x86-x64 cross compiler, and not the full x64 compiler. Like SmkViper already explained, this essentially means that the compiler and linker are 32-bit executables, but ultimately they can produce a 64-bit executable. For the most part this isn't a big deal, unless you start working on a huge project that can cause the linker to exceed its 4GB virtual address space. I have no idea why they only include the cross-compiler and not the full x64 compiler, it doesn't seem to make much sense to me.

 

OT: Unfortunately most issues come from the lack of a 64-bit versions of the IDE and of IntelliSense, browsing the code of a "huge" project like UE4 is a pain.. wacko.png

Edited by Alessio1989

Share this post


Link to post
Share on other sites
Trienco    2555

Weird. I vaguely remember MS explaining their lack of a 64bit version with something like "it's pointless, there is no reason these tools would ever require more than 4GB". So at least at some point they went with "why bloat up the executables and double our maintenance efforts when there is zero benefit?"

 

Are we already at the point where this has become the new "nobody needs more than 640k" statement? ,-)

Share this post


Link to post
Share on other sites
Vincent_M    969

Weird. I vaguely remember MS explaining their lack of a 64bit version with something like "it's pointless, there is no reason these tools would ever require more than 4GB". So at least at some point they went with "why bloat up the executables and double our maintenance efforts when there is zero benefit?"

 

Are we already at the point where this has become the new "nobody needs more than 640k" statement? ,-)

I could see the executable getting larger, but I'd also propose that they get rid of the 32-bit version. The maintenance would stay the same, and they're writing native stuff. Holding onto the 32-bit world, which doesn't exist in desktop-class hardware hasn't existed for quite some time. We're even seeing 64-bit architecture on mobile devices more and more, and any 32-bit mobile CPU would require a separate compiler for 32-bit code anyway (which, that compiler could be a 64-bit executable too, lol).

Share this post


Link to post
Share on other sites
yellowsputnik    1525
I could see the executable getting larger, but I'd also propose that they get rid of the 32-bit version. The maintenance would stay the same, and they're writing native stuff. Holding onto the 32-bit world, which doesn't exist in desktop-class hardware hasn't existed for quite some time. We're even seeing 64-bit architecture on mobile devices more and more, and any 32-bit mobile CPU would require a separate compiler for 32-bit code anyway (which, that compiler could be a 64-bit executable too, lol).

 

There are still 32bit Windows systems out there. Making VS 64bit only would exclude those, while keeping it 32bit doesn't seem to have any major drawbacks at the moment.

Share this post


Link to post
Share on other sites
Vincent_M    969

 

I could see the executable getting larger, but I'd also propose that they get rid of the 32-bit version. The maintenance would stay the same, and they're writing native stuff. Holding onto the 32-bit world, which doesn't exist in desktop-class hardware hasn't existed for quite some time. We're even seeing 64-bit architecture on mobile devices more and more, and any 32-bit mobile CPU would require a separate compiler for 32-bit code anyway (which, that compiler could be a 64-bit executable too, lol).

 

There are still 32bit Windows systems out there. Making VS 64bit only would exclude those, while keeping it 32bit doesn't seem to have any major drawbacks at the moment.

 

I just wish they'd at least make the native platform's architecture default at first, but it's just a gripe. It's caused me to go out and learn something, so I'm pretty happy there smile.png

 

Aside from that, I think I've come across the answer to my problem. I think GLEW's dll might be wrong. For example, when I added the FBXSDK, I could compile the project using the FBXSDK API calls, but the application would crash telling me that libfbxsdk.dll was missing. The DLL for my architecture and platform was in the same folder that my current config/platform was pointed to for Additional "Library Directories" under my project's Properties->Linker->General tab. Of course, the static .lib file was included as an additional dependency for the project to build, but then DLLs are linked at run-time... So, what would be the best practice for building my projects with DLL dependencies? Right now, I have four build configs:

32-bit Debug and Release

64-bit Debug and Release

 

I'm going to switch to 64-bit Debug once I get around to building GLEW and GLFW for that. Right now, I'm putting all required DLLs into my project's directory so it'll build. However, when running the project directly from Windows Explorer, I'd have to have a copy of all those DLLs for the correct platform/config in the corresponding folder. This would require some manual copying and pasting, which is fine for the moment, but is there a more automated way of doing this? I'd like to release my project as an open-source one once I figure out which 3rd-libraries I need, and which ones I have permission to distribute.

Edited by Vincent_M

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this