I downloaded Visual Studio 2013 from DreamSpark but it's the 32-bit version and I couldn't find any 64-bit version. Is there none, and if so why is there no 64-bit version of Visual Studio?
Visual Studio 2022 on Windows is now a 64-bit application.
The 64-bit versions of Windows don't provide support for 16-bit binaries or 32-bit drivers. Programs that depend on 16-bit binaries or 32-bit drivers can't run on the 64-bit versions of Windows unless the program manufacturer provides an update for the program.
Simply put, a 64-bit processor is more capable than a 32-bit processor because it can handle more data at once. A 64-bit processor can store more computational values, including memory addresses, which means it can access over 4 billion times the physical memory of a 32-bit processor. That's just as big as it sounds.
Visual Studio remains a 32 bit application, though certain components (e.g., diagnostics/debuggers, MSBuild, compilers, designers) will take advantage of 64-bit processors if available.
Update (May 2021) Visual Studio 2022 will ship as a 64-bit build: https://visualstudiomagazine.com/articles/2021/04/19/vs-2022.aspx
Original answer (Dec 2013)
First, there is a 64-bit C++ compiler that comes with Visual Studio tool set. So you can always change your project settings to make 64-bit builds of your app as needed.
Now, to answer the original question.
Think of it from a cost and ROI perspective. From years of shipping software at Microsoft, here's how I've seen the consideration for 64-bit builds get made.
When the 32-bit app works just fine on 64-bit, it's almost a non-starter to consider 64-bit.
Most of the projects at Microsoft aren't simple little Visual Studio projects in which the developer can just flip the Project settings from 32-bit to 64-bit. (I actually don't know if the Visual Studio team compiles Visual Studio with a VS project.) They are often well over a million lines of code that build with the VS compiler set, but from a command line and Makefile environment. Switching to 64-bit means updating a lot of this build infrastructure.
There is a cost of porting from 32-bit to 64-bit. The first cost is just fixing the bugs, getting the code to compile, restructuring the build environment, and all the upfront work just to get the initial build going.
There is an ongoing cost you pay for having separate 32-bit and 64-bit builds of an application. You have to build it twice every day. You have to run the test collateral on it twice every day. It's not a 2x cost, but it's not free either.
With more SKUs from the same code base, it increase that chances that a developer will break something when he checks in. Of course there can be automated tests to prevent this, but it will slow the developer down since he will have to go back and fix the other SKU that he doesn't have installed locally on his test machine.
Now here are some of the motivations for moving to 64-bit:
You really need to take advantage of 64-bit performance and memory architectures. Large database servers that use as much memory as possible will benefit from accessing more than 2GB limit imposed on a 32-bit Windows process.
You need to integrate with something already compiled with 64-bit. For example, if you want to write a shell extension for Windows, you will need a 64-bit build to run on 64-bit Windows. That doesn't mean the entire app has to be ported, but it does mean this component will need a separate 64-bit build.
You have a platform or API story for external developers to consider. Usually, they have their own needs for 64-bit builds. Hence, they may need a 64-bit ready API from you even if your native app can get away with 32-bit support.
Your team has just been re-organized into the Windows division and your team's code has been deemed necessary to be included into the next Windows release. There's no decision to be made anymore - your code will be compiling for 32-bit, 64-bit, and ARM (Surface RT).
Source code files should not be multiple gigabytes -- there's no reason for a text editor / development environment to use 64-bit pointers, which consume twice as much RAM for no benefit. Larger pointers make data structures containing pointers larger, requiring more memory bandwidth to move them around, and fitting fewer inside the CPU's data cache, so that the number of cache misses may increase as well.
The 32-bit editor is perfectly capable of launching and interacting with the 64-bit compilers, linkers, and debuggers when needed. Having only a 32-bit editor also simplifies the plugin model greatly.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With