Pervasive package identifiers

A package identifier for a package from which an application is installed on a computing device is obtained. The package identifier is assigned to each of one or more processes created for running the application and, for each of the one or more processes, whether the process is permitted to access a resource of the computing device is determined based at least in part on the package identifier.

BACKGROUND

Computers typically have multiple installed applications, and oftentimes run multiple applications concurrently. These applications typically include executable code, resources such as images and/or text, and so forth. Despite the presence of these various applications, it remains difficult to reliably identify these applications and the resources of the applications. Thus, it remains difficult to perform various operations on computers that rely on the identities of applications and their resources.

SUMMARY

In accordance with one or more aspects, a package identifier for a package from which an application is installed on a computing device is obtained. The package identifier is assigned to each of one or more processes created for the application and, for each of the one or more processes, whether the process is permitted to access a resource of the computing device is determined based at least in part on the package identifier.

In accordance with one or more aspects, a package identifier is obtained from a package obtain as part of installing one or more applications from the package on a computing device. A subset of elements of the package identifier are used as a family identifier of the package. The family identifier is assigned to each of one or more processes created for the one or more applications. The family identifier can be used in various manners, for example to restrict access to a resource so that only processes that are assigned the family identifier can access the resource.

DETAILED DESCRIPTION

Pervasive package identifiers are discussed herein. An application and/or other code, libraries, resources, and so forth is distributed as part of a package. A package has an associated package identifier that is based on one or more elements, such as a name of the package, a publisher of the package, an architecture of the package, a resource type of the package, and/or a version of the package. When the application is installed on a device, the package identifier is maintained in a protected manner so that the package identifier is accessible to the operating system of the device but not to other applications running on the device. When running an application installed from the package, one or more processes are created each of which is assigned a security identifier based on the package identifier. This security identifier can be used in a variety of different manners, such as to permit access to a storage area dedicated to applications installed from the package, to permit communication with other processes, and so forth.

FIG. 1illustrates an example system100implementing the pervasive package identifiers in accordance with one or more embodiments. System100includes a computing device102, which can be a variety of different types of devices, such as a physical device or a virtual device. For example, computing device102can be a physical device such as a desktop computer, a server computer, a laptop or netbook computer, a tablet or notepad computer, a mobile station, an entertainment appliance, a set-top box communicatively coupled to a display device, a television or other display device, a cellular or other wireless phone, a game console, an automotive computer, and so forth. Computing device102can also be a virtual device, such as a virtual machine running on a physical device. A virtual machine can be run on any of a variety of different types of physical devices (e.g., any of the various types listed above).

Computing device102includes a pervasive package identifier based operating system104that installs applications in packages on computing device102and manages running of those applications on computing device102. An application is included in a package for deployment, and a package includes one or more components or modules for one or more applications. These components or modules can include binary code that is executed as part of an application or code that is interpreted or otherwise processed as part of an application, text or images that are part of (resources of) the application or other data that is part of the application, a library that is part of or used by the application and so forth.

Computing device102obtains packages from one or more of a variety of different package sources106. Multiple packages can be obtained together (e.g., as part of a deployment collection for one or more applications), and/or individual packages can be obtained from multiple sources. Package sources106can include remote sources, such as an application store112or a Web site114. Remote sources can be accessed via a variety of different networks, such as the Internet, a local area network (LAN), a public telephone network, an intranet, other public and/or proprietary networks, combinations thereof, and so forth. Package sources106can also include local sources, such as storage device116. Storage device116can be a variety of different storage devices, such as a magnetic disk, an optical disc, a Flash memory device, and so forth. Local sources can be included as part of computing device102, can be removable devices that are coupled to and de-coupled from computing device102, can be devices in coupled to computing device102via a wired and/or wireless connection, and so forth.

FIG. 2illustrates an example computing device200implementing the pervasive package identifiers in accordance with one or more embodiments. Computing device200can be, for example, a computing device102ofFIG. 1. Computing device200includes an operating system202, which can be an operating system104ofFIG. 1, that includes a deployment module204, a process creation module206, and a security module208. Deployment module204manages installation of one or more applications, based on a package212, on computing device200. Although a single package212is illustrated inFIG. 2, it should be noted that deployment module204can manage installation of multiple applications, based on multiple packages, on computing device200. Process creation module206manages the creation of processes on computing device200based on applications installed on computing device200. Security module208manages access to various processes, locations, resources, and so forth on computing device200. This access is based at least in part on a package identifier of package212, as discussed in more detail below.

FIG. 3illustrates an example package in accordance with one or more embodiments. Package302can be, for example, a package212ofFIG. 2. A package302includes one or more files304, which can include various components or modules for one or more applications. Package302also includes a manifest306that includes various metadata indicating actions to be taken to install package302. Manifest306is associated with package302and identifies how to install the package, such as which files are to be written to disk, what configuration values are to be set (e.g., in an operating system registry or store), and so forth.

Manifest306includes a package identifier308, which includes various elements. In the illustrated example, the elements of package identifier308are a name312, a publisher314, an architecture316, a resource type318, and a version320. Name312is a name assigned to package302by the developer of package302. The developer can choose any name they desire. Publisher314is a name of the publisher of package302, which is typically the developer or distributor of package302. The publisher can identify various entities such as a corporation, an individual, etc. Architecture316refers to the processor and/or device architecture with which the components or modules of package302are designed to operate. The developer can choose one or more architecture identifiers to include as architecture316. Various different processor and/or device architectures can be identified, such as an x86 architecture, an x64 architecture, a RISC (reduced instruction set computer architecture), and so forth. Version320is a version identifier of package302. The developer can choose any versioning indications (e.g., numeric sequences, alphanumeric sequences, etc.) that they desire.

Resource type318can be any of a variety of different values or attributes identifying characteristics of package302. The developer can choose any characteristics that they desire. These characteristics can include, for example, the country or geographic region in which the components or modules of package302are designed to operate, the language (e.g., English, French, Japanese, etc.) that the components or modules of package302use, a form factor (e.g., desktop/laptop, tablet/slate, etc.) for which the components or modules of package302are designed to operate, one or more screen resolutions for which the components or modules of package302are designed to operate, whether the package302includes trial versions or fully licensed versions of applications, and so forth.

Although illustrated as including a name312, a publisher314, an architecture316, a resource type318, and a version320, it should be noted that in other embodiments package identifier308can include other combinations of elements. For example, in some embodiments additional elements (not shown) can be included in package identifier308. By way of another example, in some embodiments one or more of these elements (e.g., architecture316, resource type318, and/or version320) may not be included in package identifier308. Additionally, in one or more embodiments some elements of package identifier308can be required to be included (e.g., package identifier308is required to have values for those elements in order for an operating system (e.g., operating system202ofFIG. 2) to use the package identifier), whereas other elements of package identifier308can be optional (e.g., package identifier308may or may not have values for those elements in order for an operating system (e.g., operating system202ofFIG. 2) to use the package identifier).

A package certificate330is also associated with package302. Package certificate330is a digital certificate that can be generated in a variety of conventional manners, such as by a trusted entity digitally signing package302and/or manifest306using public key cryptography. Package certificate330includes an identifier of the publisher of package302, which is verified as being the same as publisher314when installing package302, as discussed in more detail below.

The files304included in package302, as well as the components or modules included in each file304, are determined by the developer of package302. For example, a developer could choose to distribute word processing and spreadsheet applications separately, creating one package for the word processing application and another package for the spreadsheet application. In such situations, these two packages have different package identifiers, so different package identifiers would be used when using the word processing and spreadsheet applications. Alternatively, a developer could choose to distribute word processing and spreadsheet applications together as a suite of applications, creating a single package including both the word processing and spreadsheet applications. In such situations, the single package has a package identifier, so the same package identifier would be used when using the word processing and/or spreadsheet applications.

Returning toFIG. 2, one or more applications included in package212are installed on computing device200by deployment module204. As part of the installation or deployment, deployment module204verifies that the publisher identified in the package certificate associated with package212(e.g., package certificate330ofFIG. 3) has not been altered or tampered with. The package certificate associated with package212includes an identifier of the publisher of package212that is digitally signed by a trusted entity, allowing deployment module204to readily verify the digital signature and verify that the publisher identified in the package certificate associated with package212has not been altered or tampered with. If the publisher identified in the package certificate associated with package212has been altered or tampered with, then deployment module204does not install the one or more applications in package212.

However, if the publisher identified in the package certificate associated with package212has not been altered or tampered with, then deployment module204verifies that the publisher identified in the package certificate associated with package212is the same as the publisher in the package identifier214of package212(e.g., publisher314ofFIG. 3). Deployment module204installs the one or more applications in package212if the publisher identified in the package certificate associated with package212is the same as the publisher in package identifier214. If the publisher identified in the package certificate associated with package212is not the same as the publisher in package identifier214, then deployment module204does not install the one or more applications in package212.

Deployment engine204also maintains a package store216, in which deployment engine204stores various information regarding packages installed on computing device200, including an identification of each package (e.g., the package identifier of the package) installed on computing device200and the manifests associated with packages installed on computing device200. Deployment module204records, during installation or deployment of the one or more applications in package212, a record of package identifier214in package store216. The package identifier in store216is maintained or otherwise indicated as being associated with the one or more applications installed from package212. The package identifiers in package store216are maintained in a protected manner, allowing the package identifiers to be accessed by operating system202but not by other processes running on computing device200. Thus, a process created from an application installed from package212would not have access to the package identifier stored in package store216. The package identifiers can be protected in a variety of different manners, such as maintaining package store216in a location of memory that is only accessible to operating system202, storing package identifiers in a data structure that is encrypted using a key known only to operating system202, and so forth.

Package identifier214can be based on various elements as discussed above. In one or more embodiments, the package identifier214is stored in package store216as the package identifier for package212. Alternatively, a subset of the elements in package identifier214are stored in package store216rather than all of the elements in package identifier214. For example, the name and publisher from package identifier214(which together may be referred to as a family identifier of the package) can be stored in package store216and used as the package identifier for package212. Alternatively, multiple different package identifiers can be stored in package store216as package identifiers for package212, and these different package identifiers can be used by operating system202for different purposes. For example, one package identifier for package212in store216may be package identifier214and may be used by operating system202for one set of functionality, and another package identifier for package212in store216may be a subset of the elements in package identifier214and may be used by operating system202for a different set of functionality.

Additionally, as part of the installation or deployment process, deployment module204can generate or select one or more folders (or directories) of a storage device of computing device200in which the applications in package212can store data, settings, and so forth. The names of the one or more folders can optionally be based on the package identifier (e.g., the name of a root folder of the one or more folders can be the package identifier, or some name derived from the package identifier). The one or more folders are dedicated to applications in package212, with applications in other packages being prevented from accessing (e.g., writing to and/or reading from) the folder. Deployment module204can further configure an access control list (ACL) for one or more folders, adding a security identifier (SID) generated based on the package identifier of package212in package store216. This SID based on the package identifier is also referred to as the package identifier SID. Generating the SID based on the package identifier includes generating the SID based on all elements of the package identifier of package212, or based on only a subset of the elements (e.g., the family identifier of the package—the name and publisher from the package identifier). The SID can be generated in various manners, and the ACL can be used to restrict access to that folder to just processes created from an application installed from package212, as discussed in more detail below.

Similarly, deployment module204can generate ACLs for each of one or more other resources of computing device200. Generally, a resource of computing device200refers to a device, module, component, file, or capability of computing device200that a process may desire to access. Thus, a resource can be a hardware component of computing device, a module or component in a package (e.g., package212), and so forth. For example, a resource can be a group of folders (or directories), a storage device or volume, a network adapter, a camera, and so forth. Deployment module204can add a SID generated based on the package identifier of package212in package store216to such ACLs to allow processes created from an application installed from package212to access those resources. To which resource ACLs the SID is added can be determined in different manners, such as based on information in a manifest of package212, selections made by a user during installation of the one or more applications in package212, and so forth.

Alternatively, rather than adding a package identifier SID to an ACL of a resource, additional SIDs referred to as capability SIDs can be added to the ACLs of resources. The capabilities of one or more components or modules included in a package are identified in the manifest of the package. These capabilities can include accessing particular resources, accessing particular types or classes of resources, and so forth. Capability SIDs for the capabilities of the one or more components included in the package are added to a capability store, and the package identifier SID is added to an ACL associated with the stored capabilities for the package. Including the package identifier SID in the ACL associated with the stored capabilities for the package allows the processes created from an application installed from package212to use the capability SIDs to access the resources. Thus, the package identifier SID is used to gain access to SIDs that in turn allow access to the resources.

When an application begins running on computing device200, process creation module206manages the creation of one or more processes on computing device200for that application. Process creation module206assigns the package identifier to the one or more processes, typically using a process token although other techniques can alternatively be used. The package identifier associated with the application can be identified in different manners. For example, shortcuts or menu items identifying the application can, when the application is installed, include the package identifier associated with the application. Such shortcuts or menu items can provide the package identifier to process creation module206when selected by a user to run the application. By way of another example, when a user requests to run an application, process creation module206can obtain the package identifier associated with the application from package store216.

When creating a process, process creation module206generates a process token for the application that includes various metadata regarding the process, including a SID based on the package identifier associated with the application. The SID based on the package identifier can be generated in a variety of different manners, such as by using one or more elements of the package identifier as the SID or generating another value based on the package identifier. In one or more embodiments, the package identifier (or a subset of the elements of the package identifier) is input to a message authentication code (MAC) or hash-based message authentication code (HMAC), or other key derivation function. For example, the package identifier can be input to a DES3-CBC-MAC (Triple Data Encryption Standard Cipher Block Chaining Message Authentication Code), an HMAC with SHA-1 (Secure Hash Algorithm 1), and so forth. The output of the MAC, HMAC, or other hash or key derivation function is the SID based on the package identifier.

Thus, each process created for an application installed from package212includes a process token with a SID based on the package identifier of package212. It should be noted that if a process spawns one or more other processes, each of those one or more other processes inherit the same process token. Thus, each of those one or more other processes also includes a process token with a SID based on the package identifier of package212.

The SID in the process token based on the package identifier is flagged, identified, or otherwise stored in the process token in a manner that identifies the SID as being a package identifier SID. A process token can optionally have multiple additional types of SIDs based on other criteria (e.g., a user name or account, a group name, etc.). These additional types of SIDs can be used in various conventional manners to control access to resources. However, as the package identifier SID is identified as being a package identifier SID, the package identifier SID can be identified by the operating system to determine whether the process can access particular resources, other processes, and so forth as discussed below. Thus, support for SIDs that may already be included in various operating systems or devices can be leveraged using the techniques discussed herein, extending the support in those operating systems or devices to use the package identifier SID discussed herein.

It should be noted that operating system202generates the process tokens, and does not allow a process to modify a process token (its own process token or any other process token). Accordingly, the package identifier SID in the process token can be trusted, as the operating system202knows that a process cannot alter its own process token in an attempt to access processes or resources that the process is not permitted to access.

When a process desires to access a folder or other resource having an ACL, security module208compares the package identifier SID in the process token to the ACL of the folder or other resource. The ACL can include different portions for different types of SIDS, and thus security module208compares the package identifier SID in the process token to the appropriate part of the ACL. If the ACL of the folder or other resource indicates that the SID is allowed to access the folder or other resource, then security module208allows the process to access the folder or other resource. However, if the ACL of the folder or other resource indicates that the SID is not allowed to access the folder or other resource, then security module208prevents the process accessing the folder or other resource. A process can be prohibited from accessing a folder or other resource in different manners, such as by refusing to pass a request to the folder or other resource, notifying another module or component that the process is not permitted to access the folder or other resource, and so forth. An ACL can indicate whether a package identifier SID is allowed to access a folder or other resource in various manners, such as by including in the ACL the package identifier SIDs that are allowed to access the folder or other resource, including in the ACL the package identifier SIDs that are not allowed to access the folder or other resource, and so forth. Alternatively, the package identifier SID may be used to obtain one or more capability SIDs as discussed above, and the capability SIDs are compared to the ACL of the folder or other resource rather than the package identifier SID.

It should be noted that package identifier SIDs and/or capability SIDs can be added to the ACL of a folder or other resource prior to the package identifier for a package being obtained (or even existing). For capability SIDs, the package identifier SID is used to gain access to SIDs that in turn allow access to the resources as discussed above, so the package identifier SID need not be obtained prior to adding a capability SID to an ACL. For package identifier SIDs, the package identifier SIDs can be based on a family identifier of the package, which excludes a version number. Thus, a package identifier SID based on the family identifier of a previous version of a package can be added to an ACL before a subsequent version of the package is obtained (or even exists).

The package identifier SID in the process token can also be used to determine whether a process can access another process (which does not have an ACL). Such accesses can be performed using a variety of different inter-process communication techniques, such as remote procedure calls, messaging, and so forth. When a process desires to access another process, security module208compares the package identifier SID of that process to the package identifier SID of the other process. If the two package identifier SIDs match (e.g., are the same), then security module208allows that process to access the other process. However, if the two package identifier SIDs do not match (e.g., are not the same), then security module208prevents that process from accessing the other process. A process can be prohibited from accessing another process in different manners, such as by refusing to pass a call or message to the other process, notifying another module or component that the process is not permitted to access the other process, and so forth.

FIG. 4illustrates an example system400using security identifiers based on package identifiers in accordance with one or more embodiments. System400includes a process402having an associated process token404, a process406having an associated process token408, a process410having an associated process token412, and a resource414having an associated ACL416. Security module208receives requests from processes402,406, and410to access other processes and/or resource414. Whether security module208permits a particular process402,406, or410to access another process and/or resource414is based on the package identifier SID in the security token of the requesting process.

For example, process token404and process token412both include a SID based on a particular package identifier (referred to as package identifier1). If process402were to request to access process410, then security module208would permit the access because the SIDs of processes402and412are the same. However, process token408has a SID based on a different package identifier (referred to as package identifier2). If process402were to request to access process406, then security module208would not permit the access because the SIDs of processes402and406are not the same. Further, assume ACL416indicates that a process with a SID based on package identifier1is allowed to access resource414, but processes with SIDs based on other package identifiers are not allowed to access resource414. If process402or process410were to request to access resource414, then security module208would permit the access because ACL416indicates that the SIDs of processes402and410are permitted to access resource414. However, if process406were to request to access resource414, then security module208would not permit the access because ACL416indicates that the SID of process406is not permitted to access resource414.

Alternatively, the package identifier SID may be used to obtain one or more capability SIDs as discussed above. Thus, resource ACL416would include a capability SID rather than a package identifier SID (e.g., rather than the package identifier1SID).

Returning toFIG. 2, operating system202can use package identifier214to facilitate various other functionality as well. In one or more embodiments, package identifier214is used to facilitate uninstalling or removing applications in package212from computing device212. One or more folders of a storage device can be dedicated to the applications in package212as discussed above. Thus, the data, settings, and so forth for the applications in the package212can be readily deleted because they will all be stored in those one or more dedicated folders of the storage device. Additionally, operating system202can readily identify and terminate any processes created from applications in package212because those processes will have process tokens including a SID based on package identifier214.

Additionally, in one or more other embodiments package identifier214is used to facilitate servicing applications installed on computing device212from package212. The version of the applications already installed, and thus whether some other package includes a newer version, can be readily identified based on the information stored in package store216. For example, the package identifiers for two versions of the same package would have the same elements except for the version identifiers. Which version is newer can be readily determined based on the manner in which versioning is indicated (e.g., the larger or higher number may be the newer version). Furthermore, to update the applications operating system202can readily identify and shut down any processes created from applications in package212because those processes will have process tokens including a SID based on package identifier214. Operating system202can optionally maintain a record of the processes that are shut down, and restart those processes after the applications are updated.

In addition, in one or more other embodiments package identifier214is used to facilitate logging activity on computing device212. Operating system202can maintain a log for various actions performed by processes running on computing device200, such as resources accessed, processes accessed, capabilities accessed, and so forth. Because each process created from applications in package212includes a SID based on package identifier214in its process tokens, when an action is performed operating system202can maintain a record of the SID of the process that performed the action. Thus, an indication of an application from which package performed which actions can be readily maintained.

It should be noted that in some situations, package212can be dependent on one or more other packages that are referred to as dependency packages. These dependency packages can be created by the same developer as creates package212, or alternatively another developer. One package is dependent on another package if the one package relies on that other package to be present (installed) in order for an application in the one package to function correctly when running. The manifest associated with package212also includes dependency information for the package, identifying other packages (if any) that package212is dependent on. Operating system202can maintain a record identifying each package (and manifest of each such package) installed on computing device200, and for each such package an identification of any other packages that the package is dependent on. The dependency information can be maintained using a table, dependency graph, or alternatively a variety of other conventional data structures.

In one or more embodiments, package identifier214is used to facilitate loading of code libraries (e.g., dynamic link libraries) by a process. In response to loading of a library being requested by a component or module of package212, operating system202(e.g., a load library module of operating system202) verifies that the requested library is identified in the manifest of package212or in the manifest of a dependency package of package212. If the requested library is identified in the manifest of package212or in the manifest of a dependency package of package212, then operating system loads the requested library. However, if the requested library is not identified in the manifest of package212and is not identified in the manifest of a dependency package of package212, then operating system202does not load the requested library.

Additionally, in one or more other embodiments package identifier214is used to facilitate streaming of code to computing device200. Streaming code to computing device200refers to streaming package212to computing device200from another device, typically over a network. Operating system202uses the dependencies for package212to ensure that the dependencies of a package have been received at computing device200before the application in the package is run. Additionally, the package identifier can be used to allow operating system202to readily determine, for streaming code received at computing device200, a process that the streaming code is associated with (e.g., is part of the same package as) because the process will have a process token including a SID based on package identifier214.

FIG. 5is a flowchart illustrating an example process500for implementing pervasive package identifiers in accordance with one or more embodiments. Process500is carried out by a device, such as computing device102ofFIG. 1or computing device200ofFIG. 2, and can be implemented in software, firmware, hardware, or combinations thereof. Process500is shown as a set of acts and is not limited to the order shown for performing the operations of the various acts. Process500is an example process for implementing pervasive package identifiers; additional discussions of implementing pervasive package identifiers are included herein with reference to different figures.

In process500, a package identifier for a package from which one or more applications are installed on the computing device is obtained (act502). The package identifier can include various elements as discussed above. The package identifier can be obtained during installation of the one or more applications, or alternatively prior to installation of the one or more applications (e.g., can be obtained from a manifest of the package before the one or more applications are installed).

The package identifier is assigned to processes created for the one or more applications installed from the package (act504). The package identifier can be included in its entirety, or a subset of the elements of the package identifier can be assigned to processes as discussed above. The package identifier can be assigned to the processes by adding a security identifier based on the package identifier to a process token of each of the processes as discussed above. One or more folders or directories associated with the one or more applications can also be created with ACLs including a SID based on the package identifier, as discussed above.

A determination is made, based at least in part on the package identifier, whether the one or more processes are permitted to access resources of the computing device (act506). As discussed above, this determination can be made by comparing the package identifier security identifier and/or capability security identifier for a process to an access control list of the resource.

FIG. 6is a flowchart illustrating another example process600for implementing pervasive package identifiers in accordance with one or more embodiments. Process600is carried out by a device, such as computing device102ofFIG. 1or computing device200ofFIG. 2, and can be implemented in software, firmware, hardware, or combinations thereof. Process600is shown as a set of acts and is not limited to the order shown for performing the operations of the various acts. Process600is an example process for implementing pervasive package identifiers; additional discussions of implementing pervasive package identifiers are included herein with reference to different figures.

In process600, a package identifier for a package is obtained as part of installing one or more applications from the package on the computing device (act602). The package identifier can include various elements as discussed above.

A subset of elements of the package identifier are used as a family identifier of the package (act604). The subset of elements includes a publisher of the package, and can be both the name assigned to the package and the publisher of the package as discussed above.

The family identifier is assigned to processes created for the one or more applications installed from the package (act606). The family identifier can be assigned to the processes by adding a security identifier based on the family identifier to a process token of each of the processes as discussed above.

The pervasive package identifiers techniques discussed herein support various usage scenarios. The package identifiers are pervasive in a computing device, being used for installation as well as during runtime (e.g., as a basis for security identifiers). Processes created for an application installed on the computing device have a security identifier based on the package identifier, and the security identifier can be used for various functions as discussed above.

FIG. 7illustrates an example computing device700that can be configured to implement the pervasive package identifiers in accordance with one or more embodiments. Computing device700can be, for example, computing device102ofFIG. 1or computing device200ofFIG. 2.

Computing device700includes one or more processors or processing units702, one or more computer readable media704which can include one or more memory and/or storage components706, one or more input/output (I/O) devices708, and a bus710that allows the various components and devices to communicate with one another. Computer readable media704and/or one or more I/O devices708can be included as part of, or alternatively may be coupled to, computing device700. Processor702, computer readable media704, one or more of devices708, and/or bus710can optionally be implemented as a single component or chip (e.g., a system on a chip). Bus710represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor or local bus, and so forth using a variety of different bus architectures. Bus710can include wired and/or wireless buses.

Memory/storage component706represents one or more computer storage media. Component706can include volatile media (such as random access memory (RAM)) and/or nonvolatile media (such as read only memory (ROM), Flash memory, optical disks, magnetic disks, and so forth). Component706can include fixed media (e.g., RAM, ROM, a fixed hard drive, etc.) as well as removable media (e.g., a Flash memory drive, a removable hard drive, an optical disk, and so forth).

The techniques discussed herein can be implemented in software, with instructions being executed by one or more processing units702. It is to be appreciated that different instructions can be stored in different components of computing device700, such as in a processing unit702, in various cache memories of a processing unit702, in other cache memories of device700(not shown), on other computer readable media, and so forth. Additionally, it is to be appreciated that the location where instructions are stored in computing device700can change over time.

One or more input/output devices708allow a user to enter commands and information to computing device700, and also allows information to be presented to the user and/or other components or devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone, a scanner, and so forth. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, and so forth.

“Computer storage media” include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer. Computer storage media refer to media for storage of information in contrast to mere signal transmission, carrier waves, or signals per se. Thus, computer storage media refers to non-signal bearing media, and is not communication media.

Generally, any of the functions or techniques described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or a combination of these implementations. The terms “module” and “component” as used herein generally represent software, firmware, hardware, or combinations thereof. In the case of a software implementation, the module or component represents program code that performs specified tasks when executed on a processor (e.g., CPU or CPUs). The program code can be stored in one or more computer readable memory devices, further description of which may be found with reference toFIG. 7. In the case of hardware implementation, the module or component represents a functional block or other hardware that performs specified tasks. For example, in a hardware implementation the module or component can be an application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), complex programmable logic device (CPLD), and so forth. The features of the pervasive package identifiers techniques described herein are platform-independent, meaning that the techniques can be implemented on a variety of commercial computing platforms having a variety of processors.