Abstract: A library management system may compare contracts between programming libraries to identify unions, intersections, and differences between libraries. The management system may have a contract analyzer that may remove the contract definition from an existing library to form a library contract. The library contract may be managed as a first class item within a programming environment, and may be used as a reference for comparing existing and new versions of the library. The library management system may create reference libraries for programmers to write applications using two or more intersecting libraries, among other uses.

Abstract: A library management system may compare contracts between programming libraries to identify unions, intersections, and differences between libraries. The management system may have a contract analyzer that may remove the contract definition from an existing library to form a library contract. The library contract may be managed as a first class item within a programming environment, and may be used as a reference for comparing existing and new versions of the library. The library management system may create reference libraries for programmers to write applications using two or more intersecting libraries, among other uses.

Abstract: The operating system manages software entities by creating a construct called a context that organizes and manages software-related state and configuration settings of applications. A context may comprise an installation service, a configuration service and an activation service. Contexts can be linked or arranged hierarchically to form parent-child relationships. Hierarchies may be used to affect accessibility of software items, to satisfy dependencies, to control the visibility/invisibility of software items, to provide access to configuration settings and to override software availability, dependencies and configuration settings. An override may be applied to set policy when more than one context has a configuration setting, dependency or access to a software entity.

Abstract: The database (namespace) for storing component metadata for an application that is to be run in an isolated environment is isolated by an operating system by storing the component metadata in a local set of information associated with the isolated application instead of in a global namespace. The operating system utilizes this local metadata instead of the global database when components are employed. Registration data for components is placed within a manifest, enabling the operating system to determine the relationship between an application and a component or set of components used by the application.

Abstract: Software typically changes over its useful lifetime. New versions of software are created to change or improve functionality, to add functionality, to correct coding errors, improve performance, to adapt to new hardware and for many other well-known reasons. The process of delivering new versions of software to users is called servicing the software. The operating system decides which version(s) of a piece of software satisfy dependencies of other software by creation of a context. The context may be used to organize and manage versions of software, to declare activation policies concerning the use of different versions of software and to service the versioned software. The context may include an activation service that maintains and manages resolution polices, resolves dependencies, constructs the environment in which an application runs and initiates the running of the software.

Abstract: The operating system organizes software so the set of extensions for an extendable application can be dynamically discovered and the extension can be run securely. Extensions are run as separate applications instead of within the extendable application's process. Extensions are discoverable to an activated extendable application by querying a category catalog. A category provides at least a partial description of a contract between an activating software entity and a software entity that is activated by the activating software entity. The category may enumerate a set of configuration settings associated with the contract that may be used to set up an isolated execution environment for the activated software entity. The category may also specify one or more extension points to be used for communication between the activating and activated software entities. The category may also include a list of software entities that implement the category.

Abstract: The resources needed by an application to execute are declared by the application. When the application is activated, only the declared resources are made available to the application because only the declared resources are connected to the execution environment. Accessibility to resources may be controlled by the operating system by making the resource visible or invisible to the executing software by mapping a local name used by the executing software to a global resource, possibly limiting the type of access allowed. Because the executing software relies on the mapping function performed by the operating system for access to resources, and the operating system only maps names declared by the software, the operating system can isolate the software, and prevent the application from accessing undeclared global resources.

Abstract: An operating system architecture is based on a service model in which active entities (services) are containers for objects having a number of interfaces specified through a contract language that is a subset of the language in which the service is coded. Services may reside in the same address space or may reside in separate address spaces, without changing the programming model or compiled binaries. The location of a service is independent of the location of the service's clients and of services the service calls.

Abstract: A type server on a first machine assigns a sequential small integer identifier of fixed length to lengthy information. Identifying information using a small integer identifier provides efficiencies in communication between processes on a single machine as well as efficiencies in communication between processes on different machines. Storage of this information is also more efficient. The information so identified may be, for example, interface type. The small integer identifier assigned to the interface types may be assigned in a set enumeration scheme, that is the first interface type encountered when generating a list or table of interfaces types may be assigned the integer identifier “1”, the second “2” and so on. Similarly, the small integer identifiers may be assigned whenever a new interface type is encountered during execution. A translation table including interface type name and interface type identifier for may be generated.

Abstract: A type server provides the proxy and stub code needed by client and server programs on demand (dynamically), when the code is needed during execution. When an interface for a resource is defined, the proxy code and the stub code for the type of resource is generated and stored within the type server. The client and server programs each keep a local table of type identifiers/resource type translations for each resource referenced. The local table acts like a cache: when a type identifier is not found in the table, the type server is contacted, and the type identifier for that resource type is retrieved and stored in the cache. Another local table acting as a cache stores type ID and associated proxy and stub code for the resource type. When a program needs the proxy code for a resource type, it checks its cache and it the proxy code is not found the type server is contacted, the proxy (and stub) code is retrieved from the type server and is stored in the cache.

Abstract: A system and method is provided to facilitate communications between object systems. A caller is provided having optimized in-lined functionality when initiating a remote function call between managed and unmanaged object systems, for example. The in-lined functionality includes utilizing direct calls and returns within a calling function. In this manner, pushing additional arguments onto an execution stack because of an external stub reference is mitigated. In addition, one or more code loops can be analyzed to enable stack markers to be “hoisted” and thus pushed a single time instead of each time the calling function executes. Other aspects of the optimized caller provide garbage collection and thread management, security attribute checking on outgoing calls, calling convention considerations, wherein arguments and return values are organized according to the convention utilized by the remote object system, and in-lined marshalling to provide enhanced performance over external stub code references.

Abstract: The present invention synchronizes threads in a garbage-collected system. In accordance with the invention, each thread may enable or disable garbage collection. A synchronization facility receives a request to initiate garbage collection. In response to the request, the facility identifies threads that have enabled garbage collection more recently than they have disabled garbage collection. Then, until all of the threads are identified or suspended, the facility identifies threads that enable garbage collection and suspends threads that disable garbage collection. When all threads are identified or suspended, the facility performs garbage collection. The facility also suspends any identified threads that attempt to disable garbage collection during the performance of garbage collection.