Abstract: A client is able to decompress an internal portion of a compressed file on a server without having to download and decompress the part of the compressed file that precedes the internal portion. Initially, when the file is compressed, the state of the compressor, e.g., a dictionary, is periodically captured and stored in association with positions in the compressed file. A server stores the compressor states and positions in association with the compressed file. The client identifies the internal section of the compressed file to the server. The server selects a compressor state whose position is closest to the internal section. The server sends the client the selected compressor state and the internal portion of the compressed file. The client primes a decompressor with the sent compressor state, and the primed decompressor then decompresses the internal portion of the compressed file.

Abstract: Embodiments are directed towards managing memory for an application be executing in a managed runtime environment. Managed peer objects may be generated to correspond to native objects executing in a native runtime environment such that memory may be allocated for managed peer objects. Garbage collection handles may be generated and associated with the managed peer objects. If the managed application executes instructions that interact with the managed peer objects and the native runtime environment each garbage collection handle associated with the managed peer objects may be modified based on a type of an interaction. The garbage collection handlers may be garbage collection roots for a garbage collector that may be included in the managed runtime memory manager. If a garbage collection event occurs, memory for the managed peer objects may be deallocated based in part on its correspondent garbage collection handle.

Abstract: Embodiments are directed towards generating applications that include multi-sized types running in managed code. During the compilation of an intermediate language version of an application, if a multi-size type is encountered, a runtime engine may perform actions to process the multi-size types. Accordingly, architecture information associated with the target computer may be determined. Data types corresponding to the architecture of the target computer and the multi-sized types may be determined based on the architecture information. Native code calls associated with an intermediate language code calls may be determined such that the parameters of the native code calls match the architecture dependent data types. And, a machine code version of the intermediate language code call may be generated. The generated machine code version of the intermediate language code may be executed with the data types specific to the target computer.

Abstract: Embodiments are directed towards generating applications that include multi-sized types running in managed code. During the compilation of an intermediate language version of an application, if a multi-size type is encountered, a runtime engine may perform actions to process the multi-size types. Accordingly, architecture information associated with the target computer may be determined. Data types corresponding to the architecture of the target computer and the multi-sized types may be determined based on the architecture information. Native code calls associated with an intermediate language code calls may be determined such that the parameters of the native code calls match the architecture dependent data types. And, a machine code version of the intermediate language code call may be generated. The generated machine code version of the intermediate language code may be executed with the data types specific to the target computer.

Abstract: Embodiments are directed towards managing memory for an application be executing in a managed runtime environment. Managed peer objects may be generated to correspond to native objects executing in a native runtime environment such that memory may be allocated for managed peer objects. Garbage collection handles may be generated and associated with the managed peer objects. If the managed application executes instructions that interact with the managed peer objects and the native runtime environment each garbage collection handle associated with the managed peer objects may be modified based on a type of an interaction. The garbage collection handlers may be garbage collection roots for a garbage collector that may be included in the managed runtime memory manager. If a garbage collection event occurs, memory for the managed peer objects may be deallocated based in part on its correspondent garbage collection handle.

Abstract: Embodiments are directed towards generating applications that include multi-sized types running in managed code. During the compilation of an intermediate language version of an application, if a multi-size type is encountered, a runtime engine may perform actions to process the multi-size types. Accordingly, architecture information associated with the target computer may be determined. Data types corresponding to the architecture of the target computer and the multi-sized types may be determined based on the architecture information. Native code calls associated with an intermediate language code calls may be determined such that the parameters of the native code calls match the architecture dependent data types. And, a machine code version of the intermediate language code call may be generated. The generated machine code version of the intermediate language code may be executed with the data types specific to the target computer.

Abstract: Embodiments are directed towards garbage collection for an application running on a non-cooperative target platform. Where the garbage collection optimistically manages thread state for transitions to and from native and managed code and that some threads are suspended while others are left executing during garbage collection. When a characteristic of the native code call indicates that a duration of the native code call may exceed a defined duration, state information for the thread may be updated to transition the thread to the unmanaged code environment. When a garbage collection event occurs, thread state information is updated to communicate suspend requests to the threads. Then the runtime may wait for each thread in the managed code environment to be reach a safe state before garbage collection may commence.

Abstract: Embodiments are directed towards garbage collection for an application running on a non-cooperative target platform. Where the garbage collection optimistically manages thread state for transitions to and from native and managed code and that some threads are suspended while others are left executing during garbage collection. When a characteristic of the native code call indicates that a duration of the native code call may exceed a defined duration, state information for the thread may be updated to transition the thread to the unmanaged code environment. When a garbage collection event occurs, thread state information is updated to communicate suspend requests to the threads. Then the runtime may wait for each thread in the managed code environment to be reach a safe state before garbage collection may commence.

Abstract: Embodiments are directed towards managing memory for an application be executing in a managed runtime environment. Managed peer objects may be generated to correspond to native objects executing in a native runtime environment such that memory may be allocated for managed peer objects. Garbage collection handles may be generated and associated with the managed peer objects. If the managed application executes instructions that interact with the managed peer objects and the native runtime environment each garbage collection handle associated with the managed peer objects may be modified based on a type of an interaction. The garbage collection handlers may be garbage collection roots for a garbage collector that may be included in the managed runtime memory manager. If a garbage collection event occurs, memory for the managed peer objects may be deallocated based in part on its correspondent garbage collection handle.

Abstract: Embodiments are directed towards managing generic objects across multiple runtime environments. If a generic type definition is encountered during compilation of an application it may be determined if the encountered generic type has interactions with the native runtime environment. Native runtime signatures that may be arranged to enable native objects to execute the generic type methods may be generated for each generic type methods that interact with the native runtime. Binding layer machine code may be generated to map each native runtime signature to a corresponding generic type method. And, in at least one of the various embodiments, the binding layer machine code may be inserted into the machine code version of the application.

Abstract: Embodiments are directed towards generating applications that include multi-sized types running in managed code. During the compilation of an intermediate language version of an application, if a multi-size type is encountered, a runtime engine may perform actions to process the multi-size types. Accordingly, architecture information associated with the target computer may be determined. Data types corresponding to the architecture of the target computer and the multi-sized types may be determined based on the architecture information. Native code calls associated with an intermediate language code calls may be determined such that the parameters of the native code calls match the architecture dependent data types. And, a machine code version of the intermediate language code call may be generated. The generated machine code version of the intermediate language code may be executed with the data types specific to the target computer.

Abstract: Embodiments are directed towards garbage collection for an application running on a non-cooperative target platform. Where the garbage collection optimistically manages thread state for transitions to and from native and managed code and that some threads are suspended while others are left executing during garbage collection. When a characteristic of the native code call indicates that a duration of the native code call may exceed a defined duration, state information for the thread may be updated to transition the thread to the unmanaged code environment. When a garbage collection event occurs, thread state information is updated to communicate suspend requests to the threads. Then the runtime may wait for each thread in the managed code environment to be reach a safe state before garbage collection may commence.

Abstract: A system and method for registering one or more services at a location where clients can access the services both locally and remotely is provided. A HyperText Transfer Protocol (HTTP) service multiplexer (HSM) may be accessed at a recognizable location, which may be any suitable location or resource that a client can locate on a local system. The HSM may make a plurality of services available at the recognizable location by binding the location (e.g., a Uniform Resource Identifier (URI)) to URLs or other resources associated with the services. In this manner, the HSM functions similarly to a domain name service, as HTTP redirections can be issued to enable a single well-known resource to be used for accessing the plurality of registered services.

Abstract: A system and method for inspecting a virtual appliance runtime environment is provided. In particular, runtime activity within a virtual machine may be monitored and tracked to manage a file system associated with the runtime activity. For example, a new image having a pointer to a base image being executed may be created, wherein the new image may be empty when created, and wherein data may be written to the new image in response to any files being created, deleted, modified, or otherwise accessed during execution of the base image within the virtual machine. Thus, a file system for the new image may be compared to a file system for the base image to analyze the runtime activity for the base image, wherein the new image may preserve runtime changes to the file system and provide visibility into particular runtime modifications to the file system.

Abstract: A system and method for inspecting a virtual appliance runtime environment is provided. In particular, runtime activity within a virtual machine may be monitored and tracked to manage a file system associated with the runtime activity. For example, a new image having a pointer to a base image being executed may be created, wherein the new image may be empty when created, and wherein data may be written to the new image in response to any files being created, deleted, modified, or otherwise accessed during execution of the base image within the virtual machine. Thus, a file system for the new image may be compared to a file system for the base image to analyze the runtime activity for the base image, wherein the new image may preserve runtime changes to the file system and provide visibility into particular runtime modifications to the file system.

Abstract: A system and method for registering one or more services at a location where clients can access the services both locally and remotely is provided. A HyperText Transfer Protocol (HTTP) service multiplexer (HSM) may be accessed at a recognizable location, which may be any suitable location or resource that a client can locate on a local system. The HSM may make a plurality of services available at the recognizable location by binding the location (e.g., a Uniform Resource Identifier (URI)) to URLs or other resources associated with the services. In this manner, the HSM functions similarly to a domain name service, as HTTP redirections can be issued to enable a single well-known resource to be used for accessing the plurality of registered services.