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

Abstract: Native operating system application programming interfaces (API's) are described using metadata and such descriptions are stored in a standard file format in a known location. By storing API definitions using such metadata, other applications can readily identify and use the APIs. To create such API representations, during development, a developer describes the shape of the API, including (but not limited to) the classes, interfaces, methods, properties, events, parameters, structures and enumerated types defined by the API. This API description is processed by a tool which generates a machine-readable metadata file. The machine-readable metadata file contains the same information as the API description, however in a format designed to be machine read rather than human authored.

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

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

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

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

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

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

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

Abstract: A source code editor is used to develop multilanguage documents while providing the advanced editing functionality of secondary editors and without requiring the programmer to explicitly open and interface with the secondary editors. The multilanguage document is presented to the user in a primary application view of the primary editor. Code segments written in different languages are identified and sent to the appropriate secondary editors, which in turn create secondary documents that are transparent to the programmer. As edits are made to the primary application view of the document, the edits are replicated by the secondary editors behind the scene. Functionality that is enabled by the secondary editors, such as syntax coloring, auto-completion, and validation is identified by the primary editor and replicated in the primary application view, so as to appear as if the primary editor is inherently configured with the leveraged functionality of the secondary editors.