Microsoft Technology Licensing, LLC

Elliot H Omiya

Martyn S Lovell

Mahesh Prakriya

Stephen C Rowe

Tassaduq Basu

Lawrence William Osterman

Wei Zeng

Robert Albert Wlodarczyk

Michael Aksionkin

Shakeel Solkar

Harold L Pierson, Iii

Neeraj Wadhwa

Jerry Jay Dunietz

Ales Holecek

Brent Rector

Noel Richard Cross

Christopher Douglas Edmonds

Patrick Henri Dussud

Steven E Lucco

Michael C Fanning

Raja Krishnaswamy

C Douglas Hodges

Timothy Scott Rice

Felix Gerard Torquil Ifor Andrew

Andrew R Sterland

Simon Calvert

Gregg Bernard Miskelly

Frank Dominic Yerrace

James F Springfield

Robert Alan Paveza

Daniel James Moseley

Daniel J Sisolak

Francisco Javier Wong

Jeffrey T Fisher

Taylor C Woll

Karthik Vivek Nadig

Harold Pierson

Zhaochuan Gao

Andriy Stasyuk

Li Zhang

John Michael Sheehan

Patrick Markus Baudisch

Steven J Ball

Stephen Harry Wright

Brian Robert Crawford

Christopher Scott Dickens

Daniel Oliver

Andrew Clinick

Scott E Dart

Mikhail Arkhipov

Benjamin Betz

Rodger William Benson

Albert Peter Hwang

John Joseph Rivard

Scott Robert Honji

Thomas E Quinn

Timothy R Sullivan

Harley Michael Rosnow

Eric Hyde Carter

Izydor Gryko

Mitchell K Rundle

Xin Gong

Joshua I Kaplan

Cheng-mean Liu

Michael Eng

Jason R Olson

Annette Marie Crowley

Matthew Merry

Ian H Kim

Adeel A Aslam

Stephen Smith

Todd Jefferson

Michal Sampson

Adam Krantz

Timothy Michael Mc Bride

Tassaduq H Basu

Steven Edward Lucco

Brent E Rector

Lawrence W Osterman

Harold L Iii Pierson

Gregg Miskelly

A method for diagnosing computer readable instructions related to transfers of control is disclosed. A state transition of a unit of execution within a logical operation providing an event handler for a Document Object Model is logged during runtime of the computer readable instructions. Diagnostic information of the logical operation is associated with the state transition. The state transition and associated diagnostic information is provided for retrieval at a selected point in the computer readable instructions.

Diagnostics of state transitions

A computer system supports a protocol to process directional navigation inputs to a host application and its component, to manage which component is currently active to receive input events. A first component determines whether to transfer focus to a second component. The first component initiates the transfer by sending a request to the second component. Further input events are queued. The second component processes the request to determine how to transfer focus within the second component. The second component indicates to the operating system how focus has been transferred. The operating system updates information to reflect the changes in state of the components, and informs the host and component that the state has been updated. Queued input events then can be released for processing according to the changed focus. Where the components are separate, independent processes, the protocol can be implemented through inter-process communication techniques.

Processing non-spatial input by multiple program elements of a computer program executed on a computer

A method for diagnosing computer readable instructions related to transfers of control is disclosed. A state transition of a unit of execution within a logical operation is logged during runtime of the computer readable instructions. Diagnostic information of the logical operation is associated with the state transition. The state transition and associated diagnostic information is provided for retrieval at a selected point in the computer readable instructions.

Various embodiments provide an ability to describe, independent of a programming language, one or more interfaces associated with an operating system. Alternately or additionally, a compiler associated with a specific programming language can be configured to map the independent interface description(s) to the specific programming language. In some embodiments, an application can be configured to programmatically determine one or more interfaces of the operating system.

Runtime system

Information about the operating system application programming interfaces is stored in a known format in a known location. This information fully describes the APIs exposed by the operating system and is stored in API metadata files. A language compiler or interpreter uses this API information to build a natural and familiar representation of the native system API in the target language. The language compiler or interpreter can read the API information at compile time and/or runtime. The metadata is used to allow an application to refer to named elements in the API. Projections are built that use the metadata to map named elements in the API to named elements in the target language, and to define wrappers that marshal data of those elements between the target representation and the native operating system representation.

Projecting native application programming interfaces of an operating system into other programming languages

Techniques for modes for applications are described. In one or more implementations, multiple operational modes are provided for an application. The operational modes can be associated with different resource access permissions, trust statuses, graphical user interfaces, and so on. An application can be launched in a particular one of the operational modes based on a context in which a request to launch the application is received. In one or more implementations, correlations between launch request contexts for an application and operational modes can be configured to enable different launch requests to cause an application to launch into different operational modes.

Modes for applications

Various embodiments provide an ability to abstract type resolution between multiple type systems. At least one type can be described in one or more programmatically accessible file(s). In some embodiments, an application using a different type system can programmatically access and resolve a type of the at least one type system without knowledge of a location of where a description of the type resides. Alternately or additionally, type descriptions contained in the one or more programmatically accessible file(s) can be analyzed and restructured into one or more new programmatically accessible file(s) based, at least in part, upon the type descriptions.

Flexible metadata composition

The driving of an audio device that supports two or more audio modes is accomplished by associating a first physical device object of an audio device with a first device identifier, the first physical device object representing a first audio mode enumerated by a bus enumerator; associating a second physical device object of an audio device with a second device identifier, the second physical device object representing a second audio mode enumerated by the bus enumerator; and if the first device identifier matches the second device identifier, enabling a coupled kernel streaming audio interface compatible with both the first physical device object and the second physical device object.

Exposing multi-mode audio device as a single coherent audio device

An exemplary audio system includes an audio engine, one or more shared buffers where each shared buffer is associated with a client application and one or more lock-free mechanisms to help ensure that a write position of a shared buffer stays equal to or ahead of a read position for that shared buffer and to ensure that a client application's failure to maintain a write position equal to or ahead of a read position does not prevent audio engine access to the shared buffer. Other exemplary technologies are also disclosed.

Lock-free shared audio buffer

Various embodiments provide techniques for allowing an application to opt out of system default audio stream behavior, as well as techniques for notifying applications on a computing device that a communication audio stream has been initiated. The techniques may differentiate between communication-related audio streams and audio streams that are not communication-related. In some embodiments, an application may register to receive notification that a communication stream has been initiated. The application may be configured to comply with system default audio stream handling policies, or it can perform custom behavior in response to the audio stream notification. In some embodiments, an application may register for filtered or unfiltered notification. In a filtered notification scenario, an application is notified that a communication stream has been initiated when an audio stream associated with the application has not already been modified in response to the initiation of a different communication stream. In an unfiltered notification scenario, an application/process is notified whenever a communication stream is been initiated.

Audio stream notification and processing

A volume control may be provided with some integrated graphical indication of the presence and/or level of an audio signal that it controls. For example, a slider-type volume control may be provided with a signal meter within the slider itself. A volume control may be provided with a mechanism for showing the non-mute volume control level of a volume when the volume control is muted. For example, a slider-type volume control may display a ghosted slider tab at the level of volume control in effect before muting while at the same time displaying a regular slider tab at a muted level. A user may be able to glance at a volume control and quickly and intuitively understand aspects of the volume control's state such as the level and condition of the signal that is flowing through or blocked by (if muted) the control.

Volume control

Growing community of inventors

Kirkland, WA, United States of America

Elliot H Omiya