Supporting universal windows platform and Win32 applications in kiosk mode

A hook driver and a UWP load modifier can be employed on a Windows device to modify the process of loading UWP applications so that both UWP and Win32 applications can be run in kiosk mode without needing to run Windows Explorer in a typical manner. To accomplish this, the UWP load modifier can implement a proxy function that is called when the UWP loader attempts to launch a UWP application. In some configurations, when the proxy function is called, it can start Windows Explorer, cause the UWP application to be launched while Windows Explorer is running and then stop Windows Explorer once the UWP application is launched. In other configurations, when the proxy function is called, it can cause the UWP application to be launched in a separate desktop in which Windows Explorer is running and then, after it is launched, move the UWP application to the default desktop.

CROSS-REFERENCE TO RELATED APPLICATIONS

BACKGROUND

Microsoft's Universal Windows Platform (UWP) provides core APIs that are the same across all devices that run Windows 10. A UWP application can therefore be run on any Windows 10 device thereby eliminating the need to rewrite an application for each type of device. On the other hand, a Win32 application is a traditional Windows application that is based on the Win32 API. Windows 10 also provides a kiosk mode that can be used to run a single application (single-application kiosk mode) while preventing the user from accessing any functionality outside of the single application. It is also possible to use kiosk mode to run multiple applications (multiple-application kiosk mode).

A UWP application is in the form of a package. The package itself has an identifier (or “package ID”) and also defines an identifier for each UWP application (or “application user model ID”) that it contains. To launch a UWP application, the operating system retrieves the application user model ID from the package (e.g., using the GetPackageApplicationIDs function) and uses the application user model ID to activate the application (e.g., using the IApplicationActivationManager::ActivateApplication method). Yet, to perform this functionality, Windows Explorer must be present. Therefore, if Windows Explorer is not running on the device, it will not be possible to launch a UWP application.

A primary purpose of single-application kiosk mode is to replace Windows Explorer (the default shell) with another application (the custom shell). Therefore, it is not possible to run a UWP application in single-application kiosk mode. To avoid this issue, multiple-application kiosk mode could be used so that a shell capable of running a UWP application and the UWP application itself can be run. Although this approach allows a UWP application to be run in kiosk mode, the shell capable of running the UWP application cannot also run Win32 applications. Accordingly, current kiosk shells are not capable of running both UWP and Win32 applications. To address this issue, developers typically write custom Win32 wrappers for UWP applications, which is a rather burdensome task.

BRIEF SUMMARY

The present invention extends to methods, systems and computer program products for supporting UWP and Win32 applications in kiosk mode. A hook driver and a UWP load modifier can be employed on a Windows device to modify the process of loading UWP applications so that both UWP and Win32 applications can be run in kiosk mode without needing to run Windows Explorer in a typical manner. To accomplish this, the UWP load modifier can implement a proxy function that is called when the UWP loader attempts to launch a UWP application. In some configurations, when the proxy function is called, it can start Windows Explorer, cause the UWP application to be launched while Windows Explorer is running and then stop Windows Explorer once the UWP application is launched. In other configurations, when the proxy function is called, it can cause the UWP application to be launched in a separate desktop in which Windows Explorer is running and then, after it is launched, move the UWP application to the default desktop.

In some embodiments, the present invention is implemented as a method for launching a UWP application in kiosk mode. An attempt to launch a UWP application is intercepted and, in response, Windows Explorer is started. While Windows Explorer is running, the attempt to launch the UWP application is allowed to proceed thereby causing the UWP application to successfully launch. Then, after the UWP application has successfully launched, Windows Explorer is stopped.

In some embodiments, the present invention is implemented as a method for launching a UWP application in kiosk mode. An attempt to launch a UWP application in a first desktop is intercepted and, in response, the UWP application is caused to be launched in a second desktop. After the UWP application has been launched in the second desktop, the UWP application is moved to the first desktop.

In some embodiments, the present invention is implemented as computer storage media storing computer executable instructions which when executed implement a solution for launching a UWP application in kiosk mode. The solution is configured to intercept attempts to launch UWP applications. In response to intercepting an attempt to launch a first UWP application in a first desktop, the solution is configured to cause the first UWP application to be launched in a second desktop and, after the first UWP application has been launched in the second desktop, move the first UWP application to the first desktop.

In some embodiments, in response to intercepting an attempt to launch a second UWP application, the solution may also be configured to start Windows Explorer, allow the attempt to launch the second UWP application to proceed while Windows Explorer is running thereby causing the second UWP application to successfully launch, and, after the second UWP application has successfully launched, stop Windows Explorer.

DETAILED DESCRIPTION

FIG. 1illustrates various software components on a computing device100that may be employed in implementations of the present invention. Computing device100can represent any type of computing device that is capable of running a version of Windows that supports kiosk mode (e.g., Windows 10). Although not shown, computing device100would include one or more processors, memory and other hardware to enable the Windows operating system and the depicted components to be executed.

A UWP loader110, which may oftentimes be provided as part of the Windows operating system, is available on computing device100. Among other things, UWP loader110includes an import address table110aand a virtual table110bfor the IApplicationActivationManager interface. Import address table110adefines function pointers which, at runtime, will define the addresses where the corresponding functions are loaded in virtual memory. Of relevance to the present invention, import address table110aincludes a function pointer for the CoCreateInstance function. Virtual table110bis generally similar to import address table110aand defines function pointers that are used to implement dynamic dispatch techniques. Of relevance to the present invention, virtual table110bincludes at least one function pointer for the ActivateApplication function (or method) of the IApplicationActivationManager interface.

FIG. 1also shows that a UWP application120is available on computing device100. It is noted that other UWP applications and even Win32 applications could be available for execution on computing device100. As described below, embodiments of the present invention enable any UWP application available on computing device100to be run by modifying the loading process. Any Win32 application available on computing device100could also be run. In other words, any computing device that is configured in accordance with embodiments of the present invention can be operated in kiosk mode and run both UWP and Win32 applications.

To implement the techniques of the present invention, a UWP load modifier130, a hook driver140and, in some embodiments, a helper service150can be installed on computing device100. UWP load modifier130can represent an executable (e.g., a DLL) that is loaded when UWP loader110runs. Any suitable technique can be employed to accomplish this including, for example, any of the various DLL injection techniques. Among possibly other functionality, UWP load modifier130can implement proxy functions that are called when UWP loader110invokes the CoCreateInstance and ActivateApplication functions. Hook driver140, which may be in the form of a kernel-mode component that is loaded at startup, can be employed in each of the various embodiments of the present invention. On the other hand, helper service150may only be employed in some embodiments as described below.

FIGS. 2A-2Dillustrate an example of functionality that hook driver140and UWP load modifier130can perform to enable UWP load modifier130to modify the process of loading a UWP application.FIG. 2Arepresents functionality that would typically be performed at startup. In step1a, hook driver140is loaded. As part of loading, in step1b, hook driver140can register with the operating system to be notified whenever an image is loaded (or mapped into memory). For example, as part of its driver entry routine, hook driver140could call PsSetLoadImageNotifyRoutine to register a callback routine that the operating system will call when an image is loaded.

Turning toFIG. 2B, it is assumed that there has been a request to run a UWP application which in turn has caused the operating system to load UWP loader110in step2. It is noted that, at this point, Windows Explorer is not running. Because hook driver140has registered to be notified when images are loaded, in step3a, hook driver140will receive a load notification from the operating system. For example, the operating system can call the callback routine that hook driver140registered to provide hook driver140with information about the loaded image. This information may include the name of the image, the process ID of the process in which the image has been mapped, the base address of the image in virtual memory, etc. Although not shown, hook driver140may use this information to determine whether to take any action. For example, if the loaded image is not UWP loader110, hook driver140may simply return. Alternatively, hook driver140may determine whether the loaded image is allowed (e.g., by comparing the image name to policy) and, if not, may block the image. Of primary relevance to the present invention, if the loaded image is UWP loader110, in step3b, hook driver140can employ the information to traverse import address table110ato locate the function pointer to the CoCreateInstance function and replace it with a function pointer to the ProxyCoCreateInstance function that is implemented in UWP load modifier130.

In step3cshown inFIG. 2C, it is assumed that UWP loader110has commenced execution including attempting to invoke the CoCreateInstance function. However, because hook driver140modified import address table110a, in step3d, when UWP loader110attempts to invoke CoCreateInstance, UWP load modifier130's ProxyCoCreateInstance function will be invoked. As represented by step3e, the ProxyCoCreateInstance function is configured to search the virtual memory space of UWP loader110to identify IApplicationActivationManager virtual table110band replace any function pointer for ActivateApplication with a function pointer to UWP load modifier130's ProxyActivateApplication function. Then, in step3f, the ProxyCoCreateInstance function invokes the CoCreateInstance function and returns to allow UWP loader110to continue its execution.

Turning toFIG. 2D, UWP loader110's continued execution includes attempting to invoke the ActivateApplication function to thereby launch UWP application120. If the ActivateApplication function were actually executed at this point, UWP application120would fail to launch because Windows Explorer is not running. However, because of the modification to virtual table110b, in step4b, UWP loader110's attempt to invoke ActivateApplication will actually invoke UWP load modifier130's ProxyActivateApplication.

The ProxyActivateApplication function is configured to enable a UWP application to be successfully launched on computing device100even though Windows Explorer is not accessible to UWP loader110at the time it invokes the ActivateApplication function. The functionality that the ProxyActivateApplication performs may differ based on the resources available on computing device100.FIGS. 3A-3Crepresent one example of the functionality that the ProxyActivateApplication function may perform which may be more suitable when computing device100has limited memory (e.g., less than 8 GB).FIGS. 4A-4Crepresent another example of the functionality that the ProxyActivateApplication function may perform which may be more suitable when computing device100does not have limited memory (e.g., 8 GB or more). In some embodiments, UWP load modifier130could be configured to dynamically determine available resources and then select which technique ProxyActivateApplication will employ to enable a UWP application to be launched. In other embodiments, UWP load modifier130could be preconfigured to use a particular technique.

With reference toFIG. 3A, when the ProxyActivateApplication function is invoked, in step1a, it can start Windows Explorer in the background. With Windows Explorer now running, the ProxyActivateApplication function can then invoke the ActivateApplication function (e.g., using the function pointer that it replaced in virtual table110b) consistent with UWP loader110's original attempt to invoke this function. For example, UWP loader110's attempt to invoke the ActivateApplication function would have specified the application user model ID of the UWP application to be launched (which is assumed to be UWP application120). The ProxyActivateApplication function can pass this application user model ID (and the other parameters) in its call to the ActivateApplication function.

As represented inFIG. 3Bas step1c, the ActivateApplication function will interface with Windows Explorer as part of activating UWP application120(e.g., by calling APIs that Windows Explorer exports). These interactions with Windows Explorer will allow UWP application120to be successfully launched in step1d. Once the ActivateApplication function has completed successfully, in step1e, the ProxyActivateApplication can close Windows Explorer and return. In this way, UWP load modifier130causes Windows Explorer to run only long enough to launch UWP application120. Considering that this process will happen very quickly, there will be virtually no opportunity for a user to employ Windows Explorer to improperly access functionality of computing device100.

In the technique ofFIGS. 3A-3C, because Windows Explorer is run in the security context of the default desktop, the technique consumes minimal resources. However, even though Windows Explorer is only running for a short time, the fact that it is running in the default desktop (i.e., the desktop that receives user input) still creates a security vulnerability that could be exploited. Accordingly, this technique may be best suited for computing devices lacking sufficient RAM to support the technique ofFIGS. 4A-4C.

The technique ofFIGS. 4A-4Cemploys helper service150. With reference toFIG. 4A, when the ProxyActivateApplication function is invoked, in step1a, it can send a notification350to (or otherwise invoke) helper service150. Notification350can include the parameters of UWP loader110's call to the ActivateApplication function. If helper service350has not already done so, it can create separate desktop301and/or start Windows Explorer in separate desktop301. In accordance with the Windows security architecture, a security boundary will exist between default desktop300and separate desktop301. Therefore, processes running on default desktop300, including UWP loader110, will not be able to access Windows Explorer. For this reason, helper service150could create separate desktop301and run Windows Explorer at startup so that it is already running when notification350is received.

With Windows Explorer running in separate desktop301, helper service150can invoke the ActivateApplication function in the context of separate desktop301. As a result, in step1b, helper service150will interface with Windows Explorer as part of activating UWP application120. These interactions will cause UWP application120to be launched in the context of separate desktop301in step1c.

FIGS. 4B and 4Ceach illustrate a suitable way in which UWP application120can be moved to default desktop300(i.e., the visible desktop) once it is launched. As shown inFIG. 4B, once UWP application120is successfully launched, in step1d, helper service150can move UWP application120to default desktop300where its user interface will be visible and accessible to the end user. In this context, UWP application120is moved by changing which desktop is assigned to it. At this point, helper service150could close Windows Explorer and possibly separate desktop301but need not do so given that processes running on default desktop300, as well as the user, will not have access to Windows Explorer. This technique may be best suited for computing devices having RAM sufficient for two desktops.

In contrast, inFIG. 4C, step1dof moving UWP application120to the default desktop300is accomplished by making separate desktop301the default desktop (e.g., by calling SwitchDesktop). In such cases, helper service150can close Windows Explorer before switching the default desktop so that Windows Explorer will not be accessible in the default desktop.

Using the techniques of the present invention, a computing device could be deployed with a custom shell (e.g., a shell that replaces Windows Explorer) without losing the ability to run Win32 and UWP applications. As an example use case, the custom shell could provide a desktop interface that provides the user with the option of running multiple applications including both Win32 and UWP applications. In such a case, when the user selects a UWP application, one of the above-described techniques could be employed to launch the UWP application. In contrast, when the user selects a Win32 application, the application would be loaded in a typical fashion using the Win32 APIs that do not require Windows Explorer to be running. Notably, due to the techniques of the present invention, the applications themselves do not need to be modified in any way (e.g., by writing Win32 wrappers for the UWP applications). Accordingly, from an administrator's perspective, the present invention makes it much easier to deploy custom kiosk solutions.

FIG. 5provides a flowchart of an example method500for launching a UWP application in kiosk mode. Method500generally corresponds with the functionality depicted inFIGS. 3A-3Cand may be implemented by UWP load modifier130possibly in conjunction with other components depicted inFIG. 1.

Method500includes an act501of intercepting an attempt to launch a UWP application. For example, UWP load modifier130's ProxyActivateApplication function can be called when UWP loader110attempts to invoke the ActivateApplication function of the IApplicationActivationManager interface.

Method500includes an act502of, in response to intercepting the attempt to launch the UWP application, starting Windows Explorer. For example, UWP load modifier130's implementation of the ProxyActivateApplication function may define functionality for launching Windows Explorer (e.g., by calling CreateProcessA).

Method500includes an act503of, while Windows Explorer is running, allowing the attempt to launch the UWP application to proceed thereby causing the UWP application to successfully launch. For example, UWP load modifier130's implementation of the ProxyActivateApplication function may call the ActivateApplication function.

Method500includes an act504of, after the UWP application has successfully launched, stopping Windows Explorer. For example, UWP load modifier130's implementation of the ProxyActivateApplication function may define functionality for stopping Windows Explorer (e.g., by calling TerminateProcess).

FIG. 6provides a flowchart of an example method600for launching a UWP application in kiosk mode. Method600generally corresponds with the functionality depicted inFIGS. 4A-4Cand may be implemented by UWP load modifier130in conjunction with helper service150and possibly other components depicted inFIG. 1.

Method600includes an act601of intercepting an attempt to launch a UWP application in a first desktop. For example, UWP load modifier130's ProxyActivateApplication function can be called when UWP loader110, which may be running in the default desktop, attempts to invoke the ActivateApplication function of the IApplicationActivationManager interface.

Method600includes an act602of, in response to intercepting the attempt to launch the UWP application in the first desktop, causing the UWP application to be launched in a second desktop. For example, UWP load modifier130's implementation of the ProxyActivateApplication function may invoke helper service150to cause it to call ActivateApplication in the context of separate desktop301where Windows Explorer is running.

Method600includes an act603of, after the UWP application has been launched in the second desktop, moving the UWP application to the first desktop. For example, helper service150can assign default desktop300to UWP application120(e.g., by causing SetThreadDesktop to be called using a handle to default desktop300). Alternatively, helper service150could change separate desktop301to be the default desktop (e.g., by calling SwitchDesktop) which would cause default desktop300to no longer be the default desktop. Accordingly, moving the UWP application from one desktop to another should be construed as encompassing both changing the desktop that is assigned to the UWP application as well as changing which desktop is the default desktop (i.e., the first desktop can be viewed as the current default desktop and the second desktop can be viewed as not being the current default desktop). In instances where the UWP application is moved to the first desktop by making separate desktop301the default desktop, helper service150can stop Windows Explorer before making separate desktop301the default desktop.