【正文】 臺(tái)版本運(yùn)行的程序， Visual C++現(xiàn)在使你能夠做到這些。這個(gè)區(qū)別也許需要程序針對(duì) Macintosh 轉(zhuǎn)換而重新設(shè)計(jì)。這些是慣例而不是必需的，盡管Macintosh 程序必須有這些等價(jià)項(xiàng)。 Macintosh 只有一個(gè)菜單欄，并且不管屏幕上窗口數(shù)量和布局如何 ，它總是處于同一個(gè)位置。 雖然 Intel x86 處理器從 80386 已經(jīng)開(kāi)始使用 32bit 尋址 , 但是因?yàn)榧嫒菪缘脑颍?Microsoft Windows 實(shí)際是一個(gè) 16bit 程序 , 并且所有的 Microsoft Windows應(yīng)用程序都要寫(xiě)成 16 位的。 ? Windows 允許 256 位的色彩的操作 。 Macintosh 與 Windows 區(qū)別在三個(gè)方面： ? 編程樣式的區(qū)別 ? 處理器的區(qū)別 ? 用戶界面的區(qū)別 這些方面的區(qū)別會(huì)在下面敘述。這些函數(shù)區(qū)別應(yīng)該在你設(shè)計(jì)程序時(shí)候考慮到。 編譯器經(jīng)常定位在目標(biāo)機(jī)器體系上的結(jié)構(gòu)，一些 RISC 機(jī)器，例如 MIPS R4000，對(duì)排列尤為敏感。實(shí)際上，由于行程和寄存器用法的過(guò)于復(fù)雜，在 RISC 機(jī)器上，手動(dòng)產(chǎn)生的匯編碼要比機(jī)器產(chǎn)生的還要差。使用可編程的借口去訪問(wèn)所有的系統(tǒng)或者隱藏“對(duì)象”，例如棧或堆。 你在函數(shù)名前面加全局運(yùn)算符 (::)就可以了 . ? 我怎么樣開(kāi)始使用 MFC？ 從類開(kāi)始，和 /或從讀一些書(shū)開(kāi)始。這些包括針對(duì) MIPS R4000 處理器系列和前面說(shuō)的 DEC Alpha AXP 芯片還有 Motorola Power Windows NT 下運(yùn)行，能都產(chǎn)生針對(duì)DEC Alpha 和 Motorola PowerPC 的高度優(yōu)化的 Win32 應(yīng)用程序。 2. 把你的 Windows 應(yīng)用程 序從 16 位代碼轉(zhuǎn)換成 32 位代碼，這也許是最復(fù)雜和耗時(shí)間的工作。 下面的第一章，說(shuō)明了 Visual C++是怎樣針對(duì) Macintosh 工作的。但是這兩個(gè)完全不同的操作系統(tǒng)之間有太多的不同，需要開(kāi)發(fā)人員學(xué)習(xí)新的 API、新的范例程序、新的工具。開(kāi)發(fā)人員希望能夠支持不同的平臺(tái)，例如Windows , Windows NT, 和 Windows 95 操作系統(tǒng) , 還有 Apple, Macintosh, UNIX, 和 RISC (reduced instruction set puter)等。t assume any particular byte order. contains constants that can be used to help write platformindependent macros to access individual bytes in a word. This may seem obvious, because nothing could be less portable than assembly language. Compilers, such as Microsoft Visual C++, that provide inline assemblers make it easy to slip in a little assembler code to speed things up. If you want portable code, however, avoid this temptation. It may not be necessary. Modern pilers can often generate code as good as handtuned native assembler code. Our own research at Microsoft indicates that performance problems are more often the result of poor algorithms than they are of poor code generation. Indeed, with RISC machines, handturned native assembler code may actually be worse than machinegenerated code, due to the plexity of instruction scheduling and picking register usage. Write all routines in C first。 API libraries, which thunk 32bit calls down to their 16bit counterparts. Developers who want their applications to be able to take advantage of the hot new RISC hardware, such as DEC Alpha AXP machines, can use the special multiple platform editions of Visual C++. These include versions for the MIPS R4000 series of processors as well as the aforementioned DEC Alpha AXP chip and the Motorola Power PC. These toolsets run under Windows NT and create highly optimized native Win32 applications for DEC Alpha and Motorola PowerPC platforms. Developers who have repiled their Win32 sources using these toolsets are amazed at how simple it is. Since the operating system is identical on all platforms, and the tools are identical, little work has to be done in order to achieve a port. The key difference in the RISC machines from Intel is the existence of a native 64bit integer, which is far more efficient than on 32bit (that is, Intel) processors. Microsoft works closely with two thirdparty UNIX tools providers, Bristol Technology and Mainsoft Corporation, to allow developers to repile their Win32based or MFCbased applications for UNIX. Developers seeking additional information should contact those panies directly. You39。 version , Microsoft Windows NT174。, UNIX, and RISC (reduced instruction set puter) machines. Until recently, developers wanting to build versions of their application for more than one platform had few choices: ? Maintain separate code bases for each platform, written to the platform39。t part of the framework? Call the Win32 API directly. MFC never prevents you from calling any function in the Win32 API directly. Just precede your function call with the global scope operator (::). ? I don39。re ready to embark on porting it to the Macintosh. Because significant differences exist between the two platforms, this task can appear daunting. Before you can begin to port your application, you need to better understand these differences. The Macintosh is differentiated from Windows in three general areas: ? Programming model differences ? Processor differences ? User interface (UI) differences These areas of difference are described below. Porting issues that acpany these differences are discussed in the section titled Porting from Win32 to the Macintosh. The Windows and Macintosh APIs are pletely different. For example: ? The event models are different. In Windows, you dispatch messages to WindowProcs. You use DefWindowProc to handle messages in which you39。 ? 構(gòu)建們自己的多平臺(tái)層并支持它。如果你的代碼能順利地實(shí)現(xiàn)對(duì) Macintosh 平臺(tái)的再編譯，那么你就會(huì)發(fā)現(xiàn)它其它平臺(tái)上的再編譯也不難。一個(gè)基于以太網(wǎng)或串行連接的傳輸層會(huì)把目標(biāo)代碼移動(dòng)遠(yuǎn)端的目的 Macintosh 機(jī)器上運(yùn)行。 4. 利用 Macintosh 轉(zhuǎn)換庫(kù)把 Win32 API 代碼轉(zhuǎn)換成 Macintosh 代碼，并利用 Visual C++來(lái)編譯、連接、調(diào)試。開(kāi)發(fā)人員可以通過(guò)直接和這些公司接觸來(lái)獲得更多的信息。遵守一些基本的轉(zhuǎn)換方針會(huì)使你的代碼減少對(duì)特殊平臺(tái)的依賴。 這看上去很明顯，因?yàn)闆](méi)有什 么比匯編語(yǔ)言可轉(zhuǎn)換性更差了。理論上說(shuō)，嚴(yán)格按照 ANSI C 編寫(xiě)的程序，對(duì)于任何執(zhí)行 ANSI C 標(biāo)準(zhǔn)的編譯器都是可以轉(zhuǎn)換的。 使用函數(shù)原型對(duì)于可轉(zhuǎn)換代碼來(lái)說(shuō)命令，所有的函數(shù)都應(yīng)該有原型，并且這些原型應(yīng)該與實(shí)際聲名的函數(shù)完全匹配。 關(guān)于把你的程序在 Win32 下運(yùn)行的推薦的策略，是把你的代碼再編譯成 32 bit 的 , 注意錯(cuò)誤消息和警告。在 Windows 里，你分派消息到 WindowProcs，使用 DefWindowProc 處理你不關(guān)心的消息 。 Windows 一直在 Intel x86 處理器上運(yùn)行 (除了 Windows NT)，并且 Macintosh 一直在 Motorola 680x0 處理器上運(yùn)行 (當(dāng)然 , Macintosh 現(xiàn)在也能在 PowerPC 上運(yùn)行 )。 因?yàn)? Windows NT 使用線性尋址 ,程序可以分散在 4G 的內(nèi)存里面。而且在 MDI 時(shí) ,每一個(gè)子窗口可以有自己的菜單， MDI 會(huì)在下面詳細(xì)討論 。你的 Windows 應(yīng)用程序也許能夠處理的文件名類似于 C:\ACCTG\DATA\. MSDOS 和 Windows 應(yīng)用程序遵守傳統(tǒng)的 文件格式。保持你的代碼的可轉(zhuǎn)換性，時(shí)時(shí)考慮到轉(zhuǎn)換性能，并且使用有效的工具可以幫助你在多平臺(tái)之間輕松地跳躍。 Macintosh 不支持 MDI 窗口， 一個(gè)應(yīng)