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

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

但這就是問題所在：16位程序才會使用短文件名。

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

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

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

即使解決了這個問題，你仍然會遇到跨進程邊界的 16/32 互操作的問題。

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

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

總結(jié)

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

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