Microsoft Technology Licensing, LLC

Mircea Trofin

David Charles Wrighton

Michal Strehovsky

Patrick Henri Dussud

Krzysztof J Cwalina

John Lawrence Hamby

Fadi M Hanna

Atsushi Kanamori

Rudi Martin

Morgan Asher Brown

David M Kean

Turgut Isik

Fatma Didem Gokbulut

Robert Yung-Yi Fu

John Joseph Duffy

Jobst-Immo Landwerth

Wes Haggard

Clemens Alden Szyperski

Oleg G Lvovitch

Blake W Stone

Alex Bulankou

The present invention extends to methods, systems, and computer program products for controlling runtime access to application programming interfaces Embodiments of the invention allow library developers to more precisely and easily control which of their libraries' APIs can be called dynamically. Thus, their servicing and versioning burden can be more appropriately controlled. Further, application developers can control which such APIs to further exclude from dynamic calling scenarios, to minimize the runtime support overhead (e.g., preventing generation of metadata).

Controlling runtime access to application program interfaces

Platform-agnostic source code can be augmented with one or more portions of source code annotated for different platforms and/or versions. The source code including both the platform-agnostic and platform-specific and/or version-specific portions can be compiled once to create a single executable that can be distributed to and can run on multiple device platforms and/or multiple versions of one or more platforms. Platform-specific or version-specific executables (e.g., assemblies, binaries, etc.) can be embedded into a binary or executable as resources (e.g., data). When the compiled code is executed on a device, the runtime can extract the platform-specific portion corresponding to the device on which the executable is being run, can bind the extracted portion to the executable and can load and execute the executable. Hence the same binary can produce different results or functionalities depending on the capabilities of the platform on which the binary runs.

Adaptive portable libraries

Support for dynamic behavior is specified while reducing reliance on JIT compilation and large runtimes; semantic characteristics are selectively attached to types and type members outside source code. A directives document contains human-readable directives in a parsable format for submission to an innovative compiler. The directives specify whether a type T or type member M is required, optional, or prohibited in a runtime environment. Some reference an application, library, assembly, or namespace group, and others reference group components: type, type instantiation, method, method instantiation, field, property, or event. Some directives force a generic instantiation. Some directives indirectly reference a type through a parameter, type parameter, or generic directive. Some directives reference degrees to manage runtime activation of type instances, runtime introspection over types, reflection, and/or runtime or static serialization. Degrees may enable or disable types, instance constructors, property setters, property getters, fields, or all type members. Directives may be composed.

Hierarchical directives-based management of runtime behaviors

API (application program interface) features defined by a set of APIs provide a different cross-sectional view of an application or framework than the view provided by sectioning along class or library boundaries, or binding units, for example. An API feature includes a proper subset of a library of a framework used by an application, and/or APIs which collectively reside in different libraries. A functionality feature API set provides an exposed surface area of a functionality feature of an application. Upon receiving a compilation request and determining that an API feature is to be excluded, an attempt is made to produce a compiled version of the application without the feature's APIs. In some cases, the functionality feature is independent of a baseline functionality of the application. Developers can obtain smaller but fully functional binaries. Framework architects can identify dependencies between API implementations when creating or modifying a software framework's architecture.

Cross-library framework architecture feature sets

Support for dynamic behavior is provided during static compilation while reducing reliance on JIT compilation and large runtimes. A mapping is created between metadata and native code runtime artifacts, such as between type definition metadata and a runtime type description, or between method definition metadata, a runtime type description, and a native code method location, or field definition metadata, a runtime type description, and a field location. A mapping between runtime artifacts may also be created. Some compilation results include trampoline code to support a reflection invocation of an artifact in the reduced runtime support environment, for virtual method calls, call-time bounds checking, calling convention conversion, or compiler-intrinsic methods. Some results support runtime diagnostics by including certain metadata even when full dynamic behavior is not supported.

Supporting dynamic behavior in statically compiled programs

The subject disclosure relates to enabling the evolution of a framework by providing public surface area factorings for both old and new public surface areas. The factoring can mitigate changes in the implementation of existing distributions of framework. The factoring can also mitigate breaking existing binaries. Further, the factoring can be provided while mitigating a degradation in the security guarantees of the linking model. The factorings can be applied for runtime and/or for a development toolkit. Thus, multiple, almost simultaneous, interoperable views of a framework implementation can be enabled at runtime and/or at design or build time. The views can represent different versions of the framework.

Mechanism for compatibility and preserving framework refactoring

Controlling runtime access to application programming interfaces

A framework for open, dynamic, and reflective applications contains high level metadata that define blocks of composable elements using a service definition, which defines specific keys for using the block of code. The service definition may be exported from the code using reflection without having to load the code into memory, and decisions on which block of code and how to load the code may be made at runtime. The composable elements may be grouped into composable parts. Composable part definitions may be used to instantiate or produce composable parts. At runtime, dynamic applications may search from many composable elements, and instantiate and execute the composable element as part of the application.

Framework for open dynamic reflective applications

Different views on an object that has metadata. For instance, one code segment might have one view of the object and be able to view some of the metadata of that object, while another code segment might have a different view of the object and have a view on a different set of the metadata of that object. This may be done even though the code segments reside in the same application. Thus, each code segment may have a view of the metadata on the object that is most useful for that code segment to use the object without getting confused by metadata that is less or not relevant to the manner in which the code segment is to use the object.

Growing community of inventors

Sammamish, WA, United States of America

Mircea Trofin