📄 csdn_文档中心_microsoft windows 2000 应用程序兼容性 ( 2 ).htm
字号:
month= tmpDate.getMonth() + 1 ;
if(document.ns)
{
year1=tmpDate.getYear()
year= year1.toString().substr(1,2);
}
else
year= tmpDate.getYear();
document.write(year);
document.write(".");
document.write(month);
document.write(".");
document.write(date);
// -->
</SCRIPT>
</B> </TD></TR>
<TR bgColor=#999999>
<TD colSpan=3 height=1></TD></TR></TBODY></TABLE>
<TABLE border=0 width=770>
<TBODY>
<TR>
<TD align=middle bgColor=#fafafa class=td1 vAlign=top width=150><BR>
<SCRIPT
src="CSDN_文档中心_Microsoft Windows 2000 应用程序兼容性 ( 2 ).files/microsoft.js"></SCRIPT>
</TD>
<TD align=middle width=620>
<TABLE bgColor=#eeeeee border=0 cellPadding=0 cellSpacing=0 width=600>
<TBODY>
<TR bgColor=#ffffff>
<TD align=middle height=10 width=50></TD>
<TD align=right><A href="http://www.csdn.net/">CSDN</A> - <A
href="http://www.csdn.net/develop/">文档中心</A> - <FONT
color=#003399>Visual C++</FONT> </TD></TR>
<TR>
<TD align=middle height=5></TD>
<TD align=middle width=500></TD></TR>
<TR>
<TD align=middle bgColor=#003399 height=10><FONT
color=#ffffff>标题</FONT></TD>
<TD><B> Microsoft Windows 2000 应用程序兼容性 ( 2
)</B> ghj1976（转贴） </TD></TR>
<TR>
<TD align=middle height=5></TD>
<TD align=middle width=500></TD></TR>
<TR>
<TD align=middle bgColor=#003399><FONT color=#ffffff>关键字</FONT></TD>
<TD width=500> Microsoft Windows 2000 应用程序兼容性
( 2 )</TD></TR>
<TR>
<TD align=middle height=5></TD>
<TD align=middle width=500></TD></TR>
<TR>
<TD align=middle bgColor=#003399 height=10><FONT
color=#ffffff>出处</FONT></TD>
<TD height=10> <A
href="http://www.microsoft.com/china/msdn/library/techart/win2000appcomp.asp">http://www.microsoft.com/china/msdn/library/techart/win2000appcomp.asp</A></TD></TR>
<TR>
<TD align=middle height=10></TD>
<TD height=10></TD></TR></TBODY></TABLE><!--文章说明信息结束//-->
<TABLE border=0 width=600>
<TBODY>
<TR>
<TD align=left><BR>
<H3>写保护的内核模式</H3>
<P>微软还采取了另一项措施增强平台的可靠性：任何运行于内核模式的程序都将在内存中实际拥有写保护区。如果您的设备驱动程序中使用了某些代码段或字符串段落，并且您在已列为只读区域的地方写入了某些临时内容（如注释等），这在
Windows 2000 中将是行不通的。我们不允许内核模式中的任何内容妨碍该处应该具备的保护功能，因为这会导致系统崩溃。 </P>
<P>我们发现许多设备驱动程序没有遵守 Windows 2000
的这一规则。通过检查设备驱动程序，系统将判断如果设备驱动程序的设计目标是用于 Windows NT 4.0 而不是 Windows
2000，则不会强制执行该规则。如果不这样，将会导致太多的设备驱动程序无法正常工作。对于为 Windows 2000
编写的设备驱动程序或已进行升级、以便能在 Windows 2000 上正常工作的驱动程序，系统将强制执行该规则。</P>
<H3>堆栈消费量增加</H3>
<P>为了说明兼容性方面的几个实质问题，首先，我们必须明白 Windows 2000 所使用的堆栈空间要比 Windows NT 4.0
大得多。既然我们使用的是全球范围内统一的可执行程序，Unicode
所占用的空间就会比以往任何时候都要多，另外，我们还在这里或那里声明了更多的字符串，结果导致系统需要更多的堆栈。我们发现有些应用程序通过尽可能减少堆栈空间来增强性能。如果要提高运行速度，这无疑是个好主意：很明显，占用的内存越少，运行的速度就越快。但可惜的是，它们现在确实太小了，由于系统和应用程序一起很快用光了堆栈空间，结果是，应用程序随即崩溃。
</P>
<P>为了确认您的应用程序中是否存在上述问题，需要检查以下设置：如果您在链接行中使用了 /STACK-linker
选项，则检查该选项；在编译器中检查在使用 STACKSIZE 参数或 /F 选项的 STACKSIZE-.def
文件。您需要重新检查所有这些内容，查看它们是否运行在 Windows 2000 上，并确认堆栈空间不是太小。</P>
<H3>Win32 API 的变化</H3>
<P>在 Windows 2000 中，Microsoft Win32(R) API
有许多改动；我们检查了其中几个，发现其中存在一些无意中造成的兼容性障碍。以下是我在 Windows 2000
测试过程中经常遇到的几处变化。 </P>
<P>我们要在 Windows 2000 中支持一种新的输入法。为实现这一目的，需要传递 <B>wParam</B>
中的某些信息，这些信息通过 WM_KEYUP 和 WM_KEYDOWN 消息获取。我们要求您将 <B>wParam</B>
原封不动地传递给 <B>TranslateMessage</B>。如果您没有这样做，我们将无法全面实现这一新的输入法的功能。 </P>
<P>另一个问题出在位于对话框结构内部的 DS_SHELLFONT 上。如果您指定了
DS_SHELLFONT，则不能再更改字体。我们使用 Microsoft Shell Dlg 2
作为字体；您可以更改大小，但却不能更改字形。 </P>
<P>在“打开文件”对话框的 OPENFILENAME STRUCTURE 中，初始目录的行为有细小的差别。如果
<B>OpenFile</B> 没有找到任何您要查找类型的文件，默认情况下它将直接指向“My Documents”文件夹。</P>
<P><B>GetWindowsDirectory</B>
返回的是针对每个用户的系统目录。如果您在终端服务器上，您可能会发现无法获得真正的系统目录，所获得的将是为特定用户设置的系统目录。有一个新的
<B>GetWindowsSystemDirectory</B> 调用，它能够在终端服务器上始终返回真正的系统目录。</P>
<H2><A name=win2000appcomp_topic4></A>应用程序稳定性问题</H2>
<P>现在，将要讨论应用程序的稳定性问题，这些问题源于 Windows 2000
所发生的更改，由此在应用程序的实施或细节中发现了许多导致应用程序不兼容的错误。但是，所做的改动不会破坏应用程序。有时，当应用程序以少见的方式运行时也会出现这种问题。</P>
<H3>硬代码路径</H3>
<P>应用程序普遍采用“硬代码”引用方式，所以，当 Microsoft
对系统的某些地方作出改变，应用程序将因为它要寻找的内容不在原位置而无法工作，这里主要的罪魁祸首便是硬代码路径。在 Windows
2000 甚至 Windows NT 4.0 上，很多东西都被移动了位置。例如，在 Windows 9x 上“My
Documents”文件夹只是位于 C 盘或 D 盘根目录下的一个文件夹，即：</P>
<P class=indent>\My Documents</P>
<P>Windows NT 将它移动了位置，并且针对每一用户，将其各自的文件夹放在 Windows
系统目录以下。因此在如下的例子中，即使文件夹被命名为“personal”，实际上它还是 Windows NT 4.0 上的“My
Documents”文件夹。</P>
<P class=indent>%windir%\profiles\kylemar\personal</P>
<P>而 Windows 2000 则再一次移动了该文件夹的位置，使其不再位于系统目录下或根目录下。Windows 2000
将它放在：</P>
<P class=indent>\Documents and Settings\KYLEMAR\My Documents</P>
<P>正像您所看到的那样，当文件夹改变了位置，而如果硬代码仍然按照往常行事，当然会出现错误。事实上，在被管理环境中，“My
Documents”文件夹也可能位于网络驱动器上。为了避免这种情况发生，就要像我们以前所讨论过的那样使用
<B>SHGetFolderPath</B>，并确保在 Windows 95、Windows 98 或任一平台上均采用这一方式。在默认的
Windows 2000 情况下，将完全可以找到正确位置。</P>
<H3>长文件名和长打印机名</H3>
<P>自从 Windows 95 问世之后，我们便一直在谈论长文件名及打印机名。最初，我们仅仅是要求应用程序能够支持这两者；在升级到
Windows 2000
后，我们要求程序能够正确地支持它们。我们发现在许多地方，应用程序并没有实现对长文件名的正确支持。但这并不是说这些应用程序对它们一点都不支持（尽管有少数的确如此），而是我们发现了应用程序在支持长文件名方面存在一些错误。例如，有一个应用程序，声称为实现对长文件名的支持，为全部
256 个字符提供了一个缓冲区。但是当我们将文件移走，并为应用程序提供了一个指向所寻找文件的较长路径（大约有 50
个字符）时，程序崩溃了。这表明尽管该应用程序告诉我们它拥有一个长缓冲区，而实际上只提供给我们一个较短的缓冲区。这只是应用程序中的一个简单的错误；由于我们将“My
Documents”文件夹转移到了“Documents and Settings”，而不是将其置于根目录或 Windows
系统目录下，您会经常遇到这类错误。路径有越变越长的趋势，现在的平均路径长度是 60 到 70 字符，而不再是 30 到 40
字符。长路径名的使用正在暴露出越来越多的错误。</P>
<P>我们在“Documents and Settings”文件夹方面发现的另一个问题是“Documents and
Settings”这种写法造成了许多应用程序无法正常访问到它。应用程序会对目录进行分析，只要发现“Documents”一词，程序就会认为到了“My
Documents”的结尾。这样，应用程序会中断，同时认为“我发现了‘Documents’一词，我已经找到‘My
Documents’了”。这当然行不通。</P>
<P>一定要全面检查长文件名支持功能，并进行测试。您会在 Windows 2000 应用程序规范（<A
href="http://msdn.microsoft.com/certification/appspec.asp">http://msdn.microsoft.com/certification/appspec.asp</A>）中发现一个相当长的字符串，可以使用它来确认应用程序是否可以正确地支持长文件名。</P>
<H3>堆管理</H3>
<P>另一个应用程序稳定性问题源于在 Windows NT
平台上对堆管理所进行的改动。这是我在这儿提到的最使人震惊的问题，它有极大的危险性，可以导致您的应用程序出现各种问题。它实际上与我们在旧版
C 语言中常常遇到的问题相同：出现了指针错误或内存使用错误。但它是很难处理的问题之一。</P>
<P>实际上这一问题起始于 Windows NT 4.0，Service Pack
4。我们对堆管理器进行了某些改动，目的是使它效率更高、运行更快，特别是针对拥有多处理器的计算机。Windows 2000
在此基础上又进行了一些更改，所以，能够在 Windows NT 4.0 上运行的程序，在安装 Service Pack 4
后无法运行。或者在 Service Pack 4 下可以运行的程序，在 Windows 2000
下却崩溃了，这是因为我们已经对堆管理器的工作方式作过很多改进。很明显，如果您要提高系统性能，并加快堆管理器的运行速度，可做的事情还是很多的。我们并未对
API
本身作出改动，也没有对堆的工作方式进行逻辑上的改动，但是我们对块的重复利用方式进行了一些微妙的改变，从而使应用程序中的错误暴露出来。</P>
<P>简而言之，我们所作的改动如下所示：以前，当一个块被释放出来，它将被列入未应用的空块列表，位于表的末尾，最后将被筛选出来再一次利用。现在，我们将缓存最后一次被使用的块，并把它们放在表的顶端，当您需要另一个块时，您更可能首先调回这一个块。如果您需要调回一个块，又生成了一个空块，您将会调回刚刚使用过的块，这样可以使自己保持在同一页，并且提高系统整个工作方式的速度。</P>
<P>这就是我们从一开始便在 C 语言设计及 C++
程序开发中遇到的问题。实际上并没有更好地发现这些问题的途径。您可以利用一些商业工具去找出这些问题。除此之外，您需要在 Windows
2000 上尽可能彻底地测试这些软件。</P>
<P>我们发现许多应用程序都存在堆问题，最普遍的一个问题是试图访问已经释放的内存。结果是应用程序将进行分配，它将对这些块进行读写操作，然后释放这些块，而后又对这些块进行读写操作。这种做法的危险之处是会导致数据的破坏，您的应用程序就会崩溃。但是因为它驻留在已归您支配的某一块或页中，并且因为您正在读写允许您进行写操作的块，就不会导致存取侵犯，而是导致数据的破坏。但愿导致系统崩溃，因为比较而言这种情况更容易补救，但这也很难说，任何一种情况都可能发生。</P>
<P>另一出现问题的情况是：为了使某一页的空间得到更充分的利用，在您已经重分配了一个较小的块的情况下，Windows 2000 以及
Service Pack 4
还可能会移动这种分配区。很多开发人员持有一种受怀疑的优化观点，“如果我重新分配一个比我原先指定的块更小的块，将没有人可以把指针指向我，我就可以进行重分配，并相信不再移动的指针。因此只要我使它更小，就没有人可以移动它”。这样将会导致全面错误。</P>
<H3>调用规则</H3>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -