初探Windows 7 POSIX子系统

Windows Internals 5e第二章开头提到了1989年Windows NT最初设计时的设计要求,其中倒数第二条是:

Meet government requirements for POSIX 1003.1 compliance

Windows NT一直提供了POSIX子系统,但是在最近的若干版本中,一直没有默认安装上。

要在Windows 7中安装,第一步是在“打开或关闭系统功能”中选中“基于UNIX的应用程序子系统”一项,如图所示:

setup0

稍等过后,我们就可以使用基于Windows NT的POSIX子系统的POSIX应用程序了。...好拗口,不过咱还是得稍微提醒一下,就算使用POSIX的库,但是如果不是使用基于Windows的编译器,还是没法运行的。从这个角度说,POSIX子系统也就是方便了UNIX应用程序到Windows的移植罢了。顺便提一下,Windows的POSIX子系统是基于POSIX.1(IEEE.Std 1003.1-1990;ISO/IEC 9945-1:1990)的.我们不妨稍微看看POSIX子系统给我们带来的新组件:

sua

其中,%SystemRoot%/System32/psxss.exe是POSIX子系统的环境子系统进程的映像,其地位就像csrss.exe之于Windows子系统一样。psxss.exe将会在系统首次运行POSIX应用程序的时候启动,其生命周期一直截止到系统关闭为止。psxdll.dll就是POSIX库文件,对POSIX库的调用最终都将落到它的手中。...不过它的主要任务其实是将POSIX系统调用转换为Windows系统调用,再调用Windows子系统的相关功能来完成任务。毕竟是Windows的地盘,有道是强龙难压地头蛇,更何况这地头蛇的能耐还不输强龙呢。再看那个%SystemRoot%/posix.exe,它将会成为POSIX子系统的会话管理进程,只要有任何POSIX应用程序运行,它就会存在;而如果所有POSIX进程都已经终结,这个进程也会被杀死。

但是现在我们还是不能自行编写POSIX应用程序,也不能像在Unix中一样使用C Shell和Unix Perl,这些都是需要额外下载的。微软提供了Utilities and SDK for Subsystem for UNIX-based Applications,其中包含了一系列源于SVR-5和BSD的实用程序和命令,开发所需的头文件和库,以及一套Unix Perl(呃...ActivePerl的Windows版本和Linux版的Perl咱也有...咱都快变成Perl收藏家了...),还有Visual Studio调试插件(windows 7的版本是for Visual Studio 2003/2005/2008的,不支持2010;Vista的版本不支持2008)。

现在在开始菜单中应该已经有Subsystem for UNIX-based Application子菜单了。展开它看看,一共有两个菜单项:Download Untilities for Subsystem for UNIX-based Applications和What’s new in Subsystem for UNIX-based Applications两项。Download Untilities for Subsystem for UNIX-based Applications就是指向Utilities and SDK for Subsystem for UNIX-based Applications下载页的链接——不过是Windows Server 2008和Windows Vista的版本-_-|||请使用What’s new in Subsystem for UNIX-based Applications首页上提供的链接(最终会指向http://www.microsoft.com/downloads/details.aspx?FamilyID=dc03485b-629b-49a6-b5ef-18617d1a9804&displaylang=en)下载基于Windows 7和Windows Server 2008 R2的版本——不只是版本更新,体积也变得小多了,由450M左右下降到了250M左右(说起来Windows SDK的体积也由Windows Vista的1.5G下降到了700M左右了,挺厉害的啊...)

现在开始菜单中应该已经有了更多选项了:

post-install

嗯,除了超链接和帮助之外就全是我们刚刚装上的那些工具中的Shell那部分了。微软为POSIX子系统提供了数百款来源于UNIX的工具可以使用,而这些工具都是基于Windows POSIX子系统直接使用GNU原生的代码编译的。可以说这几百个工具也是Windows POSIX子系统对于POSIX.1提供的良好支持的明证...只是,那个版本实在是太旧了...上一个图对比一下微软为POSIX子系统提供的vim工具和opensolaris 2009.06当中提供的vim工具:

vi

由图可见,微软提供的还是14年以前的版本呢。虽然不是不能理解,不过微软对这个POSIX子系统还真是不上心啊...

注意,启动Shell(我用的是C Shell)之后的当前目录好像是当前用户的目录...确实是UNIX的风格的说...可以输入cd /跳转到根目录下。输入ls -l看看~哈哈,充满UNIX风格的目录列表呈现在面前。不过,这些目录都是原原本本的Windows目录,而根目录其实就是你在安装Untility and SDK for SUA时选择的目录。正因如此,你会发现所有目录的owner竟然都是Windows的用户组:

rootDir

如果要通过POSIX子系统造访Windows的文件系统,请先进入/dev/fs下。该目录下面的虚拟目录,就是你的Windows磁盘驱动器的映射。提醒一下,UNIX是区分大小写的哦。

 

微软为POSIX子系统提供了两套GCC,分别是3.3和4.2.0...呃,后者还是GCC第一个支持OpenMP的版本。我们不妨试着编译UNIX-Only的程序看看。话说我对UNIX编程实在不太擅长,因此就写一个简单的fork好了。

隐藏行号 复制代码 Test1.c
  1. #include <unistd.h>
  2.  #include <stdio.h>
  3.  int main(int argc,char **argv){
  4.     if(fork())
  5.         printf("This is parent process.\n");
  6.     else
  7.         printf("This is child process.\n");
  8.         
  9.     return 0;
  10. }

然后输入如图的命令,别忘了修改成自己的路径,然后就可以执行看看了。写代码当然可以使用vi了,不过我用的是UltraEdit。别忘了保存的时候将编码选成ASCII,把换行符选成UNIX样式咯。

compPro

 

OK,这样就运行出来了。话说,gcc的反应好象比在OpenSolaris里面慢一点啊。就这么抵触微软吗?

不过这里编译出来的应用程序,自然是没法在UNIX操作系统下运行的。相反,只要给它加上个exe后缀,就可以像平常运行Windows应用程序一样通过POSIX子系统运行它。作为本文的结束,我们来做一个小小的实验:

首先,稍微修改一下刚刚的代码:

 

隐藏行号 复制代码 Test1.c
  1. #include <unistd.h>
  2.  #include <stdio.h>
  3.   
  4. int main(int argc,char **argv){
  5.     if(fork()){
  6.         printf("This is parent process.\n");
  7.         for(;;);
  8.     }
  9.     else{
  10.         printf("This is chile process.\n");
  11.         for(;;);
  12.     }
  13.         
  14.     return 0;
  15. }
  16.  

使用GCC编译这段代码并将编译所得的程序修改为exe后缀,随后关闭所有的POSIX进程。找一个好用一点的进程监视软件(推荐Sysinternals的Process Explorer),看看现在的进程状况。大致应该如下所示:

pe1

需要注意的是posix.exe进程已经不存在了。回想前文所述,posix.exe是POSIX的会话进程,没有posix.exe也就间接说明了没有POSIX应用程序正在运行。

现在我们启动刚才编译的程序,现在Process Explorer的界面应该如下所示:

pe2

嗯嗯,我们的程序和它fork出的子进程正在高高兴兴地运行着,因为我们在程序中添加了死循环所以进程不会立刻退出,而是像没有出口的自旋锁一样饕餮着CPU资源...嗯,这些都不重要,重要的是posix.exe的重回人间——在上面的截图中就是那个pid为5556的进程。现在,只要我们在运行着test1.exe的Shell中按下Ctrl+C,test1.exe父子就和posix.exe先生一起去进程天国报到了^^

 

(顺便插一句题外话,.Net Framework 4的TPL中好像有提供SpinLock结构支持自旋锁的功能,虽然使用自旋锁的花销会比较小,但是请谨慎使用这个结构,尤其是不要用于可能发生长时间锁定的操作——否则会发生什么,请参见上图骤然上涨的CPU使用率曲线...毕竟自旋锁就是通过循环实现的,不同于互斥锁,自旋锁会一直处于忙等的状态,直到时间片结束,然后是下一个时间片...下下个时间片...)

posted on 2010-04-25 20:27  snakealpha  阅读(14027)  评论(3编辑  收藏  举报