附录A 译文
利Visual C++代码运行台
天台开发热门课题开发员希够支持台例Windows 3x Windows NT Windows 95 操作系统 Apple Macintosh UNIX RISC (reduced instruction set computer)等直久前希开发台务开发者少种选择：
根台应程序接口台准备份单独代码
利跨台工具提供虚拟API
构建台层支持
天种新办法开发员通微软第三方工具现存针Windows API写代码列举种台重新编译文关注种新办法相关方法点
目前Macintosh紧Windows市场流行图形户界面系统两完全操作系统间太需开发员学新API新范例程序新工具般情况Macintosh应程序开发需Windows代码库增加维护升级复杂度
WindowsMacintosh代码转换难情形文重点容果代码利实现Macintosh台编译会发现台编译难
Microsoft Visual C++针Macintosh提供跨台编辑器提供工具工具Windows NT Windows 95台运行Windows代码编译适应Motorola 680x0PowerPC 处理器提供转换库辅助Windows程序Macintosh运行开发单源代码（针Win32® API）运行Microsoft Windows Apple Macintosh台
面第章说明Visual C++样针Macintosh工作源代码Windows NTWindows 95面编写编译连接工具产生68000 PowerPC然代码Macintosh资源基太网串行连接传输层会目标代码移动远端目Macintosh机器运行Macintosh应程序Macintosh台运行远端Windows机器面调试
现Apple公司两Macintosh结构竞争转换性尤重转换步骤取决处理程序16位32位般说Macintosh转换包括步：
遵循转换性方针程序更容易转换仅助保证基680x0 Macintosh机器转换助更新基RISC 芯片powerful PowerPC机器转换
Windows应程序16位代码转换成32位代码许复杂耗时间工作
独特Windows应程序分割熟悉执行方式Macintosh涉条件编译者设计工程资源树
利Macintosh转换库Win32 API代码转换成Macintosh代码利Visual C++编译连接调试
微软基础类库MFC 40实现新功例OLE 20服务器客户端者利ODBC数库支持MFC编写代码Macintosh高转换性
编写专门Macintosh代码利Macintosh独特特点利Apple 事件出版定购
开发员通Visual C++特殊台编辑器充分利新RISC硬件例DEC Alpha AXP机器包括针MIPS R4000 处理器系列前面说DEC Alpha AXP 芯片Motorola Power PC工具Windows NT 351运行产生针DEC AlphaMotorola PowerPC高度优化Win32应程序已工具进行编译Win32资源开发员程简单感惊讶台操作系统独立工具独立完成转换确需少工作量
微软公司两第三方UNIX工具提供商合作密切（Bristol Technology Mainsoft公司）开发员Win32MFC程序针UNIX进行编译开发员通直接公司接触获更信息
早时候选择编写基原始API者基MFC程序 般说会发现MFC程序转换性Win32程序应程序框架优势基操作系统进行定程度提炼种提炼类似提供种安全保证开发员常常MFC疑问例：
果需种操作系统服务应程序框架没提供处理
直接调Win32 APIMFC 会阻止Win32 API直接调函数名前面加全局运算符()
懂C++MFC？
然MFC基C++ C C++ 代码结合起
函数名前面加全局运算符()
样开始MFC？
类开始读书开始Visual C++ 系统提供MFC指南(Scribble)然购买MFC Migration Kit（网付费邮寄微软）帮助C程序移植转换成MFCC++
果天开始编写转换性程序转换会变简单遵守基转换方针会代码减少特殊台赖
假定事特假定数类型机器状态数类型排序者队列假定简单数类型处理器例intWin16Win32分2字节4字节避免代码赖数类型size of()换offset of()宏判断结构体试图手动计算编程口访问系统者隐藏象例栈堆
分解数类型提取单独字节特会WindowsMacintosh转换时出问题非写代码时候心假定类型分解LIMITSH包含常量辅助书写独立入台宏访问独立字节
明显没什汇编语言转换性更差Microsoft Visual C++样置汇编程序编译器容易摆脱汇编码提高速度然果想转换代码避免种诱惑果必须编译器产生手动产生效果样汇编码微软研究表明问题出现原算法代码实际行程寄存器法复杂RISC机器手动产生汇编码机器产生差
c语言编写程序然果必须汇编码重写确保两种执行程序保存利条件编译保持两种程序更新
美国国家标准委员会（ANSI）CC++目标提供转换种语言执行程序理说严格ANSI C编写程序执行ANSI C标准编译器转换Microsoft Visual C++提供编译器选项检查ANSI兼容性
Microsoft Visual C++ANSI C提供语言细节补充例4字符常数单行注释Microsoft C扩充程序转换Microsoft Visual C++执行操作4字符常数编写程序明白程序转换16位32位Microsoft Windows台者Macintosh台
编译器常定位目标机器体系结构RISC机器例MIPS R4000排列尤敏感排列错误导致执行期错误者悄悄显著影响程序避免封装结构限制硬件接口兼容性东西文件格式磁盘结构封装
函数原型转换代码说命令函数应该原型原型应该实际声名函数完全匹配
遵循面方针会代码容易转换果代码16位Windows代码第步做Win32正常工作需资源作额外改变
Win32编写代码Windows版运行转换库时候Macintosh运行转换代码应该意台正确编译执行然果Windows NT 特APIWindows 3X工作例线程Windows NT 工作Windows 311工作函数区应该设计程序时候考虑
Win16 Win32区寻址长度意思现32位指针远关键词支持意味着分段存储代码Win32会工作
指针句柄图形调节32位WINDOWSH会解决问题然工作需作
关程序Win32运行推荐策略代码编译成 32 bit 注意错误消息警告接着复杂函数汇编语言函数子函数代然利面技术程序正确工作转换版代子函数
已成功Windows程序16 bits 转换32 bits应该准备着手转换成 Macintosh两台间存区工作会显令畏惧开始转换程序前先明白区Macintosh Windows区三方面：
编程样式区
处理器区
户界面区
方面区会面叙述伴区出现转换问题会Win32 Macintosh转换节中讨
WindowsMacintoshAPIs 完全例
事件模型Windows里分派消息 WindowProcs DefWindowProc 处理关心消息 Macintosh里事件循环处理出现消息
Windows子窗口概念Macintosh 子窗口
Windows应程序画笔者画刷绘图 Macintosh 应程序画笔
Windows中控件建立窗口类Macintosh中 控件窗口没关系
Windows 允许256位色彩操作Macintosh 允许16位操作
两台间区Windows应程序 Macintosh 程序转变果没力工具艰巨务
Windows 直 Intel x86 处理器运行 ( Windows NT)Macintosh 直Motorola 680x0 处理器运行(然 Macintosh 现PowerPC运行)两处理器家族间区包括寻址字节排序opcodes 指令集寄存器名字数量
Intel 8086 处理器 衍生80x86系列处理器16bit址 支持65536 bytes 存储器寻址支持更存Intel 分段存储器结构 样利16bit寄存器访问1兆(2^20 bytes)存unsigned 16bit偏移量Intel 初种配置已扩展允许访问更存绝数现存Intel程序需分离代码数放64k段存储器
然Intel x86处理器80386已开始32bit寻址 兼容性原Microsoft Windows 3x 实际16bit程序 Microsoft Windows应程序写成16位说绝数指针句柄16 bits 长Microsoft Windows NT纯32bit操作系统 伴着出现应程序32bit 指针句柄32 bits长 Windows NT 线性寻址程序分散 4G存里面
Motorola 68000 PowerPC 处理器访问坦 32bit存储空间 理说种坦存储空间简化存储器寻址实践中4byte 寻址太会直 Macintosh 代码般分32K段中存储
Microsoft Windows Windows NT 运行谓 littleendian 机器—处理器重字节放前面重字节放面 Motorola 680x0PowerPC (谓 bigendian 结构)重字节放前面紧接着放第二重字节类推重放面
编译器通常程序处理字节排序细节然转换性强代码赖字节排序
Microsoft Windows Macintosh 关键方户界面较区包括菜单文件名文档界面程序
Macintosh 菜单栏屏幕窗口数量布局总处位置活动窗口 包含菜单菜单会着活动窗口改变动态变化然Windows 处顶端窗口菜单 MDI时子窗口菜单 MDI会面详细讨
Macintosh 应程序通常包含Apple menu包含桌面安装附件应程序入口System 7中 Macintosh 菜单右边包含Apple帮助图标负责应程序间切换菜单
Windows应程序通常窗口左角系统菜单菜单包含系统级功窗口移动关闭窗口应程序间切换称作务理器项目
通常 Windows程序包含键盘等效菜单项目划底线字母分布菜单入口户键盘代鼠标选择惯例必需Macintosh 程序必须等价项
文件名路径名Windows Macintosh间区许难出许程序员说处理文件名转换中费时间精力方Windows应程序许够处理文件名类似C＼ACCTG＼DATA＼SEPT93DAT MSDOS Windows 应程序遵守传统83 文件格式方面Macintosh 应程序处理文件名类似September 1993 Accounting Data
MDI窗口允许活动窗口框架子窗口许Windows程序例 Microsoft WordMDI应程序MDI 程序特点子窗口化会MDI框架部产生图标MDI子窗口会菜单
Macintosh 支持 MDI 窗口应程序开窗口然窗口变成图标享菜单区许需程序针Macintosh 转换重新设计
终够继续作解工作编写针Windows API转换成台版运行程序Visual C++现够做保持代码转换性时时考虑转换性效工具帮助台间轻松跳跃
附录B 外文原文
From one code base to many platforms using Visual C++
Multipleplatform development is a hot issue today Developers want to be able to support diverse platforms such as the Microsoft® Windows® version 3x Microsoft Windows NT® and Microsoft Windows 95 operating systems and Apple® Macintosh® UNIX and RISC (reduced instruction set computer) 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 platform＇s native application programming interface (API)
Write to a virtual API such as those provided by crossplatform toolsets
Build their own multipleplatform layer and support it
Today however a new choice exists Developers can use their existing code written to the Windows API and using tools available from Microsoft and third parties recompile for all of the platforms listed above This paper looks at the methods and some of the issues involved in doing so
Currently the most lucrative market for graphical user interface (GUI) applications after Microsoft Windows is the Apple Macintosh However vast differences separate these wholly different operating systems requiring developers to learn new APIs programming paradigms and tools Generally Macintosh development requires a separate code base from the Windows sources increasing the complexity of maintenance and enhancement
Because porting code from Windows to the Macintosh can be the most difficult porting case this paper concentrates in this area In general if your code base is sufficiently portable to enable straightforward recompiling for the Macintosh (excluding any platformspecific or edge code you may elect to include) you＇ll find that it will come up on other platforms easily as well
Microsoft Visual C++® CrossDevelopment Edition for Macintosh (Visual C++ for Mac™) provides a set of Windows NT– or Windows 95–hosted tools for recompiling your Windows code for the Motorola 680x0 and PowerPC processors and a portability library that implements Windows on the Macintosh This allows you to develop GUI applications with a single source code base (written to the Win32® API) and implement it on Microsoft Windows or Apple Macintosh platforms
Figure 1 below illustrates how Visual C++ for Mac works Your source code is edited compiled and linked on a Windows NT– or Windows 95–based (Intel) host machine The tools create 68000 and PowerPC native code and Macintosh resources An Ethernetbased or serial transport layer (TL) moves the resulting binaries to a Macintosh target machine running remotely The Macintosh application is started on the Macintosh and debugged remotely from the Windowsbased machine
Now that Apple has two different Macintosh architectures to contend with (Motorola 680x0 and PowerPC) portability is particularly important
Porting can involve several steps depending on whether you are working with old 16bit applications or with new 32bit sources In general the steps to a Macintosh port are as follows
Make your application more portable by following some general portability guidelines This will help insure not only portability to the 680x0based Macintosh machines but also to the newer more powerful PowerPC machines that are based on a RISC chip
Port your application from Windows 16bit code to 32bit code This may be the most complex and timeconsuming part of the job
Segregate those parts of your application that are unique to Windows from similar implementations that are specific to the Macintosh This may involve using conditional compilation or it may involve changing the source tree for your project
Port your Win32 API code to the Macintosh by using the portability library for the Macintosh and Visual C++ for compiling linking and debugging
Use the Microsoft Foundation Class Library (MFC) version 40 to implement new functionality such as OLE 20 containers servers and clients or database support using open database connectivity (ODBC) Code written using MFC is highly portable to the Macintosh
Write Macintoshspecific code to take advantage of unique Macintosh features such as Apple Events or Publish and Subscribe
The chief challenge among the families of Windows operating systems is the break from 16 bits (Windows 311 and Windows for Workgroups 311 operating system with integrated networking) to 32 bits (Windows NT and Windows 95) In general 16bit and 32bit code bases are somewhat incompatible unless they are written using MFC Developers have the choice of branching their sources into two trees or migrating everything to 32 bits Once the Win32 choice has been made how are legacy platforms to be run (that is machines still running Windows 311) The obvious choice is to use the Win32s® 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 351 and create highly optimized native Win32 applications for DEC Alpha and Motorola PowerPC platforms
Developers who have recompiled 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 recompile their Win32based or MFCbased applications for UNIX Developers seeking additional information should contact those companies directly
You＇ll have to decide early on whether to write to the native API (Win32) or to MFC In general you＇ll find MFC applications will port more quickly than Win32 applications This is because one of the intrinsic benefits of an application framework is an abstraction of the code away from the native operating system to some extent This abstraction is like an insurance policy for you However developers frequently have questions about MFC such as
What if I need an operating system service that isn＇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 don＇t know C++ Can I still use MFC
Sure MFC is based on C++ but you can mix C and C++ code seamlessly
How can I get started using MFC
Start by taking some classes andor reading some books Visual C++ ships with a fine tutorial on MFC (Scribble) Then check out the MFC Migration Kit (available on CompuServe or for a modest shipping and handling fee from Microsoft) It will help you migrate your Cbased application code to MFC and C++
All porting will be easier if you begin today writing more portable programs Following some basic portability guidelines will make your code less platformspecific
Never assume anything Particularly don＇t make assumptions about the sizes of types the state of the machine at any time byte ordering or alignment
Don＇t assume the size of primitive types because these have different sizes on different processors For example an int is two bytes in Win16 and four bytes in Win32 At all costs avoid code that relies on the size of a type Use sizeof() instead To determine the offset of a field in a structure use the offsetof() macro Don＇t try to compute this manually
Use programmatic interfaces to access all system or hidden objects for example the stack or heap
Parsing data types to extract individual bytes or even bits can cause problems when porting from Windows to the Macintosh unless you are careful to write code that doesn＇t assume any particular byte order LIMITSH 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 compilers 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 complexity of instruction scheduling and picking register usage
Write all routines in C first then if you absolutely need to rewrite one in assembler be sure to leave both implementations in your sources controlled by conditional compiles and keep both up to date
A major goal of American National Standards Institute (ANSI) CC++ is to provide a portable implementation of the language Theoretically code written to strict ANSI C compliance is completely portable to any compiler that implements the standard correctly Microsoft Visual C++ provides a compiler option (Za) to enable strict ANSI compatibility checking
Microsoft Visual C++ provides some language features that are in addition to ANSI C such as fourcharacter constants and singleline comments Programs that use the Microsoft C extensions should be portable to all other implementations of Microsoft Visual C++ Thus you can write programs that use fourcharacter constants for example and know that your program is portable to any 16bit or 32bit Microsoft Windows platform or to the Macintosh
Compilers normally align structures based on the target machine architecture some RISC machines such as the MIPS R4000 are particularly sensitive to alignment Alignment faults may generate runtime errors or instead may silently and seriously degrade the performance of your application For portability therefore avoid packing structures Limit packing to hardware interfaces and to compatibility issues such as file formats and ondisk structures
Using function prototypes is mandatory for fully portable code All functions should be prototyped and the prototype should exactly match the actual function declaration
Following the guidelines above will make your code a lot more portable However if you have 16bit Windows code your first step is to make it work properly under Win32 This will require additional changes in your sources
Code written for Win32 can run on any version of Windows including on the Macintosh using the portability library Portable code should compile and execute properly on any platform Of course if you use APIs that only function under Windows NT they will not work when your application runs under Windows 3x For example threads work under Windows NT but not under Windows 311 Those types of functionality differences will have to be accounted for in the design of your application
Chief among the differences between Win16 and Win32 is linear addressing That means pointers are now 32 bits wide and the keywords near and far are no longer supported It also means code that assumes segmented memory will break under Win32
In addition to pointers handles and graphic coordinates are now 32 bits WINDOWSH will resolve many of these size differences for you but some work is still necessary
The recommended strategy to get your application running under Win32 is to recompile for 32 bits noting error messages and warnings Next replace complex procedures and assembly language routines with stub procedures Then make your main program work properly using the techniques above Finally replace each stubbedout procedure with a portable version
After you successfully convert your Windowsbased program from 16 bits to 32 bits you＇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 accompany these differences are discussed in the section titled Porting from Win32 to the Macintosh
The Windows and Macintosh APIs are completely different For example
The event models are different In Windows you dispatch messages to WindowProcs You use DefWindowProc to handle messages in which you＇re not specifically interested On the Macintosh you have a big main event loop to handle all possible events
Windows uses the concept of child windows The Macintosh uses no child windows
Windowsbased applications can draw using either pens or brushes Macintosh applications can use only pens
Controls in Windows are builtin window classes On the Macintosh controls are unrelated to windows
Windows allows for 256 binary raster operations the Macintosh allows for only 16
Because of the differences between the two platforms porting a Windowsbased application to the Macintosh can be monumental task without powerful tools
Windows has always run on Intel x86 processors (until Windows NT) and the Macintosh has run on Motorola 680x0 processors (of course the PowerPCbased Macintosh is now available as well) Differences between the processor families include addressing and byte ordering in addition to the more expected differences like opcodes instruction sets and the name and number of registers
The Intel 8086 processor from which subsequent 80x86 processors are descended used 16bit addresses which unfortunately allowed only 65536 bytes of memory to be addressed To allow the use of more memory Intel implemented a segmented memory architecture to address one megabyte (2^20 bytes) of memory that used an unsigned 16bit segment register and an unsigned 16bit offset This original Intel scheme has been extended to allow much larger amounts of memory to be addressed but most existing Intelbased programming relies on separating code and data into 64K segments
Although all Intel x86 processors since the 80386 have used 32bit addressing for compatibility reasons Microsoft Windows 3x is actually a 16bit application and all Microsoft Windowsbased applications had to be written as 16bit applications That meant for example that most pointers and handles were 16 bits wide With the advent of Microsoft Windows NT which is a true 32bit operating system all native applications are 32bit applications which means that pointers and handles are 32 bits wide Because Windows NT uses linear addressing programs can share up to 4 gigabytes of memory
In contrast the Motorola 68000 and PowerPC processor have always provided the ability to address a flat 32bit memory space In theory a flat memory space of this kind simplifies memory addressing In practice because 4byte addresses are too large to use all the time Macintosh code is generally divided into segments no larger than 32K
Microsoft Windows and Windows NT run only on socalled littleendian machines—processors that place the least significant byte first and the most significant byte last In contrast the Motorola 680x0 and PowerPC (a socalled bigendian architecture) place the most significant byte first followed by the next most significant byte and so on with the least significant byte last
Compilers normally handle all details of byte ordering for your application program Nevertheless wellwritten portable code should never depend on the order of bytes
Microsoft Windows and the Macintosh present quite different user interfaces in many key areas including menus filenames and multipledocument interface (MDI) applications
Only one menu bar exists on the Macintosh and it is always in the same place regardless of the number or arrangement of windows on the screen The active window contains the menu which dynamically changes as necessary when different windows are made active Windows on the other hand gives each toplevel window its own menu In addition under MDI each child window can also have its own menu MDI is discussed in greater detail below
Macintosh applications generally have an Apple menu (the leftmost menu) that contains all the installed Desk Accessories and usually contains an About entry for the application Under System 7 the extreme right side of the Macintosh menu contains an icon for Apple＇s Balloon Help and the Application menu for switching between applications
Windowsbased applications always have a System menu at the upperleft corner of their toplevel window This menu contains systemlevel functions for sizing moving and closing the window as well as an item that calls the Task Manager for switching applications
Generally Windowsbased applications contain keyboard equivalents in their menus These are underlined letters in each menu entry that the user can select with the keyboard in lieu of the mouse This however is convention rather than requirement Although some Macintosh applications have these equivalents most do not
Filenames and pathnames represent one of the most fundamental differences between Windows and the Macintosh as well as perhaps the one most difficult to deal with Many programmers report dealing with filenames as the area of porting in which the most time and energy is spent
Your Windowsbased application probably already handles (and expects) filenames such as C＼ACCTG＼DATA＼SEPT93DAT Applications for the MSDOS and Windows operating systems are bound by the traditional 83 filename format Macintosh applications on the other hand can handle filenames such as September 1993 Accounting Data
MDI windows allow for multiple child windows within the borders of a toplevel window (the MDI frame) Many Windowsbased applications such as the Microsoft Word word processor for Windows are MDI applications Characteristic of MDI applications are clipped child windows that can be minimized to an icon within the MDI frame Each MDI child window can also have its own menu
The Macintosh does not support MDI windows An application can have multiple windows open those windows however cannot be made into icons and they share a common menu Depending on the application this difference may necessitate significant redesign for a Macintosh port
Finally you can keep doing what you know how to do best writing to the Windows API and still allow for versions of your application that run on other platforms Visual C++ now gives you special versions that allow you to do this Keeping your code portable thinking about portability all the time and using the right tools will help you make the multiple platform jump as effortless as possible
文档香网(httpswwwxiangdangnet)户传
《香当网》用户分享的内容，不代表《香当网》观点或立场，请自行判断内容的真实性和可靠性！
该内容是文档的文本内容，更好的格式请下载文档
利Visual C++代码运行台
天台开发热门课题开发员希够支持台例Windows 3x Windows NT Windows 95 操作系统 Apple Macintosh UNIX RISC (reduced instruction set computer)等直久前希开发台务开发者少种选择：
根台应程序接口台准备份单独代码
利跨台工具提供虚拟API
构建台层支持
天种新办法开发员通微软第三方工具现存针Windows API写代码列举种台重新编译文关注种新办法相关方法点
目前Macintosh紧Windows市场流行图形户界面系统两完全操作系统间太需开发员学新API新范例程序新工具般情况Macintosh应程序开发需Windows代码库增加维护升级复杂度
WindowsMacintosh代码转换难情形文重点容果代码利实现Macintosh台编译会发现台编译难
Microsoft Visual C++针Macintosh提供跨台编辑器提供工具工具Windows NT Windows 95台运行Windows代码编译适应Motorola 680x0PowerPC 处理器提供转换库辅助Windows程序Macintosh运行开发单源代码（针Win32® API）运行Microsoft Windows Apple Macintosh台
面第章说明Visual C++样针Macintosh工作源代码Windows NTWindows 95面编写编译连接工具产生68000 PowerPC然代码Macintosh资源基太网串行连接传输层会目标代码移动远端目Macintosh机器运行Macintosh应程序Macintosh台运行远端Windows机器面调试
现Apple公司两Macintosh结构竞争转换性尤重转换步骤取决处理程序16位32位般说Macintosh转换包括步：
遵循转换性方针程序更容易转换仅助保证基680x0 Macintosh机器转换助更新基RISC 芯片powerful PowerPC机器转换
Windows应程序16位代码转换成32位代码许复杂耗时间工作
独特Windows应程序分割熟悉执行方式Macintosh涉条件编译者设计工程资源树
利Macintosh转换库Win32 API代码转换成Macintosh代码利Visual C++编译连接调试
微软基础类库MFC 40实现新功例OLE 20服务器客户端者利ODBC数库支持MFC编写代码Macintosh高转换性
编写专门Macintosh代码利Macintosh独特特点利Apple 事件出版定购
开发员通Visual C++特殊台编辑器充分利新RISC硬件例DEC Alpha AXP机器包括针MIPS R4000 处理器系列前面说DEC Alpha AXP 芯片Motorola Power PC工具Windows NT 351运行产生针DEC AlphaMotorola PowerPC高度优化Win32应程序已工具进行编译Win32资源开发员程简单感惊讶台操作系统独立工具独立完成转换确需少工作量
微软公司两第三方UNIX工具提供商合作密切（Bristol Technology Mainsoft公司）开发员Win32MFC程序针UNIX进行编译开发员通直接公司接触获更信息
早时候选择编写基原始API者基MFC程序 般说会发现MFC程序转换性Win32程序应程序框架优势基操作系统进行定程度提炼种提炼类似提供种安全保证开发员常常MFC疑问例：
果需种操作系统服务应程序框架没提供处理
直接调Win32 APIMFC 会阻止Win32 API直接调函数名前面加全局运算符()
懂C++MFC？
然MFC基C++ C C++ 代码结合起
函数名前面加全局运算符()
样开始MFC？
类开始读书开始Visual C++ 系统提供MFC指南(Scribble)然购买MFC Migration Kit（网付费邮寄微软）帮助C程序移植转换成MFCC++
果天开始编写转换性程序转换会变简单遵守基转换方针会代码减少特殊台赖
假定事特假定数类型机器状态数类型排序者队列假定简单数类型处理器例intWin16Win32分2字节4字节避免代码赖数类型size of()换offset of()宏判断结构体试图手动计算编程口访问系统者隐藏象例栈堆
分解数类型提取单独字节特会WindowsMacintosh转换时出问题非写代码时候心假定类型分解LIMITSH包含常量辅助书写独立入台宏访问独立字节
明显没什汇编语言转换性更差Microsoft Visual C++样置汇编程序编译器容易摆脱汇编码提高速度然果想转换代码避免种诱惑果必须编译器产生手动产生效果样汇编码微软研究表明问题出现原算法代码实际行程寄存器法复杂RISC机器手动产生汇编码机器产生差
c语言编写程序然果必须汇编码重写确保两种执行程序保存利条件编译保持两种程序更新
美国国家标准委员会（ANSI）CC++目标提供转换种语言执行程序理说严格ANSI C编写程序执行ANSI C标准编译器转换Microsoft Visual C++提供编译器选项检查ANSI兼容性
Microsoft Visual C++ANSI C提供语言细节补充例4字符常数单行注释Microsoft C扩充程序转换Microsoft Visual C++执行操作4字符常数编写程序明白程序转换16位32位Microsoft Windows台者Macintosh台
编译器常定位目标机器体系结构RISC机器例MIPS R4000排列尤敏感排列错误导致执行期错误者悄悄显著影响程序避免封装结构限制硬件接口兼容性东西文件格式磁盘结构封装
函数原型转换代码说命令函数应该原型原型应该实际声名函数完全匹配
遵循面方针会代码容易转换果代码16位Windows代码第步做Win32正常工作需资源作额外改变
Win32编写代码Windows版运行转换库时候Macintosh运行转换代码应该意台正确编译执行然果Windows NT 特APIWindows 3X工作例线程Windows NT 工作Windows 311工作函数区应该设计程序时候考虑
Win16 Win32区寻址长度意思现32位指针远关键词支持意味着分段存储代码Win32会工作
指针句柄图形调节32位WINDOWSH会解决问题然工作需作
关程序Win32运行推荐策略代码编译成 32 bit 注意错误消息警告接着复杂函数汇编语言函数子函数代然利面技术程序正确工作转换版代子函数
已成功Windows程序16 bits 转换32 bits应该准备着手转换成 Macintosh两台间存区工作会显令畏惧开始转换程序前先明白区Macintosh Windows区三方面：
编程样式区
处理器区
户界面区
方面区会面叙述伴区出现转换问题会Win32 Macintosh转换节中讨
WindowsMacintoshAPIs 完全例
事件模型Windows里分派消息 WindowProcs DefWindowProc 处理关心消息 Macintosh里事件循环处理出现消息
Windows子窗口概念Macintosh 子窗口
Windows应程序画笔者画刷绘图 Macintosh 应程序画笔
Windows中控件建立窗口类Macintosh中 控件窗口没关系
Windows 允许256位色彩操作Macintosh 允许16位操作
两台间区Windows应程序 Macintosh 程序转变果没力工具艰巨务
Windows 直 Intel x86 处理器运行 ( Windows NT)Macintosh 直Motorola 680x0 处理器运行(然 Macintosh 现PowerPC运行)两处理器家族间区包括寻址字节排序opcodes 指令集寄存器名字数量
Intel 8086 处理器 衍生80x86系列处理器16bit址 支持65536 bytes 存储器寻址支持更存Intel 分段存储器结构 样利16bit寄存器访问1兆(2^20 bytes)存unsigned 16bit偏移量Intel 初种配置已扩展允许访问更存绝数现存Intel程序需分离代码数放64k段存储器
然Intel x86处理器80386已开始32bit寻址 兼容性原Microsoft Windows 3x 实际16bit程序 Microsoft Windows应程序写成16位说绝数指针句柄16 bits 长Microsoft Windows NT纯32bit操作系统 伴着出现应程序32bit 指针句柄32 bits长 Windows NT 线性寻址程序分散 4G存里面
Motorola 68000 PowerPC 处理器访问坦 32bit存储空间 理说种坦存储空间简化存储器寻址实践中4byte 寻址太会直 Macintosh 代码般分32K段中存储
Microsoft Windows Windows NT 运行谓 littleendian 机器—处理器重字节放前面重字节放面 Motorola 680x0PowerPC (谓 bigendian 结构)重字节放前面紧接着放第二重字节类推重放面
编译器通常程序处理字节排序细节然转换性强代码赖字节排序
Microsoft Windows Macintosh 关键方户界面较区包括菜单文件名文档界面程序
Macintosh 菜单栏屏幕窗口数量布局总处位置活动窗口 包含菜单菜单会着活动窗口改变动态变化然Windows 处顶端窗口菜单 MDI时子窗口菜单 MDI会面详细讨
Macintosh 应程序通常包含Apple menu包含桌面安装附件应程序入口System 7中 Macintosh 菜单右边包含Apple帮助图标负责应程序间切换菜单
Windows应程序通常窗口左角系统菜单菜单包含系统级功窗口移动关闭窗口应程序间切换称作务理器项目
通常 Windows程序包含键盘等效菜单项目划底线字母分布菜单入口户键盘代鼠标选择惯例必需Macintosh 程序必须等价项
文件名路径名Windows Macintosh间区许难出许程序员说处理文件名转换中费时间精力方Windows应程序许够处理文件名类似C＼ACCTG＼DATA＼SEPT93DAT MSDOS Windows 应程序遵守传统83 文件格式方面Macintosh 应程序处理文件名类似September 1993 Accounting Data
MDI窗口允许活动窗口框架子窗口许Windows程序例 Microsoft WordMDI应程序MDI 程序特点子窗口化会MDI框架部产生图标MDI子窗口会菜单
Macintosh 支持 MDI 窗口应程序开窗口然窗口变成图标享菜单区许需程序针Macintosh 转换重新设计
终够继续作解工作编写针Windows API转换成台版运行程序Visual C++现够做保持代码转换性时时考虑转换性效工具帮助台间轻松跳跃
附录B 外文原文
From one code base to many platforms using Visual C++
Multipleplatform development is a hot issue today Developers want to be able to support diverse platforms such as the Microsoft® Windows® version 3x Microsoft Windows NT® and Microsoft Windows 95 operating systems and Apple® Macintosh® UNIX and RISC (reduced instruction set computer) 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 platform＇s native application programming interface (API)
Write to a virtual API such as those provided by crossplatform toolsets
Build their own multipleplatform layer and support it
Today however a new choice exists Developers can use their existing code written to the Windows API and using tools available from Microsoft and third parties recompile for all of the platforms listed above This paper looks at the methods and some of the issues involved in doing so
Currently the most lucrative market for graphical user interface (GUI) applications after Microsoft Windows is the Apple Macintosh However vast differences separate these wholly different operating systems requiring developers to learn new APIs programming paradigms and tools Generally Macintosh development requires a separate code base from the Windows sources increasing the complexity of maintenance and enhancement
Because porting code from Windows to the Macintosh can be the most difficult porting case this paper concentrates in this area In general if your code base is sufficiently portable to enable straightforward recompiling for the Macintosh (excluding any platformspecific or edge code you may elect to include) you＇ll find that it will come up on other platforms easily as well
Microsoft Visual C++® CrossDevelopment Edition for Macintosh (Visual C++ for Mac™) provides a set of Windows NT– or Windows 95–hosted tools for recompiling your Windows code for the Motorola 680x0 and PowerPC processors and a portability library that implements Windows on the Macintosh This allows you to develop GUI applications with a single source code base (written to the Win32® API) and implement it on Microsoft Windows or Apple Macintosh platforms
Figure 1 below illustrates how Visual C++ for Mac works Your source code is edited compiled and linked on a Windows NT– or Windows 95–based (Intel) host machine The tools create 68000 and PowerPC native code and Macintosh resources An Ethernetbased or serial transport layer (TL) moves the resulting binaries to a Macintosh target machine running remotely The Macintosh application is started on the Macintosh and debugged remotely from the Windowsbased machine
Now that Apple has two different Macintosh architectures to contend with (Motorola 680x0 and PowerPC) portability is particularly important
Porting can involve several steps depending on whether you are working with old 16bit applications or with new 32bit sources In general the steps to a Macintosh port are as follows
Make your application more portable by following some general portability guidelines This will help insure not only portability to the 680x0based Macintosh machines but also to the newer more powerful PowerPC machines that are based on a RISC chip
Port your application from Windows 16bit code to 32bit code This may be the most complex and timeconsuming part of the job
Segregate those parts of your application that are unique to Windows from similar implementations that are specific to the Macintosh This may involve using conditional compilation or it may involve changing the source tree for your project
Port your Win32 API code to the Macintosh by using the portability library for the Macintosh and Visual C++ for compiling linking and debugging
Use the Microsoft Foundation Class Library (MFC) version 40 to implement new functionality such as OLE 20 containers servers and clients or database support using open database connectivity (ODBC) Code written using MFC is highly portable to the Macintosh
Write Macintoshspecific code to take advantage of unique Macintosh features such as Apple Events or Publish and Subscribe
The chief challenge among the families of Windows operating systems is the break from 16 bits (Windows 311 and Windows for Workgroups 311 operating system with integrated networking) to 32 bits (Windows NT and Windows 95) In general 16bit and 32bit code bases are somewhat incompatible unless they are written using MFC Developers have the choice of branching their sources into two trees or migrating everything to 32 bits Once the Win32 choice has been made how are legacy platforms to be run (that is machines still running Windows 311) The obvious choice is to use the Win32s® 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 351 and create highly optimized native Win32 applications for DEC Alpha and Motorola PowerPC platforms
Developers who have recompiled 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 recompile their Win32based or MFCbased applications for UNIX Developers seeking additional information should contact those companies directly
You＇ll have to decide early on whether to write to the native API (Win32) or to MFC In general you＇ll find MFC applications will port more quickly than Win32 applications This is because one of the intrinsic benefits of an application framework is an abstraction of the code away from the native operating system to some extent This abstraction is like an insurance policy for you However developers frequently have questions about MFC such as
What if I need an operating system service that isn＇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 don＇t know C++ Can I still use MFC
Sure MFC is based on C++ but you can mix C and C++ code seamlessly
How can I get started using MFC
Start by taking some classes andor reading some books Visual C++ ships with a fine tutorial on MFC (Scribble) Then check out the MFC Migration Kit (available on CompuServe or for a modest shipping and handling fee from Microsoft) It will help you migrate your Cbased application code to MFC and C++
All porting will be easier if you begin today writing more portable programs Following some basic portability guidelines will make your code less platformspecific
Never assume anything Particularly don＇t make assumptions about the sizes of types the state of the machine at any time byte ordering or alignment
Don＇t assume the size of primitive types because these have different sizes on different processors For example an int is two bytes in Win16 and four bytes in Win32 At all costs avoid code that relies on the size of a type Use sizeof() instead To determine the offset of a field in a structure use the offsetof() macro Don＇t try to compute this manually
Use programmatic interfaces to access all system or hidden objects for example the stack or heap
Parsing data types to extract individual bytes or even bits can cause problems when porting from Windows to the Macintosh unless you are careful to write code that doesn＇t assume any particular byte order LIMITSH 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 compilers 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 complexity of instruction scheduling and picking register usage
Write all routines in C first then if you absolutely need to rewrite one in assembler be sure to leave both implementations in your sources controlled by conditional compiles and keep both up to date
A major goal of American National Standards Institute (ANSI) CC++ is to provide a portable implementation of the language Theoretically code written to strict ANSI C compliance is completely portable to any compiler that implements the standard correctly Microsoft Visual C++ provides a compiler option (Za) to enable strict ANSI compatibility checking
Microsoft Visual C++ provides some language features that are in addition to ANSI C such as fourcharacter constants and singleline comments Programs that use the Microsoft C extensions should be portable to all other implementations of Microsoft Visual C++ Thus you can write programs that use fourcharacter constants for example and know that your program is portable to any 16bit or 32bit Microsoft Windows platform or to the Macintosh
Compilers normally align structures based on the target machine architecture some RISC machines such as the MIPS R4000 are particularly sensitive to alignment Alignment faults may generate runtime errors or instead may silently and seriously degrade the performance of your application For portability therefore avoid packing structures Limit packing to hardware interfaces and to compatibility issues such as file formats and ondisk structures
Using function prototypes is mandatory for fully portable code All functions should be prototyped and the prototype should exactly match the actual function declaration
Following the guidelines above will make your code a lot more portable However if you have 16bit Windows code your first step is to make it work properly under Win32 This will require additional changes in your sources
Code written for Win32 can run on any version of Windows including on the Macintosh using the portability library Portable code should compile and execute properly on any platform Of course if you use APIs that only function under Windows NT they will not work when your application runs under Windows 3x For example threads work under Windows NT but not under Windows 311 Those types of functionality differences will have to be accounted for in the design of your application
Chief among the differences between Win16 and Win32 is linear addressing That means pointers are now 32 bits wide and the keywords near and far are no longer supported It also means code that assumes segmented memory will break under Win32
In addition to pointers handles and graphic coordinates are now 32 bits WINDOWSH will resolve many of these size differences for you but some work is still necessary
The recommended strategy to get your application running under Win32 is to recompile for 32 bits noting error messages and warnings Next replace complex procedures and assembly language routines with stub procedures Then make your main program work properly using the techniques above Finally replace each stubbedout procedure with a portable version
After you successfully convert your Windowsbased program from 16 bits to 32 bits you＇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 accompany these differences are discussed in the section titled Porting from Win32 to the Macintosh
The Windows and Macintosh APIs are completely different For example
The event models are different In Windows you dispatch messages to WindowProcs You use DefWindowProc to handle messages in which you＇re not specifically interested On the Macintosh you have a big main event loop to handle all possible events
Windows uses the concept of child windows The Macintosh uses no child windows
Windowsbased applications can draw using either pens or brushes Macintosh applications can use only pens
Controls in Windows are builtin window classes On the Macintosh controls are unrelated to windows
Windows allows for 256 binary raster operations the Macintosh allows for only 16
Because of the differences between the two platforms porting a Windowsbased application to the Macintosh can be monumental task without powerful tools
Windows has always run on Intel x86 processors (until Windows NT) and the Macintosh has run on Motorola 680x0 processors (of course the PowerPCbased Macintosh is now available as well) Differences between the processor families include addressing and byte ordering in addition to the more expected differences like opcodes instruction sets and the name and number of registers
The Intel 8086 processor from which subsequent 80x86 processors are descended used 16bit addresses which unfortunately allowed only 65536 bytes of memory to be addressed To allow the use of more memory Intel implemented a segmented memory architecture to address one megabyte (2^20 bytes) of memory that used an unsigned 16bit segment register and an unsigned 16bit offset This original Intel scheme has been extended to allow much larger amounts of memory to be addressed but most existing Intelbased programming relies on separating code and data into 64K segments
Although all Intel x86 processors since the 80386 have used 32bit addressing for compatibility reasons Microsoft Windows 3x is actually a 16bit application and all Microsoft Windowsbased applications had to be written as 16bit applications That meant for example that most pointers and handles were 16 bits wide With the advent of Microsoft Windows NT which is a true 32bit operating system all native applications are 32bit applications which means that pointers and handles are 32 bits wide Because Windows NT uses linear addressing programs can share up to 4 gigabytes of memory
In contrast the Motorola 68000 and PowerPC processor have always provided the ability to address a flat 32bit memory space In theory a flat memory space of this kind simplifies memory addressing In practice because 4byte addresses are too large to use all the time Macintosh code is generally divided into segments no larger than 32K
Microsoft Windows and Windows NT run only on socalled littleendian machines—processors that place the least significant byte first and the most significant byte last In contrast the Motorola 680x0 and PowerPC (a socalled bigendian architecture) place the most significant byte first followed by the next most significant byte and so on with the least significant byte last
Compilers normally handle all details of byte ordering for your application program Nevertheless wellwritten portable code should never depend on the order of bytes
Microsoft Windows and the Macintosh present quite different user interfaces in many key areas including menus filenames and multipledocument interface (MDI) applications
Only one menu bar exists on the Macintosh and it is always in the same place regardless of the number or arrangement of windows on the screen The active window contains the menu which dynamically changes as necessary when different windows are made active Windows on the other hand gives each toplevel window its own menu In addition under MDI each child window can also have its own menu MDI is discussed in greater detail below
Macintosh applications generally have an Apple menu (the leftmost menu) that contains all the installed Desk Accessories and usually contains an About entry for the application Under System 7 the extreme right side of the Macintosh menu contains an icon for Apple＇s Balloon Help and the Application menu for switching between applications
Windowsbased applications always have a System menu at the upperleft corner of their toplevel window This menu contains systemlevel functions for sizing moving and closing the window as well as an item that calls the Task Manager for switching applications
Generally Windowsbased applications contain keyboard equivalents in their menus These are underlined letters in each menu entry that the user can select with the keyboard in lieu of the mouse This however is convention rather than requirement Although some Macintosh applications have these equivalents most do not
Filenames and pathnames represent one of the most fundamental differences between Windows and the Macintosh as well as perhaps the one most difficult to deal with Many programmers report dealing with filenames as the area of porting in which the most time and energy is spent
Your Windowsbased application probably already handles (and expects) filenames such as C＼ACCTG＼DATA＼SEPT93DAT Applications for the MSDOS and Windows operating systems are bound by the traditional 83 filename format Macintosh applications on the other hand can handle filenames such as September 1993 Accounting Data
MDI windows allow for multiple child windows within the borders of a toplevel window (the MDI frame) Many Windowsbased applications such as the Microsoft Word word processor for Windows are MDI applications Characteristic of MDI applications are clipped child windows that can be minimized to an icon within the MDI frame Each MDI child window can also have its own menu
The Macintosh does not support MDI windows An application can have multiple windows open those windows however cannot be made into icons and they share a common menu Depending on the application this difference may necessitate significant redesign for a Macintosh port
Finally you can keep doing what you know how to do best writing to the Windows API and still allow for versions of your application that run on other platforms Visual C++ now gives you special versions that allow you to do this Keeping your code portable thinking about portability all the time and using the right tools will help you make the multiple platform jump as effortless as possible
文档香网(httpswwwxiangdangnet)户传
《香当网》用户分享的内容，不代表《香当网》观点或立场，请自行判断内容的真实性和可靠性！
该内容是文档的文本内容，更好的格式请下载文档
