Abstract: 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).

Abstract: 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).

Abstract: A method for identifying duplicate machine code function implementations provides for identifying position-dependent bits within a first function included in a first executable image and masking the identified position-dependent bits to create a position-independent entity. The method further provides for applying a hashing function to the position-independent entity to generate a representative hash code and comparing the representative hash code to a number of hash codes in a table to identify at least one duplicate implementation of the function that is associated in memory with a second executable image.

Abstract: A method for identifying duplicate machine code function implementations provides for identifying position-dependent bits within a first function included in a first executable image and masking the identified position-dependent bits to create a position-independent entity. The method further provides for applying a hashing function to the position-independent entity to generate a representative hash code and comparing the representative hash code to a number of hash codes in a table to identify at least one duplicate implementation of the function that is associated in memory with a second executable image.

Abstract: 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.

Abstract: 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).

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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).

Abstract: 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).

Abstract: 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).

Abstract: The efficient use of type descriptors with frozen objects. A frozen object might actually include several type descriptors, a primary type descriptor that is canonical according to a set of canonicalization rules, and an auxiliary type descriptor that is not identical to the primary type descriptor. The auxiliary type descriptor may be used to access the canonical type descriptor. When performing an operation, if the auxiliary type descriptor can be used to perform the operation, then that auxiliary type descriptor may be used. If the canonical type descriptor is to be used to perform the operation, the auxiliary type descriptor is used to gain access to the canonical primary type descriptor. The primary type descriptor is then used to perform the operation.

Abstract: Mechanisms that allow frameworks significant flexibility in varying the library of common base classes in a manner that better suits the domain of applications served by the framework. Instead of providing the base class library, the runtime provides a data contract for the data structure of each base class. The frameworks can then define each base class in a custom way so long as the data contract is honored. Thus, for example, the framework may provide custom framework-specific methods and/or properties as is appropriate for the framework. Another framework might define the base classes in a different way.

Abstract: Authored code may include a notification that no tolerance for failure or corruption is expected for an identified sub-set of the code. Any potential failure point, which may be induced by a runtime environment routine or sub-routine, that is associated with the identified sub-set of code may then be identified and hoisted to a point apart from the identified sub-set of code.

Abstract: Mechanisms that allow frameworks significant flexibility in varying the library of common base classes in a manner that better suits the domain of applications served by the framework. Instead of providing the base class library, the runtime provides a data contract for the data structure of each base class. The frameworks can then define each base class in a custom way so long as the data contract is honored. Thus, for example, the framework may provide custom framework-specific methods and/or properties as is appropriate for the framework. Another framework might define the base classes in a different way.

Abstract: The efficient use of type descriptors with frozen objects. A frozen object might actually include several type descriptors, a primary type descriptor that is canonical according to a set of canonicalization rules, and an auxiliary type descriptor that is not identical to the primary type descriptor. The auxiliary type descriptor may be used to access the canonical type descriptor. When performing an operation, if the auxiliary type descriptor can be used to perform the operation, then that auxiliary type descriptor may be used. If the canonical type descriptor is to be used to perform the operation, the auxiliary type descriptor is used to gain access to the canonical primary type descriptor. The primary type descriptor is then used to perform the operation.

Abstract: Enabling secure and efficient marshaling, utilization, and releasing of handles in either of an operating system or runtime environment includes wrapping a handle with a counter to tabulate a number of threads using currently using the handle. Thus, handle administration is implemented to circumvent potential security risks, avoid correctness problems, and foster more efficient handle releasing.

Abstract: Reliability contracts declare an intent of executable code, and may be associated with at least a portion of the executable code. The intent of the executable code in the face of particular conditions may be declared for the use in any one of a programming, execution, or testing environment.

Abstract: Authored code may include a notification that no tolerance for failure or corruption is expected for an identified sub-set of the code. Any potential failure point, which may be induced by a runtime environment routine or sub-routine, that is associated with the identified sub-set of code may then be identified and hoisted to a point apart from the identified sub-set of code.