安装和集成

这一时刻终于到来了！经历了设计、编码、重新设计、调试、测试、调整与修订程序，您已经为您的Mac OS X应用程序工作好几个月了。现在，通过最后的编译，您的应用程序应该会以预想的方式出现：一个优雅、稳如磐石的工程壮举，它充满了力量与潜力。

但是且慢。您确信它没问题了吗？它真的适合部署吗？它已达到商用标准了吗？客户可方便地安装并使用它吗？有无您尚未注意到的事情呢？

本章试图帮助您回答这些问题。首先，本章将提供一张在部署您的应用程序前应该完成的重要任务清单（或至少设想完成的）。一些任务属于fit-and-finish范围，而另一些则对一个设计良好的应用程序来说是重要的。其次，本章将讨论如何使您的应用程序能与Mac OS X的各个部分以及其它应用程序最好地集成在一起的问题。最后，本章将叙述在安装应用程序时您能采取的各种方法以及能使用的工具。通过努力工作，您已经开发了一个了不起的应用程序，它具有您的客户们所重视的特性。现在，请花一点时间提供重要的安装和设置技巧，以确保他们会喜欢您的应用程序。

 

准备用于Mac OS X的软件

对软件开发者来说，Mac OS X是一个非常方便易用的系统。除了与传统相同的（或接近的）方法外，它经常为您提供可选择的方法以完成相同的任务。具有这种可选择的方面包括应用程序打包、资源处理以及文档定型。然而，一个方法经常比另一个更好，有时您可将这些方法组合起来。下节将叙述应用程序设计的各种重要方面，为了获得性能、互用性及强壮性，不仅需要讨论您能做什么，更重要的是讨论您应该做什么。

 

应用程序及文档FAQ

由于各种不同的因素影响应用程序和文档的性质、结构以及处理，故在本书的各个部分都有关于应用程序和文档的信息。这些因素包括束、可执行文件格式、文件系统以及Finder。本节通过为开发者概括文档和应用程序的重要部分，以回答问题的形式将这些信息汇集在一起。

应当为应用程序指定什么样的元数据？

为了让用户启动您的（束化了的）应用程序，Finder应用程序应当能够检测出文件夹是一个束，然后它应当能够查明该束是一个应用程序。为了进行这样的判断，Finder首先检查以下两件事情中的一件：

若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文件可具有任何基本名称，但如果您给予它们标准名称并将它们存放在资源的标准束位置的话，那么系统束例程将自动地管理资源。它按以下方式工作：

当应用程序被启动时，系统束例程将自动地打开这些资源并且使它们可供该应用程序使用。

总之，下列选项可供应用程序资源选择：

若希望Finder妥当地处理应用程序及其文档，您就必须将等同于束信息属性列表中的键值对保存为一个类型为 “plst”，ID为0的资源。

关于更多的此类信息，请参阅“束和资源管理器”以及“资源分支”。

如何在Mac OS X中指明文档类型？

在Mac OS X中，通过指定以下两件事情，您可以指明一个文档的类型：

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可执行下列类型的二进制代码：

在上述三种可执行文件格式中，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应用程序束时必须记住下列事情：

注意：可使用属性列表编辑器应用程序（/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中）来帮助您创建并管理图标：

/Applications/Utilities中的Grab应用程序也可用于图标设计，因为它能捕获（作为一个TIFF文件）整个屏幕或部分屏幕。

用户可将定制的图标分派给文档，如同他们在Mac OS 9中所做的那样。为此，他们必须将定制图标的拷贝粘贴在保存当前图标的位置内，该图标被显示在Finder的信息窗口中（File > Show Info）。为使用户能够做到这点，您必须放弃在Finder元数据中的默认文档图标。

 

定制控件和系统外观

若创建一个绘制自身的定制控件，您必须保证它在视觉上与用户在系统预置（System Preferences）应用程序中的通用（General）设置面板中选择的Aqua外观相一致。当前的外观，即应用于按钮、菜单和窗口的颜色，可以是蓝色或石墨色。

为使Carbon定制控件与系统外观一致，定制控件的定义必须利用Appearance Manager 应用编程接口（API）（已在Appearance.h中说明）。为使定制Cocoa控件与所选定的Aqua外观相兼容，Application Kit类的定制子类应该使用NSColor colorForControlTint，即能够得到相应于当前Aqua色调选择的NSColor对象的方法，然后使用该对象给它自己的绘图着色。

一般来说，您应避免创建那些需要绘制它们自身的定制控件，因为对此总存在一些与Aqua不兼容的可能性。如果您真的需要创建定制控件的话，新的特性在观念上应该包括绘图以外的一些东西。

 

Carbon Nib文件

Carbon项目可使用Interface Builder从“objects”调色板中创建用户界面。在调色板上的对象包括按钮、文本域、滑动块、菜单项、窗口以及进度条。您可为这些对象设置属性、尺寸以及控制信息。Interface Builder将界面作为XML档案来保存，由于它们的扩展名为.nib，所以这些档案被称为nib文件。

Carbon的nib文件可包含用于大多数用户界面对象的定义，这些对象一般出现在Carbon应用程序中。它也为Carbon事件模型等特性整合了一些功能。特殊的Carbon 应用编程接口（API）使应用程序能够使用定义在nib文件中的对象。nib文件不仅是一个用来存储用户界面规格的便利方法，而且也能被用来制作本地化的用户界面版本。另外，由于nib文件是基于XML的，因而与生俱来地与其它环境更为兼容。

为此，Apple建议Carbon开发者应着手将以前存储为资源管理器式样资源的许多用户界面组件转换为nib文件中的对象。关于哪些是可能被做到的，请参考/Developer/Examples/InterfaceBuilder/IBCarbonExample中的项目范例。请注意Carbon的nib文件缺少许多定义在Cocoa的nib文件中的功能（例如，target-action connection目标-动作连接），这主要是由于程序模型和面向对象编程模型之间的差别所引起的。

 

所有权和权限

在基础层面上，Mac OS X是一个BSD系统。支持该说法的部分理由是因为BSD实现了文件系统中文件和文件夹的所有权以及对文件和文件夹的权限控制。此模型依次控制着谁可以读、写、改名和执行文件，以及谁可以在不同的文件夹间复制和移动文件。尽管该模型通常只适用于UFS（或类似的）文件系统，但Mac OS X将它扩充到所有支持的文件系统，包括：Mac OS 标准（HFS）和Mac OS 扩展（HFS+）。

尽管对传统BSD系统的所有权和权限的全面叙述已超出了本书范围，然而对于明白它是怎样不同于Mac OS 9的权限模型以及在Mac OS X上的实现是如何不同于传统的BSD模型来讲，对它作一些理解是必需的。因此，本节在讨论这些差别前，将对BSD权限模型进行简要的概括。（对于更完整的叙述，请查阅为数众多的专门论述BSD的书籍或网站。）

 

BSD权限概要

对于文件系统中的每个文件夹和文件，BSD有三个用户类别：所有者、用户组以及其他人。对于用户的每个类别，都会有三个特殊的权限对于访问文件或文件夹产生影响，即“读”、“写”和“执行”。例如，若任何类别的用户对应用程序都没有执行权限，则他或她就不能运行该应用程序。

在BSD系统中有一个特殊的root用户，也被称为超级用户。对于附属于所使用计算机设备上的文件夹和文件，root用户可不受限制地访问它们；他们可以：

还有一个称为wheel用户组的特殊用户组。在命令行上输入su并提供一个密码后，wheel用户组中的成员用户可被授予成为超级用户的能力。

在BSD的shell中，若您在文件系统的某些位置（如：~steve/ Documents）输入命令ls-l，您可得到类似以下的结果：

 total 3704
 drwxrwxrwx 5 steve staff 264 Oct 24 20：56 General
 drwxrwxr-x 5 steve admin 264 Oct 21 21：47 ProjectDocs
 drwxr-xr-x 6 steve staff 160 Oct 25 12：00 Planning
 drwx--x--x 6 steve staff 160 Oct 21 15：22 Private
 -rwxrwxrwx 1 steve staff 0 Oct 23 09：55 picture clipping
 [spongebob：~/Documents] steve%

在其中，这些结果为文件或文件夹显示了其所有者和主要用户组，以及为每个用户类别显示它们的权限。用户在第三列显示，而主要用户组在第四列显示；在这里，对于General文件夹，它的用户是steve而用户组是staff。第一列是一组十“位”编码，它代表文件系统实体的类型和对于该实体的权限控制。开头的d表示该项目是一个文件夹（目录）；若开头位置处是一个“-”符号，则该项目是一个普通文件。剩下的九位被分成了三个权限组，按次序分别代表所有者、用户组和其他人。如果在其中出现r、w和x字符的话，那么它们表示对于该权限组所适用的用户类型，相应具备了读、写和执行的权限。

在以下例子中，请观察一下对~steve/Documents的Planning文件夹的权限：

drwxr-xr-x 6 steve staff 160 Oct 25 12：00 Planning

此文件夹的所有者权限是rwx，这表示该文件夹的所有者（steve帐户的持有者）可将文件和文件夹复制到此目录中，并可将其作为他或她的当前工作目录（通过cd命令），并可在其中执行任何程序。在staff用户组以及其它用户组中，任何人的权限都是r-x，这表示这些用户可在其中读文件，并可将其作为他们当前的工作目录，但是他们不能将文件写入该文件夹，也不能在该文件夹中更改或删除文件。

ProjectDocs文件夹有着不同的权限：

drwxrwxr-x 5 steve admin 264 Oct 21 21：47 ProjectDocs

在这里，对用户组的读、执行以及写访问权限被打开（rwx），但为了被允许访问，您还必须是一个admin用户组的成员。

每个读、写、执行的三元组也可被表示为0至7之间的一个十进制数。表13-2列出了数字和三元组之间的关系。

表13-2 文件权限映射

十进制数
权限
说明
0 --- 无权限
1 --x 只执行
2 -w- 只写
3 -wx 写及执行
4 r-- 只读
5 r-x 读与执行
6 rw- 读与写
7 rwx 读、写与执行

例如，考虑Private文件夹的权限。

drwx--x--x 6 steve staff 160 Oct 21 15：22 Private

在这里，您可用数字7代表三元组rwx，用数字1代表三元组--x。这样，可将Private文件夹的权限表示为711。用数值表示的方法对于更改文件权限的工具是有用的。

若您拥有适当的权限，您可通过Terminal中的shell来使用chown、chgrp及chmod命令，以分别改变所有者、用户组和个人的权限。详情请参阅相关的man命令帮助页。在Finder信息窗口的Privileges设置面板中，对于选定文件或文件夹，您也可以看到相同的所有权和权限信息。若您是文件或文件夹的所有者，您也能在此窗口中改变其权限。

 

Mac OS X的文件权限

传统的BSD权限语义和Mac OS X实现之间的最大差别可能是，当系统安装以后，在Mac OS X中root用户是被禁用的。即使用户属于wheel用户组（授与超级用户特权的传统方式），他们也不能通过su命令而成为超级用户。这样做的理由是显而易见的，这就是为了安全。因为root用户对文件系统有不受约束的权力，不管故意与否，他或她具有进行发泄破坏的潜在能力。如果启用远程登录或其它形式的远程访问，安全问题则更加令人关注。

然而，Mac OS X给管理员用户提供了root用户的地位。管理员几乎能执行root用户的所有操作，并可使用Finder来完成这些操作（即，不凭借命令行）。管理员被唯一限制做的事情是在系统域中直接增加、修改或删除文件；然而，管理员可使用特殊的应用程序，例如安装程序（Installer）或软件更新程序（Software Update）来达到此目的。管理员并不需要是一个真正的用户（在具有“admin”帐户的用户意义上来说），管理员是属于管理用户组的任何一个用户。

在系统上安装Mac OS X，并把信息提供给Setup Assistant应用程序的用户将自动地成为系统的第一个管理员。随后，此用户（或任何其它管理员）可使用帐户（Accounts）系统预置中的用户（Users）设置面板，在本地系统上为新用户创建帐户。通过在用户帐户上设置适当的选项，管理员可将管理特权转让给一个新的用户。具有管理权的用户属于“admin” 用户组。没有管理权的用户属于“staff” 用户组。

尽管root用户被默认地禁用，但如果您是一个管理员的话，您可重新启用它，并获得超级用户身份。但是，为了安全，只有当情况绝对需要时才可这样做。为了使root重新启用，请运行/Applications/Utilities中的NetInfo Manager应用程序，并认证自己为本地管理员。然后在Security菜单中选择Enable Root User；只有当您是本地管理用户组的一个成员并且您以前已在本地域中被认证了，此菜单项才会生效。一旦您被启用为root用户，您的密码将是空白的，因此建议您给root设置一个密码（通过Domain > Security > Change Root Password命令）。在完成了要求root访问的任务以后，您应该通过从相同的菜单中选择Disable Root User以放弃超级用户特权。

 

应用程序和文档的权限

当用Project Builder创建应用程序时，创建子系统将自动地将可执行文件的权限设置为-rwxr-xr-x；此设置使所有者，即安装应用程序的人，能够执行和写入应用程序，而所有其他人只能执行它。其他的IDE在所创建的可执行文件上也设置了类似的权限。除了应用程序需要特权（root）访问的罕见情形以外，-rwxr-xr-x的设置可满足大部分的要求。一个例子是诸如磁盘修复程序的应用程序需要进行内核级别的低水平硬件访问。在诸如这样的场合中，您应该安装应用程序setuid以便为应用程序获得root访问，然后使用NetInfo Kit和System框架中的功能来允许您认证管理员。关于setuid的更多信息，请查询setuid（2）和chmod（1）man 命令帮助页。

尽管应用程序的权限设定（特别是“x” 位）决定了谁能启动这个应用程序，但是一旦该应用程序被启动，该进程即被启动它的用户拥有。这意味着应用程序被授于了个人的所有者和用户组的身份，应用程序与登录用户具有相同的访问权利。因此，若该用户具有将文档写入某个位置的权限，则该应用程序就可将文档保存在那儿。

当Carbon，Cocoa或Java应用程序保存文档时，各自的应用程序环境将根据用户的umask值自动地设置文档的权限。默认情况下，这一权限禁止用户组和他人进行写访问。文档的此公共设置（-rw-r--r--）允许所有者读和写文件，而所有其他人只能读文件。如果希望应用程序的文档具有不同的权限，您必须使用文件管理应用编程接口（API）来设置权限；对于Carbon，这些功能由文件管理器（File Manager）提供；而对于Cocoa，则由NSFileManager类提供。

 

Classic环境和应用程序

Classic兼容性环境（或简称为Classic）使Mac OS 9的最新版本以及所有能在该版本上运行的应用程序可在Mac OS X系统上运行。如同您所期待的，Classic中 的Mac OS 9与“本机” Mac OS 9系统之间非常相似。然而也存在着差别，并且有些差别尤其对应用程序开发人员来说是非常重要的。

本节将叙述Classic环境，尤其是它与本机Mac OS 9系统的兼容性以及它与Mac OS X其余部分的集成。它告诉开发人员当Mac OS 9应用程序在Classic中运行时他们应该加以考虑的事情。对于Mac OS X的应用程序环境（即Carbon，Cocoa以及Java），它也告诉软件开发人员关于可能引起在Classic环境下运行的应用程序出现问题的所涉及领域。

关于术语的一项说明：在以下讨论中，有时明确地将Classic环境与Mac OS X作比较；当然，这里暗示指的是“Mac OS X的其余部分”。

 

Classic环境概要

Classic环境被称为“软件兼容性” 环境，因为它使在Mac OS以前版本中创建的应用程序可在Mac OS X系统上运行。这样，在完全过渡到Mac OS X之前，用户仍可使用遗留下来的应用程序。由于此过程需要跨越很长的时间阶段，因此在近期Classic环境仍会是操作系统的一个必要组成部分。

对于所被宿主的Mac OS 9操作系统，Classic是一个新的“硬件”平台。它使用Mac OS X内核环境（特别是I/O Kit）来实现硬件服务。Classic环境不是一个仿真器；Mac OS 9可以本机方式在其间运行。它在视觉及功能上与Mac OS X的其余部分保持兼容，所以对用户来说（除了在“与Mac OS X的集成”一节中所提及的以外），它与Mac OS X的其余环境基本上无法区别。

因为体系结构上的差别，Mac OS 9与运行在Classic环境中的应用程序并不能共享内核环境的全部优势，包括内存保护和抢占式多任务处理。这样，若运行在Classic环境的应用程序崩溃或暂停，有时环境本身必须被重新启动。但只是Classic环境需要被重新启动，作为其宿主的Mac OS X系统并不需要。

 

与本机Mac OS 9的兼容性

若在本地Mac OS 9系统上运行的程序试图直接在系统的较低层面上做所有事，那么它们就可能无法在Classic环境中运行。具体地说，这意味着存在下列情形：

通常，那些限制或依赖于由内核环境（特别是I/O Kit）所提供的硬件抽象以下的Mac OS内部接口的程序将不能在Classic环境中运行。如果可能，这些程序应该为这样的访问改用一种高水平的应用编程接口（API）。例如，所有的文件系统访问应该通过文件管理器（File Manager） 应用编程接口（API）。

 

设备支持

通常Mac OS X支持的大多数设备也是Classic环境所支持的（或计划很快支持的）。被支持的设备种类包括如下：

Mac OS X装载所有的块存储（“磁盘”）设备，通过文件管理器（File Manager）应用编程接口（API），Classic环境把它们看作为磁盘卷。如果Mac OS X没有使用设备的话，Classic环境可抢占对一个设备的访问。磁盘映像（包括SMI）以及装载在Mac OS X 上的AppleShare卷通过Classic内的文件管理器（File Manager） 应用编程接口（API）呈现。请注意Mac OS X总是抢占对USB键盘和鼠标的访问；Classic在更高级的事件水平与这些设备进行通信。

Classic不支持的设备类型包括如下：

对于PPP（调制解调器）以及AirPort通讯，Mac OS X中的PPP连接可作为Classic中的网络连接。

 

与Mac OS X的集成

只要有可能，Apple就设法使Classic环境的组件与它们在Mac OS X中的对应物相一致。然而，不可能所有的事情在外观及表现方面都相同。一些差别将随时间的推移而消失；而另外一些则反映出无法协调的差别。

本节对那些存在已知差别的集成部分进行讨论。在以后的操作系统版本中可能会引入其它的差别。作为经验，如果不知道一个特定的Classic组件是否能与Mac OS X的其余部分集成的话，就假定它不能。

 

用户界面

Classic环境下的窗口和其它用户界面元素与Mac OS X的其余部分之间的差别可能是最显著的。Classic窗口具有白金般的外表和感觉，而不使用Aqua。例如，Classic窗口上带有关闭钮（close box）、收缩钮（collapse box）以及放缩钮（zoom box），而并非使用半透明的红色、黄色和绿色的窗口控件。当您点击收缩钮（或窗口标题栏）时，不会出现Aqua那样的隐藏窗口的特殊 “genie” 效果；窗口中的内容只是简单地消失而已。Classic的白金窗口也不会投射“阴影”。

您也能看到Classic应用程序和其它Mac OS X应用程序采用的菜单约定方面的一些差别。例如，在Mac OS X应用程序中，用于终止应用程序的菜单命令的放置位置是不同的；Classic应用程序在File菜单中有Quit菜单选项，而Mac OS X应用程序在应用程序菜单中有“Quit application”菜单选项。

在诸如调整窗口大小及拖曳窗口的操作方面也存在差别。在进行这些操作的过程中，Aqua窗口在每一位置都会被重新绘制。然而，当您拖曳Classic窗口或调整其大小时，您将只能看到窗口的一个轮廓（一个选取框），并直到操作结束时该窗口才会重新绘制。Classic没有被加入半透明效果，且当Classic对象在半透明的Aqua窗口下面时，该对象可能完全显示为白色。而当Classic窗口在Aqua对象上面时则不是这样。

另一个明显的差别是文件系统浏览器。对此功能组件，Mac OS X只利用导航服务（Navigation Service），而Classic应用程序可使用导航服务（Navigation Service）或标准文件包（Standard File Package）。

在集成方面，Classic与Mac OS X都支持OpenGL和8位图形。

 

Classic环境和文件系统

Classic环境支持由Mac OS X支持的大多数文件系统，包括Mac OS Standard （HFS），Mac OS Extended （HFS+），AFP，ISO 9660和UDF。但是，它不支持UFS或NFS文件系统。因此，Classic应用程序不能读、写甚至看到NFS或UFS盘卷。

在处理文件系统访问权限的方式上，Classic环境也与Mac OS X不同。尽管Mac OS 9本身并不知道在本地磁盘卷上的权限，但AFP会逐个文件夹地来识别权限；对文件的访问由分配给包含文件的文件夹的权限来决定。Classic 将“BSD权限失效”映射到所对应的最接近的“AFP权限错误”上，这为运行在Classic环境中的应用程序创造了最好的兼容性。

由于此权限－集成模型，Classic环境中的应用程序（特别是安装程序）可能会遇到问题。没有妥善处理AFP权限错误的那些应用程序可能会呈现令人误解的错误信息甚至故障。另一个与权限有关的潜在问题是在Classic和Mac OS X使用相同的磁盘或分区时出现的问题。由于只有root所有者才能写入引导盘卷的根目录，所以在文件系统的根目录安装软件的任何尝试都将失败。这些应用程序的安装程序必须提示用户选择一个文件夹。

注意：对于在Mac OS X上具有这些问题的安装程序来说，唯一的补救经常是用户重新引导本机Mac OS 9，并在那里进行安装。

除了在一些特殊的位置，例如系统文件夹（System Folder），废纸篓（Trash），桌面文件夹（Desktop Folder）以及特定于Mac OS 9的某些隐藏文件夹，Classic都尊重BSD的文件权限。如果用户在Classic环境的文件系统中的根目录具有读写权限的话，那么Classic应用程序就可写入系统文件夹（System Folder），并能将项目移至废纸篓（Trash）文件夹。当在Classic环境下运行的程序试图写入一个它不具权限的文件夹时，将返回一个AFP错误代码。

对于AFP文件共享，Classic将通过Mac OS X来完成。

 

功能扩展和预置

在Macintosh计算机系统的典型设置中，本机Mac OS 9系统首先被安装在硬盘的一个分区或一个独立的硬盘上。然后，Mac OS X被安装在该系统上，并且Mac OS 9盘卷被选为Classic环境的启动磁盘。有了此设置，用户既可在Classic环境也可在本机Mac OS 9系统上使用同一组应用程序、功能扩展、预置以及其它软件。

用于本机Mac OS 9系统的一组功能扩展与在Classic环境中的对应功能扩展之间可能会存在冲突。这些冲突可导致崩溃。一般地，当存在冲突的功能扩展时，Classic在启动时将禁用对应的“本机” 功能扩展。一个恰当的例子是多用户（Multiple Users）功能扩展。Mac OS X本质上是个多用户系统。因此，Classic环境在启动时禁用多用户（Multiple Users）功能扩展；当用户从本机Mac OS 9系统引导时，多用户（Multiple Users）功能扩展将被重新启用。

注意：对于Classic环境的版本说明中列出了当前已知的一组存在冲突的功能扩展。

Classic环境以类似的方式处理存在冲突的预置（通常与联网有关）。用户使用Mac OS X中的System Preferences应用程序设置的任何预置将覆盖对本机Mac OS 9系统设置的任何对应的预置。然而，当用户从本机Mac OS 9系统引导时，所有“本机” 预置将被恢复。Classic不进行任何反过来影响本机Mac OS 9系统配置的永久更改。

 

Finder和桌面

Classic环境与所有其它应用程序环境共享Mac OS X桌面。利用Mac OS X Finder，用户可在包括Classic的任何环境下处理文件和应用程序。有了Finder，他们可以：

Classic环境以类似本机Mac OS 9的方式显示一个复合桌面。此复合桌面包括用于引导卷的Mac OS X 桌面（Desktop）文件夹，以及来自所有Classic可看到的其它装载卷的桌面文件夹（这里排除了UFS或NFS卷）。Classic处理AFP卷的方法与本机Mac OS 9处理它们的方法相同。若这样的卷有一个桌面文件夹（Desktop Folder），它将从复合桌面中被排除，但可通过Classic的标准文件包（Standard File Package）和导航服务（Navigation Services）的应用编程接口（API）来访问AFP卷的根目录。

若Mac OS 9 桌面文件夹（Desktop Folder）在根卷上，那么Mac OS X Finder和导航服务（Navigation Services）将隐藏它。当Mac OS X是在Mac OS 9 “上”安装的，若用户想从Finder或导航服务（Navigation Services）到达Mac OS 9 桌面文件夹（Desktop Folder），他们可通过/MacOS9中的一个替身来找到它。当用户切换回本机Mac OS 9引导时，他们将看到Mac OS 9桌面，即在所有装载卷上的所有非AFP桌面文件夹的组合，这正如同他们在离开时看到的那样。

Mac OS X Finder在Classic环境中执行系统文件夹（System Folder）的自动路由选择以及Mac OS 9 系统文件夹（System Folder）的保护。

 

联网与打印

在Classic中的网络环境最大程度地与Mac OS X的网络环境相集成。Classic与Mac OS X共享网络设备（以太网、AirPort以及PPP）、计算机 IP地址以及IP端口地址空间。然而，Classic运行了完全的Open Transpor协议栈（具有完全的流支持），而Open Transport在Carbon中的局部实现被创建在了BSD socket之上。

另外，用于Classic环境的互联网配置（Internet Config）的软件版本与用于Mac OS X的互联网配置的软件是不同的。调用在Mac OS X中所做的互联网配置，需要查看Mac OS X的互联网配置数据库，而调用在Classic中所做的互联网配置，需要查看Mac OS９的互联网配置数据库。这可能会引起一些混乱，由于使用了不同的互联网配置，以及两个数据库中具有不同的配置，一个启动您默认浏览器的请求很可能会产生不同的结果。

在Classic环境中的打印机设置与在本机Mac OS 9系统中一样，即都使用选配器（Chooser）或桌面打印工具（Desktop Printer Utility）。然而，在Classic中使用时的不同之处在于实际的桌面打印机未被Mac OS X Finder显示在桌面上。当应用程序在Classic环境打印时，您可在Print 对话框中所配置的打印机中进行选择，该对话框使用与本机Mac OS 9相同的弹出式菜单。当在Classic中打印时，它退而使用打印监控器（Print Monitor）而非桌面打印监控器（Desktop Print Monitor）。

 

其它的Classic集成问题

这里还有一些开发者感兴趣的关于Classic集成方面的其它问题：

 

安装应用程序

有若干利用Mac OS X安装应用程序的选择。您可简单地指示用户将应用程序拖曳到他们的硬盘上，您也可为应用程序准备一个安装程序。本节将叙述这些可能性，并对安装应用程序时需要您做的工作进行概括。

 

安装到何处

如同在“文件系统是如何组织的”中所叙, 在文件系统的标准目录布局中有若干应用程序可被安装的位置：

一般地，Mac OS X系统的大多数应用程序被安装在/ Applications中，这样能使它们可供一特定计算机系统的所有用户使用。然而，若应用程序的使用是有限制的，例如，它是在单用户许可权的条款下被购买的，那么它应该被安装在用户home目录的Applications文件夹内（此文件夹可能必须被首先创建）。若一个应用程序对于局域网上的所有用户都是可执行的，那么网络的管理员就应该在可供那些用户访问的一台文件服务器上安装该应用程序。

注意

不要将任何软件或资源，例如框架或字体，安装在/System/Library中的任何地方。这些项目应存放在本地域（/Library）的适当位置处。

并不要求用户只能在一个域位置安装应用程序。因为当应用程序被打包在束中时它们基本上被设计成自包含的，所以用户可将它们安装在任何地方，这并不妨碍它们的执行。然而，由于被安装在被建议的位置以外，应用程序可能会无法利用到一些系统特性，例如针对Cocoa应用程序的应用服务。另一个失去的特性是Finder对应用程序的认可。Finder在创建它的应用程序数据库时，会在已知域寻找应用程序。而若应用程序在所有域以外，就会影响系统的效率。关于Finder和应用程序的更多信息，请参阅“Finder”一章。

 

手工安装

由于Mac OS X的大多数应用程序被打包成自包含束，所以在大多数情况下用户在安装应用程序时所需做的仅仅是将束拖曳到对其拥有写权限的一个文件夹内。当您有一个只需进行这类安装的简单应用程序时，您可随应用程序一起提供告诉用户该做什么的说明（以简短联机或打印文档的形式）。

拖放式安装是Mac OS X中使用的首选方法。由于应用程序在它的束内保存有它需要的所有内容，所以简单的手工安装可减少文件系统的混乱，消除与驻留在文件系统其它地方的项目的相关性。它也给用户一个选择，使用户可不复制他们不特别感兴趣的项目到他们的硬盘中（例如Read Me文件）。在卸载应用程序时，用户需要做的也仅仅是将应用程序束从盘卷中删除。

作为应用程序组件简单安装的一个机制，Finder支持许多“应用程序打包”中的关键字。当您创建应用程序时，您可在应用程序的信息属性列表（Info.plist）中指定这些关键字以及它们的对应值。然后，当用户选择该应用程序并打开Finder的信息窗口时，该窗口的Application Files设置面板将列出这些组件。用户可选择任一组件进行安装（或选择任一组件进行卸载）。

关于这些关键字的更多信息，请参阅“软件配置”一章的“CFBundleVersion”。

 

安装程序

对于某些应用程序，简单的拖放安装将不能满足要求。这不仅是因为准备执行应用程序的要求太复杂，而且使用安装程序的益处也非常引人注目。这些益处包括：

注意
尽管使用安装程序可能有一些益处，但Apple建议尽可能使用简单的拖放式手工安装。只有当应用程序因为某种原因需要在它们的束外面安装项目时，您才应该使用安装程序。

若您决定使用安装程序来安装应用程序，您有若干选择。若您的应用程序是Cocoa或Java应用程序，或者是只能安装在Mac OS X的Carbon应用程序，您可使用Mac OS X的本机安装程序技术。若您的应用程序是Carbon应用程序，并且您希望在Mac OS 9和Mac OS X上都安装此应用程序，您可采用下列两个方法中的一种：

用于Mac OS X的本机安装应用程序被称为Installer，它位于/Applications/Utilities内。当用户双击安装包时，Installer应用程序即被启动。该应用程序通过为诸如认证用户特权（如图13-1所示）、指定安装位置以及定制安装等呈现一系列设置面板，并在安装过程中指导用户。Installer应用程序也能显示材料清单和安装日志。 “安装包” 一节叙述了安装包的结构和内容。

图13-1 安装应用程序

使用另一个被称为Package Maker（/Developer/Applications/PackageMaker）的应用程序，您可为Mac OS X创建一个可安装的包。“创建安装包”叙述了准备打包软件和使用Package Maker的一般方法。

 

安装包

Mac OS X中为Installer准备的软件本机形式被称为包。安装包是一个文件包，即作为文件呈现给用户的一个文件夹，其扩展名为.pkg。一个安装包包含若干组件，最重要的是文件归档包、Read Me和许可权文档（可选择）以及所有安装程序的脚本（可选择）。安装包的格式使Installer安装程序能够提供有效的功能，例如描述信息、默认安装位置和其它信息。

尽管Finder将包作为单个文件系统实体呈现，但您可使用BSD的cd命令（通过Terminal应用程序）进入包目录并浏览包的组件。对于组成一个包的各种文件，它们利用文件的后缀名来对文件中存储的信息类型进行说明。一个基本包包含以下文件：

因为安装包实质上是一个文件夹（即文件包），所以在处理过程中，它们的内容易受到破坏和影响。为了准备分发包，您应该将包再进行归档打包，或者压缩成可被安全分发的形式。

 

创建安装包

创建安装包的一般步骤包括以下二－三步：

1．创建一个发布目录，并把即将安装的软件复制到该目录内。

2．可选地创建一个安装资源目录，并将诸如Read Me文件、许可协议以及安装脚本等存放在到该目录内。

3．启动Package Maker，并完成填写所显示的“表单”。

关于这些步骤中每一步的信息，请参阅“创建发布目录”、“创建安装用资源目录”以及“完成填写Package Maker表单”等节。

 

创建发布目录

创建一具有子文件夹结构的文件夹，该文件夹构成安装您软件的默认目录层级的一个本地“镜像”。然后，将您的软件复制到适当的位置（或若干位置）。该目录层级被“扎根” 在一个文件夹中，因为该文件夹指向分发后的根目录（/），故常被命名为dstroot。发布目录中的内容被生成包的文件归案。

例如，若您已经创建了一个框架并希望将其安装在/Library/Frameworks中，您可以创建目录层级~/dstroot/Library/Frameworks并将该构架复制到此位置。当Package Maker创建您的包时，它将记录此目录层级。当您的包被安装时，安装程序将把软件放置在文件系统的正确位置处。（然而，若您的包是可重定位的，用户可以选择在其它地方安装它。）

 

创建安装用资源目录

如同在“安装包” 中叙述的那样，包中可包含仅在安装时使用但不随软件一起安装的辅助资源。两个常用的此类资源是Read Me文件和许可权文档。Read Me文件包含有用户安装软件前应该（或可能要）读的信息。许可权说明了用户使用该软件所必须接受的条款。

这些Read Me和许可权文件可以是下列三种形式之一（具有适当的扩展名）：文本（.txt），HTML（.html）或Rich Text多信息文本格式（.rtf）。当您创建文件时，请使用能以Unicode编码保存文件的文本编辑器。特定的文件基本名是为Read Me和许可权文件保留的。若Read Me文件被命名为ReadMe.ext而许可权文件被命名为License.ext，那么Installer安装程序将会识别并自动地处理这二个文件（若它们出现在包中）：

因为辅助的安装资源并不随您的软件一起安装，所以不应将它们存放在发布目录中。而应在与dstroot相同的层次创建一“resources”目录并将文件存放在那里。当资源目录被创建时，它的内容被复制入包内。

完成填写Package Maker表单

您可使用Package Maker应用程序来配置并创建安装包。使用它非常方便；您只需填写图13-2中所示的栏目和复选框的简单表单即可。

图13-2 Package Maker用户界面

请注意开头的两个域：Package Root Directory和Package Resources Directory。这些域应包含指向先前创建的发布目录和资源目录的根路径。关于这些域以及其它域和控件的用途和所需填写的值，请参阅“应用程序的联机帮助”。

 

全系统资源

若束化了的可执行文件具有因某种原因必须被安装在束外的资源，那么安装程序应该处理它们。为了利用系统服务，这样的资源常常需要存放在确定的位置处。其中的一个例子是字体。Apple Type Solution（ATS）系统通过在系统、本地、网络以及用户文件系统域的Library/Fonts目录中搜寻它们来管理字体。

另一个与文件系统域有关的问题是资源的限制。例如，若您希望一个可供单用户而非Mac OS X系统的所有用户使用的受许可权限制的字体，那么安装程序应该把它存放在用户的 ~/Library/Fonts文件夹而不是/Library/Fonts文件夹中。

您应该知道对全系统资源推荐的域位置，并用Installer安装程序将这些资源存放在合适的位置或一个用户选择的位置处。（关于这些位置的信息，请参阅“文件系统是如何被组织的”。）若该位置要求系统管理员特权，Installer安装程序应该认证用户。Mac OS XInstaller安装程序技术允许选者安装子包或将子包安装在应用程序束外。它使用metapackages的概念管理这些子包的集合。Metapackages是一个文件扩展名为.mpkg的文件包。Installer安装程序为这组基于metapackage的可安装包显示一个Customize按钮。

 

[ 返回 ]