|Publication number||US7287259 B2|
|Application number||US 09/842,270|
|Publication date||Oct 23, 2007|
|Filing date||Apr 24, 2001|
|Priority date||Apr 24, 2000|
|Also published as||US20020019972|
|Publication number||09842270, 842270, US 7287259 B2, US 7287259B2, US-B2-7287259, US7287259 B2, US7287259B2|
|Inventors||Michael J. Grier, RoseMarie FitzSimons, David D'Souza, Peter Wilson, Srivatsan Parthasarathy, Sanjay G. Shenoy, Micheal Dunn|
|Original Assignee||Microsoft Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (10), Non-Patent Citations (3), Referenced by (50), Classifications (5), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present application claims priority to U.S. Provisional Patent Application Ser. No. 60/199,374, filed Apr. 24, 2000, and is also related to U.S. patent application entitled “Configurations for Binding Software Assemblies to Applications,” Ser. No. 09/842,278, filed concurrently herewith.
The present invention is generally directed to computer systems, and more particularly to executable computer code such as application programs that utilize shared assemblies (components).
At one time, computer applications were monolithic blocks of executable code and data, although some of their data such as variable settings could be maintained in separate files. This made tasks like moving or replacing the application simple. In contrast, contemporary computer applications and other executable code (such as an operating system component) bind to and make use of shared components, wherein in general a component is a self-contained software entity, offering a set of functions that can be used by a variety of applications. Such components include dynamic link libraries (DLLs) and objects such as OLE (Object Linking and Embedding) components and COM (Component Object Model) components, including ActiveX® controls. In turn, some of these shared components depend on other shared components.
On any given machine, at present there is one version of each of these components shared by applications, such as the most-recently installed version, although some mechanisms are known that replace an installed component only when an available replacement component has a higher version number. The metadata maintained for using these components is generally maintained in the system registry, and the application has the names of the needed components compiled into its binary code. Because in general the application does not change as components change, to function properly, global component sharing requires that any shared component function exactly like previous other versions of that component with respect to what an application expects. In practice, however, perfect backwards compatibility is difficult if not impossible to achieve, among other reasons because it is impractical to test the many configurations in which the shared component may be used. For example, both newer and older applications end up sharing the same component, whereby over time, fixing and improving the component becomes increasingly difficult. Moreover, the practical functionality of a component is not easily defined. For example, some applications may utilize unintended side effects in a component that are not considered part of the core function of the component, e.g., an application may become dependent on a bug in a component, and when the component publisher chooses to fix that bug, the application fails. Of course, on the other side, application writers cannot test future versions of components.
As a result, problems occur when a component is updated to its newer version, such as when a new application or operating system service pack is installed with updated copies of components, as the newly installed component versions become the ones used by other applications and components on the system. The sheer volume of applications and components that rely on other components magnifies this problem, which is sometimes referred to as “DLL Hell.”
One mechanism that provided sharing for some applications while enhancing the stability of other applications was provided in Microsoft Corporation's Windows® 2000 and Windows® 98, Second Edition, operating systems. In general, this mechanism provided a way for an application to be bound to a local copy of a component instead of a shared copy. However, with this solution, a component needed to be isolated per application, which resulted in multiple copies of the same component version having to be maintained on the system. Additionally global non-code data, such as COM data, was not isolated, limiting this mechanism's usefulness with COM objects.
Briefly, the present invention provides a method, system and infrastructure that allow an application to run with specified versions of components bound thereto, wherein each component (also referred to herein as an assembly, wherein an assembly is set of one or more component files which are versioned and shipped as a unit) may exist and run side-by-side on the system with other versions of the same assembly being used by other applications. To this end, the application provides a manifest to specify any desired assembly versions. An activation context is created for the application based on the manifest to map global, version independent names to a particular version maintained in an assembly cache or in the application's respective directory. In order to specify a version for an assembly, applications need not have their code rewritten, but instead can provide the application manifest, (e.g., in an XML data structure). Similarly, each assembly has an assembly manifest that specifies the versions of dependent assemblies.
In the pre-application execution phase when creating a new process, the operating system checks for an application manifest in the same file system directory as the calling executable. When an application manifest exists, the operating system checks for an activation context for the application that was built from the manifest. If the activation context does not exist (for example this is the first time application has been executed), or it exists but is not coherent with current policy, an activation context is created via the application manifest and the assembly manifests of any dependent assemblies/assemblies listed in the application manifest.
At runtime, when a program requests creation of a global object, the operating system automatically consults the activation context built from the application and assembly manifests, to locate and load the assembly version that the application wants to use. The operating system also maps any uses of this named object (such as object (e.g., Windows®) classes) to the appropriate version to allow for multiple versions of the code module to run simultaneously without interfering with each other. By its manifest and the activation context built therefrom, an application may be bound to specific assembly versions and thereby be isolated from changes made to assembly versions by other applications.
Other objects and advantages will become apparent from the following detailed description when taken in conjunction with the drawings, in which:
Exemplary Operating Environment
The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so forth, that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
With reference to
The computer 110 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computer 110 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, 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 includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk 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 accessed by the computer 110. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer-readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation,
The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media, discussed above and illustrated in
The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in
Isolating and Binding Assembly Versions
The present invention is generally directed to isolating versions of components (including code and/or data) per-application program or the like, in a manner that allows multiple versions of the same component to exist and operate side-by-side on a system. For practical purposes, components may be collected into an assembly, which, when referring to items such as a component, is the lowest unit of storage packaged for activation, distribution and versioning, and isolation, as described herein. Rather than deal with individual components, of which there may be a relatively large number, many of the actions regarding components that are grouped together can be handled by referring to their assembly. For example, rather than list in the manifest 204 1 the dependencies on a large number of individual components that are packaged together in an assembly, the manifest may simply list a dependency on the assembly. As used herein, the term “assembly” will refer to one or more components, whether referring to a single component (e.g., one contiguous DLL) or to a plurality of components grouped together.
Assemblies can be shared, such as when more than one application or the like needs an instance of the assembly's code. To provide significant flexibility while being transparent to existing and newly-developed applications, the present invention has been implemented in an operating system, with applications being run via the operating system. As will be understood, however, the present invention is not limited to applications and/or an operating system implementation, but rather is capable of being implemented by virtually any mechanism internal or external to executable code (e.g., an application) that needs or wants to use a specific version of an assembly. Note that as used herein, an application program is not limited to any particular type of software product, but includes any executable code such as operating system components, drivers and so on that in turn use other assemblies. Notwithstanding, the present invention will be primarily described with an application that uses assemblies including DLLs, resources and objects.
Although the application manifest lists its dependencies on assembly versions, it should be noted that technically, the application is only dependent on the manifest-specified assemblies themselves, not necessarily the exact versions that are specified. Instead, the specified versions are only those which have been tested with the application. In one implementation, another version of a needed assembly can replace the application-preferred version when additional information is available to the assembly loading mechanism (e.g., an operating system component). For example, as also described in copending U.S. patent application entitled “Configurations for Binding Software Assemblies to Applications” Ser. No. 09/842,278, assigned to the assignee of the present application, filed concurrently herewith, and hereby incorporated by reference, policy data (configurations) and/or an assembly manifest associated with the specified assembly may override the version information set forth in the application manifest. Nevertheless, it is expected that such policies and assembly manifests will be used conservatively, e.g., only for important fixes and/or after thorough testing, since they will cause replacement of the trusted assembly version.
Two types of assemblies are possible, those having strong names, e.g. including a public key signature or the like such that any two different assemblies can be unambiguously identified, and those having a simple name, which may be ambiguous in the context of an application and, for example, do not contain a public key. To provide isolation, any simply-named assemblies on which an application manifest specifies a dependency are treated as privatized. Privatized assemblies are those that the application does not intend to be shared with other applications. Privatized assemblies that have simple names are normally installed into the same folder as the executable application code, whereby the assembly is isolated and the application is given the effect of being monolithic, e.g., its assemblies are not influenced by different assemblies having the same simple name, and so forth. By not being shared, privatized assemblies with simple names thus have the benefit of virtually complete isolation, at the expense of the benefits obtained by sharing. Assemblies having strong names do not need to be placed into the application folder for isolation purposes, because assemblies with strong names are known to be the exact one the application needs. Thus, instead of being privatized by storing in a certain directory, such assemblies may be placed into a global assembly cache 212 to obtain the benefits of sharing, while effectively preserving isolation, because an application that asks for a strongly named assembly will get a copy that is exact.
Note that as represented in
As further represented in
Privatized assemblies that are not strongly named are copied to the application folder, as described above. To this end, an installer or the like contacts the operating system, which then directs the installer as to where (e.g., what folder) to install any given application files or assembly files based on the manifest type, file name data (strong or simple), and/or other installation information. In this manner, any privatized assemblies with simple names are installed into the same folder as the executable application code, as described above, while sharable assemblies are stored in the assembly cache 208.
The assembly manifest is preferably copied to the assembly cache 208 with its corresponding assembly at the time of installation. The assembly manifest describes the assembly and includes information about its individual assembly, including, for example, the name and version of the assembly, the items (program files, resources) that make up the assembly, and the binding path to items within the assembly (e.g., for Win32 DLLs this is the location of the DLL relative to the root of the assembly, whereas for COM Servers this is the CLSID (class identifier), ProgID (programmatic identifier) and other COM metadata). The assembly manifest may also include any dependencies on other assemblies, object classes and global names.
Example manifests in XML format are set forth in the tables below, wherein TABLE1 is an example of a simple application manifest where the application depends on a side-by-side version of COMCTL32:
<?xml version=“1.0” encoding=“UTF-8” standalone=“yes”?>
<description>Your app description here</description>
TABLE2 is an example of an application manifest where the application depends on a side-by-side version of COMCTL32 and an assembly is privatized to the application:
<?xml version=“1.0” encoding=“UTF-8” standalone=“yes”?>
<description>Your app description here</description>
<!-- Privatized assembly -->
<comClass description=“Font Property Page”
<comClass description=“Color Property Page”
<comClass description=“Picture Property Page”
description=“SxS_COM 1.0 Type Library”
Assemblies may be dependent on other assemblies, which in turn are dependent on other assemblies, and so on. To ensure the proper versions of dependent assemblies, one or more of the assemblies 210 1-210 n (e.g., assembly 210 1) may have an assembly manifest 212 1 associated therewith that provides assembly dependency data 214 1. To this end, assembly authors that create side-by-side assemblies may also author an assembly manifest 212 1 with each assembly, and have that assembly manifest evaluated for proper version dependencies. Note that although not separately shown in
A sample assembly manifest is set forth in TABLE3 below:
<?xml version=“1.0” encoding=“UTF-8” standalone=“yes”?>
<comClass description=“Font Property Page”
<comClass description=“Color Property Page”
<comClass description=“Picture Property Page”
<comClass description=“Registrar Class”
00A0C90391D3}” version=“1.0” helpdir=“”/>
Among other things, an assembly manifest can specify (e.g., in an XML format) an assembly's dependency on a particular version of an assembly. For example, in
Note that although not shown in
In accordance with one aspect of the present invention, the metadata in an application manifest and the metadata in appropriate assembly manifests is used during the creation of an activation context for the application to provide an efficient way to load the correct version of an assembly for the corresponding application. As a result, when an application uses the side-by-side assemblies, the application code does not have to change internally to reflect the version of the assembly being used, e.g., the application simply executes its code generally rather than perform different operations each tailored to a particular assembly version. For example, in
As represented in
It should be noted that not every assembly used by an application needs to be specified in the application manifest, nor does each assembly manifest have to specify all of its dependent assembly versions, only those versions wherein there is a particular version desired. This is because the architecture described herein allows a default assembly version to be used when a particular version of an assembly is not specified in a manifest. Normally, when more than one version of an assembly is available, the default assembly is the most-recent version, however it is possible for an administrator or user to set (e.g., via interaction with the operating system through a dialog box, property sheet or the like) any version as a default.
In keeping with the present invention, the activation context 302 for an application maps version-independent assemblies that are requested by an application to the versions that are specified in the application manifest and/or assembly manifests. By way of example,
Once created, the activation context 302 1 is maintained in a persistable binary form for caching. Preferably, a new activation context is recomputed each time the application is launched, and freed when the application is closed. However, in one alternative, the activation context may be preserved, e.g., to a non-volatile storage. If preserved, because policy or the like may change the dependency information therein, (e.g., a new assembly manifest has been installed), the activation context 302 1 may include a cache coherency section 402 that is used to detect whether the saved activation context 302 1 is valid, wherein when the activation context 302 1 is not coherent with current policy, it is recomputed. A section per API that implements version-specific binding is maintained.
To map the application's requests to the proper assembly versions, the activation context 302 1 includes a DLL redirector section 404 and an object class redirector section 406. The DLL redirector section 404 includes a record or the like for each DLL dependency that includes fields (e.g., 408 1 and 409 1) that relate the DLL name used by an application to the exact pathname of the version specified in the application manifest and/or assembly manifest. The object class redirector section 406 includes a record or the like for each object class (e.g., Windows® object class) on which an application depends, wherein each record includes fields (e.g., 412 1, 413 1, and 414 1) that relate the object class name used by an application to the DLL file it is in and a version specific name. Note that the fields are arranged in a manner that optimizes lookup, e.g., the application-provided request data corresponds to the search key, and the records may be arranged in any way (e.g., alphabetically, by frequency, linearly, binary or so on) to speed searches.
Via the activation context, during runtime, an application's requests for assemblies can be efficiently satisfied with the correct version of that assembly. If a given assembly is not found in the activation context data, the default assembly is used. To summarize, when an application first runs, the activation context built from the manifest data is cached, whereby the global, version-independent named objects requested by an application are mapped to version-dependent named objects as specified in the manifest. As the application executes and requests a named object via one of the activation APIs, the version-independent named objects are applied in a version specific fashion by accessing the application context, whereby the application gets the correct version.
When the application API 300 1 receives the request, the request data (e.g., the application provided name) is passed to a runtime version-matching mechanism 502 (the arrow labeled two (2)). The runtime version-matching mechanism 502 locates the correct activation context 304 1 for the calling application 202 1, and accesses the records therein to determine the correct version of the requested assembly (the arrows labeled three (3) and four (4)). Via the tables in the activation context 304 1, the runtime version-matching mechanism 502 will either return (e.g., as a return parameter, with the arrow labeled five (5)) the path and filename of the version-specific assembly, or a not-found status or the like (and/or the path and filename of the default file) to the activation API that called it, in which case the activation API will load the default assembly. As represented in
Turning to an explanation of the operation of the present invention with particular reference to the flow diagrams of
When step 600 determines that an application manifest exists, the initialization mechanism 304 (
In the event that the initialization process continues to step 610 to create the activation context, step 610 represents obtaining the binding information from the application manifest. Steps 610, 612, 614 and 616 of
By way of example,
When the appropriate assembly is in the graph following any possible replacements, step 702 branches to step 706 wherein any dependencies listed in the current assembly's manifest are added to the dependency graph. For example, in
Beginning at step 900 the activation API receives the application request including the version-independent assembly name, not the version specific name, and passes it as a parameter or the like to the runtime version matching mechanism, where it is received at step 902. If an entry for the name is in the activation context at step 904, the runtime version matching mechanism returns the version specific information (e.g., including the path and filename of the correct version) based on the manifest at step 906. If an entry for the name is not found in the activation context at step 904, at step 908 the runtime version matching mechanism returns a not found status, (or alternatively can determine and return the path and filename of the default version). At step 910, the activation API loads appropriate version, and returns a loading status or the like. The operating system also maps any uses of this named object to the appropriate version to allow for multiple versions of the code module to run simultaneously without interfering with each other, whereby, for example COM object data is isolated per object. At this time, the correct version as specified in the manifests is loaded, even though the application's executable code did not specify any version. Indeed, by providing an associated manifest that can be stored into the application's directory, an already existing application (e.g., written and installed before the present invention) can benefit from the present invention.
By way of a further example, consider two versions of an object class container, COMCTL32 version six (v6), and COMCTL32 version seven (v7), both of which have a SysListView object class therein. When the application launches for the first time, the operating system reads the manifest and creates version-specific classes for items listed in the manifest, for example, the application manifest has listed v6 and this has not been overridden. The activation context is created and the object class created for SysListView, wherein the version number for the COMCTL32 object class container and the SysListView object class is v6, as specified in the application manifest.
When the application program is running and requests an object class, the application does so as it always has, that is, by specifying the object, SysListView, without specifying any version information. However, based on the activation context, the appropriate version name of SysListView (in this example corresponding to V6) will be automatically returned and version v6 of the object will be located. As is understood, the application developer need not modify the application in any way to get the appropriate version, but instead only needs to provide a suitable application manifest.
In this manner, instead of having a system default of a single control such as SysListView in COMCTL32 that the processes use, multiple side-by-side versions of SysListView can be available and running. Each process has the option to choose the specific version to use. Moreover, because more metadata is being maintained about the runtime, self-healing systems are possible. For example, if an application fails, the operating system may intelligently use this metadata to repair the problem.
As can be seen from the foregoing detailed description, there is provided a method, system and infrastructure to version globally named objects in the system. Application authors may create safe, isolated applications by simply creating a declarative manifest that describes dependencies on these shared objects, without needing to be concerned with coding the application to adjust to the version of the assembly being used. By the present invention, assemblies can be safely shared and applications can be more completely isolated.
While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific form or forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4809170||Apr 22, 1987||Feb 28, 1989||Apollo Computer, Inc.||Computer device for aiding in the development of software system|
|US5339430||Jul 1, 1992||Aug 16, 1994||Telefonaktiebolaget L M Ericsson||System for dynamic run-time binding of software modules in a computer system|
|US5805899||Jul 6, 1995||Sep 8, 1998||Sun Microsystems, Inc.||Method and apparatus for internal versioning of objects using a mapfile|
|US5974470 *||Sep 3, 1997||Oct 26, 1999||Chicago-Soft, Ltd.||System for reducing conflicts among dynamic link library modules by aliasing modules|
|US6185734||Jul 21, 1998||Feb 6, 2001||Hewlett-Packard Company||Hierarchical registry structure for managing multiple versions of software components|
|US6314565||Apr 30, 1998||Nov 6, 2001||Intervu, Inc.||System and method for automated identification, retrieval, and installation of multimedia software components|
|US6332168 *||Sep 28, 1995||Dec 18, 2001||International Business Machines Corporation||Method of, system for, and computer program product for providing a run time subsystem for run time libraries|
|US6442753 *||Aug 28, 1997||Aug 27, 2002||International Business Machines Corporation||Apparatus and method for checking dependencies among classes in an object-oriented program|
|US6560614||Nov 12, 1999||May 6, 2003||Xosoft Inc.||Nonintrusive update of files|
|US6658659 *||Dec 16, 1999||Dec 2, 2003||Cisco Technology, Inc.||Compatible version module loading|
|1||Finnie, Scot et al., "The Final Beta-Inside Windows 2000 Beta 3", www.PlanetIT.com/docs/PIT19990707S0023, Jul. 1, 1999, pp. 1-8.|
|2||Grinzo, Lou, "Paranoia is Your Friend", www.winmag.com/library/1997/0601/analy034.htm, Jun. 1997, pp. 1-3.|
|3||Richardson, Robert, "Components Battling Components", www.byte.com/art/9711/sec6/art6.htm, Nov. 1997, pp. 1-12.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7519814 *||Sep 13, 2004||Apr 14, 2009||Trigence Corp.||System for containerization of application sets|
|US7568188 *||Mar 7, 2003||Jul 28, 2009||Microsoft Corporation||Method for testing a software shim|
|US7581225||Feb 23, 2006||Aug 25, 2009||Microsoft Corporation||Multithreading with concurrency domains|
|US7644109 *||Jan 9, 2006||Jan 5, 2010||Netapp, Inc.||System and method for storage of snapshot metadata in a remote file|
|US7721194 *||Mar 18, 2005||May 18, 2010||Groove Networks, Inc.||Method and apparatus for efficient management of XML documents|
|US7886269||Feb 23, 2006||Feb 8, 2011||Microsoft Corporation||XML application framework|
|US7917894 *||Jun 3, 2005||Mar 29, 2011||International Business Machines Corporation||Constraining source code and objects for analysis tools|
|US7984434 *||May 21, 2003||Jul 19, 2011||Altera Corporation||Nondestructive patching mechanism|
|US8046737||Feb 23, 2006||Oct 25, 2011||Microsoft Corporation||XML application framework|
|US8111563||Feb 7, 2012||Samsung Electronics Co., Ltd.||Multi-level nonvolatile memory device with fast execution of program speed and programming method of the same|
|US8132148||Feb 23, 2006||Mar 6, 2012||Microsoft Corporation||XML application framework|
|US8229980||Apr 30, 2008||Jul 24, 2012||Microsoft Corporation||State buckets|
|US8291401 *||Aug 7, 2008||Oct 16, 2012||International Business Machines Corporation||Processing symbols associated with shared assemblies|
|US8321843||Feb 9, 2009||Nov 27, 2012||Tranxition Corporation||Automatic analysis of an application's run-time settings|
|US8418132 *||Feb 23, 2006||Apr 9, 2013||Microsoft Corporation||Application description language|
|US8464242||Jun 11, 2013||Tranxition Corporation||Virtualization of configuration settings|
|US8522227 *||Aug 24, 2009||Aug 27, 2013||Microsoft Corporation||Runtime activation and version selection|
|US8793649||Mar 2, 2012||Jul 29, 2014||Microsoft Corporation||XML application framework|
|US8799857||Feb 23, 2006||Aug 5, 2014||Microsoft Corporation||XML application framework|
|US8862686 *||Aug 28, 2003||Oct 14, 2014||International Business Machines Corporation||System and method for providing shared web modules|
|US8893116 *||Jan 15, 2012||Nov 18, 2014||Microsoft Corporation||Installation engine and package format for parallelizable, reliable installations|
|US8903705||Dec 17, 2010||Dec 2, 2014||Microsoft Corporation||Application compatibility shims for minimal client computers|
|US9323921||Jul 13, 2010||Apr 26, 2016||Microsoft Technology Licensing, Llc||Ultra-low cost sandboxing for application appliances|
|US9389933||Dec 12, 2011||Jul 12, 2016||Microsoft Technology Licensing, Llc||Facilitating system service request interactions for hardware-protected applications|
|US9413538||Dec 12, 2011||Aug 9, 2016||Microsoft Technology Licensing, Llc||Cryptographic certification of secure hosted execution environments|
|US9417931||Jun 24, 2008||Aug 16, 2016||Microsoft Technology Licensing, Llc||Unified metadata for external components|
|US9425965||Feb 13, 2012||Aug 23, 2016||Microsoft Technology Licensing, Llc||Cryptographic certification of secure hosted execution environments|
|US20040177338 *||Mar 7, 2003||Sep 9, 2004||Microsoft Corporation||Method for testing a software shim|
|US20050050155 *||Aug 28, 2003||Mar 3, 2005||International Business Machines Corporation||System and method for providing shared web modules|
|US20050060722 *||Sep 13, 2004||Mar 17, 2005||Trigence Corp.||System for containerization of application sets|
|US20050165815 *||Mar 18, 2005||Jul 28, 2005||Groove Networks, Inc.||Method and apparatus for efficient management of XML documents|
|US20060112151 *||Jan 9, 2006||May 25, 2006||Manley Stephen L||System and method for storage of snapshot metadata in a remote file|
|US20060248112 *||Feb 23, 2006||Nov 2, 2006||Microsoft Corporation||Application description language|
|US20060248448 *||Feb 23, 2006||Nov 2, 2006||Microsoft Corporation||XML application framework|
|US20060248450 *||Feb 23, 2006||Nov 2, 2006||Microsoft Corporation||XML application framework|
|US20060248530 *||Feb 23, 2006||Nov 2, 2006||Microsoft Corporation||Multithreading with concurrency domains|
|US20060277528 *||Jun 3, 2005||Dec 7, 2006||International Business Machines Corporation||Constraining source code and objects for analysis tools|
|US20070250574 *||Jun 23, 2006||Oct 25, 2007||Tseitlin Ariel D||Continuous deployment|
|US20080222160 *||Mar 13, 2008||Sep 11, 2008||Macdonald Craig||Method and system for providing a program for execution without requiring installation|
|US20090276442 *||Apr 30, 2008||Nov 5, 2009||Microsoft Corporation||State Buckets|
|US20090319554 *||Jun 24, 2008||Dec 24, 2009||Microsoft Corporation||Unified metadata for external components|
|US20090320007 *||Dec 24, 2009||Microsoft Corporation||Local metadata for external components|
|US20100037208 *||Feb 11, 2010||International Business Machines Corporation||handle based method for side-by-side assemblies in a unix environment|
|US20100205416 *||Feb 9, 2009||Aug 12, 2010||Lanner Mats E||Automatic analysis of an application's run-time settings|
|US20100214831 *||Oct 19, 2009||Aug 26, 2010||Ho-Jung Kim||Memory device, memory system having the same, and programming method of a memory cell|
|US20100246246 *||Sep 30, 2010||Ho-Jung Kim||Memory device, memory system having the same, and programming method of a memory cell|
|US20110010700 *||Jan 13, 2011||Lanner Mats E||Virtualization of configuration settings|
|US20110047536 *||Aug 24, 2009||Feb 24, 2011||Microsoft Corporation||Runtime activation and version selection|
|US20130185709 *||Jan 15, 2012||Jul 18, 2013||Microsoft Corporation||Installation engine and package format for parallelizable, reliable installations|
|WO2012119139A3 *||Mar 3, 2012||Jan 3, 2013||Microsoft Corporation||Application compatibility with library operating systems|
|U.S. Classification||719/331, 717/164|
|Aug 23, 2001||AS||Assignment|
Owner name: MICROSOFT CORPORATION, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GRIER, MICHAEL J.;FITZSIMONS, ROSEMARIE;D SOUZA, DAVID;AND OTHERS;REEL/FRAME:012107/0342;SIGNING DATES FROM 20010611 TO 20010621
|Mar 24, 2011||FPAY||Fee payment|
Year of fee payment: 4
|Dec 9, 2014||AS||Assignment|
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034541/0001
Effective date: 20141014
|Mar 25, 2015||FPAY||Fee payment|
Year of fee payment: 8