为什么 FindFirstFile 会查找短文件名?

为什么 FindFirstFile 会查找短文件名?

作者:BlogUpdater |  时间:2022-12-01 |  浏览:112 |  评论已关闭 条评论

FindFirstFile 函数会尝试匹配短文件名和长文件名。这可能会产生一些令人惊讶的结果。例如,如果你查找 “*.htm” ,那么它会返回给你文件 “x.html” ,因为它的短文件名是 “X~1.HTM”。 这确实比较令人感到意外。

为什么 FindFirstFile 会匹配短文件名呢?它不应该只匹配长文件名吗?毕竟,只有旧的 16 位程序才会使用短文件名。

但这就是问题所在:16位程序才会使用短文件名。

通过称为通用Thunk 的方法,16 位程序可以加载 32 位 DLL 并调用它。Windows 95和Windows NT中的Windows 16位仿真层严重依赖通用Thunk,因此他们不必编写所有内容的两个版本。相反,16 位版本只是升级到 32 位版本。

但请注意,这意味着 32 位 DLL 将看到文件系统的两个不同视图,具体取决于它们是从 16 位进程还是 32 位进程托管的。

“然后让 FindFirstFile 函数检查其调用方是谁,并相应地更改其行为”,因为你无法信任返回地址,因此这种方法不会起作用。

即使解决了这个问题,你仍然会遇到跨进程边界的 16/32 互操作的问题。

例如,假设一个 16 位程序调用 WinExec(”记事本 X~1.HTM”)。32位记事本程序最好打开文件X~1.HTM,即使它是一个短文件名。此外,获取文件属性(如上次访问时间)的常用方法是使用文件名调用 FindFirstFile,因为 WIN32_FIND_DATA 结构将该信息作为查找数据的一部分返回。(注意:GetFileAttributesEx 是更好的选择,但该功能相对较新。如果 FindFirstFile 函数不适用于短文件名,则上述技巧对于跨 16/32 边界传递的短文件名将失败。

再举一个例子,假设 DLL 将文件名保存在进程外部的位置,例如配置文件、注册表或共享内存块。如果 16 位程序程序调用此 DLL,它将传递短文件名,而如果 32 位程序调用 DLL,它将传递长文件名。如果文件系统函数仅返回 32 位程序的长文件名,则在 32 位程序中运行的 DLL 副本将无法读取在 16 位程序中运行的 DLL 写入的数据。

总结
由于 API 是一个已经对外公开的调用规范,不可轻易修改,否则会破坏兼容性。
为此在最新的操作系统上运行那些老程序,只能最大限度地保留现有 API 的外部接口。
同时,通过增加新的 API 来支持操作系统上开发出来的新特性。
这就说我们经常说的:对扩展开放,对修改关闭。

所以,”先知性” 是在规划高层设计的一项特殊能力。

最后
Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一,里面有很多关于Windows的小知识,对于广大Windows平台开发者来说,确实十分有帮助。
本文来自:《Why does FindFirstFile find short names?》

最近我写了个东西
正如你们所知道的,拓扑梅尔智慧办公平台(Topomel Box)是一款绿色软件,主要面向经常使用电脑的朋友。它提供了各种提升办公效率的小功能,同时操作上尽可能地简单方便。
我想:你值得拥有。

评论已关闭。