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

創(chuàng)新互聯(lián)專注于滎經(jīng)企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站開發(fā),商城開發(fā)。滎經(jīng)網(wǎng)站建設(shè)公司,為滎經(jīng)等地區(qū)提供建站服務(wù)。全流程定制開發(fā),專業(yè)設(shè)計,全程項目跟蹤,創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)
為什么 FindFirstFile 會匹配短文件名呢?它不應(yīng)該只匹配長文件名嗎?畢竟,只有舊的 16 位程序才會使用短文件名。
但這就是問題所在:16位程序才會使用短文件名。
通過稱為通用Thunk 的方法,16 位程序可以加載 32 位 DLL 并調(diào)用它。Windows 95和Windows NT中的Windows 16位仿真層嚴(yán)重依賴通用Thunk,因此他們不必編寫所有內(nèi)容的兩個版本。相反,16 位版本只是升級到 32 位版本。
但請注意,這意味著 32 位 DLL 將看到文件系統(tǒng)的兩個不同視圖,具體取決于它們是從 16 位進(jìn)程還是 32 位進(jìn)程托管的。
“然后讓 FindFirstFile 函數(shù)檢查其調(diào)用方是誰,并相應(yīng)地更改其行為”,因為你無法信任返回地址,因此這種方法不會起作用。
即使解決了這個問題,你仍然會遇到跨進(jìn)程邊界的 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 將文件名保存在進(jìn)程外部的位置,例如配置文件、注冊表或共享內(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è)計的一項特殊能力。?
文章標(biāo)題:為什么FindFirstFile會查找短文件名?
分享網(wǎng)址:http://m.fisionsoft.com.cn/article/djppisi.html


咨詢
建站咨詢
