11.14 忠告

从 MS-DOS® 和 Windows® “成长” 起来的汇编程序员， 通常倾向于走捷径。 读键盘扫描码和直接写屏， 在 MS-DOS 上就属于很多人毫不犹豫地采用， 并自认为正确的一种做法。

原因嘛？ PC BIOS 和 MS-DOS 在执行这些操作时实在是太慢了。

在 UNIX® 环境下继续照此行事也许是相当有诱惑力的做法， 我还见过一个网站专门介绍如何在常见的类 UNIX 系统上访问键盘扫描码。

一般来说， 在 UNIX 环境下这是一个 糟糕透顶的主意！ 下面来解释一下为什么。

11.14.1 UNIX® 是受保护的

首先， 简而言之这是不可行的。 UNIX 是在保护模式下运行的。 只有内核和设备驱动才允许直接访问硬件。 也许某些设计不良的类 UNIX 系统会让您读取键盘扫描码， 但是通常真正的 UNIX 操作系统都不允许这样做。 而且， 即便某个版本允许您这么做， 也许下个版本就不行了， 因此您精心雕琢的软件， 很可能会沦为昨日黄花。

11.14.2 UNIX 是一种抽象

即使在允许您这样做的类 UNIX 系统上， 也不去尝试直接操作硬件的一个更重要原因 (当然， 除非您正在撰写设备驱动) 是：

UNIX 是一种抽象！

MS-DOS 和 UNIX 的设计哲学有一个截然相反的地方。 MS-DOS 是为单用户系统设计的， 它只在那些键盘和显示屏幕都直接插在主机上的计算机上运行， 来自用户的输入， 基本上一定来自于那个键盘， 而您程序的输出， 最终也一定会反映到那个显示器上。

在 UNIX 中从未提供这样的保证。 使用管道来重定向输入和输出这样的事情在 UNIX 用户看来是极为稀松平常的事情：

% program1 | program2 | program3 > file1

如果您撰写了 program2， 则输入并非来自键盘， 而是来自 program1 的输出。 类似地， 您的输出并不会显示到屏幕上， 而是成为 program3 的输入， 而后者的输出， 则相应地会存入 file1。

且慢！ 即使您能确保输入输出都来自真正的终端， 也没有任何人能保证那终端一定是 PC： 在您预期的位置可能并不是显存， 其键盘也未必会产生 PC-风格的扫描码。 它可能是一台 Macintosh®， 或者其他种类的计算机。

现在您也许会摇头： 我的软件是用 PC 汇编语言写成的， 它如何能在 Macintosh 上运行？ 请注意， 我并不是说它要在 Macintosh 上运行， 而只是说终端可能是一台 Macintosh。

在 UNIX 中， 终端未必会直接连在运行您软件的计算机上， 它甚至可能在另一个大洲， 甚至在另一个星球上。 很有可能某位澳洲的 Macintosh 用户会通过 telnet 连到在北美 (或其他地方) 的 UNIX 系统上。 这样， 软件是在一台计算机上运行的， 而终端则在另一台计算机上： 如果您试图读取扫描码， 就会得到不正确的输入！

同样的问题也适用于任何其他硬件： 您正读取的文件， 可能位于您无权直接访问的磁盘上。 提取图像的一部照相机， 也许正在某个透过卫星连接的航天飞机上。

这就是为什么在 UNIX 下您不应对数据的来源和去向有任何心存侥幸的假定。 任何时候都应让系统来处理对硬件的物理访问。

注意: 这些只是忠告， 而不是绝对的规则。 有时会有一些例外的情况。 例如， 如果文本编辑器检测到它正在本地机器上运行， 就可能希望直接读取扫描码来改善控制。 这些忠告并非要告诉您该做什么和不该做什么， 只是提醒您在刚刚从 MS-DOS 迁移到 UNIX 时可能碰到的一些问题。 当然， 富于创意的人们通常会打破规则， 如果他们知道打破的是什么规则， 以及为什么要这样做的话， 一般也不会产生太严重的后果。