MicrosoftWindows2000应用程序兼容性

我们发现许多设备驱动程序没有遵守 Windows 2000 的这一规则。通过检查设备驱动程序，系统将判断如果设备驱动程序的设计目标是用于 Windows NT 4.0 而不是 Windows 2000，则不会强制执行该规则。如果不这样，将会导致太多的设备驱动程序无法正常工作。对于为 Windows 2000 编写的设备驱动程序或已进行升级、以便能在 Windows 2000 上正常工作的驱动程序，系统将强制执行该规则。 堆栈消费量增加为了说明兼容性方面的几个实质问题，首先，我们必须明白 Windows 2000 所使用的堆栈空间要比 Windows NT 4.0 大得多。既然我们使用的是全球范围内统一的可执行程序，Unicode 所占用的空间就会比以往任何时候都要多，另外，我们还在这里或那里答咐声明了更多的字符串，结果导致系统需要更多的堆栈。我们发现有些应用程序通过尽可能减少堆栈空间来增强性能。如果要提高运行速度，这无疑是个好主意：很明显，占用的内存越少，运行的速度就越快。但可惜的是，它们现在确实太小了，由于系统和应用程序一起很快用光了堆栈空间，结果是，应用程序随即崩溃。 为了确认您的应用程序中是否存在上述问题，需要检查以下设置：如果您在链接行中使用了 /STACK-linker 选项，则检查该选项；在编译器中检查在使用 STACKSIZE 参数或 /F 选项的 STACKSIZE-.def 文件。您需要重新检查所有这些内容，查看它们是否运行在 Windows 2000 上，并确认堆栈空间不是太小。 Win32 API 的变化在 Windows 2000 中，Microsoft Win32(R) API 有许多改动；我们检查了其中几个，发现其中存在一些无意中造成的兼容性障碍。以下是我在 Windows 2000 测试过程中经常遇到的几处变化。 我们要在 Windows 2000 中支持一种新的输入法。为实现这一目的，需要传递 wParam 中的某些信息，这些信息通过 WM_KEYUP 和 WM_KEYDOWN 消息获取。我们要求您将 wParam 原封不动地传递给 TranslateMessage。如果您没有这样做，我们将无法全面实现这一新的输入法的功能。 另一个问题出在位于对话框结构内部的 DS_SHELLFONT 上。如果您指定了 DS_SHELLFONT，则不能再更改字体。我们使用 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 将它移动了位置，并且针对每一用户，将其各自的文件夹放在 Windows 系统目录以下。因此在如下的例子中，即使文件夹被命名为“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 情况下，将完全可以找到正确位置。 长文件名和长打印机名自从 Windows 95 问世之后，我们便一直在谈论长文件名及打印机名。最初，我们仅仅是要求应用程序能够支持这两者；在升级到 Windows 2000 后，我们要求程序能够正确地支持它们。我们发现在许多地方，应用程序并没有实现对长文件名的正确支持。但这并不是说这些应用程序对它们一点都不支持（尽管有少数的确如此），而是我们发现了应用程序在支持长文件名方面存在一些错误。例如，有一个应用程序，声称为实现对长文件名的支持，为全部 256 个字符提供了一个缓冲区。但是当我们将文件移走，并为应用程序提供了一个指向所寻找文件的较长路径（大约有 50 个字符）时，程序崩溃了。这表明尽管该应用程序告诉我们它拥有一个长缓冲区，而实际上只提供给我们一个较短的缓冲区。这只是应用程序中的一个简单的错误；由于我们将“My Documents”文件夹转移到了“Documents and Settings”，而不是将其置于根目录或 Windows 系统目录下，您会经常遇到这类错误。路径有越变越长的趋势，现在的平均路径长度是 60 到 70 字符，而不再是 30 到 40 字符。长路径名的使用正在暴露出越来越多的错误。 我们在“Documents and Settings”文件夹方面发现的另一个问题是“Documents and Settings”这种写法造成了许多应用程序无法正常访问到它。应用程序会对目录进行分析，只要发现“Documents”一词，程序就会认为到了“My Documents”的结尾。这样，应用程序会中断，同时认为“我发现了‘Documents’一词，我已经找到‘My Documents’了”。这当然行不通。 一定要全面检查长文件名支持功能，并进行测试。您会在 Windows 2000 应用程序规范（ http://msdn.microsoft.com/certification/appspec.asp （英文））中发现一个相当长的字符串，可以使用它来确认应用程序是否可以正确地支持长文件名。 堆管理另一个应用程序稳定性问题源于在 Windows NT 平台上对堆管理所进行的改动。这是我在这儿提到的最使人震惊的问题，它有极大的危险性，可以导致您的应用程序出现各种问