为什么VS没有提供平win64程序编写项

最近在学习C++和MFC编程，突然有个疑问，为什么每次新建项目时，都只有win32 console application，从来没见过win64的选项，于是去网上查了查，下面是我找到的几个答案：

作者：仲唐
链接：https://www.zhihu.com/question/20370633/answer/16422813
-------------------------------------------------------------------------------------
1、指针占用空间变大，cpu的cache size不变，会带来性能问题。
2、对VS团队来说，移植到64bit最好办法是把native code移植到managed code。但这样成本太高。
对于一个IDE，与其移植到64bit以使用4GB内存，不如把精力花在优化内存使用上。
3、VS现有的extension都是32bit的，64bit需要重新建立生态系统。
-------------------------------------------------------------------------------------

作者：红伞菌
链接：https://www.zhihu.com/question/20370633/answer/15526209
-------------------------------------------------------------------------------------
首先，从性能的角度来看，64位需要庞大的指针，因此造成的数据结构更具规模，但处理器高速缓存大小保持不变的情况下，这容易导致运行速度变得极慢。

举个例子，好比你自己挖了一个洞，然后你通过使用额外的4G以上内存来把自己再刨出来然后继续做自己要做的事情。在Visual Studio中，可能会存在一些大规模计算的解决方案，但我认为维护一个环境一个最好的tradeoff是只使用较少的内存。很多的VS的算法是适合的。effectiveness和efficiency比fashion和fabulous要好得多。

下面列出64位的优劣：
from http://blogs.msdn.com/b/joshwil/archive/2006/07/18/670090.aspx
Pluses:
- more memory (+++++)
- better 64-bit math (+++)
- X64 OS kernel takes advantage of more memory to do good things for a lot of stuff (+++)

Minuses:
- things need more memory (pointers are bigger, and especially in managed code references are everything and are everywhere) (--)
- the processor's cache is effectively smaller (when comparing against the same machine in 32-bit vs 64-bit mode) because of the prior point (----)
- code also tends to be bigger because of extra prefix bytes and instructions that carry around 8-byte immediate values instead of 4 byte immediate values
其次，性能问题，从成本的角度来看，如果要全部从已有的32位移植到64位，最短的路径可以是先移植大部分保证增量开发的代码，然后移植那些剩余的，不是那么重要的那些。然而本机代码的完整移植的成本将是相当高的，而且当然所有已知的扩展将被破坏。我们还要创建一个64位的生态系统，这非常像你部署一次全新的64位驱动程序。

更麻烦的，如果所有你想要做的是将64位的代码移植而并非重新开发，最方便的路径确实是直接点对点移植。但是，这种情况根本不可能！！！在实践中，移植是有很大机会成本的，它与M¥ sorry不是，M$其他的业务竞争时间和资源。因此，情况是更可能是这样的：微软的32位C＋＋团队说“我想要往里添加一个OOXX功能，如果我基于已有的环境里开发新的，我可以更容易的做出功能OOXX，并且加上其他的东西比如OOOXXX特效，比如OOOOXXXX的连续自动化量产方案，这样，OOOXXX，OOOOXXXX的成本就很低了“，这也是他们喜欢托管代码原因。

但现在，他们也有64位的一个path。在现实中就变成有是越来越多的Visual Studio版本而不仅仅是32和64两种。所以基于以上考虑，我感觉最好部署VS的方法就是微软想出的策略，使用64位系统运行32位模拟模式的VS，这可以增加一倍可用空间而且不会导致空间问题，并且你也有了64位开发环境。
尽管如此，我知道肯定有很多用户会更加受益于64位的版本，但其实，我觉得，更好的做法不是简单的移植，而是努力优化IDE现有的结构，以图可以更好地减少内存占用。

下面回答一些更详细的问题，
1. 移植成本高是不是因为老代码质量差？
差的只是一小部分，VS太大了对于人类来说。而且大部分软件包都不会有64位地址优势。而且绝大部分的软件算法并没有优化，更有甚者许多继承了效率很低的代码占用了很大的空间，这不是微软自己能解决的。所以移植成64位以后微软也就要跟开发者们说拜拜了。

2. 64位程序出错就会少么？page faults。。。
不是的，64位进程的地址空间反而会引起更多问题 因为你数据块多了，地址多了，很多棘手的问题就接踵而来。然而一个64位的系统则会使问题迎刃而解，假设你在一个64bit OS上运行一个32位程序，你得到的使整个4GB空间，即使你不是直接使用那些64位指针，操作系统自己会判断。你的硬盘缓存会变得很小，即使你有很多其他程序也在运行。比如你的瞬态组件和数据都跑物理内存里了而非占用地址空间。
增加地址空间的真正意义在于允许你分配更多内存，但如果本身已经适应了4GB地址的程序你再把它的指针加大，那问题就来了，你会发现它有多少内存吃多少。别忘了cache大小是不变滴。你也许会发现更大的地址空间允许你创建更少的分区，更多的共享空间，但是auto-relocates这个东西会做得更好。也许更多得指令集是移植得又一好处吧。所以移植的好处就仅仅变成当系统无法再适应4G了，但那个时候你是觉得这个系统还tm能用么？回去用UNIX算了。
有一些必须使用庞大数据处理比如“复共线性空间数据回归模型挖掘”，那另当别论了。估计很少人会经常使用吧。所以即便只支持32位显得不是那么fashion，但是我们做产品要力求—— 简，而非减。

3. 但为啥微软很多其他软件都倾向于部署64位？比如OFFICE2013...
首先，OFFICE的根本问题不应是确保新的代码能运行的很流畅，而是要力求新的文件格式在新的代码生成这些文件时候，要和之前的版本兼容，（之后的版本也是）。所以记住，现在的64位word就应当想到：“我有很多数据结构有了64位偏移”。毕竟几乎所有的二进制文件格式都会有指针尺寸问题，然而Office已经解决了这一难题，使用了压缩格式的XML，所以他们可能已经不用内嵌指针了。
其次，像是EXCEL之类的，很多处理文档的人原因导入大于4G的data，但是想象一下你什么时候需要让VS也处理这么大的数据呢？你如果处理那些大的分析系统，你就安装一个64位的分析调试工具包即可。
One more thing，至今我还是认为32位系统已经足以适合各种开发和使用，64位尽管有那么那么多的好处，它根本上（用户方面）把许多不应该存在的问题复杂化了，所以 你尽管用你的32位，让别人说去吧。
-------------------------------------------------------------------------------------