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

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

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

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

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: Interface identifier parameterization techniques are described. In one or more implementations, a textual description is obtained of a parametric type represented in a binary standard of a programming model and an interface identifier is generated based at least in part on the obtained textual description of the parametric type.

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

Abstract: Described herein are one or more implementations offering a centralized (e.g., single-point) user-interface, where a user may manipulate audio properties (e.g., volume level) for one or more audio submixes produced by each of multiple active operating-system processes.

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

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: Interface identifier parameterization techniques are described. In one or more implementations, a textual description is obtained of a parametric type represented in a binary standard of a programming model and an interface identifier is generated based at least in part on the obtained textual description of the parametric type.

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: A method and system is provided for tolerating component failure in a continuous media server system. The present invention guarantees data streams at a constant rate to subscribers for the data streams even when at least one component fails. The present invention is able to guarantee data streams at a constant rate by utilizing declustered mirroring and by reserving bandwidth for both normal mode processing and failure mode processing. The declustered mirroring of the present invention is performed by dividing the data to be stored in the continuous media server system into blocks. The blocks are then striped across the storage devices of the continuous media server system and each block is divided into a number of sub-blocks. The sub-blocks are in turn stored on separate storage devices. The present invention reserves bandwidth for both normal mode processing and failure mode processing.