Microsoft Technology Licensing, LLC

Scott M Louvau

Michael C Fanning

Christopher M Faucon

Dmitri A Klementiev

Eric I Maino

Ryan J Cavanaugh

Kristopher Makey

Xuechun Li

Compression of data that permits direct reconstruction of arbitrary portions of the uncompressed data. Also, the direct reconstruction of arbitrary portions of the uncompressed data. Conventional compression is done such that decompression has to begin either at the very beginning of the data, or at particular intervals (e.g., at block boundaries&#x2014;every 64 kilobytes) within the data. However, the principles described herein permit decompression to begin at any point within the compressed data, without having to decompress any prior portion of the file. Thus, the principles described herein permit random access of the compressed data. In accordance with the principles described herein, this is accomplished by using an index that correlates positions within the uncompressed data with positions within the compressed data.

Compression/decompression using index correlating uncompressed/compressed content

Partial initial construction of a deferred object model. This is done using a map that correlates positions of a hierarchically structured definition and corresponding hierarchical positions within an object model. The map is accessed and used to initially construct a deferred object model that even leaves some of the deferred objects unpopulated. The map is used to determine which parts of the hierarchical object definition no longer need to be parsed in order to construct this initial form of the deferred object model. If a request for an object is detected at some point after the initial construction, and that requested object is not represented even in deferred form in the deferred object model, the system uses the map to find the position of the corresponding object definition in the hierarchical object definition. At that point, the system parses that position, and constructs the object.

Initial loading of partial deferred object model

A data structure that includes border data structures that appear at the respective interfaces between each of at least some of the segments in the data structure. The border does not conform to a data format for any of the elemental data types of the elemental data items represented within the data structure, and does not represent a size of any of the neighboring segments. Second, the data structure also includes an index. When writing the data structure, the writer tracks the position of each of the regions. When all segments and regions have been written, the writer can then write an index that represents the position of each region. The reader can then use that index to quickly read from only those regions of interest, and quickly skip over regions not of interest.

Using border data structure with index

Aspects of the subject matter described herein relate to searching. In aspects, a software package may be received and transformed into searchable data. Static and dynamic analysis may be performed on code and data included in the software package. A data structure is created that may index the code, metadata, indexable resources, and analysis artifacts associated with the software package. The data structure may be used to satisfy queries and the transformed data and analysis artifacts may be made available for viewing.

Integrating search with application analysis

Aspects of the subject matter described herein relate to grid queries. In aspects, a client sends search criteria that represent two or more dimensions to a service. The service obtains results that satisfy the search criteria and performs intersection operations to populate a data grid. The data grid is then returned to the client for output on an output device of the client. The client may provide a user interface that allows quick updating of the search criteria to obtain a new data grid.

Grid queries

A generated object model engine abstracts actions, used in test cases, in a manner to produce new object model types that are independent of an underlying code implementation. The generated object model engine analyzes action classes to aggregate a set of actions having similarly-related class types. Action classes having similarly-related class types are then used to form a new object model type. The new object model type may be used in a test case to hide the action's code implementation from the test case.

Generated object model for test automation

A test case can be run with actions from the test case being executed in multiple execution paths. This can be done with the aid of an action broker. For example, the broker may identify available automation implementations for the actions and use a priority list to select between available automation implementations for executing an action from the test case. The broker may also perform conversions of results of actions for use by implementations executing other actions in different execution paths, as well as passing results between implementations in different execution paths.

Growing community of inventors

Redmond, WA, United States of America

Scott M Louvau