当然部分评论员会对这些增强功能不以为然，还有一些人把View4.5发布推迟的现象跟将来的VMware客户端虚拟化联系在一起，虽然它们在VMware内部是完全不同的开发项目。

　　我是根据Office of the CTO VMware博客上的相关内容来看待该项目的。下面摘录了VMware桌面产品组产品经理Scott Davis的原文：

　　1类客户端虚拟化是一项非常有趣的技术，现在依然处于实验室阶段。不过，它无法独立达到我们客户所追求的，在设备选型、集中管理和复合桌面花销等方面可以获得的优势。请参考Divis的全文回复。

　　尽管VMware没有放弃对客户端虚拟化的开发和测试进程，但是他们对于该产品的市场需求并不自信。笔者对本地桌面和客户端虚拟化两者的实际应用还是有怀疑的。我认为这不算什么大事，在我的客户中很少有对VMware缺少客户端虚拟化而抱怨的，也没有多少人对本地桌面功能的推出而欢欣鼓舞。

　　虚拟桌面在本地的运行是需要物理机适当的RAM和CPU资源来支持的。假设虚拟桌面是分配了4GB内存和2个vCPU的Windows7系统，它虽然可以在带有72GB内存的8路宿主服务器上良好运行，但是在只有2GB内存的本地笔记本是完全支持不了的。

　　VDI的核心思想是把桌面系统跟本地硬件脱离，使其集中到高安全和高带宽环境的数据中心。

　　既然有各种办法可以实现移动办公，为什么还非要本地桌面功能呢？例如，我是在伦敦西斯罗机场的候机厅，用苹果笔记本写的这篇文章。Wi-Fi的费用太高了，所以我只需离线撰写文章，然后在到达旧金山之后再发布。很明显，在带宽较差的情况下，我们需要本地运行应用程序。

　　ThinApp的增强

　　View和ThinApp的集成是VMware另一改善重点。

　　ThinApp没有真正的安装过程，除非您的部署过程是通过MSI或者是Microsoft Group Policy Object策略软件来完成应用的推送。View4.5增加了对ThinApp的支持，可以通过把ThinApp上传到集中存储应用的区域，然后根据策略分发到正确的桌面。

　　但是这种部署方式仅限于ThinApp和View。如果我们需要把ThinApp推送到传统桌面PC该怎么做呢？

　　ThinApp宣称所有的应用都是独立的.exe文件可以单独运行，无需安装和维护agent或者是client软件。这样的做法极具吸引力，当然也有一些缺陷。由于缺少客户端，限制了ThinApp的安装过程无法被Windows这样的子操作系统感知。当然，很多用户会非常排斥在他们的桌面安装代理程序这样的接收器，他们认为这样的做法相当于给虚拟机安装了后门程序。

　　独立运行的ThinApp具备强大的便携性和兼容性，但是它缺少诸如微软的App-V这样基于客户端程序的部分易管理性。ThinApp的设置和选项保存于Windows的3-style .INI文件中。除了文本编辑器和安装脚本之外，赋予ThinApp管理员更高权限可以部分缓解这些问题。例如，包含大量的实时项目管理工具，从而可以在一个单独的界面中显示所有的ThinApp配置，并且把这些高级配置功能以图形界面呈现出来。通过可选的agent，VMware可以允许ThinApp管理员，在独立于View之外的AD用户或组成员范围内，推送所需的应用程序。

　　ThinApp经过了很多的改变。它可以在Windows 7和Windows Server 2008 R2支持虚拟的IE 6。这是微软的App-V无法实现的。

　　另外，VMware引入了可以把特殊URL重定向到本地浏览器的ThinDirect功能。因此当用户点击超链接后，浏览器可以打开正确的页面。另外，加入AppLink功能增强了ThinApp 4.6跟其它旧版本软件之间的互操作性。最后一点，ThinApp Converter可以批量地把多种.MSI文件转化为可以供虚拟机使用的ThinApp文件。