当前位置: 首页 > 文档资料 > FreeBSD 开发手册 >

11.14 忠告

优质
小牛编辑
141浏览
2023-12-01

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

原因嘛? PC BIOSMS-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 时可能碰到的一些问题。 当然, 富于创意的人们通常会打破规则, 如果他们知道打破的是什么规则, 以及为什么要这样做的话, 一般也不会产生太严重的后果。