A portable plug-in is a plug-in that you need only recompile to use in another environment. Because the plug-in interface and the command and query language are nearly identical in both Windows and on the Macintosh, it is possible to write a plug-in that you can compile in both environments.
You write portable code to be independent from its environment. You must make no assumptions about the compiler, the processor, or the byte order:
#ifdef WINDOWS ... #endif /* WINDOWS */ #ifdef MACINTOSH ... #endif /* MACINTOSH */
Examples: For examples of portable code, see Frame.C, included on disk in this SDK.
To make software run on both the Motorola and Intel families of microprocessors, you must be aware of some of the differences between the processor families.
One major difference is that the order of bytes in a word, and of words in a long word, is different between the processor families. Although the bit order in a byte is the same, the high-order byte comes first in the 680x0 and PowerPC (Motorola) family, and the low-order byte comes first in the 80x86 family (Intel).
Be aware that floating-point values not only have a different byte order but also have different formats that may be compiler-dependent.
The order of bits in C-bit field types is both platform- and compiler-specific. In plug-in, some compilers will automatically pad a group of bit fields to a word boundary, while others will stop at a byte boundary. For portability, pad all bit field groups out to a word boundary.
Because of the difference in byte order between the processor families,
binary files that contain SHORTs and LONGs are not compatible when transported
between the Macintosh and the PC. Code that directly reads binary files
must be able to process reversed byte order. (SHORT and LONG are data types
defined in PMTypes.h.)
![]() |
Comments or suggestions? Contact Adobe
Developer Support Copyright © 1997 - 2001 Adobe Systems Incorporated. All rights reserved. Legal notices and trademark attributions |