初探Windows 7 POSIX子系统

xiguaqq20

　　Windows Internals 5e第二章开头提到了1989年Windows NT最初设计时的设计要求，其中倒数第二条是：
　　Meet government requirements for POSIX 1003.1 compliance
　　Windows NT一直提供了POSIX子系统，但是在最近的若干版本中，一直没有默认安装上。
　　要在Windows 7中安装，第一步是在“打开或关闭系统功能”中选中“基于UNIX的应用程序子系统”一项，如图所示：

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

　　其中,%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左右了，挺厉害的啊...）
　　现在开始菜单中应该已经有了更多选项了：

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

　　由图可见，微软提供的还是14年以前的版本呢。虽然不是不能理解，不过微软对这个POSIX子系统还真是不上心啊...
　　注意，启动Shell（我用的是C Shell）之后的当前目录好像是当前用户的目录...确实是UNIX的风格的说...可以输入cd /跳转到根目录下。输入ls -l看看~哈哈，充满UNIX风格的目录列表呈现在面前。不过，这些目录都是原原本本的Windows目录，而根目录其实就是你在安装Untility and SDK for SUA时选择的目录。正因如此，你会发现所有目录的owner竟然都是Windows的用户组：

　　如果要通过POSIX子系统造访Windows的文件系统，请先进入/dev/fs下。该目录下面的虚拟目录，就是你的Windows磁盘驱动器的映射。提醒一下，UNIX是区分大小写的哦。
　　
　　微软为POSIX子系统提供了两套GCC，分别是3.3和4.2.0...呃，后者还是GCC第一个支持OpenMP的版本。我们不妨试着编译UNIX-Only的程序看看。话说我对UNIX编程实在不太擅长，因此就写一个简单的fork好了。




隐藏行号 复制代码 ？ Test1.c

• 
  #include
  
• 
  #include
  
• 
  int main(int argc,char **argv){
  
• 
      if(fork())
  
• 
          printf("This is parent process.\n");
  
• 
      else
  
• 
          printf("This is child process.\n");
  
• 
  
• 
      return 0;
  
• 
  }
  

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

　　
　　OK，这样就运行出来了。话说，gcc的反应好象比在OpenSolaris里面慢一点啊。就这么抵触微软吗？
　　不过这里编译出来的应用程序，自然是没法在UNIX操作系统下运行的。相反，只要给它加上个exe后缀，就可以像平常运行Windows应用程序一样通过POSIX子系统运行它。作为本文的结束，我们来做一个小小的实验：
　　首先，稍微修改一下刚刚的代码：
　　




隐藏行号 复制代码 ？ Test1.c

• 
  #include
  
• 
  #include
  
• 
  
  
• 
  int main(int argc,char **argv){
  
• 
      if(fork()){
  
• 
          printf("This is parent process.\n");
  
• 
          for(;;);
  
• 
      }
  
• 
      else{
  
• 
          printf("This is chile process.\n");
  
• 
          for(;;);
  
• 
      }
  
• 
  
• 
      return 0;
  
• 
  }
  
• 
  

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

　　需要注意的是posix.exe进程已经不存在了。回想前文所述，posix.exe是POSIX的会话进程，没有posix.exe也就间接说明了没有POSIX应用程序正在运行。
　　现在我们启动刚才编译的程序，现在Process Explorer的界面应该如下所示：

　　嗯嗯，我们的程序和它fork出的子进程正在高高兴兴地运行着，因为我们在程序中添加了死循环所以进程不会立刻退出，而是像没有出口的自旋锁一样饕餮着CPU资源...嗯，这些都不重要，重要的是posix.exe的重回人间——在上面的截图中就是那个pid为5556的进程。现在，只要我们在运行着test1.exe的Shell中按下Ctrl+C，test1.exe父子就和posix.exe先生一起去进程天国报到了^^
　　
　　(顺便插一句题外话，.Net Framework 4的TPL中好像有提供SpinLock结构支持自旋锁的功能，虽然使用自旋锁的花销会比较小，但是请谨慎使用这个结构，尤其是不要用于可能发生长时间锁定的操作——否则会发生什么，请参见上图骤然上涨的CPU使用率曲线...毕竟自旋锁就是通过循环实现的，不同于互斥锁，自旋锁会一直处于忙等的状态，直到时间片结束，然后是下一个时间片...下下个时间片...)