苹果支持的可执行文件格式
发布网友
发布时间：2022-04-29 13:10
共1个回答
热心网友
时间：2022-05-15 15:45
应用程序及文档FAQ
由于各种不同的因素影响应用程序和文档的性质、结构以及处理，故在本书的各个部分都有关于应用程序和文档的信息。这些因素包括束、可执行文件格式、文件系统以及Finder。本节通过为开发者概括文档和应用程序的重要部分，以回答问题的形式将这些信息汇集在一起。
应当为应用程序指定什么样的元数据？
为了让用户启动您的（束化了的）应用程序，Finder应用程序应当能够检测出文件夹是一个束，然后它应当能够查明该束是一个应用程序。为了进行这样的判断，Finder首先检查以下两件事情中的一件：
在束文件夹上，束位是否被设置成“开（on）”
束的扩展名是否是那些为束保留的扩展名中的一种（包括.app）
若Finder断定该文件夹是一个束，它将读取存储于束的Info.plist文件中的CFBundlePackageType键码；若此键码包含“APPL”的值，则可确定该束是一个应用程序。若该文件未包含此键码，则它将根据束扩展名（应用程序为.app）决定束类型。
就象HFS和HFS+元数据的其它形式一样，由于束位在包括多文件系统的联网环境中很容易被丢失，所以应用程序束保持.app的扩展名是重要的。当您创建一个应用程序时，Project Builder将自动地添加此扩展名，但是其它IDE可能并不如此。任何情况下您都不应该删除该扩展名或是鼓励您的用户这样做。若.app的 “不雅观” 使您感到烦恼，请别担心，Mac OS X Finder会隐藏.app扩展名的显示。尽管Apple不在其应用程序上设置束位，但当您创建应用程序时您可在它的束文件夹上设定此属性。关于更多的此类信息，请参阅“Finder和束”以及“应用程序和文档的处理”。
必须将CFM可执行文件打包在一个束中吗？
简单的答案是“不，但或许应该这样做”。 更详尽的答案请参阅“CFM可执行文件”。
应该怎样存储应用程序资源？
在Mac OS 9和Mac OS的以前版本中，应用程序将它们的资源存放在应用程序可执行文件的资源分支中。但对于Mac OS X来说，这不再是被推荐的方法。取而代之的是，应用程序应该将它们的资源存放在应用程序束中的独立文件的数据分支中。
此建议的理由与下文中关于文档定型应该有文件扩展名以及Finder元数据的理由相同（请参阅“为何要有扩展名？”）。HFS和HFS+ 卷格式允许文件具有多分支或数据流。然而，当文件在局域网、企业网或互联网的不同种类计算机系统之间传送时，不在文件数据分支中的任何东西都可能会被容易地丢失。关键是要使资源和所有其它形式的数据在日益互联的网络世界中保持不变。
Carbon应用程序的开发者必须考虑与Mac OS X的资源相关的其它因素，尤其是如果那些应用程序依赖于Code Fragment Manager （CFM）的话。若该应用程序是一个由CFM管理的单文件可执行代码（即，不是一个束化了的CFM应用程序），那么资源应该存放在可执行代码的资源分支中。当打包成单文件CFM可执行代码的应用程序被启动时，将默认地打开它们的资源分支。相反，当打包成束的应用程序被启动时，将默认地打开它们的本地化数据分支资源。
如果Carbon应用程序被打包在束中的话，那么对于资源来说就出现了更多的可能性。您可将某种类型的资源放在它自己的文件内，而不是将资源与资源管理器管理的其它资源结合在一起。例如，若应用程序使用了一个TIFF图像，那么您可将该TIFF图像数据存放在一个具有.tiff扩展名的文件的数据分支中。然后，通过使用合适的束应用编程接口（API），您就可直接地访问该资源。将每个资源存放在它自己的文件中带来很多的益处。例如，这样的方法使“输出”指示在XML属性列表中的资源变得更为容易。Carbon应用程序，不管它们是基于CFM还是基于dyld的，总能使用资源管理器式样的资源。然而，如果将应用程序打包在一个束中（如同被推荐的那样），您就应该把资源存放在束目录的文件中，并且应该只使用这些文件的数据分支。这些文件应该有一个.rsrc的扩展名，它们象任何其它文件一样被当作束资源，并很容易被国际化。尽管.rsrc文件可具有任何基本名称，但如果您给予它们标准名称并将它们存放在资源的标准束位置的话，那么系统束例程将自动地管理资源。它按以下方式工作：
将非本地化资源存放在一个名为executableName.rsrc的文件中，并将此文件存放在这些资源的束位置处（即，直接存放在Resources目录中）。
将本地化资源存放在一个名为Localized.rsrc的文件中，将这些文件存放在本地化资源的适当的束位置处（即，.lproj目录中）。
当应用程序被启动时，系统束例程将自动地打开这些资源并且使它们可供该应用程序使用。
总之，下列选项可供应用程序资源选择：
每个特定类型的资源存放在它自己的文件中，该文件具有一个适合其类型的扩展名。此方法适合于任何应用程序环境中束化了的应用程序。对此“one-per-file”模式例外的是本地化字符串，它们在每次本地化时被收集，并按规定存放在一个名为Localized.strings的文件中；更多信息请参阅“本地化字符串” 。
束化了的Carbon应用程序可将它们的资源管理器式样的资源存放在文件的数据分支中，每个文件都带有.rsrc的扩展名。这些文件可被存放在非本地化和本地化资源的束位置处。
未束化了的Carbon应用程序必须将它们的资源管理器式样的资源存放在应用程序可执行代码的资源分支中。
若希望Finder妥当地处理应用程序及其文档，您就必须将等同于束信息属性列表中的键值对保存为一个类型为 “plst”，ID为0的资源。
关于更多的此类信息，请参阅“束和资源管理器”以及“资源分支”。
如何在Mac OS X中指明文档类型？
在Mac OS X中，通过指定以下两件事情，您可以指明一个文档的类型：
作为文件属性存储的类型和创建者代码（如果它被创建在HFS或HFS+ 卷上的话）
与类型相关的一个或多个文件扩展名（例如，.html和.htm）
Apple推荐您的应用程序使用所有这两种形式来为文档定型。若您的应用程序拥有一种文档，您可在应用程序项目的信息属性列表（Info.plist）中指定它的类型和创建者代码以及文件扩展名（请参阅“信息属性列表”）。Project Builder为输入此信息提供一个工具，可以在用于编译目标的Application Settings设置面板中找到。应用程序应该为其文档强制进行所有有效类型的设置，尤其是设置文档的文件扩展名。请参阅“应用程序应如何保存文件？”。
对于扩展名有一个最后的说明。一般来说，应用程序应该能够打开那些具有扩展名但是没有类型和创建者代码的文档。对于公共（跨平台）文档类型，例如图像文件、文本文件以及HTML文件，尤其需要此特性。
可以把插件当作文档吗？
插件或任何其它可加载束都是文件包，Finder将它们作为文件呈现。应用程序也可以像处置文件那样，视可加载束为文档。所以，在“如何在Mac OS X中指明文件类型？”中提出的建议也适用于它们。可加载束应该总是带有扩展名，如果适用的话，也应该将类型代码（“BNDL”）和创建者代码写入束中的Info.plist文件中。关于与所有束相关的定型信息，请参阅“必须为应用程序指定什么样的元数据？”
Finder如何处理文档？
Finder使用文件的类型和创建者代码以及文件扩展名来决定此文档的类型和所隶属的应用程序。当Finder在其中的一个窗口显示文件时，它使用此信息寻找适当的图标以表示该文档。当Finder用文件响应用户操作时，即当用户双击图标打开一个文档时，它将文档类型作为键码来查找对应该操作的应用程序。依据定型信息的特征（例如，有扩展名但是没有类型或创建者代码），Finder可能：
立即用一个应用程序打开此文档
显示一个可供用户选择应用程序的对话框
在可识别该文档类型的应用程序中，用其中的一个应用程序打开此文档
若一个文件既没有类型和创建者代码也没有扩展名，Finder将把它当作一个非文档文件；该文件用一通用图标显示，双击它不会在任何应用程序中打开。
请记住，应用程序可将可加载束当作文档。如果一个束可以被识别的话，双击该束将会使应用程序加载它。为了能处置任何其它文档，应用程序需要指定该束的扩展名、类型代码、创建者代码、角色以及在其信息属性列表中的其它信息。在应用程序能将可加载束作为文档来进行处理前，Finder必须判定它确是一个束。
更多信息请参阅“应用程序和文档的处理”。
为什么要有扩展名？
一些Macintosh软件开发者对文件扩展名感到沮丧。作为指定文档类型和所有权的一个方法，与类型和创建者代码以及可能由多分支HFS和HFS+ 卷格式生成的其它多信息元数据相比，扩展名似乎是很原始的。使用扩展名似乎是倒退了一步。
这是真的，但只在限定的范围内如此。Macintosh用户再也不会生活在狭隘的Macintosh世界中。在互联网时代，文档频繁地在不同种类的网络中传送，例如，从一台家用Macintosh到一台Linux网络服务器，然后到公司局域网的一台Windows计算机中。不仅在文档类型而且在文件的构成方面，上述路径中的每台计算机都可能有不同的概念。许多计算机系统只根据众所周知的扩展名（例如.jpg，.mp3以及.html）来定义文档的类型。它们可能不知道如何处理一个无扩展名的文件，可能会把它当作一个未知的类型。它们也会忽略HFS+ 元数据，或更糟的是会将其完全清除，这样它就无可挽回地被丢失了。
应用程序应如何保存文件？
应用程序应该将它的文档保存为某一种类型，且应用程序只能是以编辑器（Editor）为角色来处理这一类型的文档。当应用程序保存文档文件时，Apple建议它应与合适的文件扩展名以及任何已被定义的类型和创建者代码联系起来。用户以后可改变或删除该扩展名（这样做会付出代价），但在应用程序保存其文档后，应用程序应始终应用所有有效的文档定型方式（包括以扩展名来定型）。（关于这样做的理由请参阅“为什么要有扩展名？”）
当应用程序可采用一种或多种类型来保存文档时，Apple建议它应在Save对话框中的弹出式菜单中显示那些类型（可以将任何一种“本机”文档类型作为预选类型）。然后，应用程序将以下列方式处理扩展名：
若用户没有在文件名域中输入扩展名，则为它添加扩展名。
若用户输入了错误的扩展名，则删除它并添加一个正确的扩展名。
若用户输入了正确的扩展名，则接受它。
另一个可能的方法是显示一个 “untitled”文件名，其添加了正确的扩展名，但只有基本文件名是可以修改的；作为一个例子，“Untitled-1.txt”中只有“Untitled-”是可以修改的。
CFM可执行文件
如前所述，Mac OS X是一个非常方便易用的操作系统。它支持多种文件系统、多种应用程序环境、多个编程模型、多个图形绘制库以及多个网络协议栈。它也支持多个运行时间环境和可执行文件格式。具体地说，Mac OS X可执行下列类型的二进制代码：
由动态链接编辑器（dyld）管理的Mach-O代码模块
由代码片段管理器（Code Fragment Manager，CFM）管理的PEF代码片段
由Java虚拟机管理的Java类文件
在上述三种可执行文件格式中，Mach-O是最为优秀的。它是其它类型最终依赖的本机格式。CFM和PEF技术是Mac OS 9中优秀的库管理程序和可执行文件格式，是通向Mach-O/dyld技术的桥梁，正如CFM-68K曾是通向PowerPC的桥梁一样。也就是说，Mach-O和dyld是Mac OS X的本机可执行文件格式和库管理程序，这就意味着所有系统框架，甚至Carbon框架，都被创建为由dyld管理的Mach-O格式的二进制代码。然而，CFM是传统的Macintosh库管理程序，而PEF是针对代码片段的传统的可执行文件格式，所以目前有很多Macintosh IDE为此运行时环境（包括Classic兼容性环境）生成应用程序可执行文件。
正如“库管理程序和可执行文件格式”一节中所解释的，把用于Mac OS X的应用程序创建为Mach-O可执行文件具有充分的理由。在这些理由中最重要的一个是性能。CFM/PEF运行时环境位于dyld/Mach-O运行时环境的上层；这样，基于CFM/PEF的代码必须通过软件的一个附加层才能执行。
然而，没有什么能阻止您将应用程序创建为由CFM管理的二进制代码。这样的二进制代码在Mac OS X上，包括在Classic应用程序环境中运行都是没有问题的。
的确，可能有时需要CFM应用程序在Classic环境而不是在Carbon环境中运行；例如，当应用程序依赖于尚未完全移植至Carbon的插件时。这时，Finder的信息窗口将呈现一个可使用户在Classic中启动选定的CFM应用程序的选项。若希望忽略此选项并使应用程序始终在Carbon中启动（或始终在Classic中启动），您可指定在信息属性列表中指定适当的Launch Services关键字。若选择以CFM可执行文件来部署应用程序，您必须决定是否将它打包在应用程序束中。当考虑打包时，（Java除外）有三种不同类型的应用程序可在Mac OS X上运行。表13-1给出了可能的类型。
表13-1 Mac OS X支持的应用程序类型
库类型 单文件 在束中
CFM/PEF 支持 支持
dyld/Mach-O 不支持 支持
理论上，您应该将CFM可执行文件打包在应用程序束中。通过这样做，应用程序将获得因打包而产生的所有益处，在“一个应用程序就是一个束”一节中对这些益处进行了详尽说明。一个束化了的CFM应用程序在Mac OS X和Mac OS 9上都易被启动，但方法不同。在Mac OS X中，用户双击文件包（其内容被隐含），然后Finder将启动应用程序。在Mac OS 9中，用户需要打开.app文件夹，并双击包含在其中的一个CFM可执行文件的替身。同时请记住在“应该使用CFM还是dyld？”一节中所提出的建议。理论上，从性能的观点出发，应用程序束应该有两种可执行文件：最适于在Mac OS 9中运行的是由CFM管理的可执行文件，而最适于在Mac OS X中运行的是由dyld管理的可执行文件。目前，还没有用于创建束化CFM应用程序的开发技术；您必须根据“束”和“应用程序打包”两章中的信息，手工创建束。幸运的是，有一个捷径。若您有权使用Project Builder，您可用它创建一个空的应用程序，并为CFM应用程序重新使用所生成的束。即便使用此捷径，当创建CFM应用程序束时必须记住下列事情：
束目录本身应该有“APPL”的类型定义并尽可能设置束位。同时它应该带有.app的扩展名。
CFM可执行文件应该存放在Contents目录下一级的名为MacOSClassic的目录中。
在束目录的顶层，创建一个CFM可执行文件的替身（相同名称的）。下列程序清单对此进行举例说明：
MyApp.app/ MyApp /* alias to Contents/MacOSClassic/MyApp */ Contents/ MacOSClassic/ MyApp ...
创建一个文件名为Info.plist的XML属性列表；在此信息属性列表中，指定如同在“信息属性列表”一节中所叙述的所有必需的键值对。然后，立即将文件存放在Contents目录下。
注意：可使用属性列表编辑器应用程序（/Developer/Applications/PropertyListEditor）来帮助您创建属性列表。若用其它编辑器创建属性列表，并且在文本中包含了非ASCII字符，则应保证该编辑器可保存UTF-8编码的文件。您也可以使用一个现有应用程序的 Info.plist文件作为模板。
遵照“应如何存储应用程序资源？”一节中的说明，请将应用程序资源存放在束中。
如果您希望的话，可将CFM可执行文件以单文件应用程序的方式来部署，该应用程序将其资源管理器式样的资源存放在它的资源分支中。如果这样做并希望Finder能妥当地处理应用程序及其文档的话，您必须将应用程序信息属性列表的内容保存为一个类型为 “plst”，ID为0的资源。若单文件可执行文件没有一个“plst” 资源，则它会被认为是一个仅能在Classic环境中运行的应用程序。通过一个Finder信息窗选项，您也可强制要求CFM应用程序在Classic环境中启动。
用户界面问题
在应用程序准备部署前，您可能必须考虑若干用户界面问题。首先，您应该确保应用程序遵守“Inside Mac OS X: Aqua Human Interface Guidelines（Aqua人性化接口指南）”中的说明。您可以从以下列出Mac OS X技术文件的Apple Developer Connection网站获得此书的PDF版本：
http：//developer.apple.com/documentation/macosx/
其次，应保证对于所有的语言和区域，应用程序已进行了适当的国际化和本地化；作为国际化的一部分，应保证应用程序可在一个文档上支持多个语系的表示。关于这些方面的信息，请参阅“国际化”一章。以下几节将讨论与开发有关的应用程序用户界面的其它方面。
图标
应用程序或文档图标必须是一个“icns” 资源，该资源被包含在有.icns扩展名的文件的数据分支中。Apple提供两个应用程序（在/Developer/Applications中）来帮助您创建并管理图标：
Icon Composer图标设计程序：以最标准的位图形式输入一个图像（包括TIFF，PICT，JPEG和GIF），将其转换为象素尺寸为16 x 16，32 x 32，64 x 64和128 x 128的一组图标。它也为前三个尺寸创建位掩码。为了得到最好的结果，您应该为四个尺寸的每一个都创建单独的图标版本；另外，输入图像的高度和宽度应相等。应用程序以扩展名为.icns的文件保存图标。
Pixie：在各种放大倍率下显示部分的屏幕，并允许将那些放大了的图像复制到剪贴板或作为TIFF文件保存。
/Applications/Utilities中的Grab应用程序也可用于图标设计，因为它能捕获（作为一个TIFF文件）整个屏幕或部分屏幕。
用户可将定制的图标分派给文档，如同他们在Mac OS 9中所做的那样。为此，他们必须将定制图标的拷贝粘贴在保存当前图标的位置内，该图标被显示在Finder的信息窗口中（File > Show Info）。为使用户能够做到这点，您必须放弃在Finder元数据中的默认文档图标。
定制控件和系统外观
若创建一个绘制自身的定制控件，您必须保证它在视觉上与用户在系统预置（System Preferences）应用程序中的通用（General）设置面板中选择的Aqua外观相一致。当前的外观，即应用于按钮、菜单和窗口的颜色，可以是蓝色或石墨色。
为使Carbon定制控件与系统外观一致，定制控件的定义必须利用Appeara
