Microsoft Technology Licensing, LLC

Microsoft Corporation

Brian M Grunkemeyer

Christopher Wellington Brumme

Sean Edwin Trowbridge

Gopala Krishna R Kakivaya

Lance Olson

Henry L Sanders

Jonathan C Hawkins

Anthony J Moore

Michael M Magruder

James S Miller

Krzysztof J Cwalina

Mahesh Prakriya

David S Mortenson

Ramasamy Krishnaswamy

Erik B Christensen

Anders Hejlsberg

Raja Krishnaswamy

David Bau

Brian LaMacchia

David S Ebbo

Julie D Bennett

Travis Muhlestein

Seth Mitchell Demsey

Stefan Harrington Pharies

Shawn Patrick Burke

Christopher L Anderson

Loren Kohnfelder

Yung-Shin Lin

Erik B Olson

Yann Christensen

Jeffrey M Cooperstein

Fabio A Yeon

James H Hogg

Craig T Sinclair

Corina Eva Feuerstein

Adam Wade Smith

Caleb L Doise

Alan Geoffrey Boshier

Shajan Dasan

Manish S Prabhu

Radu Rares Palanca

John I McConnell

Tarun Anand

Suzanne Maurine Cook

Joseph L Roxe

Hany E Ramadan

Jesus Ruiz-Scougall

Joe Dennis Long

Jayanth V Rajan

Daniel Takacs

David L Detlefs

John Joseph Duffy

Vance Palmer Morrison

Gregory Darrell Fee

David S Callahan

Eric Dean Tribble

Rudi Martin

David Owen Driver

WeiWen Liu

Patrick Henri Dussud

Dmitry Robsman

Manuel Alfred Fahndrich

Michael Barnett

Ian H Carmichael

Stephen Harris Toub

Michael C Fanning

Yan Valerie Leshinsky

Stephen James Millet

Giovanni Moises Della-Libera

Nikhil Kothari

Wolfram Schulte

Scott David Guthrie

Luca Bolognese

Keith W Ballinger

Brian Keith Pepin

Alessandro Catorcini

Mark T Anders

Jun Fang

Susan M Warren

Jesse Daniel Kaplan

Manu Vasandani

Robert Michael Howard

Barend Hermanus Venter

Nicholas M Kramer

Brent Rector

Chad W Royal

Mark W Fussell

Mark A Boulter

Kumar Gaurav Khanna

Omri Gazitt

Sreeram Nivarthi

Andrew J Pardoe

Nithyalakshmi Sampathkumar

Neetu Rajpal

Daniel Dedu-Constantin

Joe Duffy

Blaine J Dockter

Ryan A Byington

Brandon Scott Wadsworth

William A Adams

A cancelation registry provides a cancelation interface whose implementation registers cancelable items such as synchronous operations, asynchronous operations, type instances, and transactions. Items may be implicitly or explicitly registered with the cancelation registry. A consistent cancelation interface unifies cancelation management for heterogeneous items, and allows cancelation of a group of items with a single invocation of a cancel-registered-items procedure.

Unified and extensible asynchronous and synchronous cancelation

An error handling system is described herein that provides a facility for controlling the behavior of software when the software violates a contract condition. The system provides configurable runtime behavior that takes place when a contract fails. The error handling system provides an event that a hosting application or other software code can register to handle and that the system invokes upon detecting a contract failure. The application's response to the event determines how the system handles the failure. If the event is unhandled, the system triggers an escalation policy that allows an administrator or application to specify how the system handles contract failures. Thus, the error handling system provides increased control over the handling of contract failures within software code.

Contract failure behavior with escalation policy

An assembly aggregate comprising a virtual, logical view of an arbitrarily defined collection of intermediate code and metadata can be authored, factored, accessed, modified, and distributed. Multiple physical containers of assembly information can be aggregated to create a single logical assembly called an assembly aggregate. An assembly can thus be redefined as a logical view against (or projection over) the assembly aggregate. Such an assembly can be targeted to the requester: that is, an assembly can be redefined according to tool and/or execution context rather than conforming to explicit or implicit requirements enforced by the runtime.

Logical extensions to intermediate code

Various technologies and techniques are disclosed for providing concurrent exception handling. When one or more exceptions are received from concurrent workers, one or more exception handler functions are supplied. For each respective exception in the exception results, determine if the respective exception is one of a kind of exceptions handled by the one or more exception handler functions. If the respective exception is one of a kind handled by the exception handler functions, then run a particular handler of the exception handler functions and mark the respective exception as handled. Any unhandled exceptions are then processed appropriately. In one implementation, a collection of input data is processed to produce a collection of output results, with the exceptions being interleaved with other output results. In another implementation, a particular exception is selected that represents the multiple exceptions. The selected one particular exception is then thrown.

Concurrent handling of exceptions in received aggregate exception structure with supplied exception handlers and marking handled exceptions

In one embodiment, a computer system provides an application programming interface (API) for augmenting an application API. A computer system receives software code written in a second programming language indicating a user's intention to augment an application API with contracts from a contract API written in a first programming language. The software code includes a reference to the contract API. The contracts include assertions indicating appropriate use of the application API. The computer system accesses portions of the contract API according to the reference in the software code and compiles the received software code and the referenced portions of the contract API into an intermediate language (IL) version of the software code. The IL version is in an intermediate language common to both the first programming language and the second programming language. The IL version includes the assertions indicating appropriate use of the application API.

Contract programming for code error reduction

Various technologies and techniques are disclosed for providing concurrent exception handling. Exceptions that occur in concurrent workers are caught. The caught exceptions are then forwarded from the concurrent workers to a coordination worker. The caught exceptions are finally aggregated into an aggregation structure, such as an aggregate exception object. This aggregation structure is rethrown and the individual caught exceptions may then be handled at a proper time.

Concurrent exception handling using an aggregated exception structure

A method and system for implementing a safe buffer is described herein. The method includes implementing a buffer class that ensures that accesses to memory are performed in a safe manner. The buffer class may be a handle to protected resources in memory. The buffer class may exploit methods to read and write to memory that ensures that read and writes are performed to valid memory locations within buffer bounds.

Safe buffer

Various technologies and techniques are disclosed for providing a numeric tower that represents a structure supporting statically defined numeric data types. The numeric data types each are operable to implement a different but accurate representation of a particular value. Numeric operations are supported for the numeric tower that can be performed with any of the statically defined numeric data types. The numeric tower is extensible, and allows for additional statically defined numeric data types to be added, as well as operations. The numeric tower is also operable to detect overflow situations. For example, suppose a result of an operation will result in an overflow situation because the operation does not fit within a range supported by the particular numeric type. The system converts the numeric type to a different one of the numeric data types when the result does not fit within a range supported by the first one.

Tower of numeric types

Throwing one selected representative exception among aggregated multiple exceptions of same root cause received from concurrent tasks and discarding the rest

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.

Constrained execution regions

The exposure and usage of one or more particular physical and logical resources by methods within an isolation boundary may be annotated so as to preempt resource usage conflicts. Further described are tools, contracts, and collaborative processes for at least identifying potential resource usage conflicts. More particularly, the example tools, contracts, and collaborative processes may be used to annotate at least one of exposure and consumption of one or more particular physical and logical resources by methods within an isolation boundary.

Resource usage conflict identifier

A finalizer may include a notification that no tolerance for failure or corruption is expected. Any potential failure point, which may be induced by a runtime execution environment routine or subroutine that is associated with the finalizer may then be prepared apart from the finalizer.

Critical finalizers

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.

Safe handle

An application program interface (API) provides a set of functions for application developers who build Web applications on Microsoft Corporation's .NET&#x2122; platform.

Computing system and method for allowing plurality of applications written in different programming languages to communicate and request resources or services via a common language runtime layer

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.

Reliability contracts

Growing community of inventors

Issaquah, WA, United States of America

Brian M Grunkemeyer