【導讀】involvedindoingso.easilyaswell.Mac?theWindows-basedmachine.

　　

【正文】 需要很少的工作量。 微軟公司與兩個第三方 UNIX 工具提供商合作密切（ Bristol Technology 和 Mainsoft 公司），這使得開發(fā)人員把自己的 Win32 或 MFC 程序針對 UNIX 進行再編譯。開發(fā)人員可以通過直接和這些公司接觸來獲得更多的信息。 很早的時候，你可以選擇是編寫基于原始 API 或者基于 MFC 的程序。 一般來說你會發(fā)現(xiàn) MFC 程序可轉換性比 Win32 程序好，這是因為應用程序 框架的一個內在優(yōu)勢是對基本操作系統(tǒng)進行了一定程度的提煉，這種提煉類似于為你提供了一種安全保證。但是，開發(fā)人員常常對 MFC 有些疑問，例如： ? 如果我需要一種操作系統(tǒng)服務，但應用程序框架沒有提供如何處理 ? 直接調用 Win32 API， MFC 不會阻止你任何 Win32 API 的直接調用，只要你在函數名前面加全局運算符 (::)就可以了 . ? 我不懂 C++，還能用 MFC 嗎？ 當然可以。 MFC 是基于 C++的 , 但是你可以把 C 和 C++ 代碼很好的結合起來。 你在函數名前面加全局運算符 (::)就可以了 . ? 我怎么樣開始使用 MFC？ 從類開始，和 /或從讀一些書開始。 Visual C++ 系統(tǒng)提供了一個很好地 MFC 指南(Scribble)，然后，購買 MFC Migration Kit（可以網上付費，自己郵寄到微軟），它將幫助你把 C 程序移植轉換成為 MFC 和 C++。 如果你從今天開始編寫可轉換性好的程序，那么所有的轉換都會變得簡單。遵守一些基本的轉換方針會使你的代碼減少對特殊平臺的依賴。 不要假定任何事，特別是不要假定數據類型的大小、機器的狀態(tài)、數據類型排序、或者隊列不要假定簡單數據類型的大小，因為它們在不同的處理器上有不同的大 小。例如， int 在 Win16 和 Win32 上分別是 2 個字節(jié)和 4 個字節(jié)，無論如何，避免代碼依賴于數據類型的大小。使用 size of()來替換。使用 offset of()宏來判斷結構體的大小，而不要試圖手動計算。使用可編程的借口去訪問所有的系統(tǒng)或者隱藏“對象”，例如?；蚨选? 分解數據類型以提取單獨的字節(jié)或比特，會在從 Windows 到 Macintosh 的轉換時出問題，除非你在寫代碼時候小心，不假定任何類型分解。 包含了一些常量，用于輔助書寫獨立入平臺的宏，以訪問獨立的字節(jié)。 這看上去很明顯，因為沒有什 么比匯編語言可轉換性更差了。像 Microsoft Visual C++這樣有內置匯編程序的編譯器，可以很容易的擺脫匯編碼來提高速度。然而，如果你想轉換代碼，要避免這種誘惑。如果不是必須的，當今的編譯器可以產生和手動產生效果一樣好的匯編碼。我們在微軟的研究表明，問題出現(xiàn)的原因往往是算法的不好，而不是代碼的不好。實際上，由于行程和寄存器用法的過于復雜，在 RISC 機器上，手動產生的匯編碼要比機器產生的還要差。 用 c 語言編寫所有的程序，然后，如果你必須用匯編碼重寫，確保把兩種執(zhí)行程序都保存，利用條件編譯，并且保持兩 種程序的更新。 美國國家標準委員會（ ANSI）對 C/C++的一個主要目標是，提供一個可轉換的這種語言的執(zhí)行程序。理論上說，嚴格按照 ANSI C 編寫的程序，對于任何執(zhí)行 ANSI C 標準的編譯器都是可以轉換的。 Microsoft Visual C++提供了一個編譯器選項，可以用來檢查 ANSI 的兼容性。 Microsoft Visual C++為 ANSI C 提供了一些語言細節(jié)的補充，例如 4 字符常數和單行的注釋。使用 Microsoft C 擴充的程序可以轉換到 Microsoft Visual C++的任何其它執(zhí)行操作。因此，你可以使用 4 字符常數編寫程序，并且明白的程序可以轉換到任何16 位或 32 位 Microsoft Windows 平臺，或者是 Macintosh 平臺。 編譯器經常定位在目標機器體系上的結構，一些 RISC 機器，例如 MIPS R4000，對排列尤為敏感。排列錯誤可能導致執(zhí)行期錯誤，或者可能悄悄地和顯著的 影響你的程序。因此，避免封裝結構，限制對硬件接口與兼容性地東西如文件格式和磁盤結構的封裝。 使用函數原型對于可轉換代碼來說命令，所有的函數都應該有原型，并且這些原型應該與實際聲名的函數完全匹配。 遵循上面的方針，將會是你的代碼容易轉換，但是，如果你代碼是 16 位的 Windows代碼，那你第一步要做的是使它能在 Win32 下正常工作，這需要你的資源作額外的改變。 為 Win32編寫的代碼可以在任何 Windows版本下運行，有轉換庫時候還可以在 Macintosh下運行?？赊D換的代碼應該能在任意平臺上正確的編譯和執(zhí)行。 當然，如果你使用Windows NT 特有的 API，那他們在 Windows 下將不能工作，例如有些線程在 Windows NT 下工作，卻不能在 Windows 工作。這些函數區(qū)別應該在你設計程序時候考慮到。 Win16 和 Win32 的主要區(qū)別是尋址長度，意思是現(xiàn)在 32 位的指針對于或遠或近的關鍵詞不再支持了，也意味著分段存儲的代碼在 Win32 下會不能工作。 除了指針，句柄和圖形調節(jié)也是 32 位， 會解決一些大小不同的問題，但是仍然有一些工作需要作。 關于把你的程序在 Win32 下運行 的推薦的策略，是把你的代碼再編譯成 32 bit 的 , 注意錯誤消息和警告。接著，把復雜的函數和匯編語言函數用子函數代替，然后，利用上面的技術使你的主程序正確的工作。最后用一個可轉換的版本代替所有的子函數。 當你已經成功地把你的 Windows 程序從 16 bits 轉換為 32 bits,你應該準備好了著手把它轉換成 Macintosh，因為這兩個平臺之間存在很大的區(qū)別，所以這個工作會顯得令人畏懼。在你開始轉換你的程序之前，你最好先明白這些區(qū)別。 Macintosh 與 Windows 區(qū)別在三個方面： ? 編程樣式的區(qū) 別 ? 處理器的區(qū)別 ? 用戶界面的區(qū)別 這些方面的區(qū)別會在下面敘述。伴隨這些區(qū)別出現(xiàn)的轉換問題會在“從 Win32 到 Macintosh 的轉換”一節(jié)中討論。 Windows 和 Macintosh 的 APIs 完全不同，例如 : ? 事件模型不同。在 Windows 里，你分派消息到 WindowProcs，使用 DefWindowProc 處理你不關心的消息 。在 Macintosh 里，你有一個大的事件循環(huán)來處理所有可能出現(xiàn)的消息。 ? Windows 使用子窗口的概念， Macintosh 不使用子窗口。 ? Windows 應用程序 可以使用畫筆或者畫刷繪圖， Macintosh 應用程序只能使用畫筆。 ? Windows 中的控件建立在窗口類上，在 Macintosh 中， 控件和窗口沒有關系。 ? Windows 允許 256 位的色彩的操作 。Macintosh 只允許 16 位的操作。 因為兩個平臺之間的這些區(qū)別，從一個 Windows 應用程序到 Macintosh 程序的轉變如果沒有有力的工具，那將是一個艱巨的任務。 Windows 一直在 Intel x86 處理器上運行 (除了 Windows NT)，并且 Macintosh 一直在 Motorola 680x0 處理器上運行 (當然 , Macintosh 現(xiàn)在也能在 PowerPC 上運行 )。兩個處理器家族間的區(qū)別包括尋址和字節(jié)排序，還有 opcodes, 指令集 ,以及寄存器的名字和數量。 Intel 8086 處理器 , 以及隨后衍生的 80x86 系列處理器使用 16bit 地址， 只能支持 65,536 bytes 的存儲器尋址。為了支持使用更大的內存， Intel 使用分段存儲器結構， 這樣利用 16bit 寄存器可以訪問 1 兆 (2^20 bytes)內存，還有一個 unsigned 16bit 的偏移量。 Intel 最初的這種配置已經擴展，允許訪問更大的內存了，但是絕大多數現(xiàn)存的 Intel 程序需要把分離的代碼和數據放在 64k 的段存儲器上。 雖然 Intel x86 處理器從 80386 已經開始使用 32bit 尋址 , 但是因為兼容性的原因， Microsoft Windows 實際是一個 16bit 程序 , 并且所有的 Microsoft Windows應用程序都要寫成 16 位的。這就是說絕大多數的指針和句柄是 16 bits 長。 Microsoft Windows NT是一個純 32bit操作系統(tǒng) , 伴隨著它的出現(xiàn)，它所有的應 用程序都是 32bit的 , 指針和句柄也都是 32 bits 長。 因為 Windows NT 使用線性尋址 ,程序可以分散在 4G 的內存里面。 與之對比， Motorola 68000 和 PowerPC 處理器只能訪問 平坦的 32bit 存儲空間， 理論上說，這種平坦的存儲空間簡化了存儲器尋址。實踐中，因為 4byte 尋址由于太大不會一直使用， Macintosh 代碼一般分到不大于 32K 的段中存儲。 Microsoft Windows 和 Windows NT 只能運行在所謂的 littleendian 機器上— 處理器把不重要的字節(jié)放在前面，把最重要的字節(jié)放在最后面，與之對比， Motorola 680x0 和 PowerPC (一個所謂的 bigendian 結構 )把最重要的字節(jié)放在最前面，緊接著放第二重要的字節(jié)，依此類推，最不重要的放在最后面。 編譯器通常為你的程序處理字節(jié)排序的細節(jié)，然而，好的可轉換性強的代碼從不依賴字節(jié)的排序 Microsoft Windows 和 Macintosh 在很多關鍵地方的用戶界面有較大區(qū)別，包括菜單，文件名，和多文檔界面程序。 Macintosh 只有一個菜單 欄，并且不管屏幕上窗口數量和布局如何，它總是處于同一個位置?！盎顒哟翱凇? 包含菜單，這個菜單會隨著活動窗口的改變而動態(tài)的變化。然而 Windows, 給每個處于頂端的窗口以菜單。而且在 MDI 時 ,每一個子窗口可以有自己的菜單， MDI 會在下面詳細討論 。 Macintosh 應用程序通常包含 Apple menu，它包含了所有桌面安裝的附件，以及應用程序的入口。在 System 7 中 , Macintosh 菜單的最右邊包含了一個 Apple 的幫助圖標，還有一個負責應用程序之間切換的菜單。 Windows 應用程序 通常在窗口左上角有一個系統(tǒng)菜單，這個菜單包含系統(tǒng)級功能如窗口大小，移動，關閉窗口，還有一個可以在應用程序之間切換的被稱作任務管理器的項目。 通常， Windows 程序包含和鍵盤等效的菜單項目，這些劃有底線的字母分布在每一個菜單入口，用戶可以用鍵盤代替鼠標來選擇它們。這些是慣例而不是必需的，盡管Macintosh 程序必須有這些等價項。 文件名和路徑名是 Windows 和 Macintosh 之間最大的區(qū)別之一，而且也許是最難出的。許多程序員說處理文件名是轉換中最費時間和精力的地方。你的 Windows 應用程序 也許能夠處理的文件名類似于 C:\ACCTG\DATA\. MSDOS 和 Windows 應用程序遵守傳統(tǒng)的 文件格式。另一方面 Macintosh 應用程序處理的文件名卻類似于 September, 1993 Accounting Data. MDI 窗口允許一個活動窗口框架內有多個子窗口，許多 Windows 程序，例如 Microsoft Word 是 MDI 應用程序。 MDI 程序的一個特點是子窗口最小化后，會在 MDI框架內部產生一個圖標。每個 MDI 子窗口也會自己的菜單 。 Macintosh 不支持 MDI 窗口，一個應用程序可以打開多個窗口；然而這些窗口不能變成圖標，并且它們共享一個菜單。這個區(qū)別也許需要程序針對 Macintosh 轉換而重新設計。 最終你能夠繼續(xù)作你最了解的工作。編寫針對 Windows API，但又能轉換成其它平臺版本運行的程序， Visual C++現(xiàn)在使你能夠做到這些。保持你的代碼的可轉換性，時時考慮到轉換性能，并且使用有效的工具可以幫助你在多平臺之間輕松地跳躍。