WINDOWS 和 LINUX 的系统层次比较

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

刚毕业的时候,做了将近一年的Window下的程序开发,主要用MFC,那是也不明白程序在操作系统角度从上到下的整个调用层次。遇到调用库函数,不明白,就查MSDN,每个月1500行代码左右,那是以为这就是软件开发了。后来跳槽的另外一家公司,工作也是Windows下的程序开发,这里可以用到多线程、COM组件,还能用到涉及模式,那是高兴的不得了。刚开始用到多线程,就买了一本书《WIN32多线程程序设计》,边学边用。

创建线程有好几种方法,比如:CreatThread 和_beginthread()等,记得当时不明白这几种方法有何区别,就随便拿一个用。心中有疑问:怎么创建一个线程这么多函数?WINAPI、CRT、MFC 到底有何关联?最近读《程序员的自我修养》一书,给了我明确的答复。参考下图:

创建线程函数分属不同的层次/类库,如下:

1.WINAPI:CreateThread();

2.CRT: _beginthread(); 和_beginthreadex();

3.MFC AfxBeginThread();

从上图可以看到,CRT和MFC函数最终都是调用WINAPI来实现的。即CRT和MFC库函数都是对WIN API的封装。

Linux下应用程序调用层次如下图:

上图只是列出了CRT,当然也存在其它很多类库,比如Linux下的线程库QT,也是对系统调用的封装。

从Windows和linux程序调用层次图,我们可以看到有如下区别:

Linux下可以直接进行程序调用,而Windows下不能直接进行系统调用。即Windows下的系统调用接口微软并没有开放给developer, 而是在系统调用上面添加了一层WINAPI。至于微软为什么不开放系统调用,而添加一层WINAPI,诸位可以参考《程序员的自我修养》第12章的12.3.2。Windows API是以DLL 导出函数的形式暴露给developer的,核心DLL有kernel32.dll、user32.dll和

gdi32.dll. 我们可以用dumpbin /EXPORTS *.dll命令来查看每个dll的导出函数。

根据以上2个图,来简单谈一下跨平台编程。大家知道windows下的应用程序.exe放到Linux下是不能运行的,反之,Linux下同样不能运行Windows下的程序,就相当于用PDF Reader 打不开Word文档一样,大家知道Windows

下的可执行文件是PE文件格式,Linux可执行文件下是ELF文件格式。

我们程序员写的代码,用Windows下的编译器连接器(cl,即VC++编译链接器)编译连接后,生成的目标文件是PE文件格式,同样的代码在Linux下用编译器gcc编译,链接器ld链接,生成的目标文件是ELF文件格式。同样的代码在不同的平台下编译通过的前提是代码中的函数符号(Symbol)能够被正确识别,这里我们不得不提及CRT,即C Runtime, Windows下是MSVCRT, Linux下是glibc (GNU C Library). C 语言运行库至少包含如下功能:

1.程序的启动和退出;

2.标准函数, 既是C语言标准库;

3.I/0

4.堆heap 的封装和实现;

5.调试

我们主要关注第2点:标准函数,即只要代码中我们调用函数都是C语言标准库函数,这些函数代码在Windows和Linux下是都能识别的,因为glibc和MSVCRT都在各自的平台上实现了这些函数,简单的讲就是: 提供给developer 的函数接口遵从C标准库,下层实现调用各自系统的系统调用。如果你调用MFC 库中的函数,这些函数Symbol在linux下是无法识别的。所以我们在写跨平台C 代码时(我们这里不讨论JAVA), 一定要调用标准C库函数,这样完成的代码就可以在Windows和Linux下用各自的编译器链接器编译链接(备注:包含的头文件不同,因为MSVCRT和glibc导出c库函数头文件不同),生成的目标文件就可以在各自的系统上运行。

相关文档
最新文档