LINE: run elf in windows

转自http://www.cnblogs.com/gussing/archive/2009/10/30/1593187.html

最近有那么一个想法，要开发一个东西叫LINE。我们都知道linux上有一款很牛逼的软件叫WINE（WINE Is Not Emulater)，可以在linux上运行windows程序。LINE（LINE Is Not Emulater）就是WINE的反面，让linux程序在windows上运行。http://gussing.cnblogs.com/

WINE之所以可行是基于这么一个事实：windows程序都是建立在windows API基础之上的，ntdll.dll, kernel32.dll, user32.dll等api把windows系统调用全部封装起来，基于API的应用程序可以完全不知道内核的细节。WINE就干了两件事情：1.开发一个PE loader可以load windows程序，2.开发一整套windows api供windows程序使用。据我所知，WINE牛逼到了绝大多数windows API都已经实现的程度。WINE的大体架构如下:http://gussing.cnblogs.com/

后来又出现一个叫“兼容内核”的项目，他们打算把WINE代码里有系统调用的部分全部移入内核。我们知道linux系统调用和windows系统调用是不可能一一对应的，比如说NtCreateProcessEx系统调用想在linux上实现，可能会有不止一个linux系统调用。倘若把windows系统调用直接在linux内核里实现，那么次数就会减少到1，效率就会提高。另外，用户态很难办到的一些事情在内核态内核导出函数的帮助下，也会变得相对容易些。有兼容内核之后的大体架构如下：http://gussing.cnblogs.com/

如上图所示，兼容内核修改了WINE DLL, 把“用linux系统调用模拟windows DLL”的机制换成了"在linux上打通int 2e，模拟出原生windows DLL”。http://gussing.cnblogs.com/

而LINE之所以（被我认为）可行，是基于这么一个事实：大多数linux程序都是基于glibc之上的，与windows api类似，glibc包装了linux的系统调用，如果可以把linux系统调用界面实现一遍，那么glibc应该就能运行在windows上，相应的大多数*原生*linux程序也可以在windows上运行。http://gussing.cnblogs.com/

 这里不得不提一款几乎类似的程序：cygwin。cygwin在windows上模拟了glibc的功能，叫做cygwin1.dll，通过port到windows上的gcc.exe把带源代码的linux程序都重新编译一遍，也做到了在windows上运行linux程序，如下图所示：http://gussing.cnblogs.com/

大体架构和WINE有异曲同工之妙，但是也有很明显不一样的地方，那就是cygwin运行的是PE格式的linux程序，省掉了做elf loader的麻烦。为什么WINE不编译一套elf格式的windows程序呢？很简单，因为没有源代码。http://gussing.cnblogs.com/

最后讲一讲我预想中LINE的架构：http://gussing.cnblogs.com/

如上图所示，先得有一个elf loader，把原生linux程序load进程空间里，原生linux程序要和glibc打交道，所以也要把glibc load进来。glibc有两部分，一部分在用户态就能做完，一部分需要通过系统调用进入内核，所以LINE里有一个内核态驱动，实现了int 80系统调用的支持。linux里有300多个系统调用，我一个人全部做完是不可能的，且不说时间不够，有些调用根本困难的要命，所以系统调用例程被分为两部分：一部分在内核里实现，一部分未实现。未实现的部分就用APC弹回到用户态，从cygwin1再走一遍。

如此一来，LINE就和WINE一样，可以执行*原生*linux程序了。其实最开始我还想着另一种路径，那就是直接修改cygwin让它走int 80 路径，这么一来glibc相关的一系列讨厌的问题（相信我，还真是很多很讨厌）都可以避免的，还可以最大限度利用已有资源。不过这条路径少elf loader和runtime lib，能学到的东西就会少很多，所以被我否掉了。http://gussing.cnblogs.com/

LINE这个项目我一直是利用业余时间在做，不知道能到什么程度。有时候想想，连我自己都很期待呢哈哈。