?FindFirstFile 函數(shù)會(huì)嘗試匹配短文件名和長(zhǎng)文件名。這可能會(huì)產(chǎn)生一些令人驚訝的結(jié)果。例如，如果你查找 “*.htm” ，那么它會(huì)返回給你文件 “x.html” ，因?yàn)樗亩涛募?“X~1.HTM”。 這確實(shí)比較令人感到意外。

為什么 FindFirstFile 會(huì)匹配短文件名呢？它不應(yīng)該只匹配長(zhǎng)文件名嗎？畢竟，只有舊的 16 位程序才會(huì)使用短文件名。

但這就是問(wèn)題所在：16位程序才會(huì)使用短文件名。

通過(guò)稱為通用Thunk 的方法，16 位程序可以加載 32 位 DLL 并調(diào)用它。Windows 95和Windows NT中的Windows 16位仿真層嚴(yán)重依賴通用Thunk，因此他們不必編寫(xiě)所有內(nèi)容的兩個(gè)版本。相反，16 位版本只是升級(jí)到 32 位版本。

但請(qǐng)注意，這意味著 32 位 DLL 將看到文件系統(tǒng)的兩個(gè)不同視圖，具體取決于它們是從 16 位進(jìn)程還是 32 位進(jìn)程托管的。

“然后讓 FindFirstFile 函數(shù)檢查其調(diào)用方是誰(shuí)，并相應(yīng)地更改其行為”，因?yàn)槟銦o(wú)法信任返回地址，因此這種方法不會(huì)起作用。

即使解決了這個(gè)問(wèn)題，你仍然會(huì)遇到跨進(jìn)程邊界的 16/32 互操作的問(wèn)題。

例如，假設(shè)一個(gè) 16 位程序調(diào)用 WinExec（”記事本 X~1.HTM”）。32位記事本程序最好打開(kāi)文件X~1.HTM，即使它是一個(gè)短文件名。此外，獲取文件屬性（如上次訪問(wèn)時(shí)間）的常用方法是使用文件名調(diào)用 FindFirstFile，因?yàn)?WIN32_FIND_DATA 結(jié)構(gòu)將該信息作為查找數(shù)據(jù)的一部分返回。（注意：GetFileAttributesEx 是更好的選擇，但該功能相對(duì)較新。如果 FindFirstFile 函數(shù)不適用于短文件名，則上述技巧對(duì)于跨 16/32 邊界傳遞的短文件名將失敗。

再舉一個(gè)例子，假設(shè) DLL 將文件名保存在進(jìn)程外部的位置，例如配置文件、注冊(cè)表或共享內(nèi)存塊。如果 16 位程序程序調(diào)用此 DLL，它將傳遞短文件名，而如果 32 位程序調(diào)用 DLL，它將傳遞長(zhǎng)文件名。如果文件系統(tǒng)函數(shù)僅返回 32 位程序的長(zhǎng)文件名，則在 32 位程序中運(yùn)行的 DLL 副本將無(wú)法讀取在 16 位程序中運(yùn)行的 DLL 寫(xiě)入的數(shù)據(jù)。

總結(jié)

由于 API 是一個(gè)已經(jīng)對(duì)外公開(kāi)的調(diào)用規(guī)范，不可輕易修改，否則會(huì)破壞兼容性。為此在最新的操作系統(tǒng)上運(yùn)行那些老程序，只能最大限度地保留現(xiàn)有 API 的外部接口。同時(shí)，通過(guò)增加新的 API 來(lái)支持操作系統(tǒng)上開(kāi)發(fā)出來(lái)的新特性。這就說(shuō)我們經(jīng)常說(shuō)的：對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉。

所以，”先知性” 是在規(guī)劃高層設(shè)計(jì)的一項(xiàng)特殊能力。?