阻碍工作站部署64位操作系统的障碍？

这个问题不容易总结，但主要的问题是，供应商总是不愿意发明时间，因此金钱，发展司机，他们不知道他们将获得必要的回报价值。

简而言之：如果他们不认为64位用户太多，他们就不会为他们开发。

同样适用于应用程序。 大多数应用程序只是为了32位操作而编写的，并且通过填充来依靠向上的兼容性来工作。 但是，根据源代码执行的是什么样的奥术魔术，尽pipe不是太常见，但它可能会变成梨形，大多数情况下，只有像游戏这样的复杂应用程序真的受到兼容性问题的困扰。

操作系统本身很less有错误的做坏的东西与体系结构 – 64位的大多数实现是健全的。

至于什么时候64位操作系统将占多数，那么，这可能将是一个缓慢的，缓慢的过程。 最简单的方法是让芯片制造商全心全意转储32位处理兼容性。 这将迫使操作系统开发人员维护32位应用程序兼容性层，这样就可以以这种方式运行旧软件，但积极劝阻任何试图编写新软件的用户去32位。

如果Windows是您select的客户端操作系统，并且您的硬件具有来自制造商的强大的64位驱动程序支持， 并且已经完全testing。 我不认为你会看到重大的软件问题。

Vista 64位的32位软件模式相当不错，我一直在使用标准的应用程序（Office，VMWare，FireFox等）将它作为工作和家中的主要工作站使用近一年。痛点是我们的本地复印机/打印机支持打印机驱动程序，但在testing过程中应该find这些东西。

与所有的事情一样，你的里程可能会有所不同，你必须testing！ testing！ testing！ testing业务应用程序，testing您的外围设备和设备，并validation它们在64位操作系统上工作，但是您可以考虑在更换旧硬件时将其引入。

无论所有这些testing是否值得您花费时间，只有您可以做出决定，我们仅在使用系统需要时才部署64位客户端（例如，需要处理大量的RAM），但随着时间的推移会发生变化。

在工作站上运行非Windows 64位操作系统应该没有任何问题。 现在，Solaris已经有了一个64位的内核，而且大多数默认的linux安装也都是64位的。

不幸的是，对于Windows用户，许多供应商还没有创build或更新驱动程序来使用64位操作系统版本。 更具体地说，针对Win64的供应商主要针对服务器硬件，而不是工作站设备。

在我的实验室中，64位操作系统是绝大多数。 我们只有less数运行Linux 32位的（旧）机器。

该实验室是用来操纵图像和video，在大学的环境，一切工作正常。

这是一个罕见的应用程序，在64位Vista的32位模式下运行不正常。 确保你testing和确定问题到底在哪里。 如果只有less数人需要使用它，则可以使用VirtualPC或其他虚拟化机制来让less数人工作。

还要看看Windows 7和Windows 7 Professional的XP模式。 如果您可以稍微等一下，那么应该允许您以XP模式运行32位应用程序，而系统的其余部分以32位运行。 这假设司机不是问题。 除非您使用的是非常旧的或非常专有的硬件，否则应该提供64位驱动程序。

我的经验是在64位的Windows操作系统上，所以我只会把我的陈述限制在他们的身上。

我遇到的唯一问题是几个客户，他们仍然在使用一些16位软件（一些旧的税务软件，一些相对较新的，但显然还是16位的土地所有权软件，还有一个DOS应用程序与机床接口）。 16位代码根本不能在Win64下运行，为了在Win64操作系统上运行16位代码，您必须使用虚拟机（虚拟PC，VMware Workstation / Server等等）。

除此之外，迁移到x64已经非常平静。

就个人而言，我有一些挫败感，运行Windows 7 x64，并尝试使用VMware Server 1.x（我讨厌2.x版本）和OpenVPN。 这两个应用程序都使用内核模式驱动程序，Windows 7将不会运行，直到我启动时禁用了驱动程序签名validation。

免责声明：以下评论适用于我在Windows平台上使用的内容。

也许这就是我所使用的，但是如果使用的是64位版本的XP（不，我不会使用Vista），我使用的许多应用程序（如果不是绝大多数的话）将无法正常运行。 有人可能会认为，我应该升级应用程序，但我看到它的方式，我已经支付了我所拥有的版本，并且完全满意我的版本，那么为什么我应该花费大量的金钱升级64位我很less，如果有的话，受益？ 在某些情况下，我可以在其他人的计算机上试用64位版本的软件，但从未观察到性能上的显着差异。