建站
咨詢
售后
建站咨詢
新聞中心
?FindFirstFile 函數(shù)會(huì)嘗試匹配短文件名和長(zhǎng)文件名。這可能會(huì)產(chǎn)生一些令人驚訝的結(jié)果。例如，如果你查找 “*.htm” ，那么它會(huì)返回給你文件 “x.html” ，因?yàn)樗亩涛募?“X~1.HTM”。 這確實(shí)比較令人感到意外。
創(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è)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)
為什么 FindFirstFile 會(huì)匹配短文件名呢？它不應(yīng)該只匹配長(zhǎng)文件名嗎？畢竟，只有舊的 16 位程序才會(huì)使用短文件名。
但這就是問題所在：16位程序才會(huì)使用短文件名。
通過稱為通用Thunk 的方法，16 位程序可以加載 32 位 DLL 并調(diào)用它。Windows 95和Windows NT中的Windows 16位仿真層嚴(yán)重依賴通用Thunk，因此他們不必編寫所有內(nèi)容的兩個(gè)版本。相反，16 位版本只是升級(jí)到 32 位版本。
但請(qǐng)注意，這意味著 32 位 DLL 將看到文件系統(tǒng)的兩個(gè)不同視圖，具體取決于它們是從 16 位進(jìn)程還是 32 位進(jìn)程托管的。
“然后讓 FindFirstFile 函數(shù)檢查其調(diào)用方是誰，并相應(yīng)地更改其行為”，因?yàn)槟銦o法信任返回地址，因此這種方法不會(huì)起作用。
即使解決了這個(gè)問題，你仍然會(huì)遇到跨進(jìn)程邊界的 16/32 互操作的問題。
例如，假設(shè)一個(gè) 16 位程序調(diào)用 WinExec（”記事本 X~1.HTM”）。32位記事本程序最好打開文件X~1.HTM，即使它是一個(gè)短文件名。此外，獲取文件屬性（如上次訪問時(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 副本將無法讀取在 16 位程序中運(yùn)行的 DLL 寫入的數(shù)據(jù)。
總結(jié)
由于 API 是一個(gè)已經(jīng)對(duì)外公開的調(diào)用規(guī)范，不可輕易修改，否則會(huì)破壞兼容性。為此在最新的操作系統(tǒng)上運(yùn)行那些老程序，只能最大限度地保留現(xiàn)有 API 的外部接口。同時(shí)，通過增加新的 API 來支持操作系統(tǒng)上開發(fā)出來的新特性。這就說我們經(jīng)常說的：對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉。
所以，”先知性” 是在規(guī)劃高層設(shè)計(jì)的一項(xiàng)特殊能力。?
網(wǎng)頁名稱：為什么FindFirstFile會(huì)查找短文件名？
瀏覽路徑：http://www.5511xx.com/article/djppisi.html
