操作系统与应用程序的关系
操作系统主要可以分为两大部分：内核和内核之外的一些程序。
内核就是直接控制最底层的硬件， 而我们日常所用到的软件， 大都是
通过内核之外一些程序与内核之间的接口完成的，例如 WINDOWS
API 就是为我们提供了应用程序与内核的接口， 以实现硬件上的一些
操作。操作系统（ Operating System，简称 OS）是一管理 电脑硬件 与
软件资源的程序， 同时也是计算机系统的内核与基石。 操作系统是一
个庞大的管理控制程序，大致包括 5 个方面的管理功能 :进程与 处理
机 管理、 作业管理 、存储管理、 设备管理 、文件管理。目前微机上常
见的操作系统有 DOS、OS/2、UNIX 、XENIX 、LINUX 、Windows、
Netware等。
应用软件是用户可以使用的各种程序设计语言 , 以及用各种程序
设计语言编制的应用程序的集合 , 分为应用软件包和用户程序 . 应用
软件包是利用计算机解决某类问题而设计的程序的集合 , 供多用户使
用。
内核系统与应用程序的关系
在 Linux 系统中，内核为用户程序提供了两方面的支持。 其一是
系统调用接口，即中断调用 int 0x80 ；另一方面是通过开发环境库
函数或内核库函数与内核进行信息交流。 不过内核库函数仅供内核创
建的任务 0 和任务 1 使用，它们最终还是去调用系统调用。 因此内核
对所有用户程序或进程实际上只提供系统调用这一种统一的接口。lib/ 目录下内核库函数代码的实现方法与基本 C 函数库 libc 中类似
函数的实现方法基本相同， 为了使用内核资源， 最终都是通过内嵌汇
编代码调用了内核系统调用功能。
系统调用主要提供给系统软件编程或者用于库函数的实现。 而一
般用户开发的程序则是通过调用像 libc 等库函数来访问内核资源。
这些库中的函数或资源通常被称为应用程序编程接口（ API），其中
定义了应用程序使用的一组标准编程接口。通过调用这些库中的程
序，应用程序代码能够完成各种常用工作， 例如，打开和关闭、 对文
件或设备的访问、 进行科学计算、 出错处理以及访问组和用户标识号
ID 等系统信息。
在 UNIX类操作系统中，最为普遍使用的是基于 POSIX标准的 API
接口。Linux 当然也不例外。 API 与系统调用的区别在于：为了实现
某一应用程序接口标准，例如 POSIX，其中的 API 可以与一个系统调
用对应， 也可能由几个系统调用的功能共同实现。 当然某些 API 函数
可能根本就不需要使用系统调用， 即不使用内核功能。 因此函数库可
以看做实现像 POSIX标准的主体界面， 应用程序不用管它与系统调用
之间到底存在什么关系。 无论一个操作系统提供的系统调用有多么大
的区别， 但只要它遵循同一个 API 标准，那么应用程序就可以在这些
操作系统之间具有可移植性。
系统调用是内核与外界接口的最高层。 在内核中， 每个系统调用
都有一个序列号（在 include/unistd.h 头文件中定义），并且常以宏的形式实现。应用程序不应该直接使用系统调用，因为这样的话，
程序的移植性就不好了。因此目前 Linux 标准库（Linux Standard
Base，LSB）和许多其他标准都不允许应用程序直接访问系统调用宏。
库函数一般包括 C 语言没有提供的执行高级功能的用户级函数， 如输
入/ 输出和字符串处理函数。 某些库函数只是系统调用的增强功能版。
例如，标准 I/O 库函数 fopen 和 fclose 提供了与系统调用 open 和
close 类似的功能，不过是在更高的层次上。在这种情况下，系统调
用通常能提供比库函数略微好一些的性能， 但是库函数却能提供更多
的功能，而且更具检错能力。
实际上软件程序还可以细分成两种： 系统程序软件和应用程序软
件。系统程序软件实际上就是我们所说的驱动程序， 它们的目的只有
一个，就是为了驱动硬件，使之能正常地完成某种硬件功能，比如网
卡的发送数据功能， 声卡的播放声音功能。 应用程序软件则用来接收
用户的输入请求， 进行很多业务运算后， 再通过驱动程序驱动硬件去
完成用户所要求的任务， 有时候应用程序软件也负责把运算的最终结
果反馈给用户。画成图就是图一那样，注意， 在整个软件系统中，也
只有驱动程序最清楚硬件的功能及工作方式， 如果上面应用程序想要
硬件完成什么样的任务， 必须使用相应的驱动程序所提供的那些接口
才行。 驱动程序直接驱动硬件进行工作， 而应用程序则只需要知道这
些接口， 通过它们间接去驱动硬件来完成任务。 这种策略看似简单好
用，但也会受到两方面因素的制约。图一
首先， 一个计算机系统里面的硬件设备通常不会只有一个。 比方
我的魅族 MP3里除了音频解码器外，自然也有用来存储歌曲的设备。
这些设备各具不同的功能， 完成这些功能的操作也就各不相同， 就决
定了写出来的驱动程序也是各式各样的， 最后导致他们提供给应用程
序使用的接口也是千变万化的， 如图二那样， 用不同颜色的箭头表示
不同的接口使用。 这大大增加了应用程序开发的难度， 因为应用程序
开发者不仅要考虑上层业务逻辑的处理， 还要非常熟悉各种驱动所提
供出来的不同接口。
图二: 一个应用使用多个硬件设备
其次，一个计算机系统里面同时运行着的应用程序通常也不会只有一
个，这些应用程序会竞争使用总量特定的硬件设备资源。 比方你和朋
友在用qq聊天的同时， 也听着千千静听放出来的音乐， 他们都要使用
屏幕设备 show出界面，也都要使用物理内存 (2)来运行程序代码。但
是屏幕只有一个， 内存也只有那么多， 所以在整个计算机系统范围内，
必须有某种机制来管理分配这些特定硬件资源的使用。 如图三， 设计
的时候， 这种机制要么放在应用程序中实现， 要么放在驱动程序中实现，但无论放在哪一方， 都是会给这一方的程序开发者带来额外的负
担。
图二 一个应用使用多个硬件设备
图三: 多个应用使用多个硬件设备
引入操作系统之后
上面之所以说额外， 那是因为对于应用程序开发者来讲， 其重点要考
虑的是业务逻辑如何实现， 而不是去考虑硬件资源的管理分配， 也最
好用不着去区分那么多驱动程序的不同接口。 类似的， 对于驱动程序
开发者来说， 其要考虑的重点是如何正确的驱动特定的硬件， 而不是去考虑硬件资源的管理分配上。那这部分 “额外 ”的工作由谁去做呢，
这正是后来出现的操作系统 (3)的职责所在。
图五: 引入操作系统后的情况
如图五， 操作系统帮我们考虑对各种硬件资源的分配管理， 并完成对
各种驱动程序所提供接口的抽象， 形成一套简单一致的接口给上层的
应用程序去使用。 如此，应用程序开发人员只需要知道操作系统所提
供的这套编程接口 (API)，就可以实现不同的业务应用。前面我们讲
系统程序软件实际上就是驱动程序， 但这里我们讲系统程序软件是操
作系统。 概念上，我们认为操作系统依赖于驱动程序这一层，但实际
上，驱动程序是嵌入到操作系统中去的， 所以我们认为驱动程序是操
作系统的一部分。 这种镶嵌大大增加了以往驱动程序开发者的工作难
度，因为他们不仅要熟悉手头的硬件工作原理， 更重要的是要确保他
们写的驱动能正确的镶嵌到操作系统里面去， 这就要求他们同时也必须熟练掌握操作系统提供出来的，用来完成镶嵌工作的各种接口。