现在，回答原来的问题。
从成本和投资回报的角度考虑。从微软多年的运输软件，我看到了64位版本的考虑。
>当32位应用程序在64位上工作正常时，几乎不用考虑64位。
> Microsoft的大多数项目都不是简单的Visual Studio项目，开发人员可以将项目设置从32位翻转到64位。 (我实际上不知道Visual Studio团队是否使用VS项目编译Visual Studio。)它们通常用超过一百万行的代码构建VS编译器集，但是从命令行和Makefile环境。切换到64位意味着更新了很多这种构建基础设施。
>从32位移植到64位是有代价的。第一个成本只是修复错误，获取代码编译，重构构建环境，以及所有的前期工作，只是为了初步构建。
>您需要支付单独的32位和64位应用程序的费用。你必须每天建两次。你必须每天运行两次测试抵押品。这不是2倍的成本，但它也不是免费的。
>随着更多的SKU来自相同的代码库，它增加了开发人员在签入时会打破某些机会的机会。当然，可以进行自动测试来防止这种情况，但是由于他必须退回并修理他没有在他的测试机上安装的其他SKU。
现在这里有一些推动到64位的动机：
>您真的需要利用64位性能和内存架构。使用尽可能多内存的大型数据库服务器将受益于访问32位Windows进程上超过2GB的限制。>您需要与已编译64位的内容进行整合。例如，如果要为Windows编写Shell扩展，则需要64位构建才能在64位Windows上运行。这并不意味着整个应用程序必须被移植，但它的确意味着这个组件将需要一个单独的64位构建。>您有一个平台或API故事供外部开发人员考虑。通常，他们有自己的64位构建需求。因此，即使您的本机应用程序可以摆脱32位支持，他们也可能需要64位即时API。>您的团队刚刚重新组织到Windows部门，您的团队代码被认为有必要包含在下一个Windows版本中。没有任何决定 – 您的代码将被编译为32位，64位和ARM(表面RT)。
