Abstract: Systems and methods for managing the lifecycle of an API over a number of different versions of an operating system—as well as over a number of different platforms are disclosed. In one embodiment, a method is disclosed wherein for a given API, metadata is created and associated with certain constructs of the API. The metadata may comprise a version indication. A set of versioning rules may be defined. Such versioning rules govern whether a particular construct of an API may be changed for a given version. These versioning rules may be enforced at the time of constructing a new build. The versioning rules may be enforced by the IDE system.

Abstract: In one embodiment, a unified pointer message 300 may describe in a single type of pointer message a coordinate input from a user via multiple types of pointer devices. An input device interface 150 may receive a coordinate input 350 from an input device. A processor 120 may execute an application programming interface layer 430 that creates a unified pointer message 300 for the coordinate input 350. The processor 120 may send the unified pointer message 300 to an application. The processor 120 may process a device specific data set 244 unhandled by the application.

Abstract: Systems and methods of pre-fetching data for applications in a computer system that are terminated or suspended and may be pre-launched by the computer system are disclosed. The applications may employ data that is remote from the computer system and available from a third party content resource. A method for pre-fetching such remote data comprises associating a set of application with such data and/or its location; determining a set of pre-fetching conditions, determining which applications may be pre-fetched and pre-fetching the data, if pre-fetch conditions meet a desired pre-fetch policy. A predictive module or technique may be used to identify those applications which may be pre-launched. The present system may comprise a pre-fetch success module capable of measuring the success data for a current pre-fetch and associating such success data with an application to improve future pre-fetches.

Abstract: Systems and methods for managing the lifecycle of an API over a number of different versions of an operating system—as well as over a number of different platforms are disclosed. In one embodiment, a method is disclosed wherein for a given API, metadata is created and associated with certain constructs of the API. The metadata may comprise a version indication. A set of versioning rules may be defined. Such versioning rules govern whether a particular construct of an API may be changed for a given version. These versioning rules may be enforced at the time of constructing a new build. The versioning rules may be enforced by the IDE system.

Abstract: In one embodiment, a unified pointer message 300 may describe in a single type of pointer message a coordinate input from a user via multiple types of pointer devices. An input device interface 150 may receive a coordinate input 350 from an input device. A processor 120 may execute an application programming interface layer 430 that creates a unified pointer message 300 for the coordinate input 350. The processor 120 may send the unified pointer message 300 to an application. The processor 120 may process a device specific data set 244 unhandled by the application.

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: A presence tracking architecture for datagram-based protocols. A client application seeking to know the presence or lack thereof of a device and/or service utilizes a standard protocol in a non-intuitive way to trigger notification of the device and/or service before any associated timeout expires. At first presence, a multicast message is broadcast to notify all devices. Subsequently, on-demand notification may be requested by a client application by sending directly (e.g., in unicast) to the device before its timeout has expired a message that is normally only sent in multicast. If capable, the device can then respond normally with a unicast message indicating it is on-line. If the response is not received, the device and/or service is determined to be off-line.