今天回家照常浏览了下cnbeta.com，看看有什么新鲜的内容。
于是乎，就看到了那么一条 Windows Power Shell 1.0
恩，我对这个东西很感兴趣，毕竟Windows目前的Shell是在是太弱了，立马从微软站点下载，安装，发现其是以补丁包的形式发布的，并非常规的MSI，那么，我估计Vista已经自带了这个东西了。
下面将尝试了解PowerShell(以下简称PS)
安装完成后，打开程序菜单，看来M$老习惯还是保持的不错的，帮助很详细
发行说明
快速参考
入门
用户指南
其他不做细表
看过文档以后，发现比较重要的一点是，PS是用.Net编写，并且完全支持.Net的任何对象。
.Net！什么？
祭出屠龙刀 Reflector 打开 PowerShell的主程序及目录下的所有DLL，失败：CLR头无效，没有一个被正确反编译了的，不是说用PS是由 .Net编写的么？怎么...M$在忽悠我们？
那他是如何操作.Net对象的呢？
那么再来，祭出PE Explorer 打开 PS的主程序 看了下其API导入，发现 PS 的主程序。
引用了mscoree.dll 的函数 CorBindToRuntimeEx
MSDN是这样解释 CorbindToRuntimeEx 的 ： 使非托管主机能够将公共语言运行库加载到进程中。
这说明了PS在运行前是以非托管代码执行了必要的初始化，然后才进入CLR的，也可能是建立一个混合环境，方面托管和非托管代码交互执行；那么，宿主程序在哪呢？
用 Windows 的搜索功能搜索关键字 "PowerShell"，失败，找出来的全部是程序目录里的东西！~~~
仔细想了一下，决定从根源着手；Windows的补丁程序是使用CAB打包的，因此可以直接用 WinRAR打开，用WinRAR打开 WindowsXP-KB926140-x86-CHS.exe，找到了我需要的东西 "_sfx_manifest_"，用文本格式打开查看，发现了一些我需要的东西：
"microsoft.powershell.consolehost.dll" = "_sfx_0008._p", "powershell.exe"
"system.management.automation.dll" = "_sfx_0009._p", "microsoft.powershell.consolehost.dll"
"microsoft.powershell.security.dll" = "_sfx_0010._p", "system.management.automation.dll"
......
这充分说明了，宿主程序是存在的，它就是 Microsoft.PowerShell.ConsoleHost.dll，那么，为什么我找不到这些文件呢？
再考虑以下，觉得这些东西可能在 GAC 中，打开GAC目录查看；哈，他们都在那呢？
但是用 Reflector 仍然有问题！Reflector 找不到这些程序集~~~，用 Open Cache 同样找不到!!!
没法，就从补丁包里把文件解出来看吧，弄出来再用 Reflector 打开，傻了，"File is not a portable executable. DOS header does not contain 'MZ' signature."，文件头不对；用记事本打开看看，发现文件头居然为 "PA19"，这是什么格式的文件，为什么我从来没有见过？NGEN生成的本地代码？或者是加密过的Managed DLL？
先不管这个，找其他办法弄出 GAC里面的程序集好了。
GAC目录已经被一个 Shell Extension所接管了，那么现在要做的就是把目录里面的文件弄出来，我先后尝试了对话框，复制文件夹，未果，最后用一条命令行搞定了:
xcopy /e C:\Windows\assembly\GAC_MSIL G:\GAC_MSIL
然后在拷贝出来的目录中寻找需要的程序集。哈，现在我们可以看PS的代码了，这将是很愉快的一件事。
另外，我通过 _sfx_manifest_ 文件和 Reflector 分析程序集引用发现多了一个程序集 "System.Management.Automation.dll",其EXE备注为"Microsoft Command-Line Shell Engine Core Assembly"
我将这些解出来的程序集打包上传，点这里下载，我们可以Reflector分析他的代码，或者将他和PS的主程序一起打包用以实现 XCOPY 部署，用以做为产品的脚本系统。
到这里，我们已经把代码程序集都搞出来了，我们来看一下 PowerShell 到底是什么东西，能做什么:
由于以下原因，Windows PowerShell 使用它自己的语言，而不是重用现有的语言：
•Windows PowerShell 需要用于管理 .NET 对象的语言。
•该语言需要为使用 cmdlet 提供一致的环境。
•该语言需要支持复杂的任务，而不会使简单的任务变得更复杂。
•该语言需要与在 .NET 编程中使用的高级语言（如 C#）一致。
PS语言的一些特性:
1.高级语言的部分特性(变量、数组、运算符、哈希表、函数，条件语句，循环语句...)
2.能直接在文件系统、注册表、证书存储区、驱动器中导航，而导航方式和我们熟悉的DOS导航方式极相似。
3.强大的通配符和字符串搜索功能
4.可以创建和操作.Net对象 和 COM 对象
5.基于对象管道功能使用任何对象(包括.Net和COM对象)与目标交互
7.可以直接访问 WMI 对象。
8.可以编写 .Net 程序集来扩展PS，通过扩展，几乎可以无限的扩充 PS 的功能。
其他特性请参考PowerShell的帮助文档。
常见的命令:
Get-Date - 获得当前日期。
Get-Help - 获取帮助。
Get-Member - 查看对象结构(可用此命令查看 .Net 对象的成员)。
Get-WmiObject - 获取 WMI 对象。
Get-Process - 获取进程对象。
Get-Service - 获取Windows服务对象。
现在已经是月黑风高催人眠，只能等明天继续研究了；最后，我们以经典的 Hello World 来结尾吧，明天，我们再来进一步研究 PS:
使用 输出命令
Write-Output "Hello World!"
使用 .Net 来输出
[System.Console]::ForegroundColor = [System.ConsoleColor]::Blue[System.Console]::WriteLine("Hello World!")
真是强大的Shell！
PS:
我一直都希望M$能够提供一个无图形界面的，从目前看来似乎是时间还早了，但是现在是朝着好的方向发展，PowerShell让我看到了希望，说不定PowerShell就是将来的无图形界面 Server 的雏形。
所以，我大胆预测，Vienna(继Vista之后的下一个OS，完全重写内核)将会是内核和图形界面分离，而非现在基于NT的内核，内核与图形界面将凑在一起；并且将会有一个无图形界面的Server和目前的图形Server，两者将在很长一段时间内并存，至于谁会被取代，我觉得似乎是没可能了。
因此，我能想象的到的东西大概是，微软会将 Windows PE 升级，使其使用 Vienna 的核心，并且将会包含 .Net Framework X.Y，同时分为字符界面和图形界面。这样，Windows PE 将会成为一个极为顺手的系统诊断、故障排除工具。
Windows Server 在和 Unix/Linux Server 的距离在拉近。