来源：
下一代Shell脚本语言，Windows Power Shell!
作者：
Zealic
今天回家照常浏览了下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 来输出
::ForegroundColor = ::Blue
::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 的距离在拉近。
Source:
Next Generation Shell Scripting Language, Windows Power Shell!
Author:
Zealic
Today, I went home and browsed cnbeta.com as usual to see what new content there was.
Then, I saw that there was such a
Windows Power Shell 1.0
Well, I'm very interested in this thing. After all, the current Shell of Windows is really too weak. Immediately, I
downloaded from the Microsoft site, installed it. I found that it was released in the form of a patch package, not a regular MSI. Then, I estimated that Vista already came with this thing.
Next, I will try to understand PowerShell (referred to as PS below)
After the installation is complete, open the program menu. It seems that M$'s old habits are still well maintained, and the help is very detailed
Release Notes
Quick Reference
Getting Started
User Guide
Other details are not elaborated.
After reading the document, I found that an important point is that PS is written in .Net and fully supports any object of .Net.
.Net! What?
Take out the Dragon Slaying Sword Reflector to open all the DLLs in the main program and directory of PowerShell. It failed: the CLR header is invalid, and none of them are decompiled correctly. Isn't it said that PS is written in .Net? How... Is M$ fooling us?
Then how does it operate .Net objects?
Then again, take out PE Explorer to open the main program of PS and look at its API imports. I found that the main program of PS.
Referenced the function
CorBindToRuntimeEx of mscoree.dll
MSDN explains CorbindToRuntimeEx like this: It enables unmanaged hosts to load the common language runtime into the process.
This shows that PS executes the necessary initialization with unmanaged code before running, and then enters the CLR. It may also be to establish a mixed environment to facilitate the interactive execution of managed and unmanaged code; then, where is the host program?
Use the search function of Windows to search for the keyword "PowerShell", but it failed. All the found ones are things in the program directory!~~~
After thinking carefully, I decided to start from the root. The Windows patch program is packaged with CAB, so it can be opened directly with WinRAR. Open WindowsXP-KB926140-x86-CHS.exe with WinRAR, and found the thing I need "_sfx_manifest_". Open it in text format to view, and found some things I need:
"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"
......
This fully shows that the host program exists. It is Microsoft.PowerShell.ConsoleHost.dll. Then, why can't I find these files?
Considering again, I think these things may be in the GAC. Open the GAC directory to view; Ha, they are all there?
But there is still a problem with Reflector! Reflector can't find these assemblies~~~, and using Open Cache can't find them either!!!
No way, just extract the files from the patch package. After extracting them and opening them with Reflector, I was stupid. "File is not a portable executable. DOS header does not contain 'MZ' signature." The file header is incorrect. Open it with Notepad and find that the file header is actually "PA19". What format is this? Why have I never seen it before? Native code generated by NGEN? Or encrypted Managed DLL?
Don't care about this for now. Find other ways to get the assemblies in the GAC.
The GAC directory has been taken over by a Shell Extension. So what I need to do now is to get the files in the directory out. I tried dialog boxes and copying folders one after another, but it didn't work. Finally, I solved it with a command line:
xcopy /e C:\Windows\assembly\GAC_MSIL G:\GAC_MSIL
Then look for the required assemblies in the copied directory. Ha, now we can see the code of PS. This will be a very pleasant thing.
In addition, through the _sfx_manifest_ file and Reflector analyzing the assembly references, I found that there is an additional assembly "System.Management.Automation.dll", and its EXE comment is "Microsoft Command-Line Shell Engine Core Assembly"
I packaged these extracted assemblies and uploaded them. Click
here to download. We can analyze its code with Reflector, or package it together with the main program of PS for XCOPY deployment, and use it as the script system of the product.
Here, we have all the code assemblies. Let's see what exactly PowerShell is and what it can do:
Due to the following reasons, Windows PowerShell uses its own language instead of reusing the existing language:
•Windows PowerShell needs a language for managing .NET objects.
•The language needs to provide a consistent environment for using cmdlets.
•The language needs to support complex tasks without making simple tasks more complicated.
•The language needs to be consistent with advanced languages used in .NET programming, such as C#.
Some characteristics of the PS language:
1. Some characteristics of advanced languages (variables, arrays, operators, hash tables, functions, conditional statements, loop statements...)
2. Can directly navigate in the file system, registry, certificate store, and drive, and the navigation method is very similar to the DOS navigation method we are familiar with.
3. Powerful wildcard and string search functions
4. Can create and operate .Net objects and COM objects
5. Can use any object (including .Net and COM objects) to interact with the target based on the object pipeline function
7. Can directly access WMI objects.
8. Can write .Net assemblies to extend PS. Through extension, the functions of PS can be expanded almost infinitely.
For other characteristics, please refer to the help document of PowerShell.
Common commands:
Get-Date - Get the current date.
Get-Help - Get help.
Get-Member - View the object structure (can use this command to view the members of .Net objects).
Get-WmiObject - Get WMI objects.
Get-Process - Get process objects.
Get-Service - Get Windows service objects.
Now it's dark and the wind is high, urging people to sleep. I can only wait until tomorrow to continue the research. Finally, let's end with the classic Hello World. Tomorrow, we will come to further study PS:
Use the output command
Write-Output "Hello World!"
Use .Net to output
::ForegroundColor = ::Blue
::WriteLine("Hello World!")
It's really a powerful Shell!
PS:
I have always hoped that M$ can provide a non-graphical interface. It seems that the time is still early, but now it is developing in a good direction. PowerShell gives me hope. Maybe PowerShell is the prototype of the future non-graphical interface Server.
Therefore, I boldly predict that Vienna (the next OS after Vista, completely rewriting the kernel) will separate the kernel and the graphical interface, rather than the current NT-based kernel, where the kernel and the graphical interface will be together. And there will be a non-graphical interface Server and the current graphical Server, and both will coexist for a long time. As for who will be replaced, I don't think it's possible.
Therefore, what I can imagine is that Microsoft will upgrade Windows PE to make it use the core of Vienna, and will include .Net Framework X.Y, and be divided into character interface and graphical interface. In this way, Windows PE will become an extremely handy system diagnosis and troubleshooting tool.
Windows Server is getting closer to Unix/Linux Server.
