Microsoft Technology Licensing, LLC

Michael H Krause

Chaitanya Dev Sareen

Miron Vranjes

Christopher Doan

Zinaida A Pozen

Benjamin Salim Srour

Yaou Wei

Haseeb Ahmed

Jesse Clay Satterfield

Robert J Jarrett

Arun Upadhyaya Kishan

Hari R Pulapaka

Nils Anders Sundelin

Matthew Isaac Worley

Jeremy Monroe Bowen

Mohammed Samji

Song Zou

David Bradley Probert, Jr

Alex G Snitkovskiy

Corneliu I Lupu

Yi Meng

Stephan Doll

Vamshidhar Radha Kommineni

Richard K Neves

Gerald Francis Maffeo

William Hunter Hudson

Zachary Grant Herman

Anshul Rawat

Tyler Joseph Donahue

Matthew Robert Ayers

Yau Ning Chin

Hui Huang

Phillip Feng Lu

Victoria Elizabeth Milton

Alex Bendetov

Steven Joseph Tricanowicz

Christopher Ronald Anthony

Zoran Dimov

Shrikesh Himanshu Tanna

Anand B Iyer

Yunfei Shang

Kumneger T Zelalem

Described herein are embodiments that relate to implementation of multi-stage gestures, using multi-stage gestures to control applications, and allowing, under certain conditions, invocation of an open operation (which would normally only open an application or bring an application to the fore) to cause a target application to terminate before being newly opened. A multi-stage gesture may be used to invoke different functions at respective gesture stages of a same input stroke. The functions may be different forms of application 'closing', such as backgrounding or suspending an application, terminating an application, and restarting an application. The restarting (including termination) of an application when the application is opened may be termed a 'smart-restart', which may involve interpreting from specific user activity that a user intends to restart an application.

Closing, starting, and restarting applications

Techniques for an experience mode transition are described. Generally, an experience mode refers to a visual and functional arrangement that is presented to a user of a device. Different experience modes present different visual and functional arrangements to a user. According to various embodiments, a computing device is configured to operate in multiple experience modes and may transition between different experience modes and based on a variety of different triggering events. Generally, a transition between different experience modes causes a visual and/or functional reconfiguration of a user experience on a device.

Experience mode transition

Cart mode provisioning of shared computing devices refers to provisioning or configuring the shared computing devices so that the shared computing devices operate in an appropriate mode for a particular shared usage environment. Such a shared usage environment can be, for example, a school environment in which the appropriate mode is a mode in which the shared computing devices are locked so that a limited number of programs and network accessibility is available to the shared computing devices. A user of a setup computing device selects some preferences regarding the setup of the shared computing devices, and a configuration package is generated that includes various configuration information based on the user selections. The configuration package is then made available to the shared computing devices, which are configured or provisioned in accordance with the configuration information.

Cart mode provisioning of shared computing devices

Techniques for configuring a user interface based on an experience mode transition are described. Generally, an experience mode refers to a visual and functional arrangement that is presented to a user of a device. Different experience modes present different visual and functional arrangements to a user. According to various embodiments, a computing device is configured to operate in multiple experience modes and may transition between different experience modes and based on a variety of different triggering events. Generally, a transition between different experience modes causes a visual and/or functional reconfiguration of a user experience on a device.

Configuring a user interface based on an experience mode transition

Only a particular number of applications on a computing device are active at any given time, with applications that are not active being suspended. A policy is applied to determine when an application is to be suspended. However, an operating system component can have a particular application be exempted from being suspended (e.g., due to an operation being performed by the application). Additionally, an operating system component can have an application that has been suspended resumed (e.g., due to a desire of another application to communicate with the suspended application).

Resuming applications and/or exempting applications from suspension

In accordance with one or more aspects, an application that is to be suspended on a computing device is identified based on a policy. The policy indicates that applications that are not being used are to be suspended. The application is automatically suspended, and is allowed to remain in memory but not execute while suspended. Additionally, when memory is to be freed one or more suspended applications to terminate are automatically selected based on the policy, and these one or more selected applications are terminated.

Policy based application suspension and termination

An application programming interface (API) that leverages operating system instrumentation to provide a chain of threads and processes may alleviate some debugging complications. Specifically, the chain may start with the first thread in the process that experienced the original failure and end with the last thread upon which the first thread directly or indirectly depends. The API may aid debugging efforts by classifying all threads related or dependent upon an original failed thread into specific categories of failures, requesting further information from the originating OS concerning specific failed threads, and using that information to debug the failed application or process more thoroughly.

Failed process reporting

In a computing device running multiple applications, a check is made as to whether a threshold value of multiple threshold values has been met. Each of the multiple threshold values is associated with a characteristic of one of the multiple applications or a characteristic of a resource of the computing device. If the threshold value has not been met, then the multiple applications are allowed to continue running on the computing device. However, if the threshold value has been met, then one or more of the multiple applications to shut down is selected based at least in part on the characteristic associated with the threshold value that has been met, and the selected application is shut down.

Application lifetime management

Modern application tracing techniques are described herein that enable dynamic logging of events declared in a static manifest. Various events for logging can be declared in a static manifest. The static manifest may then be compiled to translate the declared events into a library of corresponding functions that can be called by 'modern' applications written using dynamic code. Calls made to these functions from dynamic code are converted to corresponding static events and forwarded to existing tracing application programming interfaces (APIs) designed to handle logging of static events for 'legacy' applications that use compiled code. In this manner, static functions that are compatible with tracing APIs can be created and called dynamically from dynamic code. This can occur without requiring administrative rights to install the code and while preserving existing features for legacy applications, such that a tracing log can include events from both modern applications and legacy applications.

Modern application tracing

Exempting applications from suspension

Instrumentation to find the thread or process responsible for an application failure

Growing community of inventors

Redmond, WA, United States of America

Michael H Krause