计算环境能够执行为该计算环境的硬件组件设计的，包含一条 或多条指令的计算机代码，以执行一个或多个操作。通常计算机代 码要加载到计算环境中执行。在物理加载前，计算机代码可以被编 译以使之能够在特定的计算环境中操作(例如，计算环境操作系统和 /或计算环境平台)。计算机代码能被计算环境链接到驻留在该计算 环境中的其它计算机代码中，以执行一个或多个操作。根据计算环 境对给定计算机代码的处理方式，可以创建二进制对象给该计算环 境使用和/或与其它计算机代码协同操作。该二进制对象可能包含一 个或多个协同计算程序(计算程序)需要的信息、函数和/或操作。
进而，一个或多个函数可以聚合到一个或多个库中，以便为计算 应用程序、其它库或计算环境所使用，以执行一个或多个操作。在 通常的实践中，设计实现的库可以被拥有特定硬件体系结构的单个 计算环境使用。库能够基于静态或动态库的形式被计算环境使用。 在静态背景下，给定计算应用的库和其它组件被联合到单个文件 中，它能够被加载至存储器执行。相对的，动态操作(例如，动态链 接组件)函数和组件(例如，对象和库)被设计成在计算应用执行时 使用。动态组件能够在计算环境上的多个计算应用中共享，因为动 态链接的组件在设计和操作上不与计算应用的主要部分绑定。
但是，当前的实践在创建和执行为不同计算环境使用的计算机 代码时很麻烦。因为当前的实践通常要求为具有特定计算硬件架构 的特定计算环境创建和执行代码(例如，通过软件开发包-SDK)， 为数个不同计算环境(例如，拥有不同操作系统和/或计算平台)创 建单个二进制对象很困难。当为特定计算环境创建代码时，计算机 代码能够在加载到计算环境之前预先编译，在执行计算机代码时被 计算环境链接。由于这些限制，计算机代码通常只为单一计算环境 (即操作系统和/或平台)设计和创建。
另外，计算环境会对计算机代码创建的方式施加限制和规则， 从而使之在给定的计算环境中能够正确的执行。例如，平台和/或操 作系统(例如，运行Symbian Quartz的SymbianOS)对在该特定平台 和/或操作系统上执行的计算机代码施加数个限制，包括但不限于， 对可写静态和/或全局变量的使用。换句话说，平台和/或操作系统可 以禁止具有可写静态和全局变量的计算机代码。
在计算机代码开发人员中普遍的实践包括但不限于，开发各种 执行相同操作的代码，但是这些代码要针对每个不同的操作系统和平 台进行构建。例如，可以使用单一高级编程语言来开发日历计算应 用，比如Java，C++或Visual Basic。为了减少开发时间和资源，核 心计算应用代码可以被开发人员重复使用。但是，这种重用的范围 有限，因为当前实践中需要开发和定制额外的组件(例如，库、函数、 数据结构等)以确保计算应用在每个不同的计算环境(例如，操作系 统和/或平台)中都可操作。
传统实践和方法还有其它限制，包括但不限于，无法使单个平 台无关的二进制对象无需为每个不同计算环境重建或重新编译而跨 不同计算环境操作。此外，当前的实践和方法在不提供本地支持的 平台中没有提供用于共享对象的动态链接的机制。同时，在当前实 践中，预先编写的代码组件可能由于违反特定代码中的平台限制产 生不兼容，从而无法在平台中使用。此外，当前实践没有为非面向 对象代码的加载提供机制，非面向对象代码可以绕过多执行实例和 代码内在的循环执行的限制。同时，当前实践和方法没有提供在封 闭式平台(例如，限制执行附加程序的平台)中允许动态链接和加载 二进制对象的机制。

在此描述的系统和方法提供了能够在拥有选定硬件架构的不同 计算环境中操作的平台无关的二进制对象(PIBO)，而无需重新编 译、重建或重新加载。在示例的实现中，提供的二进制对象拥有选 定的结构(例如，对象文件格式)。该二进制对象文件能够通过编译 源代码创建，当源代码被创建时不具有平台依赖性。在示例实现中， 二进制对象文件包括用于源文件的二进制代码和数据。此外，在示例 的实现中，提供示例性解析程序对示例的二进制对象文件进行操 作，生成源代码桩文件。此外，提供作为示例的计算应用一部分的 示例链接程序/加载程序，其使用该桩文件链接和加载该平台无关二 进制对象，使之允许与不同计算环境中的计算程序协作。同时，还 提供示例接口允许协作计算应用访问例子中的PIBO。
在示例的操作中，所述PIBO文件能够被示例的解析程序分析， 以源代码的方式生成桩文件。该桩文件源代码不依赖平台。示例的 链接/加载程序和桩文件，可以和一个不同计算环境的协作计算应用 的主要源代码编译在一起，生成该一个不同计算环境(和/或平台) 中可运行的二进制可执行文件。在示例的实现中，在该协作计算应 用执行时，示例的链接/加载程序能够将该PIBO链接和加载到协作 计算应用中。在示例的实现中，该链接/加载程序能够处理符号的解 析和重定位，将协作计算应用的二进制可执行文件与该PIBO绑定在 一起形成一个整体的可运行进程。
在示例的实现中，所述PIBO能够在不同的背景中使用，包括但 不限于，作为不提供本地设施的平台上动态链接共享对象的机制； 利用在平台上预写好的代码组件，该特定代码本来由于违反平台限 制而不兼容；作为加载非面向对象的代码的机制，该非面向对象的 代码绕过多执行实例和重复执行代码的限制；以及作为允许使用的 二进制对象为封闭式平台提供附加功能的机制。
本发明的其它特性将在下面继续深入探讨。
附图说明
平台无关的动态对象和使用方法通过结合附图举例进行详细描 述，其中：
图1是根据所描述的系统和方法的实现的示例计算环境框图；
图2的框图示出示例数据通信架构的示例组件的协作；
图3是动态链接架构的框图；
图4是在将相同的库链接到第一个不同计算平台操作系统时的 动态链接架构框图；
图5是在将相同的库链接到第二个不同计算平台操作系统时的 动态链接架构框图；
图6是支持根据在此描述的系统和方法的多个平台的多个操作 系统的框图；
图7中的框图显示的是根据在此描述的系统和方法的平台无关 链接架构的示例平台中各个示例组件间的交互；
图8中的框图显示的是根据在此描述的系统和方法的主要应用 程序和动态库之间的交互；
图9显示的是根据在此描述的系统和方法的平台无关链接架构 的示例平台执行的处理流程图；
图10显示的是在没有本地设施支持的计算环境中动态链接平台 无关的二进制对象时执行的处理流程图；
图11显示的是在受限计算环境中使用平台无关二进制对象时执 行的处理流程图；
图12显示的是在受限计算环境中使用平台无关二进制对象运行 协作计算应用的多个实例的处理流程图；
图13显示的是在封闭式硬件环境上使用平台无关二进制对象扩 展功能时执行的处理流程图；以及
图14显示的是根据在此描述的系统和方法的示例实现的受限计 算环境中通过下载启动应用以提供扩展功能时执行的处理流程图。

1、概述
计算机代码能够在计算机系统或设备内的中央处理器(CPU)或 其它计算处理器上执行。常见的CPU架构包括但不限于，INTEL_ x86系列、ARM_RISC(精简指令集代码)架构、SUN_SPARC和 MOTOROLA_68000。代码可以写成人类能够理解的高级程序语 言，比如C、C++或JAVA_，但最终这些代码会被计算环境编译和汇 编成在示例计算机处理器上执行的机器指令。
CPU可以处于软件环境中，该软件环境通常被称作系统平台。 该平台可以包括操作系统，比如为更大型计算环境设计(例如，桌面 系统、膝上个人计算机)的MICROSOFT_WINDOWS_和Linux。 对于更小型的计算环境(例如，移动和通信设备)，有多种操作系统 正在使用，包括但不限于，Linux、SymbianOS、WindowsCE_、 PalmOS、BREW、REX和Itron。
平台通常可以为特定目扩展操作系统而维护额外的功能。例 如，WinCE.NET、Smartphone和PocketPC平台使用的是Windows CE 操作系统，但在其它方面有所不同，比如用户界面——即， WinCE.NET能以工业设备为目标，PocketPC能以带触摸屏的个人数 字助理(PDA)为目标，Smartphone能以键盘操作的移动蜂窝电话为 目标。平台还能包含根据特定计算应用定制的扩展功能。在提供的 例子中，PocketPC平台可以在PDA上维护一系列个人信息管理功 能，而Smartphone平台可以装配适合移动电话的通信功能。
在传统系统中，创建能够在特定平台上运行的二进制代码可以 通过使用工具链编译构建代码，比如为特定平台(和/或操作系统) 提供的软件开发套件(SDK)。在给定的操作系统上需要不同的SDK 来开发不同平台的代码(例如，Symbian Quartz需要的SDK与 Symbian Crystal不同)。如果为特定平台开发代码使用了不合适的 SDK，生成的二进制代码就无法运行在期望的平台上。
在源代码级，有些操作系统对代码的编写方式施加了限制和规 则。例如，SymbianOS要求创建的代码不能使用可写静态变量或全 局变量。作为这些限制的结果，一开始为一个操作系统编写的先前 的代码可能无法在另一个要求不同代码规则的操作系统上编译。虽 然如此，普遍的做法是编写单一的可以随后在多平台构建的源代 码。在实现时，可以开发通用源文件。通用源文件可以通过选定平 台的工具链分别处理，从而从单一源文件创建多个不同的特定平台 的二进制输出。
2、动态链接和加载
计算机程序可以包含多个组件。当程序运行时，组件可以组合 在一起形成完整的功能系统，并可以被加载进协作计算环境的主存 储器中执行程序。合并计算程序组件的过程被称为链接。当程序组 件被合并进可以被加载进存储器执行的单个文件时，该过程被称为 “静态链接”。通常，链接程序是工具链的一部分，它以组件对象文件 作为链接程序的输入，连接这些文件形成单个输出文件。当程序是 由多个子程序组成时，一个子程序到另一子程序的引用可以通过符 号(比如变量和函数名字)做到。除了其它函数和操作，链接程序可 以在协作计算环境存储器通过符号(或多个符号)的位置分解引用， 然后补上对子程序调用的对象代码，这样调用指令就能指向所需的 存储器位置。
在“静态链接”中，当程序调用存储在另一组件内的函数时，所 需函数代码能够由静态链接程序合并进可执行程序。实际做法是静 态链接程序将所有需要的函数代码拷贝进输出可执行文件。相反 的，“动态链接”可以使函数和组件只在执行程序的时候可用。因为 动态链接组件通常不与程序主要部分绑在一起，它们可以被多个可 执行程序共享。主程序还可以比静态链接的对应程序小很多，因为 实际代码不会成为程序的可执行文件的一部分，因为动态链接组件 作为分开文件存在。“动态链接”在当今的计算环境中十分普遍。例 如，在微软_的WINDOWS_中，动态链接组件被称为DLL(动态链 接库)，在Unix/Linux中他们被称为共享对象(.so)文件。
举个例子，一个程序调用动态链接库中的函数，编译程序和链 接程序可以生成重定位表，其中包含在运行期能够允许协作计算环 境加载库和找到所需函数代码的信息。在动态链接库中，直到使用 该库的程序开始运行(被称为“加载期动态链接”)或直到程序开始第 一次调用(被称为“运行期动态链接”)，符号才与实际地址绑定。
动态可执行文件能够在动态链接程序/加载程序的控制下执行。 这些应用依赖动态库(或共享对象)，其可由动态链接程序定位和绑 定以创建可运行进程。共享对象还能依赖其它共享对象，这些共享 对象也由动态链接程序管理。使用传统方法，处理用于动态链接和 加载的绑定、符号解析、代码重定位以使得可执行文件与共享对象 组合在一起以完整的程序运行的例程通常是计算环境的操作系统中 的一部分。
在实践中，动态库可以在加载时链接。当动态库被创建时，会 生成小的桩文件或导入库，它为计算环境提供可以用来加载动态库 和定位导出函数的信息(比如符号和重定位表)。导入库(或桩文件) 能够在主可执行程序生成时被链接，这样所有共享对象库中的函数 位置都为可执行程序中已知，即使实际共享对象的二进制代码依然 是分开的文件。
2(a)、示例计算环境
图1描述的是一个根据在此描述的系统和方法的计算机系统100 实施例。计算机系统100能够执行各种的计算程序180。示例性计算 系统100主要由计算机可读指令控制，可读计算机指令可以是软件 形式，也可以提供指令指明该软件存储在哪，如何访问。该软件可 以在中央处理单元(CPU)110中执行，使数据处理系统100工作。 在许多已知计算机服务器、工作站和个人计算机中，中央处理单元 110由称为微处理器的微电子芯片CPU实现。协处理器115是可选处 理器，与主CPU 110不同，它执行额外功能或辅助CPU 110。CPU 110可以通过互连器112与协处理器115相连。一个常见的协处理器 是浮点协处理器，也叫作数字或算术协处理器，它设计成比通用 CPU 110更快、更好的执行数字计算。
应该理解，虽然示出的示例计算环境包含单个CPU 110，这种描 述只是作为解释性目的，计算环境100可以包含多个CPU 110。另 外，计算环境100可以通过通信网络160或一些其它数据通信方式 (未示出)利用远程CPU资源(未示出)。
操作时，CPU 110取得、解码以及执行指令，通过计算机主数 据传输通路系统总线105与其它资源进行信息传输。该系统总线连 接计算机系统100内的组件，是数据交换的媒介。系统总线105通常 包括发送数据的数据线，发送地址的地址线，以及发送中断和操作 系统总线的控制线。这种系统总线的一个例子是PCI(周边部件互 连)总线。一些当前高级总线提供称为总线仲裁的功能，用来控制扩 展卡、控制器和CPU 110对总线的访问。挂接在这些总线上仲裁接 管总线的设备被称为总线主控。总线主控支持还允许通过增加总线 主控适配器创建总线的多处理器配置，这些适配器包含处理器和支 持芯片。
与系统总线105连接的存储器设备包括随机存取存储器(RAM) 125和只读存储器(ROM)130。这些存储器包括允许存储和读出信 息的电路。ROM 130通常包含存储的不能修改的数据。存储在RAM 125的数据可以被CPU 110或其它硬件设备读取或修改。对RAM 125和/或ROM 130的访问可以由存储器控制器120控制。存储器控 制器120可以提供地址转换功能，在指令执行时将虚拟地址转换成 物理地址。存储器控制器120还可以提供存储器保护功能，将系统 内的进程和系统进程与用户进程隔离开。这样，在用户模式运行的 程序通常只能访问它自己进程虚拟地址空间映射的存储器。换种说 法就是，程序无法访问另一进程的虚拟地址空间，除非进程间设立 了存储器共享。
此外，计算机系统100可以包含外置设备控制器135，其负责从 CPU 110到外置设备的通信指令，比如打印机140、键盘145、鼠标 150和数据存储驱动器155。
显示器165由显示控制器163控制，用于显示由计算机系统100 生成的可视输出。该可视输出可以包括文本、图像、动画和视频。 显示器165可以由基于CRT的视频显示器、基于LCD的平板显示器、 基于等离子气体显示器、触摸屏或其它各种大小的显示器实现。显示 控制器163包括用于生成发往显示器165的视频信号的电子组件。
此外，计算机系统100可以包含网络适配器170，用于将计算机 系统100与外部通信网络160连接。通信网络160可以为计算机用户 提供电子形式的传输和发送软件和信息的方式。此外，通信网络160 可以提供分布式处理，它涉及多台计算机和工作负载的共享或执行 任务的协作努力。要理解的是所示的网络连接只是以解释性为目 的，计算机间可以使用其它方式建立通信连接。
要理解计算机系统100只是为了解释这里描述的系统和方法可 以操作的计算环境，其不限制在此描述的系统和方法在拥有不同的 组件和配置的计算环境中的实现，因为在此描述的创造性概念可以 在具有不同的组件和配置的不同的计算环境中实现。
2(b)、示例计算机网络环境
上述的计算系统100可以作为计算机网络的一部分部署。通 常，上述的计算环境可以同时适用于网络环境中部署的服务器计算 机和客户计算机。图2展示了示例网络计算环境200，其中，服务器 205通过通信网络与客户计算机通信，其中可以部署在此描述的设备 和方法。如图2所示，服务器205可以通过通信网络160(可以是固 定连线或无线LAN、WAN、内部网、外部网、点对点网络、因特网 或其它通信网络中的任何一个或它们的组合)与多个客户计算环境相 连，比如台式个人电脑210、移动电话215、电话220、个人电脑100 和个人数字助理225。此外，在此描述的设备和方法可以通过通信网 络160与汽车计算环境(未示出)、消费电子计算环境(未示出)和 建筑自动控制计算环境(未示出)协作。例如，在通信网络160是因 特网的网络环境中，服务器205可以是专用计算环境，其用于使用 任何一种公知的协议，比如超文本传输协议(HTTP)、文件传输协议 (FTP)、简单对象访问协议(SOAP)或无线应用协议(WAP)处理 和传送与客户计算环境100、210、215、220和225之间的数据。每 个客户计算环境100、210、215、220和225可以提供有一个或多个 计算程序180，比如网页浏览器(未示出)或移动桌面环境(未示出) 以访问服务器计算环境205。
操作时，用户(未示出)可以和在客户计算环境中运行的计算程 序交互，获得期望的数据和/或计算程序。数据和/或计算应用可以存 储在服务器计算环境205中，通过示例的通信网络160通过客户计算 环境100、210、215、220和225传送到协同操作用户。参与的用户 可以请求访问全部或部分在服务器计算环境205上的特定数据和应 用。该数据通信可以在客户计算环境100、210、215、220和225与 服务器计算环境之间传送，进行处理和存储。服务器计算环境205 可以装有计算程序、进程和小型程序(applet)用以生成、验证、加密 和传送数据，可以与其它服务器计算环境(未示出)、第三方服务供 应商(未示出)、网络存储(NAS)和存储区域网络(SAN)以实现 这样的数据事务。
因此，在此描述的设备和方法可以在具有客户计算环境与服务 器计算环境的计算机网络环境中使用，其中客户计算环境访问网 络，与网络交互，服务器计算环境与客户计算环境交互。但是，这 些提供移动性设备平台的设备和方法可以使用各种基于网络的架构 实现，不应局限于展示的例子。
3、平台依赖链接
可执行程序通常是依赖平台的。换种说法就是，一个特定程序 在开发时目标就是要在特定平台上运行，因此它必须为特定平台编 译、链接和构建。同时，该过程生成的二进制可执行文件通常无法 在不同的平台上运行。在传统系统中，需要为每个不同的操作系统 分别构建动态库。当要支持多个操作系统时，要使用专用工具将库 代码构建成多个共享对象(动态库)，即每个操作系统一个。如果代 码没有明确参考单个平台的唯一项，则为给定的操作系统创建共享 的对象库，并使该库在从该操作系统导出的多个平台上运行就足够 了。相反的，如果库代码对平台唯一函数有明确依赖关系，则要为 给定平台服务构建共享对象，而且该共享对象通常无法在缺少明确 依赖性的其它平台上运行。
在操作系统支持多个平台的例子中，这组程序组件通常会包 括，但不限于以下组件：与平台唯一依赖的可执行二进制文件；为 基于该平台的操作系统而构建的一组可选共享对象(动态库)。
图3展示了示例性计算环境300执行“动态链接”的过程。如图3 所示，在块345中程序源文件350被编译以创建对象文件。类似的， 在块310库源文件305被编译以创建动态库。生成的动态库对象文件 315作为导入库管理程序320的输入，导入库管理程序320操作动态 库对象文件315以生成导入库桩文件325。从编译345生成的对象文 件与桩文件325一起静态链接以创建动态二进制可执行文件340。
如图3所示，动态链接程序330接收动态可执行对象文件340和 动态库对象文件315作为输入，以生成被完全链接和绑定的可执行 文件335(例如，可运行进程)。在操作中，计算应用(例如，程序 源文件350)可以从协作动态链接库中调用一个或多个函数。当函数 被调用或程序执行时(如上所述)，动态链接程序330动态定位由程 序应用或程序执行所需的代表被调用函数的符号在存储器中的位 置。
图4和图5描述如何用传统方法处理源处理代码使之在多个操作 系统和平台中运行。参看图4，其中单个操作系统A 485支持两个平 台A1 475和A2 480，图4展示的示例性动态链接架构400具有库源 文件405和程序源文件415。库源文件405在块410被编译以创建操 作系统A 485的动态库。得到的动态库A 430的动态库对象文件作为 导入库管理程序445的输入，导入库管理程序445为动态库A 430处 理动态库对象文件，生成导入库桩文件A 450。
类似的，程序源文件415在块420被编译以为平台A1 475创建 对象文件，在块425被编译以为平台A2 480创建对象文件。编译420 得到的对象文件与桩文件450静态链接以创建所到的动态可执行对 象文件A1exec 435(例如，在平台A1 475上可执行)。同时，如图 所示，编译425得到的对象文件与桩文件450一起静态链接以创建动 态可执行对象文件A2exec 440(在平台A2 480上可执行)。动态链 接程序455将动态库430与动态可执行对象文件A1exec 435链接以 创建完全链接好的可执行文件465，它被加载进入操作系统A 485的 存储器中，为平台A1 475生成运行进程。类似的，动态链接程序 460将动态库430与动态可执行对象文件A2exec 440链接以创建完全 链接好的可执行文件470，它被加载进入操作系统A 485的存储器 中，为平台A2 480生成可运行进程。在操作中，完全链接可执行文 件465或470各自从动态库430中调用函数或获取数据。
参看图5，图5展示的示例动态链接架构500具有库源文件505 和程序源文件515。库源文件505在块510中被编译以为操作系统B 585创建动态库。为操作系统B 585得到的动态库对象文件530作为 导入库管理程序545的输入，导入库管理程序545处理动态库对象文 件530，生成导入库桩文件B 550。
类似的，程序源文件515在块520被编译以为平台B1 575创建 对象文件，在块525被编译以为平台B2 580创建对象文件。编译520 得到的对象文件与桩文件550静态链接以创建所得到的动态可执行 对象文件B1exec 535(例如，在平台B1 575上可执行)。同时，如 图所示，编译525得到的对象文件与桩文件550一起静态链接以创建 所得的动态可执行对象文件B2exec 540(在平台B2 580上可执行)。 动态链接程序555将动态库530与动态可执行对象文件B1exec 535 链接以创建完全链接好的可执行文件565，它被加载进入操作系统B 585的存储器中，为平台B1 575生成运行进程。类似的，动态链接 程序560将动态库530与动态可执行对象文件B2exec 540链接以创 建完全链接好的可执行文件570，它被加载进入操作系统B 585的存 储器中，为平台B2 580生成运行进程。在操作中，完全链接可执行 文件565或570各自从动态库530中调用函数或获取数据。
如图4和图5所示，有一组分别包括应用程序415和515和库文 件405和505的共同源代码。在解释性实现中，编写的应用程序可以 运行在四个不同的平台上，即由共同的操作系统A 485而来的平台 A1 475和A2 480，由操作系统B 585而来的平台B1 575和B2 580。 应用415和515的源代码能够维护对应各个平台的指令，分别是平台 A1 475、平台A2 480、平台B1 575和平台B2 580，应用415和515 的源代码编写方式可以使得它们对平台的依赖性在编译时被识别出 来。
在提供的实现中，库405和505的源代码通常无需维护特定平台 依赖性。在说明性操作中，库可以被协作应用程序调用，可以作为 动态库操作。如图4所示，每个平台(475和480)能够要求它们自 己的动态可执行文件A1exec 435、A2exec 440，这些动态可执行文件 可以通过平台特有的编译程序工具(例如，编译程序块420和425) 编译共同的应用源文件415创建。在说明性实现中，协作动态库430 可以创建一次，然后动态链接到可执行文件A1exec 435或A2exec 440中，以在各个平台A1 475和A2 480中创建可运行进程。
图5示出了两个额外的可执行文件B1exec 535和B2exec 540被 编译以允许应用在平台B1 575和平台B2 580上运行。此外，创建新 的动态库530以与可执行文件B1exec 535和B2exec 540链接，因为 可执行文件B1exec 535和B2exec 540是为操作系统B 585构建的。 在此实现中，为了实现跨越运行于两个操作系统(分别是操作系统A 485和操作系统B 585)的四个平台(平台A1 475，平台A2 480，平 台B1 575，和平台B2 580)的动态链接，需要构建四个动态可执行 文件和两个动态库。要理解使用传统方法，开发能够运行于不同的 计算环境的二进制对象是要耗费大量资源的。
图6示出了示例计算环境600的组件。如图6所示，在源代码 607和CPU 670之间可以存在层次结构605、610和615。这种层次 结构在高层和底层存在高度共同性但在之间区别明显。在最高层 605，源代码607对于具有有限平台特有的元素620的所有协作平台 来说大部分都相同。在最低层615，代码运行在CPU 670上。在所示 的实现中，当CPU 670架构在一些不同计算环境(未示出)中都相 同时，低层机器指令也应该是相同的。但是中间层610可以维护多 个操作系统640、655和665，每个系统有多个平台变体630、635、 645、650和660，由于不同的特性和工具链，它们需要各自不同的二 进制文件。同样如图所示，顶层605包含平台无关源代码625，可以 与平台和操作系统都无关。
在示例性实现中，参看图6，有五个平台操作在三个操作系统 上。具体而言，平台A1 630、平台A2 635运行在操作系统A 640上， 平台B1 645和B2 650运行在操作系统B 655上，平台C1 660运行 在操作系统C 665上。使用传统方法，需要创建每个应用程序的五 个不同版本(每个平台一个)加上三个单独的动态库(每个操作系统 一个)，以保证计算机程序的正确操作。在此描述的系统和方法的目 标是通过提供能跨越五个平台和两个操作系统的单个动态库来改善 传统实践的缺点。在示例性实现中，可以创建单组二进制库，其在包 含特定CPU架构的所有系统上可用，而无论在该CPU上运行的操作 系统，这样就可以利用图6中顶层605和底层615的共同性。
在此描述的系统和方法可以应用到不同的计算环境中。在示例 性实现中，在此描述的系统和方法可用于桌面系统，它通常包含 INTEL_x86家族的处理器。桌面PC的通用操作系统是微软_的 WINDOWS_和Linux，两者都有动态链接功能。但是这些操作系统 为它们的二进制对象使用了不兼容的格式，因此需要为Linux和 WINDOWS_提供不同的二进制文件，尽管它们运行在相同的CPU 上。
在移动和嵌入式设备上，多样性问题可能更显著。具体而言， 移动和嵌入式设备使用更多数量的操作系统，包括但不限于， Linux、WINDOWS_CE、PalmOS_、SymbianOS_、BREW_、Itron。 但在CPU级615，根据选定的计算机硬件架构可以有相当的共同 性，比如ARM RISC架构。当前的实践不利用此共同性，相反根据 操作系统或平台层(如610)定制创建库。
在说明性实现中，在此描述的系统和方法可以被应用到所选的 计算环境市场(例如，移动设备市场)来发行能够在拥有选定硬件架 构(例如，设备包含ARM处理器)的计算环境上运行的单个软件库， 而不管软件平台。这种方法能够提供为软件开发商和客户同时提供 各种商业好处，包括但不限于，节省开发和维护多个平台专用版本 库的成本。此外，通过同一组件在多个平台安装累积的经验，代码 质量可以更快的建立。另外，使用这种方法，对库的修改可以更彻 底有效的测试。设备制造商(例如蜂窝电话制造商)可能在他们不同 产品线上部署共同的库，如果该库在单个产品线已经被证实可用。
图7展示示例性平台无关二进制对象和链接架构700。如图所 示，平台无关二进制对象和链接架构700包含源代码和平台无关源 代码组件，源代码包括主应用源代码705，平台无关源代码组件它包 括但不限于平台无关动态库(PIDL)源代码725；编译程序730、PIDL 对象文件735、对象解析程序740，PIDL桩文件源代码765、PIDL 动态加载程序/链接程序源代码720、已定义的应用程序接口(API) 710和API解析程序715。
在说明性操作中，PIDL源代码725在块730被编译成标准对象 格式，该标准对象格式创建PIDL对象735。该PIDL对象文件然后 可以通过对象解析程序740解析，生成PIDL桩文件的源代码765。 类似的，应用程序接口(API)解析程序715可以操作API 710，以 生成PIDL_getSymbol函数，允许PIDL对象文件735访问协作主应 用705。如图7所示，如果执行主应用源代码705、动态加载程序/ 链接程序代码720、PIDL桩文件源代码765，该PIDL_getSymbol源 函数755(例如，一组编译组件源代码745)在步骤770为目标平台 被编译构建。得到的动态二进制可执行文件795使用主应用函数 775、PIDL_getSymbol函数780和动态PIDL加载程序/链接程序函数 785从PIDL对象文件735中调用函数和获取数据。
要理解，虽然示出示例性平台无关二进制对象和链接架构700具 有特定配置的不同的组件并执行特定操作，但这种描述只是为了说 明性目的，在此描述的发明概念可以应用到拥有不同组件、配置和 操作的任何平台无关二进制对象和链接架构。
在说明性实现中，示例性平台无关二进制对象和链接架构700 可以根据以下方法操作。PIDL对象文件735能够创建成定义好的标 准对象文件格式。对象解析程序740可以操作解析该标准的PIDL对 象结构来创建桩文件765。生成的桩文件765是源代码。此外，桩文 件765的源代码与平台无关。动态加载程序/链接程序720可以作为 主应用程序705的一部分被编写进去。此外，API 710是PIDL库调 用主应用的接口，其可以被指定和转化成源代码函数 (PIDL_getSymbol)755，以与主应用705编译在一起。在提供的实 现中，如果目标平台是已知的，合并成的源代码(例如，这组编译组 件源代码745)能够被编译成给定平台(未示出)的二进制可执行代 码795。在运行期，动态加载程序/链接程序785(例如，编译的加载 程序/链接程序)能够处理符号解析和重新定位，以将动态二进制可 执行文件795和PIDL文件735作为完全可运行的进程绑定在一起。
如上所述，动态库的平台无关性可以首先通过将库源代码725 编译成已知对象文件格式735实现。在该精心设计的实现中，PIDL 源代码725不含有对任何特定平台的依赖性。对象文件格式(未示 出)通常可以包含多种类型的信息，包括但不限于，头部信息比如代 码大小、编译器或汇编器生成的对象代码，链接程序785要用到的重 定位信息—当对象代码的地址被链接程序改动时，要从此模块导入 或从其它模块导出的符号的符号表。
在说明性实现中，平台无关二进制对象和链接架构700可以用 不同的对象文件格式，包括但不限于，ELF(可执行和链接格式)、 微软_可移植可执行(PE)格式和其它对象格式(例如，专门为在此 描述的系统和方法设计的对象格式)。
传统上，不同的操作系统和平台使用不同的对象文件格式。这 些平台的链接程序和加载程序期望接收这些预定格式的可链接对 象，且拒绝其它格式。当该平台也提供动态链接时，动态链接程序 就是操作系统的一部分，可以“固定连接”到唯一的对象格式。
在此描述的系统和方法通过提供通用加载程序/链接程序720改 善这个缺点。在说明性实现中，通用加载程序/链接程序720可以编 写成以选定的对象文件格式(例如，ELF或选择的任何其它对象格 式)处理对象文件。在操作中，通用加载程序/链接程序785操作以 定位PIDL对象文件735内的符号、重定位信息以及其它信息。如图 7所示，加载程序/链接程序720的部署可以通过创建与协作主应用 705源代码一起编译的源代码完成。这种情况下，链接和加载控制就 从操作系统中去除，被包含在运行可执行文件中。动态加载程序/链 接程序785同样可以操作处理非PIDL库。这种情况下，动态加载程 序/链接程序785可以设计成确定动态库是PIDL类型还是非PIDL类 型，并相应地处理该PIDL或非PIDL库。在说明性实现中，当处理 的是非PIDL库时，链接和加载控制可以传递给底层的操作系统。
在说明性实现中，PIDL对象文件可以跨越不同平台部署而无需 重新建立或编译。在此实现中，因为主应用程序与选定平台的动态 链接程序/加载程序一起编译，且因为链接控制是不依赖平台的，而 是放在可执行文件内部，这样就可以完成在不同平台上的运行期链 接PIDL而无需重编译或生成PIDL对象。
如图7所示，桩文件765以源代码的形式创建。与传统方法比 较，参看图3，传统方法生成定义导出和导入的全局符号的库桩对象 文件325。在操作中，该桩文件通常很小，且允许链接程序在合并/ 汇编的程序中分解符号。在操作中，主程序可以调用在动态库中存 在的命名函数，动态库也可以调用主程序中的函数。为了使合并的 程序工作正确，一旦加载程序将所有对象代码组件加载进计算环境 的存储器，这些函数调用就可以分解、重定位到正确的地址了。
如图8所示，函数或符号A和B的代码可以位于主程序810中， 函数C、D可以位于动态库820中。在说明性实现中，为了使动态库 820调用A和B，或者主程序810使用库函数C或D，所有函数的符 号和位置都在合并的程序中分解。在说明性实现中，该操作可以通 过示例性链接程序(未示出)执行。用传统方法，桩库(例如，图3 中的325)可以保存将从库导出的函数(例如，C和D)和由它调用 的函数(例如，A，B)绑定所需的信息。要理解，参看图3，使用传 统方法，架构300在静态链接阶段将库的桩文件325链接到主程序的 预编译对象文件，创建二进制可执行文件340。其后，当二进制可执 行文件被加载执行时，在通常为操作系统一部分的动态链接程序330 的控制下，它可以与动态库315进行动态链接。这种情况下，因为 不同系统使用各自的链接程序和对象格式，结果是需要平台依赖的 库桩文件。这样，单一库需要为不同的操作系统准备不同的桩文 件。
在此描述的系统和方法目标是通过提供作为源代码文件的桩文 件来改善现存方法的缺点。参看图7，桩库765由对象解析程序740 创建。对象解析程序740解析PIDL对象文件735，从中提取符号名 字和属性，然后创建源文件765(例如，以高级语言的形式，包括但 不限于，C语言等)作为解析程序的输出。在图7所示的说明性实现 中，为PIDL桩文件765生成的源代码是平台无关的，且随后可以作 为主应用程序的一部分编译(与动态链接程序代码一起)。通过在编 译阶段包含PIDL桩文件信息，从PIDL导出的符号可以在生成的动 态可执行文件中声明。
要理解，传统方法中将桩文件作为源代码创建而不是对象代码， 意味着桩文件中包含的库信息将包括在构建过程的编译阶段中。相 反，传统方法在主应用已经编译之后，在静态链接阶段结合桩文件。 静态链接程序在操作系统的控制之下，它需要被链接的对象是操作 系统特有的格式，该格式通常不会被不同的操作系统的链接程序识 别。为了实现平台无关的解决方案，需要去除对链接阶段的依赖。 使用此处描述的系统和方法，这个目标可以通过提供源代码形式的 桩文件而不是要链接的对象代码来实现。
要理解，只要主应用编译进了动态链接程序和合适的PIDL桩文 件，在此描述的系统和方法允许主应用访问部署为PIDL对象的动态 库。在此描述的系统和方法同样适用于当PIDL需要访问主应用中的 功能(如图8所示)时的例子。这种情况下，主应用对PIDL库表现 出的功能API(图7的710)(应用编程接口)可以首先指定和发布(这 样PIDL可以使用表现的函数)。该API(图7的710)然后可以被 解析生成源代码函数PIDL_getSymbol(图7的755)，其可以作为主 应用的一部分编译(如图7所示)。在说明性实现中， PIDL_getSymbol函数可以返回被API表现的命名地址，然后在重定 位时被动态链接程序用来替代由PIDL调用的符号的地址。这样，当 PIDL调用主应用中的函数时，链接和地址已经被动态链接程序分解 了(图7中785)。
此外，动态链接程序可以允许PIDL对象的运行期链接。主应用 源该用能够如图7所示为目标平台编译，以生成包含动态链接程序 和PIDL_getSymbol函数以及主程序的二进制可执行文件。PIDL库可 以被创建，可以作为对象文件使用。
在说明性实现的说明性操作中，当主程序开始运行时，它可以 被平台加载程序放置到存储器中。当执行开始时，主程序决定它是 否要调用相对它来说是外部的符号。该调用会请求PIDL链接程序， 其首先决定包含有被该调用函数的库名字和路径。如果该库是如微 软_的DLL(即不是PIDL)的普通平台特有的动态库，如果平台有 相应的加载程序，链接程序将控制传递给普通平台库加载程序。如 果相反，被调用的函数在PIDL中，它可以通过使用PIDL桩文件利 用符号名字识别出来，其中PIDL桩文件被编译进了主程序且包含了 它表现出来的符号，因此符号引用已确定。
响应于函数调用，链接程序能够创建代表PIDL对象的程序结 构。它然后查询对象以确定代码大小(例如，定义在对象文件格式中 的某个域中，因而是随时可用的)，能够分配合适大小的存储器固定 块，能够将PIDL文件加载进分配好的存储器空间内。
然后，链接程序操作以重新定位存储器中的符号地址。该PIDL 内的内部符号被重定位。在操作中，二进制文件包含对象代码内的 符号地址，但通常操作前提是库代码的基准起始地址是零。但该 PIDL被加载至不同的地址，因为PIDL是被加载进存储器，所以该 地址可以被确定。链接程序的重定位工作涉及调整符号的地址以反 映存储器实际起始地址。
在重定位内部PIDL符号后，链接程序然后能够重定位被该 PIDL调用的相对它是外部的所有符号，例如包含在主应用中的函 数。对于这些符号，链接程序能够将这些要重定位的外部符号作参 数调用PIDL_getSymbol函数。因为这个函数包含了被应用API显示 的所有符号列表，所以它可以通过匹配名字并返回命名符号的实际 地址。
在这个阶段，PIDL维护它导出或导入的内部和外部符号的正确 地址。在重定位结束后，被PIDL导出的符号重定位的地址可以传回 给链接程序。主程序访问被重定位的符号，这样当从PIDL外部调用 PIDL的一个符号时，会使用正确的符号地址。
在此描述的系统和方法可以使用链接到单个应用的多个库(例 如，多个PIDL)。这些库能够互相调用，使用它们导出的函数和符 号。使用多个库，链接机制可以一致地应用——即，动态库保存成 标准对象格式，生成源代码格式桩文件，主程序与之使用的PIDL库 的桩文件一起编译。当被调用时，动态加载程序/链接程序在加载或 运行期加载每个库，由动态加载程序/链接程序(例如，图7的785) 处理的PIDL库之间和主程序中的重定位和分解符号的信息被编译5 进主程序。
4、平台无关动态库
图9展示了示例计算环境在一个或多个PIDL的运行期链接时的 处理过程。如图所示，处理在块900开始，其中动态二进制可执行 文件被编译构建(如图7所示，动态二进制可执行文件可以包括但不 限于被编译的主应用源代码、PIDL加载程序/链接程序源代码和PIDL 桩源代码)。处理从这里前进到块910，其中动态可执行文件运行于 计算环境中。处理然后前进到块915，其中确定协作计算机程序调用 了库函数。在块920中执行一个检查决定调用的函数是否在协作 PIDL中。如果块920中的检查确定调用的函数不在协作的PIDL中， 处理前进到块925，其中协作动态库通过普通操作系统/平台链接程 序加载。然后处理结束。
但是，如果在块920中确定调用的函数在协作PIDL中，处理前 进到块930，其中PIDL对象的程序结构被创建，这样该PIDL对象 文件和它预定的文件格式就可以被查询。该PIDL对象的大小在块 935中被确定，处理然后前进到块940，其中存储器块被分配，PIDL 对象文件可以被加载进被分配的存储器块中。在块945中，使用符 号表和从该对象文件提取的加载地址重新定位该PIDL的内部符号。 在块950中使用API函数(PIDL_getSymbol)调用重定位PIDL外部 符号。从这里，在块955中PIDL链接程序通知协作计算机程序PIDL 符号地址。从这里，在块960中符号和调用被分解和重定位，链接结 束。然后处理结束。
5、在受限环境中的动态链接机制
一些操作系统不提供动态链接能力。当在这些系统上使用库 时，库被静态链接——即，库在链接时绑定到二进制可执行文件 中。可执行文件也可以是静态的，因为其可用于执行而无需额外的 链接，而且，在链接完成后不可以改变。通常，静态链接库无法做到 不冲击(例如，中断或停止)它绑定的底层程序而改变。同时，因为 库中的例程和数据的地址被绑定到程序中，对这些地址的改变会使 得绑定的程序出错。
在此描述的系统和方法通过在不提供本地动态执行支持的操作 系统上提供动态执行从而改善此缺点。在说明性实现中，动态链接 可以被认为是推迟链接直至运行期或加载期的能力，或者可执行程 序使用未与其静态链接的库的能力。此外，在此描述的系统和方法 允许特定操作系统本身不支持的二进制对象格式的链接。
在说明性实现中，大程序可以被分成主应用加上提供支持功能 的一组库组件。使用传统方法，该程序整体上会作为单个静态可执 行文件提供。这样，如果程序需要做出改动，需要构建整个新的可 执行文件，发行以替换未改动的版本。相反的，在说明性实现中， 可以与使用组件的应用无关而一次性提供组件。这样，应用可以拥 有更小的大小，如果需要新的或改动应用，只是应用本身需要重新 创建，而无需重建相关的库。
相反的，在提供的实现中，如果应用保持不变，但一个组件需 要改动，新的组件可以替换早期的版本而无需改动其它组件。只要 修改版本的符号名字一样，新版本的组件可以在运行期链接到原始 的应用程序和其它组件中。在说明性实现中，动态链接程序负责地 址重定位。如果新版本组件中的符号位于不同的地址，该地址在运 行期依然可以被分解和重定位。
图10示出了当在不支持动态执行的计算环境中部署PIDL时执 行的处理。如图10所示，处理开始于块1000，其中程序被分成主应 用和一个或多个库，目的是作为动态库在运行期部署。在块1020， 库然后可以被编译进PIDL对象文件，它拥有已知的标准文件格式。 在块1030用以前面描述过的方式解析PIDL对象文件生成包含平台 无关源代码的桩文件。在块1010，该桩文件可以与主应用源代码和 动态链接程序/加载程序代码一起编译。该链接程序/加载程序组件具 有前面描述过的解释已知标准文件格式的PIDL对象文件的功能，可 将对象文件加载进存储器，执行必要的链接操作以分解和重定位库 和协作应用之间的符号。
上述在块1000-1030执行的所有功能和/或操作都可以在构建时 执行，即在程序部署和执行之前。在不提供动态链接本地支持的受 限环境中，接着的构建的可执行文件和外部库之间的协作或交互通 常无法实现。相反，说明性实现提供了额外块1040至1080以提供运 行期的动态操作。在块1040，构建的可执行文件开始运行，在块 1050，可以在本地操作系统的控制下加载至存储器。作为块1010的 结果的可执行文件包含了动态链接程序/加载程序，能够操作加载和 绑定PIDL库到运行的应用中。(参看图9的块915至960)。得到 的程序与所有库完全绑定，调用得到分解，然后可以在块1080中运 行。
要理解，虽然所示的在受限环境中的动态链接操作方式中，库是 平台无关的，这种描述只是为了说明性目的，在此描述的发明概念 可以应用到与平台依赖的库中。
6、代码组件机制
在移动电脑(例如，比如PalmOS，SymbianOS)中使用的特定 操作系统(OS)强行限制对全局变量和静态可写变量的使用。这种 限制的存在使得操作系统可以避免对代码重定位的完全处理和对全 局变量的地址管理。因为静态变量放在与全局变量相同的存储器段 中，操作系统还可能禁可写静态变量的使用。当计算机程序代码为 此种操作系统编写时，当然可以遵守这种限制编写兼容代码。但是 当代码片段，比如库代码要为不具该限制的不同平台编写时，代码 可能可能包含违反这些规则的地方而依然可以在受限操作系统上编 译或构建。这样就限制了在一些操作系统上使用第三方库和预先编 写的代码的能力，因此减少了它们的灵活性。这样使得开发效率更 低，因为时间要花费修改已有代码使之遵守操作系统的限制，或者 在某些情况下需要完全重写。
在此描述的系统和方法允许规避操作系统限制。在说明性实现 中，违反操作系统限制的库的源代码可以编译构建成PIDL格式。然 后该PIDL库与应用程序合并，然后运行在受限操作系统上。在此描 述的系统和方法的独特的动态加载和链接机制为该PIDL分配存储器 块。此外，在该实现中，全局变量在PIDL存储器区域之外不会被认 为是全局的。
这样，这样在该实现中，库内部定义的全局变量被限定在该存储 器区域之内，操作系统不可见，也就不会认为是全局变量。静态变 量也同样被限定在分配的存储器块内，不受操作系统干扰。结果就 避免了操作系统无法重定位该全局和静态变量。在该实现中，PIDL 加载程序/链接程序可以执行对库变量的重定位工作以完成它们的功 能。
图11展示的是受限计算环境处理PIDL的过程，该PIDL能够规 避该计算环境的一个或多个限制。如图11所示，处理开始于块 1100，其中PIDL由库创建，该库的代码违反了所述操作系统的一个 或多个限制。在块1110，包含源代码的桩文件能够以前面描述的方 法被创建，在块1120，桩文件被编译，与动态链接程序/加载程序和 使用库的计算应用构建在一起。
在说明性实现中，运行期，执行应用程序的指令在块1130被接 收。在块1140，可执行文件可以被主机计算环境按普通方式加载。 在块1160，该PIDL可以提供给计算环境使用。在识别出应用程序和 库之间的依赖性后，动态链接程序/加载程序(在块1120构建进程序 中)可以在块1150分配存储器块并加载该PIDL进分配的存储器块。 如块1170所示，库中定义的全局和可写静态变量的范围限定在所分 配的存储器块中，无法在该存储器块之外通过名字访问。它们对所 有的库函数有效因为这些函数也在分配的存储器块内，因此在该计 算环境内库可以正确操作，尽管它违反了在该环境的传统操作下的 限制。在块1180完成对该PIDL的链接，生成完全绑定可运行的进 程。
要理解虽然展示的代码组件特性操作的方式中库是平台无关 的，但这种描述只是以演示为目的，在此描述的发明概念也适用于 与平台有依赖的库。
7、代码加载机制
在传统软件开发中，可以使用面向对象的方法。不是通过调用 函数来完成某个特定的任务，而是创建对象然后调用对象的方法来 执行希望的任务。这种方法是有益的，因为可以创建多个对象，而且 多个任务可以同时进行。有许多情况下执行计算任务的多个实例更有 利。例如，在播放和渲染文档内的电影片段的库的例子。当某个此 类文档包含两个电影片段时，通过运行公共代码对象的两个实例来 同时播放它们将很方便。如果没有面向对象方法，开发人员将面临 这样一种情况，其中一个对象成功得执行一个任务，但很难允许多 个同样的对象同时执行任务。
虽然开发人员可以选择以面向对象的风格编写代码，但这种选 择在集成第三方代码时就失效了。特别是对于库的代码开发，其中 库操纵数据并包含访问数据的函数。在说明性例子中，非面向对象 代码可以使用全局变量和只做一次初始化的静态变量。这种情况 下，在特定的计算环境中，这样就阻止了计算环境在同一进程内对 库对象的多次调用，因为单个进程可能只保存了一份用到的模块或 库的数据。具体的，同一对象的两次调用可能互相会扰乱它们共享 使用的有名全局变量。另一种情况，库可能编写成可以成功执行一 次，但即使该运行完成，企图运行第二次就会失败，因为静态初始 化的变量不再拥有必须的初始值了。这是因为静态变量是在构建时 由编译器初始化的，而不是在运行期，因此如果被初始化了的变量 在执行过程中被改变，接着的执行得到的改变过的值，与正确执行 需要的初始值不一样了。
在此描述的系统和方法目标是通过提供上述的PIDL加载机制改 善这些缺点。通过允许PIDL的多个实例使用限定在存储器块内的它 们自己“私有”的数据拷贝，在进程内只能使用单组数据的限制被去 除，这些就避免了传统方法中导致故障的相互作用和冲突。这种方 法允许相同进程内的多个实例和重复执行。它还使在不允许多个进 程的环境中执行多个并行进程成为可能。在说明性实现中，PIDL将 全局变量视为动态分配缓冲内的地址。单个PIDL可以被多次加载， 每个拷贝将拥有各自不同且无关的全局变量的拷贝，因此避免了存 在问题的交互。类似的，每次库要运行时，从文件加载一次拷贝， 因此它就含有正确初始化的静态变量。
图12展示了示例计算环境执行的处理过程，在说明性实现中， 当处理PIDL时可以使用它来避免受限代码组件间存在问题的交互。 处理从块1200开始，其中PIDL从库中创建，库的代码违反了禁止 重复执行的限制。在块1210，包含源代码的桩文件以上述方式生 成，在块1220，桩文件被编译，与动态链接程序/加载程序和使用库 的计算应用构建在一起。
在说明性实现中，运行期，运行应用程序的指令在块1230被接 收。在块1240，可执行文件可以被主机计算环境加载。在块1260， 该PIDL可以提供给计算环境使用。在识别出应用程序和库之间的依 赖性后，动态链接程序/加载程序(在块1220构建进程序中)可以在 块1250分配存储器块并加载该PIDL进分配的存储器块，链接该 PIDL和协作应用。然后在块1270执行检查决定是否有PIDL的新实 例要被加载到计算环境中。如果块1270的检查指示要加载PIDL的 新实例处理然后前进到块1280，其中该PIDL的一个新实例被加载至 不同的存储器块且与计算机程序链接在一起。但是，如果在块1270 中确定没有PIDL的新实例要加载，处理返回到块1270的输入，从 那继续往进执行。
要理解，虽然展示的代码加载特性操作的方式中库是平台无关 的，但这种描述只是以演示为目的，在此描述的发明概念也适用于 与平台有依赖的库。
8、封闭式或受限平台的扩展运行期(run time)环境
一些计算设备作为封闭式计算环境操作，这样该设备可能只能 执行该设备从制造商或供应商发货时自带的程序和应用。这类设备 (如移动无线设备)可以包含操作系统来运行自带的程序，但其它应 用无法无限制的加载进去，即使该应用是为其主机操作系统创建 的。这种封闭式平台的例子是称为特性电话的一大类移动手持设 备，除了语音功能之外，为这类设备提供了一组固定的特性(例如相 机功能)，但这些特性是固定的，用户无法自行扩展。这类设备对于 发货后的应用是封闭的，因为它无法或限制向其中的计算平台增加 功能。
相反，开放式计算平台允许增加和运行为其操作系统编写的应 用。微软_WINDOWS_平台可以看作是个人电脑的开放式平台的例 子。在移动手持设备领域，开放式平台的等价类被称为智能电话， 它提供无限制的增加在设备上运行的应用的环境。智能电话平台的 例子包括微软_智能电话、Symbian的UIQ和Linux。
还存在第三类移动手持设备，它们是装配了运行期环境(RTE) 的特性电话。这种运行期环境的例子包括Java J2ME(Java 2微版本) 和BREW(二进制无线运行期环境)。RTE允许手持设备以RTE应 用的形式增加功能——用J2ME时是Java小程序，用Brew环境时是 Brew认证的应用。这些应用有别于运行于如智能电话的开放式平台 上的应用，因为这些应用是为RTE而构建的(例如，在一些情况下 必须为RTE认证以正确操作)，不是为本地操作系统而构建。同样 的，这种支持RTE的特性电话相对智能电话有局限性，有些限制是 基于技术原因而有些是基于商业原因。
例如，硬件设备制造商、网络运行商或RTE提供商可以与应用 提供商签署排他或半排他协议，为他们特定的硬件设备提供应用和/ 或更新应用。通常，运行在RTE上的应用与设备的完整功能接口的 能力是受限的。例如，API(应用程序接口)允许控制网络堆栈，或 运行控制设备上的外围存储，从RTE可能不能访问该API。有时这 种情况被描述为RTE在本地计算环境中它自己的“沙盒”中操作。相 比较来说，在开放式平台(如智能电话)每个可执行程序可以运行于 自己的进程中，通常这种开放式平台的操作系统可以将设备的所有 功能开放给每个运行的进程使用。此外，有些环境(如Brew)只允 许RTE应用通过网络加载，禁止应用通过存储卡的方式加载进设 备。当要加载大型应用时就会有问题，例如大型游戏，通过网络加 载需要大量的带宽和时间。
在此描述的系统和方法通过为封闭式平台提供增加功能的方式 改善现有方法的缺陷。在说明性实现中，增加的功能以PIDL的方式 提供给硬件设备。封闭式平台创建时可以包含“启动”程序，它包含 前面提到的动态链接程序/加载程序和PIDL桩文件，还有与PIDL协 作的应用。创建的启动程序可以在封闭式设备内为主操作系统构建 并运行，可以在设备发货时就驻留在设备内部。如下所述，启动程序 加上PIDL库允许为该封闭式设备增加新的功能，即使增加的功能在 设备发货时没有自带。在运行期，该PIDL可以供设备和启动应用启 动时使用。启动应用内部的动态链接程序/加载程序通过使用桩文件 中的信息，可以加载、链接和绑定PIDL到协作的启动程序，该启动 程序驻留在硬件设备中，运行于设备操作系统之上。PIDL中的所有 功能因而可以暴露给在设备中运行的程序，因此达到所期望的结 果，即给封闭式设备增加新功能。这样，PIDL绕过了硬件设备强制 的限制，使得可以动态运行(如前面所述)。
要理解“启动”应用本身可以提供一组功能，其操作不依赖于 PIDL的存在。类似的，同一处启动应用可以支持许多不同类型的新 功能，每个功能在不同的PIDL库中提供，它们的桩文件与启动应用 编译在一起。使用所说明性实现，使得模拟某种运行期的环境成为 可能，其中不同功能可以动态增加进去。
通过说明性的例子，启动应用可以包含游戏终端软件和一个或 多个游戏。更多的游戏可以以PIDL库的形式添加，每个游戏一个 PIDL，当PIDL下载进设备后就可以通过启动应用玩。或者，启动 应用可以提供基本的消息功能，比如短消息系统(SMS)。更多功 能，比如email或多媒体消息、视频和音频播放、PIM(个人信息管 理)以及其它类型的功能可以以PIDL库的方式在设备中部署，它们 与启动程序交互操作。
在另一个演示实现中，封闭式设备发货时可以包含两个或多个 “启动”应用，每个被构建来识别一组特定的PIDL库。用这个方法， 就能以明显的方式扩展和组织功能增加的范围。
在此描述的方法和系统在封闭式平台上应用时克服了封闭式平 台现有方法的缺点。提供售后解决方案的可能性为设备用户创造了 更大的使用性，为设备或网络提供商增加了收入机会。由于该方法 不涉及增加可执行文件形式的功能(例如，PIDL库可以是数据而不 用是可执行文件)，平台的“封闭”性得到控制，因为它对于为设备操 作系统创建的可执行文件形式的普通应用而言依然保持封闭。设备 提供商可以预先决定要提供的功能扩展范围，因为只有提供那些功 能的桩文件与启动程序一起编译的功能才是可用的。结果可以是一 组动态安全和商业控制。
在说明性实现中，PIDL可以以多种方式提供给设备，包括：通过 无线或有线网络下载，从PC上连线传输数据，和通过插入的存储卡 传输到设备中。将PIDL以对象而不是可执行应用的形式加载还有一 个独特的方面就是PIDL可以通过数字版权管理(DRM)技术保护。 作为数据文件的PIDL经得起DRM技术的检验，这和可执行程序不 同。这种完好的安全方案在商业协议下增加功能可以同时为运营商 和用户提供灵活性和可靠性。
如上所述，当将PIDL对象的平台无关性和链接方案组合起来， 设备制造商或网络提供商就能够通过单一的PIDL对象为他们所有设 备产品线提供附加功能，即使这些设备使用了不同的主机平台或操 作系统。通过避免了为每个不同的平台定制应用或库，而只是简单 得提供在所有平台上同样工作的平台开关动态库(PIDL)，运营商 将大规模得实现效率和节约。
上面针对封闭式平台(如特性电话)描述的方法和系统同样可以 应用于支持运行期环境的平台(例如，Java或Brew)。这种安排为 设备提供了两种增加功能的方法——传统方案下载applet或由RTE 使用的授权应用，另一实现方案是在设备内驻留的启动应用的控制 下加载PIDL功能库。
相比于这两种方案，基于PIDL的方案可以提供在传统运行期环 境中不存在的附加特性。换种说法，当单一启动应用使用多个分开 的PIDL时，多个功能就可以同时运行。这样，使用PIDL实现， PIDL的功能就可以在共同的启动进程下执行，且因此可以同时运 行。此外，通过PIDL加载方法，使得在设备上加载功能的方式有更 大的灵活性，包括从存储卡加载，这种方式在特定的运行期环境(如 Brew)是不允许的。对于DRM，在部署PIDL数据库时可以实现 DRM，此技术在运行期环境中部署可执行应用或applet是不可用 的。同时，如果需要，设备或网络提供商还可以限制可增加的功 能，使发货的设备中的启动应用只识别被允许的功能。
与启动程序在构建时被包含进去的严格封闭式环境不同，拥有 运行期环境(RTE)的设备可以利用在发货后下载启动应用的优势。 当使用这种方式时，上述的基于动态库(DL)的方案可以与RTE共 存，同时提供RTE自身无法提供的优点。具体来说，DL库可以访问 通过RTE无法访问的设备功能和API(如存储卡)。使用这种方案， 启动应用就可以穿过通信网络下载到设备的RTE，其中启动程序作 为代理允许通过其它方式，比如存储卡，增加更多功能。类似的， RTE常常限制在RTE下运行的应用的最大大小。通过下载本身很小 的启动应用，其大小在限定的范围内，但添加的含有功能代码的DL 库却可以超越大小限制，这样可以绕过最大大小，以使设备可以使用 更大的程序。因为DL库是作为二进制数据对象而不是作为RTE应 用加载的，RTE的大小限制不针对它。
图13展示了示例计算环境处理PIDL以在封闭式计算环境中实 现动态执行的处理过程。(相同的过程也适用于具有传统运行期环境 的封闭式环境和开放式计算环境)。如图13所示，处理从块1300开 始，其中功能被分成两部分，一部分是设备发货时(未示出)在设备 内驻留的启动应用中提供的自带功能，另一部分作为附加功能提 供。
在图13所示的说明性实现中，PIDL库对象在块1320中创建， 它含有附加功能，在块1330中生成源代码形式的桩文件。启动应用 在块1310中编译构建，其中含有从块1300中的自带功能，还有桩文 件1330和动态链接程序/加载程序。如块1340中所示，启动程序可 以在设备发货时就包含在设备中。
设备发货后，在块1350中可以提供采用附加功能的授权。就像 可理解的那样，授权可以基于商业协议，或者其它根据设备使用情 况的标准。在授权后，在块1360，PIDL库可以通过合适的方式提供 给设备使用，方式可以包括但不限于：下载到设备存储器，网络传 输，或从存储设备或设备链接的卡提供。然后在块1370中设备中的 启动应用可以运行。然后在块1375执行检查，决定是否有PIDL可 供设备使用。这个检查可以通过启动应用中的动态链接程序/加载程 序使用在块1310中编译好的PIDL桩文件执行。如果块1375的检查 表明没有PIDL可供设备使用，处理前进至块1380，其中启动应用继 续执行，但只是在设备自带的功能中运行(即，不执行PIDL包含的 附加的功能)。
但如果块1375的检查表明有PIDL库可供设备使用，处理前进 至块1390，其中PIDL被加载、链接并与启动应用绑定。利用这一步， 启动应用能访问的功能范围得到扩展，如块1395所示，以包括PIDL 提供的功能。
图14展示了通过下载启动应用提供附加功能的处理过程。该过 程可以在示例的计算设备发货后发生，与下载到开放式环境或下载 启动应用与设备上现有的RTE一起操作的情况类似。该过程还可以 作为独特事件发生，其中下载应用到封闭式环境中，环境对于下载 或增加的其它计算应用(例如，启动应用之外的应用)还保持封闭状 态。启动应用可以通过技术或商业控制的方式(例如下载)操作。
如图所示，处理开始于块1400，其中程序被分成启动应用和附 加功能。然后处理分开至块1415或1405。在块1405中，附加功能 的动态库(DL)对象被创建。在块1415中启动应用、链接程序/加载 程序和桩文件被编译和构建。从块1405开始，处理进一步分叉。从 块1405起，处理可以前进至块1410，其中生成的DL桩文件为源代 码形式。从1410起，处理前进至块1415然后前进。同样从块1405 起，处理可以前进至块1445，其中DL被提供给协作设备(如移动电 话)。从块1445起，处理前进至块1450，下面对此进行讨论。
从块1415起，处理前进至块1420，其中启动应用被下载至设 备。然后在块1425执行检查，确定下载的启动应用是否被授权在下 载的设备上操作。如果块1425的检查表明该启动应用没有授权，处 理在块1440结束。但如果块1425确定该启动应用被授权在该设备上 操作，处理前进至块1430，其中启动应用运行。然后在块1435执行 检查，决定DL是否经过上述的块1445为设备可用。如果块1435的 检查表明没有DL可供设备使用，启动应用的范围保持在发货时的范 围，不扩展由DL提供的附加功能。但如果块1435的检查表明有DL 可供设备使用，处理前进至块1450，其中链接程序/加载程序加载 DL，将它与运行的应用绑定。处理前进至块1455然后从那继续。在 块1455中，启动应用的范围得到扩展，包括DL提供的功能。
要理解图14描述的过程可以应用于下载单个启动应用或下载多 个启动应用。这种启动应用可以操作根据库的桩文件指示增加的功 能，该桩文件可以在启动应用构建时包含进去。
总之，在此描述的设备和方法提供可以跨越不同计算环境、操 作不同平台的平台无关二进制对象。但要理解，本发明可以有不同 的修改和替换构造。本发明不限于在此描述的特定构造。相反，本 发明意在涵盖所有的修改、替换构造和在本发明范围和精神之内的 等价构造。
还要注意的是本发明可以在不同的计算机环境中实现(包括非无 线和无线计算机环境)、局部计算环境和实际环境。在此描述的不同 技术可以在硬件或软件中实现，或结合两者实现。所述技术优选在 如下计算环境中实现，其中计算环境维护可编程计算机，其中包括 处理器、处理器可读的存储媒介(包括易失和非易失的存储器和/或 存储器件)、至少一个输入设备和至少一个输出设备。计算硬件逻辑 与不同指令集协作一起应用到数据上，执行上述功能和生成输出信 息。输出信息被应用于一个或多个输出设备。被示例计算硬件使用 的程序可以以不同的编程语言实现，包括高级过程或面向对象编程 语言，来和计算机系统通信。如果愿意，在此描述的示例性设备和 方法可以以汇编或机器语言实现。无论何种情况，该语言可以是编 译性或解释性语言。每个计算机程序优选存储在存储媒介或设备(例 如，ROM或磁盘)上，它们可以被通用或专用可编程计算机读取， 以配置和操作计算机来执行上述操作。该设备还可以考虑实现成计 算机可读存储介质，通过计算机程序配置，其中存储媒介配置成使 得计算机以特定和预定的方式操作。
虽然本发明的示例实现已经在上面进行了详细描述，但本领域 的技术人员可以理解，在说明性实施例中可以进行许多额外修改而不 实质性脱离本发明的新颖主旨和优势。相应的，这些以及所有这种 修改也被包括在本发明的范围之内。本发明由权利要求更好地定 义。