Windows 版 (精华区)

发信人: bali (阿奔), 信区: Windows
标  题: Microsoft Windows 2000 应用程序兼容性(3)
发信站: 紫 丁 香 (Fri May  5 23:34:36 2000), 转信

安全性问题
最后，作为设置和安装的最后一个问题，我们将讨论随 Windows 2000 出现的几
个安全性问题：
高级用户应能安装整个系统范围的应用程序。我们发现有些应用程序坚持只能由
管理员进行这类安装。对于锁定的机器，企业仍然希望许多不同用户，或一天中
有两三个用户能够进行共享；或者是在特定的某一天，所有雇员都能够使用这一
系统。他们只是不希望任何人都能以管理员权限对系统任意更改，为所欲为。许
多客户要求高级用户（不仅是管理员）也能够完成应用程序的安装。
另一条，所有人都可以安装供自己（而不是系统中的任何人）使用的应用程序。
如果我希望玩某个游戏，我就应该能安装该游戏，而且不让系统中的其他任何人
使用这一游戏。但请记住，非高级用户不能向 “Program Files” 目录写东西；
该用户无法对 HKEY_LOCAL_MACHINE 进行写操作。在安装过程中，您应能打开 H
KEY_LOCAL_MACHINE，查看您对它有没有写权限，然后让它作出如下声明：“您不
能对该处进行写操作；是否希望这一应用程序只供个人使用？”
另一个安全性问题是默认的服务器权限。如果您试图安装服务器应用程序或服务
，而使用的是非特权服务帐户（意即，您没有使用本地系统的帐户，也没有使用
作为本地管理员组的成员所建立的帐户），则该帐户基本上不可能拥有实际运行
服务所需的特权。在 Windows 2000 中，非特权用户（实际上是非特权服务帐户
）所拥有的权限与 Windows NT 4.0 中不同。前者拥有的权限较少。例如，非特
权用户无法在 Windows 系统目录的任何地方写入东西。如果您拥有一个正在运行
的服务器，该服务器试图进行某些操作，或试图安装某些东西，但它可能没有具
备适当的权限。如果您正在运行服务器应用程序，请确认它已登录了正确的帐户
，并拥有正常运行所需的所有权限。
Windows 2000 兼容性问题
我要讨论的下一个问题被我称之为 Windows 2000 兼容性问题，这里指的是我们
对 Windows 平台进行的某些更改，其目的是推动平台不断进步，并实现我们为用
户提供更为可靠的平台的目标。这些改动将影响某些应用程序在 Windows 2000
上运行的方式。
设置前台窗口
我们以一个相当简单的操作开始：设置前台窗口。实际上，这一变动始于 Windo
ws 98。不能指望只是简单地由应用程序调用 SetForegroundWindow ，然后您的
窗口就能自动地变更为前台窗口。所有这些都是为了防止在任何人希望跳到最前
台时出现令人烦恼的选项。您正在兴致勃勃地键入，突然弹出了一个窗口，要请
求某种操作。您可能在键入过程中毫无意识地对某些根本不了解的东西作出了肯
定的答复。
为了防止出现这种情况，对应用程序何时能成为前台应用程序制订了规则。其实
在 Windows 98 中这些规则已经存在：
如果您的进程已经是前台进程，则可以取前台窗口。
如果您的进程刚刚由前台进程启动，则可以取前台窗口。
如果您的进程收到最后一次输入，则会变为前台窗口。
如果此时没有前台窗口，则可以取前台窗口。
如果正在对前台进程进行调试，则每个人都可以取前台窗口。
如果发生了前台超时锁定（某一段时间内前台锁定没有任何操作，而且不会作出
响应），那么别人可以取得前台窗口。
如果当前任何系统菜单是活动的，则您的应用程序将无法取得前台。这主要是为
了防止出现以下令人烦恼的情况：您正在使用“开始”菜单，并沿着它的分支菜
单正要启动某个应用程序，突然这些菜单全部消失。 Windows 2000 中新增的这
一规则可以防止出现这种情况。
超级隐藏文件
Windows 2000 中增加的另一个新特性称为“超级隐藏文件”(Super Hidden Fil
es)。这里，系统会将几个文件同时标记“系统”和“隐藏”属性。文件仍位于原
位置，我们还可以应用这些文件；只是当您进入 Windows 资源管理器之后，这些
文件不会显示出来。即使选中“显示隐藏文件”，也无法看到它们。在文件夹的
属性列表中有一个新的复选框，该复选框将允许用户看见这些文件，但普通用户
不会选中该选项，所以无法看到这些文件。
而且，系统将不再显示 Windows 环境中那些几乎毫无用处的文件，其中绝大多数
是基于 MS-DOS(R) 的旧文件以及类似文件。大多数情况下，这对普通用户没有影
响；他们所看到的将是一个更简洁的系统。
对于 32 位应用程序来说，这其实不是兼容性问题。应用程序能够在常规的“打
开文件”对话框中看到文件，并顺利地打开文件，命令行也依然有效。如果您采
用能够查看超级隐藏文件的 Dir /ASH 命令，将会看到所有文件。
唯一存在兼容性问题的是 16 位应用程序，这类程序会碰到一点麻烦。这主要是
由调用 MS-DOS 的 INT21 引起。如果您要求系统查找隐藏文件，MS-DOS 的 INT
21 只会查找出隐藏的服务文件。
部分被隐藏的文件：
MS-DOS 系统文件，如 io.dos
Office 快速查找文件
NetBIOS
NetBIOS 一直是 Windows NT 的一部分。从 Windows 2000 开始，这一情况有所
变化。它不是默认配置，用户可能对系统进行设置，使之不加载并不出现 NetBI
OS。如果您的应用程序在没有 NetBIOS 的系统中调用使用 NetBIOS 的 API，则
这些应用程序将无法继续正常工作，同时将返回错误。例如，如果采用诸如 Net
ServerEnum 的调用，而运行的系统中没有 NetBIOS，则将返回错误信息。您必须
检查所有使用 NetBIOS 调用的地方，确定它们是否发生在没有 NetBIOS 的机器
中，并进行正确处理。或者，可以将其替换成非 NetBIOS 调用。请确保您的用户
知道您的系统始终需要 NetBIOS，并在安装程序或版本发布说明中明确告知。
需要新的网络 .inf 文件
如果您拥有任一网络设备（如网络驱动程序、传输驱动程序以及某些网络文件打
印提供程序等），则您需要确认系统中存在该设备所需的新的网络 .inf 文件，
以便支持 Windows 2000 即插即用。无论使用网络设备的系统是从头开始安装，
还是由 Windows NT 4.0 升级到 Windows 2000，都要用到这些新文件。因这一格
式与 Windows 98 兼容，所以您以前可能用过。无论如何，您都需要立刻将这些
文件提供给用户，以便在系统升级到 Windows 2000 后，网络设备仍然能够得到
支持。
物理驱动器号
如果您的应用程序需要以低级方式访问硬盘驱动器和卷（如病毒扫描程序），则
将需要查找物理驱动器号，这时必须更改查找该号码的方式。过去，您可能使用
符号链，该符号链返回的内容类似于：
\Device\HarddiskX\PartitionY
在其中的某个地方您会找到“Harddisk”以及后面的 X，并看出它是硬盘 2 或硬
盘 3。而现在，符号链返回的是：
\Device\HarddiskVolumeZ
物理驱动器号将不再出现在这一符号链的任何地方。您需要用一对可用的 IOCTL
 来代替。第一个是：
IOCTL_STORAGE_GET_DEVICE_NUMBER
该 IOCTL 只对单个物理驱动器号有效。例如，如果驱动器是 C 驱动器，甚至在
一个驱动器上有多个分区，该 IOCTL 都将生效。但针对多卷集合，则需要使用：

IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS
该 IOCTL 对于 Windows NT 4.0 同样生效；从符号链中发现物理驱动器号总是有
点危险的事情：在可能是多驱动器集的信息中，它们会只告诉您第一个驱动器。

访问磁带驱动器
如果您的应用程序要用到磁带驱动器，则您必须更改访问该磁带驱动器的方式。
新的“层次结构存储管理”(Hierarchical Storage Management) 应用了称之为
“可移动存储管理器”(Removable Storage Manager) 的工具，其主要操作过程
如下：进入服务器并确认某个文件已很长时间未被访问。它会说：“让我们将它
转到磁带上，如果某人需要该文件，我们可以将其找回，并让它脱离磁带”。用
户将等待稍微长的时间，但可以获取该文件。这样，您可以使用一个似乎空间大
得多的小驱动器。
因为“可移动存储管理器”正在服务器上频繁运行，而您的应用程序也在试图访
问磁带驱动器，所以，应用程序会发现磁带驱动器总是处于忙碌状态，应用程序
将无法控制磁带驱动器。在此讨论如何处理这一问题的篇幅不足。建议您在 Mic
rosoft.com 上访问“Windows NT 5.0 存储应用程序开发过程中应考虑的问题”
(Development Considerations for Storage Applications in Windows NT 5.0
)。在该文中，您可以大致了解如何处理新的磁带驱动器。在实施这种处理之前，
请花点时间浏览 SDK 中的 “可移动存储管理器程序员参考”（Removable Stor
age Manager Programmer's Reference)，以便学习如何编写能与可移动存储管理
器共享磁带驱动器的应用程序。
挂接显示驱动程序
如果您的应用程序试图“楔入”显示设备中（例如，您编写了一个显示驱动程序
，它会先获得所有调用，然后再将它们移交给原始显示驱动程序），则需要改变
操作方式。您已经见过进行这种操作的应用程序（远程控制应用程序即是一个例
子），在这些例子中应用程序会取得显示驱动程序命令，并通过线路发送一个调
用，然后在本地执行一个调用。如果要在 Windows 2000 中进行这种操作，则必
须使用新的"显示驱动程序管理层"(Display Driver Management Level, DDML)
将该输出镜像到远程设备。这将启动多个显示驱动程序，而这正是远程控制应用
程序正在进行的操作。这部分文档资料包含在 Windows 2000 Beta 3 版的 DDK
中。
写保护的内核模式
微软还采取了另一项措施增强平台的可靠性：任何运行于内核模式的程序都将在
内存中实际拥有写保护区。如果您的设备驱动程序中使用了某些代码段或字符串
段落，并且您在已列为只读区域的地方写入了某些临时内容（如注释等），这在
 Windows 2000 中将是行不通的。我们不允许内核模式中的任何内容妨碍该处应
该具备的保护功能，因为这会导致系统崩溃。
我们发现许多设备驱动程序没有遵守 Windows 2000 的这一规则。通过检查设备
驱动程序，系统将判断如果设备驱动程序的设计目标是用于 Windows NT 4.0 而
不是 Windows 2000，则不会强制执行该规则。如果不这样，将会导致太多的设备
驱动程序无法正常工作。对于为 Windows 2000 编写的设备驱动程序或已进行升
级、以便能在 Windows 2000 上正常工作的驱动程序，系统将强制执行该规则。
堆栈消费量增加
为了说明兼容性方面的几个实质问题，首先，我们必须明白 Windows 2000 所使
用的堆栈空间要比 Windows NT 4.0 大得多。既然我们使用的是全球范围内统一
的可执行程序，Unicode 所占用的空间就会比以往任何时候都要多，另外，我们
还在这里或那里声明了更多的字符串，结果导致系统需要更多的堆栈。我们发现
有些应用程序通过尽可能减少堆栈空间来增强性能。如果要提高运行速度，这无
疑是个好主意：很明显，占用的内存越少，运行的速度就越快。但可惜的是，它
们现在确实太小了，由于系统和应用程序一起很快用光了堆栈空间，结果是，应
用程序随即崩溃。
为了确认您的应用程序中是否存在上述问题，需要检查以下设置：如果您在链接
行中使用了 /STACK-linker 选项，则检查该选项；在编译器中检查在使用 STAC
KSIZE 参数或 /F 选项的 STACKSIZE-.def 文件。您需要重新检查所有这些内容
，查看它们是否运行在 Windows 2000 上，并确认堆栈空间不是太小。
Win32 API 的变化
在 Windows 2000 中，Microsoft Win32(R) API 有许多改动；我们检查了其中几
个，发现其中存在一些无意中造成的兼容性障碍。以下是我在 Windows 2000 测
试过程中经常遇到的几处变化。
我们要在 Windows 2000 中支持一种新的输入法。为实现这一目的，需要传递 w
Param 中的某些信息，这些信息通过 WM_KEYUP 和 WM_KEYDOWN 消息获取。我们
要求您将 wParam 原封不动地传递给 TranslateMessage。如果您没有这样做，我
们将无法全面实现这一新的输入法的功能。
另一个问题出在位于对话框结构内部的 DS_SHELLFONT 上。如果您指定了 DS_SH
ELLFONT，则不能再更改字体。我们使用 Microsoft Shell Dlg 2 作为字体；您
可以更改大小，但却不能更改字形。
在“打开文件”对话框的 OPENFILENAME STRUCTURE 中，初始目录的行为有细小
的差别。如果 OpenFile 没有找到任何您要查找类型的文件，默认情况下它将直
接指向“My Documents”文件夹。
GetWindowsDirectory 返回的是针对每个用户的系统目录。如果您在终端服务器
上，您可能会发现无法获得真正的系统目录，所获得的将是为特定用户设置的系
统目录。有一个新的 GetWindowsSystemDirectory 调用，它能够在终端服务器上
始终返回真正的系统目录。
应用程序稳定性问题
现在，将要讨论应用程序的稳定性问题，这些问题源于 Windows 2000 所发生的
更改，由此在应用程序的实施或细节中发现了许多导致应用程序不兼容的错误。
但是，所做的改动不会破坏应用程序。有时，当应用程序以少见的方式运行时也
会出现这种问题。
硬代码路径
应用程序普遍采用“硬代码”引用方式，所以，当 Microsoft 对系统的某些地方
作出改变，应用程序将因为它要寻找的内容不在原位置而无法工作，这里主要的
罪魁祸首便是硬代码路径。在 Windows 2000 甚至 Windows NT 4.0 上，很多东
西都被移动了位置。例如，在 Windows 9x 上“My Documents”文件夹只是位于
 C 盘或 D 盘根目录下的一个文件夹，即：
\My Documents
Windows NT 将它移动了位置，并且针对每一用户，将其各自的文件夹放在 Wind
ows 系统目录以下。因此在如下的例子中，即使文件夹被命名为“personal”，
实际上它还是 Windows NT 4.0 上的“My Documents”文件夹。
%windir%\profiles\kylemar\personal
而 Windows 2000 则再一次移动了该文件夹的位置，使其不再位于系统目录下或
根目录下。Windows 2000 将它放在：
\Documents and Settings\KYLEMAR\My Documents
正像您所看到的那样，当文件夹改变了位置，而如果硬代码仍然按照往常行事，
当然会出现错误。事实上，在被管理环境中，“My Documents”文件夹也可能位
于网络驱动器上。为了避免这种情况发生，就要像我们以前所讨论过的那样使用
 SHGetFolderPath，并确保在 Windows 95、Windows 98 或任一平台上均采用这

一方式。在默认的 Windows 2000 情况下，将完全可以找到正确位置。

--



  在时间面前，没有永恒
      
         ------一个热爱自由的人

※ 来源:．紫 丁 香 bbs.hit.edu.cn．[FROM: 202.108.67.114]