syswow64
有时候人们怀疑一个系统的底层结构能否保证这个系统在被使用时达到安全而高效，64位版本的windows在这方面就比较完美。Windows XP和Windows Server 2003都是运行64位硬件的64位版本操作系统。64位Windows操作系统运行64位代码，同时通过使用WoW64(Windows on Windows 64)也能运行32位代码。
你看，这并不是什么大问题，毕竟，32位版本的不同Windows操作系统都用来同时运行32位和16位代码。(技术上说，并不是同时运行，相关解释在以后的技巧中会展示给大家)
32位版本的Windows在如何允许32为和16位代码并肩运行方面有着很复杂的机制。然而，这个系统被设计成无论你是系统管理员还是临时用户，你都不需要知道这些机制如何运行。
但是64位版本的Windows就不同了。从一个用户的立场上看，64位应用程序和32位应用程序简单地同时运行，没有什么特殊的。但是对于一个管理员(和帮助桌面用户的人员)来说，这其中就有很大不同了:32位代码与64位代码相隔离。这个隔离是如此重要以至于64位版本的Windows有两个注册表，一个是针对64位，一个是针对32位。
尽管64位版本的Windows XP和Windows Server 2003看起来在操作时候和它们32位的版本几乎同样的，但是在表象之下其实是有很大不同的。如果你在64位版本的Windows下按照32位版本一样来执行某些程序，你可能引起一些麻烦。
DLL 存放到何处?
64位应用程序的第一条规则是:你绝对不能把32位和64位代码混和在同一个应用程序内。如果你有一个64位应用程序，所有与这个应用程序相关的东西，包括DLL文件，必须是64位的。这就有一个有趣的挑战，因为有时候很多应用程序都依靠一个共同的DLL文件。幸运的是，Windows保持32位的DLL文件和64位的DLL文件处于隔离状态。
如果你查看一下在32位操作系统内的\Windows文件夹，你会发现两个子目录:一个名为SYSTEM，还有一个名为SYSTEM32。SYSTEM目录是Windows 3.x遗留下来的，用来保持Windows的对一些旧的应用程序的向下兼容性。一般说来，16位的DLL文件(以及其它的支持文件)被存放在\Windows\System文件夹里，32位DLL文件和不同支持文件被存放在\Windows\System32文件夹里。
32位版本的Windows保持16位和32位DLL文件的方式是非常简单的，但是64位版本的Windows保持64位和32位DLL文件的方式就不这么简单了。
理论上说，微软将要创建一个名为\Windows\System64的文件夹来用其存放64位DLL文件，但是取而代之的是，微软创建了一个新的名为syswow64的文件夹来存放32位的DLL文件。第一眼看起来，让人感觉这个文件夹应该存放64位应用程序的，但是注意，32位应用程序本来应该存放它们的DLL文件到\Windows\System32文件夹里面。
\Windows\System32文件夹在64位版本的Windows内仍然存在。但是微软使用这个文件夹做为64位DLL的仓库，而不是32位DLL文件的。我不清楚微软使用\Windows\System32文件夹来存放64位DLL的原因，但是我听说这么做是为了向下兼容性。
那么是不是所有32位应用程序该存放它们的DLL文件到\Windows\System32文件夹呢?这又让事情变得混乱。
如我之前所提及的，32位代码不能默认在64位版本的Windows内运行。为了运行32位的应用程序，Windows使用WOW64 emulator，来让这些应用程序还认为它们在32位版本的Windows内运行。
当你安装一个32位的应用程序，安装向导通过WOW64 emulato运行。32位和64位代码并不混和。一旦一个应用程序(包括一个安装向导)从WOW64 emulator开始运行，它必须接着在WOW64内继续运行。这意味着当你安装一个应用程序，安装向导并不知道这个程序被安装到64位版本的Windows内，并且和它运行在32位操作系统一样把DLL文件写到\Windows\System32文件夹里面。
当然，WOW64知道安装向导通过emulator来运行的32位应用程序。同时也知道64和32位代码不能混合在一起。所以，WOW64 emulator 给\Windows\SysWOW64创建一个别名。这意味着任何时候32位应用程序要写入到\Windows\System32文件夹或者从\Windows\SysWOW64文件夹读取，WOW64 emulator都能使其改道到\Windows\SysWOW64文件夹。
所有这些都意味着如果你需要手动操作\Windows\System32文件夹内的内容，你可能要非常的麻烦。我最近了解到一个管理员需要安装一些小的支持脚本到一个已经安装的应用程序，这个脚本的指导上说明这些脚本需要被存放到\Windows\System32文件夹。当然这些脚本的说明假定这个应用程序是在32位操作系统上运行的。
这些脚本没有引起系统崩溃。然而Windows给人幻想永远不用进行更新。当管理员运行应用程序，它将被改道到\Windows\SysWOW64文件夹。管理员知道他自己把这些脚本放到\Windows\System32文件夹并且能通过Windows浏览器看到这些脚本，但是不能指出为什么应用程序不能看到这些脚本。考虑到这个问题是和权限相关的，他花费了一些时间来研究这个，所以知道了关于64位版本的Windows保存DLL文件隔离的方法，所以他能够把这些脚本放到\Windows\SysWOW64文件夹。
64位版本的Windows对于一个管理员来说，了解底层系统结构非常重要。
---------------------------------------------------------------------------------------------------------------------
本人问题：拷贝脚本把dll拷贝到system32,发现自动到了SysWOW64!
有点无语，最后把dll放在自己程序目录下了，没有在撕这个问题。
文章最后发布于: 2018-11-05 10:14:50
相关阅读
（未完待续） 访问系统和硬件信息。使用这个类可以了解底层平台和硬件的功能。例如，您可以检查支持哪种RenderTexture格式(SupportsRen
无意间发现C32ASM的启动和Server服务有关，刚好今天我看了网上的win7系统优化的文章，也就按照上面的方法优化系统，由于server服务和共
转自：http://blog.sina.com.cn/s/blog_6b8bd9d80101fe8t.html在对新写的超快xml解析器和xpath引擎进行效率测试时，为获取执行时间，开
System.currentTimeMillis()计算方式与时间的单位转换
一、时间的单位转换1秒=1000毫秒(ms) 1毫秒=1／1,000秒(s) 1秒=1,000,000 微秒(μs) 1微秒=1／1,000,000秒(s) 1秒=1,000,000,000 纳
Pizza的脚本中是通过get_bytes和patch_bytes两个API来将所有机器码读出然后再Patch回去的中间匹配pattern的过程是构造字符串然后