【正文】 plications 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。ll have to decide early on whether to write to the native API (Win32) or to MFC. In general you39。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 isn39。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。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 and/or 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, don39。t make assumptions about the sizes of types, the state of the machine at any time, byte ordering, or alignment. Don39。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. Don39。t try to pute 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 doesn39。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。 then, if you absolutely need to rewrite one in assembler, be sure to leave both implementations in your sources, controlled by conditional piles, and keep both up to date. A major goal of American National Standards Institute (ANSI) C/C++ is to provide a portable implementation of the language. Theoretically, code written to strict ANSI C pliance is pletely portable to any piler that implements the standard correctly. Microsoft Visual C++ provides a piler option (/Za) to enable strict ANSI patibility checking. Microsoft Visual C++ provides some language features that are in addition to ANSI C, such as fourcharacter constants and singleline ments. 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. Limi t packing to hardware interfaces and to patibility 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 declaratio