編寫可以在所有WINDOWS平臺上執行的應用軟體 (轉)

編寫可以在所有WINDOWS平臺上執行的應用軟體 (轉)[@more@]

編寫可以在所有平臺上執行的應用 

 
---摘自軟體世界1995.11 作者不詳, 對原作有部分改動, 如"串"改為"執行緒", 
 "對話"改為"對話方塊"等等. ---- TSAI ---- 
 
Windows 95的出現使PC的使用非常容易, 並吸引越來越多的人使用PC. 這將導致對 
WINDOWS應用軟體以及基於WINDOWS應用軟體的開發人員的巨大需求. WINDOWS 95為 
應用軟體的更易使用以及和WINDOWQS平臺的更高整合, 帶來新的景象和機會. 
 
和OLE2.0 
對一個較高水平而言, 基於WINDOWS的應用人員在開發WINDOWS95的應用軟體 
時需要考慮五個重要因素: 最重要的兩個因素是WIN32和OLE2.0. 它們是為所有平臺編寫 
大的WINDOWS應用軟體的基本建造模組; 第三個因素是開發者應遵循正為未來的WINDOWWS 
操作開發的USER INTERFACE DESIGN GU, 它包含使用的通用和對話; 第四個 
因素是PLUG-AND-PLAY事件跟蹤, 這使得顧客只需插入一個裝置並開啟PC--系統做剩下 
的所有工作. 開發人員編寫的應用軟體應是PLUG-AND-PLAY事件清楚的, 以便於應用軟體 
能夠很好地安置在WINDOWS 95中,對裝置的插入和拔出這些變化很清楚; 最後一個因素是, 
開發者應當利用所提供的對註冊資訊,長名和通用命名約定(UNC)路徑名的支援以及 
所提供的資料型別的檔案觀察器, 使得開發出的應用軟體和WINDOWS95外殼較好地整合在 
一起. 幸運的是, 開發者考慮上述五個因素以後開發出的應用軟體透過WIN32 仍可在 
WINDOWS NT和WINDOWS 3.1上執行. 不僅如此, 開發出的應用軟體還可以在 
WINDOWS NT下一版本CAIRO下執行. 
 
WIN32: 一個API, 多個平臺 
使用WIN32 QPI, 可以開發出在WINDOWS95, WINDOWS NT, 以及WINDOWS 3.X上均能 
成功執行的應用軟體, 該軟體仍可利用基礎平臺的特徵. 主要原因在於, WIN32 API 
提供一套向上相容的WIN32功能,資訊,結構, 它們在WINDOWS95, WINDOWS NT和WINDOWS 
3.X或WINDOWS NT的下一版本CAIRO上執行的結果是一致的. 
特定平臺的基礎能力決定了WIN32 API在其中實現的程度. 例如, 所有WINDOWS平臺, 
包括WINDOWS 3.1 WITH WIN32, 為包括32位虛擬管理(VirtualAlloc)和對映 
檔案的強有力功能提供一個環境, WINDOWS95和NT允許應用軟體編寫者利用一些附加 
功能, 如執行緒和長檔名, WINDOWS 3.X WITH WIN32S沒有這些功能 . WINDOWSNT提供了 
WINDOWS95 和WIN32S沒有的一些附加功能, 例如性和UNICODE API. 
由於WIN32S和WINDOWS95上還保留著不被支援的功能, 使用者可用GetVersion探測 
基礎平臺的種類, 因而在一次中可利用不同水平的功能(依平臺種類而定). 例如, 
使用者可以編寫一個應用軟體, 它在WINDOWS95和WINDOWS NT上執行時使用長檔名和 
執行緒, 在WINDOWS 3.X WITH WIN32S上執行時提供8.3檔名, 並且使執行緒無效. 
與基於WINDOWS的16位應用軟體不同,執行在WINDOWS95 和NT上的WIN32應用軟體搶佔式 
執行多工, 也能在它們分離的,保護的地址空間執行多個執行執行緒. WIN32應用軟體允 
許使用者真正地同時操作多個任務. 例如, 使用者可以同時進行編譯,複雜的電子資料表核 
算, 檔案列印及單人玩紙牌遊戲. 
 
可移植的WIN32應用軟體 
從發展的角度來看, 應用軟體可以訪問32位的帶狀儲存空間, 避免使用段儲存空間. 
WIN32 API就利用了目前的32位, 也允許應用軟體使用新的API創新, 例如路徑, 
Bozier以及執行緒. WIN32 API也可以移植到非平臺, 例如MIPS R4000/R4400, DEC 
ALPHA AXP以及POWERPC. 這意味著使用者只需重新編譯和測試應用軟體, 該軟體就可在多 
個上執行. 
把現有的WINDOWS 16位應用軟體4移植到WIN32中要相對容易些. 事實上, 伴隨WIN32 SDK 
提供了一個被稱為PORTTOOL的工具, 可以在把WIN16應用軟體移植到WIN32的過程中掃描 
, 並指出哪些程式碼需要加以修改. PORTTOOL的一個修訂版本, 已經出現在MS 
DEVELOPMENT LIBRARY中, 不僅可以幫助軟體移植, 也可以示範一個應用軟體如何做到 
既可以利用所在基礎平臺的獨特功能, 雙可以在所有平臺上執行. 
 
連線和嵌入 
OLE2.0版本為終端使用者提供了一個用來建立複合文件的一致性方法使交叉應用程度的編 
程成為可能並提供在應用軟體和桌面之間的拖放功能 . 它也允許使用者從外殼閱讀 
豐富的檔案資訊, 例如圖示,動作以及應用軟體自身的特性. 
WINDOWS95是MS的第一個實現以檔案為中心,用在個人計算機上的作業系統產品. 
WINDOWS 95拉口開發的目的是為由OLE2.0規定定義的終端使用者功能提供基礎以及使 
WINDOWS當前使用者開始使用WINDOWS95時使用就很高. 
為了與WINDOWS95環境很好地整合在一起, 應用軟體應當採用OLE2.0技術, 例如複合文 
件, 拖放功能, 可視編輯以及自動化. 應用軟體使用複合檔案以及在被稱作為 
"SUMMARY INFORMATION"的檔案中駐留一個資訊流是非常重要的. WINDOWS95將使用該流 
的資訊提供關於來自外殼中檔案的補充資訊. 另外, 如果使用者為他們的應用軟體註冊 
OLE2.0, OLE類標識等, 並且適當設定檔案型別, WINDOWS95 能夠跟蹤哪一個應用軟體 
建立了哪一個不帶副檔名的檔案, 以獲得有關OLE2.0重要性的更加具體的資訊. 
 
使用者介面設計指導: 一致性和整合性 
 
WINDOWS作業系統和基於WINDOWS的應用軟體的一個大的優點即一致性. 在學習如何使用 
WINDOWS和至少一個基於WINDOW析應用軟體以後, 熟悉一個新的應用軟體相對來說就比較 
容易. 一致性也建造了一個內聚環境, 允許人們把注意力集中於他們的資料而不是應用 
軟體和外殼. 
另一個優點是USER INTERFACE DESIGN GUIDE, 它描述瞭如何設計執行在WINDOWS操作系 
統上的軟體. 它的目的是促進基於WINDOWS軟體內部以及軟體之間的可視性和功能的一 
致性. 
WINDOWS介面功能的增強為從基本的圖形使用者介面設計向更加物件導向的使用者介面設計演 
變鋪平了道路, 物件導向的使用者介面以資料為中心, 而不是以應用軟體為中心. 這種設 
計是OLE所提出方向的繼續作為結果. 開發都和設計者可能需要重新考慮介面中應包括 
哪些基本的組成部分(物件)以及物件的操作和屬性. 雖然應用軟體仍是重要的, 但它們 
不再是使用者考慮的焦點. 使用者應當能夠不用考慮如何開始一個應用軟體就能與他們的數 
據相互作用, 因此使用者可以把注意力集中在他們的任務上. 
應用軟體可以自動使用許多新的可視工具以發出標準的WIN32 API. 例如, 一個新的 
帶有左對齊標題文字的標題條將出現在應用軟體中, 對應用軟體部件未作任何修改. 對 
於其他標準的WINDOWS控制元件, 情況也是這樣. 然而, 如果開發者開發一個使用使用者控制元件 
的應用軟體, 開發者應當瞭解一下設計指導, 考慮使用新的通用控制元件和對話方塊. 
WIN95引進幾個新的WIN32 API, 對通用控制元件和對話方塊提供支援. 使得新的可視使用者介面 
特徵的實現容易些. 新的通用控制元件包括工具條, 狀態條, 列標題(COLUMN HEADING), 標 
志(TABS), 幻燈片(SLIDER), 進度顯示器(PROGRESS INDICATOR), 豐富的文字控制元件, 表 
顯示以及樹顯示. 也將對現有通用對話方塊進行一些修改, 以增加一些補充功能, 現有通 
用對話方塊包括OPEN, SAVE AS以及PRINT SETUP. 已經使用通用對話方塊的應用軟體應當繼 
續這樣做. 
當WIN95和NT CAIRO裝備有再分配動態連線庫(DLL)時, 透過DLL新的通用控制元件和對話方塊 
也適用於WIN32S和WINNT的當前版本. 這樣, 應用軟體可以利用新的控制元件和對話方塊, 而且 
仍然可以執行在所有的WINDOWS平臺. 修訂的USER INTERFACE DESIGN GUIDE, 可以在 
DEVELOPMENT LIBRARY中找到, 覆蓋了新的控制元件和對話方塊以及其他風格的應用軟體指導準 
則. 
 
PnP事件: 使PC用起來更容易 
 
應用軟體應當支援新的PLUG-AND-PLAY資訊. MS與PC系統和部件的製造商密切合作, 開 
發了新的PNP硬體設計標準, 該標準可以實現PC系統上裝置的自動和動態配置. PNP將成 
為MS作業系統產品的標準特徵, WIN95首次採用了PNP功能. 
雖然PNP可能看起來象硬體系統專有的創造, 但它提供了一些關鍵功能, 使得應用軟體智 
能地響應系統的變化. 在這種方式下, 一般應用軟體也將很好地與WINDOWS系統整合在一 
起. 當硬體配置發生動態變化, 例如, 插入一個傳真調變解調器, 或者介面卡, 
應用軟體將收到有關資訊, 並且可以在沒有請求使用者介面的任何干預的情況下, 自動利 
用這些新的硬體的能力. 這種設計方法使得PC對新的和現有使用者都很直觀. 例如, 當 
計算機網路上移去, 應用軟體能夠提醒使用者注意網路上的開啟的檔案. 
此外, 應用軟體可能關心在掃描過程中顯示解析度的變化( 這種變化可能發生在WIN95 
上). 也放存在不同的圖示或位對映, 應用軟體使用它們依賴於顯示解析度. 應用軟體 
獲得WM_DISPLAYCHANGED訊息, 它能作出必要的. 
另一個重要的特徵, 被稱為慢連線, 允許應用軟體對聯絡擁有智慧化的知識. 如 
果應用軟體執行在透過遠端訪問服務連線到網路的計算機上, 應用軟體對從網路和自 
動儲存檔案裝入資料非常靈敏. 
應用軟體也應當為網路上的長操作提供一個CANCEL按芻, 在相同的方式下, 應用軟體 
能夠監視ADVANCED POWER MANAGEMENT(APM)資訊以檢測系統是否依賴電池執行. 如果 
系統依賴電池執行, 為了完成背景任務應用軟體能夠作出轉以及自動儲存頻率的 
靈敏選擇. 
如果使用者加進這個功能, WINDOWS NT和WIN32上將發生什麼? 對於其中大部分組成, 什 
麼也不發生. WINDOWS NT對檢測慢連線(SLOWLINK)的支援, 如同執行在WINDOWS FOR 
WORKGROUP上的WIN32所做的那樣. 但是, WINDOWS NT和WIN32S的當前版本對PNP並不清 
楚, 所以它們不宣傳這些訊息. WINDOWS NT CAIRO將對PNP完全清楚, 支援所有PNP訊號 
和事件. 
 
外殼支援 
 
WIN95透過提供單一工具與所有資源( 檔案, , 印表機以及其他各種設施 )一起工 
作, 簡化了與系統資源的工作. WIN95把各種不同的管理者-- PROGRAM MANAGER, FILE 
MANAGER, CONTROL PANEL, PRINT MANAGER和WINDOWS SETUP聯合起來--並且可以把所有 
資源組織在一個靈活的層次結構中. 為了系統資源, 拖放功能操作將受到支援, 一個桌 
面區域將用來放置經常訪問的資源. 
增強功能還包括5個閱讀器, 使使用者可以在沒有建立檔案的應用軟體的條件下閱讀 
檔案的內容. WIN95為必個資料型別提供一些標準的檔案閱讀器. 然而, 使用者也可以為 
自己的資料型別提供檔案閱讀器, 或者提供帶有更多特徵( 例如複製和列印 )的檔案 
閱讀器. DEVELOPMENT LIBRARY的未來版本將提供更多有關檔案閱讀器的資訊. 
WIN95中對長檔案和UNC路徑名(SERVERSHARE)的支援使得資訊瀏覽和安置非常方便. 
應用軟體應當使用UNC路徑名, 而不是器字母, 以便於在網路共離上開啟的檔案, 
下一次在沒有請求使用者與相同的驅動器字母再聯絡的條件下開始對話方塊時, 仍可能很 
容易地被訪問. WINNT和WFW3.11已經支援UNC路徑名. WIN95和WINNT支援長檔名, 但 
使用者的應用軟體在WIN32S上將看8.3檔名. 如果使用者使用通用對話方塊, 使用者將自動獲得 
長檔名和UNC路徑名支援, 所以, 使用者所要做的全部事情是確保緩衝區足夠儲存255個 
字元的長檔名, 外加一個260字元的UNC路徑名. 
使用者也需要為他的應用軟體在系統註冊處註冊幾個關鍵項, 如大小圖示, 語意選單的缺 
省動詞, 附加屬性頁. WIN95將利用這些註冊項顯示使用者應用軟體的有關資訊. 
 
踏上走向WINDOWS 95的路 
 
既然使用者已經知道WIN95應用軟體的一些重要特徵, 便可以很容易地設計開發32位的 
WIN95應用軟體, 開發出的應用軟體也能執行在WINNT和WFW WITH W32S上. 下面給出一些 
值得注意的地方: 
 1.檢查PORTTOOL. 
 2.請使用WIN32眾多開發工具的一個工具, 如WIN32 SDK, VC FOR WINNT, WATCOM C++ 
95,  C 6.1, BC4.0或者PHARLAP TNT. 
 3.按WINDOWS95 特徵設計應用軟體, 開發WIN32 OLE2.0支援的應用軟體. 
 4.首先在WINNT和WIN32S上, 然後在WIN95上測試應用軟體. 
 
PORTTOOL 
 
使用者可以在他的應用軟體中加入許多特徵, 以利用基礎平臺. 這些特徵包括執行緒, 增強 
的超檔案, 多, 通訊, 網路, 高階圖形, 安全等等. 使用者可以利用DEV LIBRARY中 
的"WRITING GREAT WIN32 APPLICATIONS"表幫助確定各個平臺所能提供的功能. 使用者 
然後就可以決定在他的應用軟體中加入哪些特徵以及如何使應用軟體可以在多個平臺運 
行. 
下面透過修改後的PORTTOOL樣本來介紹執行緒. PORTTOOL使得WIN95和WINNT支援執行緒, 但 
在WIN32S執行時它卻使得執行緒無效. 同樣, 在WIN95上執行時, PORTTOOL使得一個小圖示 
可以由WIN95外殼顯示. 當螢幕解析度發生變化時它也彈出對話方塊, 以顯示應用軟體能 
夠對PNP事件作出反應. 
當然, 一個實際的應用軟體所要做的事情遠遠超過一個對話方塊. 進一步地, 當PORTTOOL 
執行在安裝有雙處理器的NT系統上時, 它將自動利用雙處理器的優點, 每個執行緒在兩個 
處理器之間均勻分配. 些外, 執行在NT和WIN95上的PORTTOOL支援長檔名, 而WIN32S 
要用8.3檔名. 所有這些都可以發生在一次執行過程中! 
下列顯示如何探測使用者的應用軟體執行所依賴的平臺及如何利用平臺之間的不同. 這些 
都非常容易. 當PORTTOOL執行在WIN3.X WITH WIN32S上時, 下述摘自PORTTOOL.C的程式碼 
片斷的背景選擇無效. 
 //獲得OS版本資訊, 並儲存在一個全域性變數中 
 dwVersion = GetVersion() 
 ... ... 
 //處理不同平臺 
 if( dwVersion  //Windows NT 
 } else if( LOBYTE(LO(dwVersion()))  //Win32s 
 //由於不能使用執行緒, 所以background porting 無效 
 EnableMenuItem( GetMenu(hWnd), IDM_PORTBKGND, MF_GRAYED ) 
 } else{ 
 // Windows 95 
 } 
 
WINDOWS 95 程式碼鍵 
 
作為開始, 在幾個工具的幫助下, 使用者既可以把16位基於WINDOWS的應用軟體移植到 
WIN32的, 支援OLE的應用軟體中, 也可以重新開發WIN32的, 支援OLE的應用軟體. 利用 
USER INTERFACE DESIGN GUIDE, 使用者可以在使用現有對話方塊及正確理解新控制元件的條件 
下準備應用軟體來開拓WIN95. 使用者可以利用"Writing Great Win32 Applications"表 
的幫助來了解三個平臺提供的功能. 當使用者準備在目標平臺上測試應用軟體, 使用者有 
理由相信, 在NT和WIN32S上均可執行的應用軟體一定也可以在WINDOWS95上執行. 
同於不同的平臺有不同的特徵, 在三個平臺上都測試一下應用軟體是極其重要的. 平臺 
之間的不同主要包括: 
 .WIN95和NT均是搶佔式執行多工環境, 為基於WIN32的應用軟體提供分離的受保護 
地址空間, 而WIN3.X with WIN32S是一個非搶佔式執行多工環境, 在該環境裡所有 
應用軟體共離相同的地相空間. 
 .WINDOWS 3.X with WIN32S 有一個同步輸入佇列. WIN95 和NT有不同步的輸入佇列. 
 .WIN32S執行在WINDOWS 3.X上, 因此和WINDOWS 3.X一樣, 只能為GDI( 圖形裝置介面) 
區提供64K儲存空間. 相反, WIN95 和NT在32位堆以外分配區域, 因此, 區域可以和可 
提供的儲存空間一樣大. 
 .WINDOWS3.X with WIN32S和WIN95有16位全域性座標系統, 該系統限制的X和Y座標 
在32K位元組範圍之內. NT使用32位全域性座標系統, 允許圖文的X和Y座標達到2BG位元組. 
如果32位數值傳送到文字和圖形函式, WIN32S和WIN95在執行請求操作之前截去座標的 
高16位. 
 
建立一個大型WINDOWS95應用軟體所要做的最重要的十件事情 
 
10.在所有的WINDOWS平臺上測試應用軟體. 
9.在系統註冊處登記大小圖示, 預設動詞等. 
8.監視PNP事件. 
7.支援長檔名和UNC路徑名. 
6.使用通用控制元件和對話方塊. 
5.遵循USER INTERFACE DESIGN GUIDE. 
4.註冊OLE CLASS ID. 
3.在OLE 2.0複合檔案中駐留SUMMARY資訊流. 
2.實現OLE 2.0拖放功能. 
1.使用WIN32 API.