?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 來支持操作系統上開發出來的新特性。這就說我們經常說的：對擴展開放，對修改關閉。

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