|< Previous PageNext Page >|
Rosetta must run the entire process when it translates. This has implications for applications that use third-party plug-ins or any other component that must be loaded at the time your application launches. All parts (application, plug-ins, or other components needed at launch time) must run either nonnatively or natively. For example, if your application is built as a universal binary, but it uses a plug-in that has only a PowerPC binary, then your application needs to run nonnatively on an Intel-based Macintosh computer to use the nonnative plug in.
Rosetta takes endian issues into account when it translates your application. Multibyte data that moves between your application and any system process is automatically handled for you—you don’t need to concern yourself with the endian format of the data.
The following kinds of multibyte data can have endian issues if the data moves between:
Your translated application and a native process that’s not a system process
A custom pasteboard provided by your translated application and a custom pasteboard provided by a native application
Data files or caches provided by your translated application and a native application
You might encounter this scenario while developing a universal binary. For example, if you’ve created a universal binary for a server process that your application relies on, and then test that process by running your application as a PowerPC binary, the endian format of the data passed from the server to your application would be wrong. You encounter the same problem if you create a universal binary for your application, but have not yet done so for a server process needed by the application.
Structures that the system defines and that are written using system routines will work correctly. But consider the code in Listing A-1.
Listing A-1 A structure whose endian format depends on the architecture
void savefile(data_t data, int filehandle)
write(filehandle, &data, sizeof(data));
When run using Rosetta, the application will write a big-endian structure; x and y are both written as big-endian integers. When the application runs natively on an Intel-based Macintosh, it will write out a little-endian structure; x and y are written as little-endian integers. It is up to you to define data formats on disk to be of a canonical endian format. Endian-specific data formats are fine as long as any application that reads or write the data understands what the endian format of the data is and treats the data appropriately.
Keep in mind that private frameworks and plug-ins can also encounter these sorts of endian issues. If a private framework creates a cache or data file, and the framework is a universal binary, then it will try to access the cache from both native and PPC processes. The framework either needs to account for the endian format of the cache when reading or writing data or needs to have two separate caches.
|< Previous PageNext Page >|
Last updated: 2006-07-24