Cross-process interface for non-compatible frameworks

A computer device is provided that includes a processor configured to execute a first application configured for a first user interface framework, instantiate a host window of the first application using the first user interface framework, and execute a second application, that is out of process with the first application. The second application is configured for a second user interface framework that is incompatible with the first user interface framework. The processor is further configured to instantiate a hosted window of the second application using the second user interface framework, establish a cross-process interface between the first application and the second application configured to exchange rendering information between the hosted window and the host window, and cause the host window to display the rendering information from the hosted window within the host window on a display of the computer device.

BACKGROUND

A large number of application programs have been built on and continue to be built on legacy technologies. However, these legacy technologies may become incompatible with modern technologies that provide improved functionality. To access the runtime improvements and functionality of these modern technologies, developers typically must rewrite their code base and build their application on the modern technology, which may be time consuming and expensive for these developers.

SUMMARY

A computer device is provided that may include a processor configured to execute a first application configured for a first user interface framework, instantiate a host window of the first application using the first user interface framework, and execute a second application, that is out of process with the first application. The second application is configured for a second user interface framework that is incompatible with the first user interface framework. The processor may be further configured to instantiate a hosted window of the second application using the second user interface framework, establish a cross-process interface between the first application and the second application configured to exchange rendering information between the hosted window and the host window, and cause the host window to display the rendering information from the hosted window within the host window on a display of the computer device.

DETAILED DESCRIPTION

Many developers are building or have built their applications on legacy technologies. For example, these legacy applications may be built using legacy technologies such as WINDOWS API (Win32), WINDOWS Presentation Foundation, WINDOWS Forms, etc. However, it will be appreciated that these legacy applications may also be built using other legacy technologies and are not limited to WINDOWS specific technologies. Additionally, even though these legacy applications may be built using programming languages such as, for example, C #, Visual Basic, etc., they may also integrate legacy web content into the application to provide a user interface and other functionality using legacy web applications such as Internet Explorer (IE) 7, IE 11, etc., and legacy web code such as code written in Hypertext Markup Language (HTML) versions prior to HTML5, Javascript, etc.

The legacy web components of the legacy technologies that these legacy applications are built on are typically tied to corresponding legacy web technologies. For example, the legacy web components of Win32, WINDOWS Presentation Foundation, WINDOWS Forms, etc., may be tied to IE 7, IE 11, etc. Consequently, these legacy applications may be unable to integrate web content that is built on a modern technology that is incompatible with the legacy technology. As a specific example, applications built on Win32 may be unable to natively integrate web content from modern web applications built on modern technologies such as Universal WINDOWS Platform (UWP) using modern web code such as HTML5.

To access the runtime improvements and functionality of these modern technologies, developers typically must rewrite their code base and build their application on the modern technology, which may potentially be time consuming and expensive for the developer. Additionally, it will be appreciated that these challenges are not limited to legacy vs modern technologies. Typically, an application built on a first user interface framework based on a first programming language may not be able to integrate content from another application built on a second user interface framework based on a second programming language that is incompatible with the first framework. For example, an application built using Java typically cannot integrate visuals and content from another application built using C #.

To address the challenges discussed above, a computer device10, shown in the example embodiment ofFIG. 1, is provided. As will be described in more detail below, the computer device10is configured to establish a cross-process interface12between two or more applications configured for non-compatible user interface frameworks. In the illustrated example, the cross-process interface12is configured to exchange rendering information14from a hosted window16of a second application built on UWP with a host window18of a first application built on Win32 to cause the host window18of the first application to display the rendering information14from the hosted window16of the second application within the host window18on a display20of the computer device10. It will be appreciated that the cross-process interface12is not limited to UWP and Win32, but may also be established between other non-compatible frameworks via other implementations of the cross-process interface12.

FIG. 2illustrates a schematic view of the computer device10. The computer device10includes a processor22, volatile storage/non-volatile storage devices24, an input device26, the display20, and other suitable computer components to implement the methods and processes described herein. The input device26may include, for example, one or more of a mouse, a touchscreen, a trackpad, a keyboard, a camera, a microphone, and/or other input devices. The processor22is configured to execute an operating system28and instructions for applications stored on the volatile storage/non-volatile storage devices and/or retrieved from a server device via a network.

As illustrated inFIG. 1, the processor22is further configured to execute a first application30configured for a first user interface framework32. The first application30is configured to integrate content, such as a user interface or other functionality, from a second application34configured for a second user interface framework that is incompatible with the first user interface framework32. In one specific example, the first application30may take the form of a legacy application built on a legacy technology such as Win32, and the second application34may take the form of a modern web application built on a modern technology such as UWP. For example, the first application30may take the form of a stand-alone executable such as MICROSOFT OFFICE or MICROSOFT EXCEL application for Win32, and the second application34may be a web-based add-in such as a currency calculator built on UWP. However, it will be appreciated that the first and second application30and34may take other forms, and may be configured for other example incompatible first and second user interface frameworks32and36.

In one example, the second user interface framework36is incompatible with the first user interface framework32by having no native control in the first user interface framework32to host an application of the second user interface framework36. That is, the first user interface framework32does not natively include a control, such as, for example, a webview controller/manager, that is configured to launch and manage a webview for an application configured for the second user interface framework36to present rendering information14and other functionality (e.g. user interface) of the second application34within the first application30.

In another example, the first user interface framework32is based on a first programming language and the second user interface framework36is based on a second programming language, the first programming language being incompatible with the second programming language. For example, the first application30may be configured for a user interface framework built on Java and the second application may be configured for a user interface framework built on C #, which are incompatible programming languages. However, it will be appreciated that the first and second programming languages may take the form of any suitable pair of incompatible programming languages.

While executing the first application30, the processor22is configured to instantiate a host window18of the first application30using the first user interface framework32. In one specific example, the instance of the host window18includes a handle (e.g. HWND) to the host window18that is recognized within the first user framework32. However, it will be appreciated that other platforms/frameworks may use other handles to manage their windows. In one example, the host window18includes a size and location that may be initially set by the first application30, and moved or resized via user input40to the input device26.

As discussed above, the first user interface framework32may not include a native control for launching a webview of an application built on the second user interface framework36. Thus, in one example, the operating system28includes system code for an out of process webview control42and a system hosting application control44that may be executed within the process of the first application30. The out of processor webview control42and the system hosting application control44may include application programming interface (API) functions that are recognized by the first user interface framework32.

After instantiating the host window18, the processor22executing code for the first application30may be configured to being a process for establishing a cross-process interface12by activating an instance of the system hosting application control44. The instance of the system hosting application control44may be configured to launch a system hosting application process46which is a system process configured to host and manage out of process webviews for applications built on the second user interface framework36. The system hosting application control44and the system hosting application process46may be configured to launch and manage a plurality of webviews for one or more applications built on the second user interface framework36. The system hosting application control44is a runtime class that the first application30process may use to manage the system hosting application program46and the one or more webview processes launched by the system hosting application program46. In one example, the first application30may use properties of the system hosting application control44to size and position the one or more launched webviews for the second application34, set a scale of the one or more webviews, setting programmatic focus and tabbing into/out of the one or more webviews, etc.

In one specific example, the system hosting application process46is a DirectX UWP application included in the operating system28being executed by the computer device10that is configured to host webviews for applications built on UWP. However, it will be appreciated that the system hosting application process46may be built on technologies other than UWP in other incompatible framework scenarios, such as Java and C #. The system hosting application process46includes system hosting application components48that may be configured to forward notifications from the system hosting application control44, such as notifications for size, position, visibility, etc. of the webview, to the one or more launched webview processes for the second application34so that the one or more webview processes are may be correctly resized, repositioned, etc.

After launching a webview process for the second application34, the processor22is further configured to execute the second application34, that is out of process with the first application30. As discussed previously, the second application34is configured for the second user interface36framework that is incompatible with the first user interface framework32. The executed code for the second application34may include various functionality, user interfaces, visual content, etc., that may be provided to the first application30via the cross-process interface12.

When launching the webview process for the second application34, the processor22is further configured to instantiate a hosted window16of the second application34using the second user interface framework36. Similarly to the host window18, the hosted window16may also include a backing HWND. However, it will be appreciated that other frameworks and platforms may use different handles for windows.

The HWND for the hosted window16may be returned or otherwise sent to the instance of the system hosting application process46. In the example illustrated inFIG. 2, the system hosting application process46may create an instance of a system bridge window50that is owned by the system. In one example, the system hosting application process46may be configured to establish a cross-process parenting52between the system bridge window50and the hosted window16using their corresponding backing HWNDs. The bridge window may be configured to act as a translation layer between the operating system28and the hosted window16, such that the hosted windows18receives appropriate window messages and events from the system in the same manner as when the second application34is run in a non-hosted scenario.

Next, the processor22may be configured to call a SetParent function of the system hosting application control44within the first application30process that passes the backing HWND of the host window18to the system hosting application process46, and causes the system hosting application process46to establish a cross-process parenting52between the host window18and the system bridge window50using the corresponding backing HWNDs. In this manner, the processor22is configured to establish a cross-process interface12between the host window18and the hosted window16, configured to exchange rendering information14between the hosted window16and the host window18. In the illustrated example, to establish the cross-process interface12the processor22is configured to establish the cross-process parenting52between the host window18and the hosted window16, such as, for example, through the system bridge window50as described above. That is, the host window18may be established as a parent of the hosted window16through the cross-process parenting52methods described above, such that rendering information14generated when executing the code for the second application34and sent to the hosted window16is also exchanged with the parent host window18.

Once the cross-process interface12between the host window18and the hosted window16has been established, the processor22is configured to cause the host window18to display the rendering information14from the hosted window16within the host window18on a display20of the computer device10. In one example, the process for the first application30may be further configured to create a first application window54that is configured to present first application rendering information56that is rendered based on the code of the first application30. Thus, the first application30being displayed view the display20may include both the first application window54and the host window18, such that both the first application rendering information56and the second application rendering information14is displayed to the user of the computer device in a unified format such that the user perceives that only one application is running.

In the example illustrated inFIG. 3, the display20may display the first application window54for the first application30being executed by the processor22. The first application window54for the first application30may contain the first application rendering information56that was rendering according to the code of the first application30. The first application window54may further contain the host window18at a designated location and with a designated size relative to the first application window54. As discussed above, the designated size and location may be communicated to the hosted window16via the instance of the system hosting application control44within the process of the first application30.

The rendering information14generated according to the code of the second application34may be exchanged between the hosted window16and the host window18via the established cross-process interface12, and the rendering information14may be displayed in the host window18in the first application window54for the first application30, such that a unified view of both the first application rendering information56and the second application rendering information14are presented to the user of the computer device10in a unified format.

As illustrated inFIG. 3, the user may enter user input40to the computer device10via the input device26, which, for example, make take the form of a mouse input device. Using the input device26, the user may enter the user input40via clicking on particular locations of the display20. The user input40is processed by a system input handler58, which may be configured to compare the locations of user inputs40with the known location of the host window18and the hosted window16to determine whether the user inputs40are directed to the hosted window16. For example, the system input handler58of the operating system28may be configured to determine an area of the display associated with the hosted window16, such as, for example, via the system bridge window50or the system hosting application process46owned by the operating system28, and compare the determined area to the location of the user input40. The system input handler58may be further configured to route user inputs40from the area of the display20associated with the hosted window16to the hosted window16directly. That is, the system input handler58may route user inputs40that are determined to be directed towards the hosted window16directly to the hosted window16without passing through the first application30and the host window18. In the example illustrated inFIG. 3, the example user input40A is located within the area of the display20associated with the hosted window16, and is thus routed to the hosted window16and the second application34directly from the operating system28. On the other hand, the example user input40B is located outside of the area of the display20associated with the hosted window16, and is thus routed to the first application30from the operating system28.

Turning back toFIG. 2, after the system hosting application control44, the system hosting application process46, and the webview process for the second application34have been launched according to the processes discussed above, the system hosting application control44may be further configured to create the out of process webview control42configured to route navigation controls60from the first application30to the second application34. As illustrated, the out of process webview control42of the cross-process interface12is included in the system code29being run within the process of the first application30. The system hosting application control44may be configured to initialize the out of process webview control42with the instance of the webview process for the second application34that was launched by the system hosting application control44.

The out of process webview control42may be configured to make calls to the webview process of the second application34that is out of process from the process of the first application30that includes the out of process webview control42, and receive callbacks from the webview process to perform web related API functions. The out of process webview control42may include API functions that are recognized by the first application30that is configured for the user interface framework32. Using the API functions exposed by the out of process webview control42, the process for the first application30may interact with the out of process webview control42to route navigation controls60to the webview process of the second application34. In one example, the navigation controls60are web application programming interfaces selected from the group consisting of navigation functions, script invoking functions, and navigation event callbacks. However, it will be appreciated that other types of web APIs may be routed as navigation controls60from the process of the first application30to the webview process of the second application34.

In the manner described above, the process of the first application30may interact with and exchange rendering information with a webview process of the second application34that is built on an incompatible user interface framework by establishing the cross-process interface12including the out of process webview control42and the system hosting application control44.

FIGS. 4 and 5illustrate a schematic view of a specific WINDOWS implementation of the cross-process interface12. It will be appreciated that the broader concepts described in the specific implementation ofFIG. 4andFIG. 5for establishing a cross-process interface12may also be applied to other frameworks, such as, for example, Java and C #, with modifications to suit the specific characteristics of those frameworks.

At (S1) the host application is configured to create a Win32WebViewSiteStatic, which is a static object that includes a function CreateWebViewAsync that is configured to start an async operation to create a WebView process.

At (S2) CreateWebViewAsync is configured to create an instance of a Win32WebViewSite runtime class (e.g. System hosting application control44).

At (S3) the instance of the Win32WebViewSite is configured to launch a Win32WebViewHost App (e.g. system hosting application46) and receive an instance of the Win32WebViewHost app as IHostedApp inFIG. 4. The instance of the Win32WebviewHost app may be interacted with by the host application process to manage the Win32WebViewHost app. The Win32WebViewHost application is a DirectX UWP application that is a system application that is on the computer device10.

At (S4) the Win32WebViewHost App is activated by system code of the operating system.

At (S5) a DirectXMain object of the Win32WebViewHost App is configured to create a WebViewHost.

At (S6) the WebViewHost is initialized with a system bridge window50and an ActivatedEventArgs.

At (S7) the WebViewHost provides an instance of itself to the Win32WebViewSite through the ActivatedEventArgs.

After the Win32WebviewHost app is activated at (S4) and Win32WebViewSite has a proxy to the WebViewHost, at (S8) the Win32WebViewSite creates a CoreWebViewComponentCallback and calls CreateWebViewInRac on the proxy of the WebViewHost with the CoreWebViewComponentCallback.

At (S9) the WebViewHost calls into a WebViewManager to launch an Out of Process Webview process (e.g. process for the second application34) with the CoreWebViewComponentCallback. The system bridge window50is attached (e.g. cross-process parenting52) to a backing HWND of a hosted window16of the process for the second application34.

At (S11) the WebViewHost returns the CoreWebViewComponent to the Win32WebViewSite.

At (S12) the Win32WebViewSite will create an instance of the OutofProcess WebViewControl42runtime class.

After (S1)-(S13) have been completed, the Win32WebViewHost app (e.g. system hosting application46) and the out of process webview (e.g. process for second application) have been launched. At (S14) the Win32WebViewHost app is attached (e.g. cross-process parenting52) to the backing HWND of the host window18of the host application process (e.g. process for first application30) via a SetParentWindow call on the instance of the Win32WebViewHost app IHostedApp. After (S14) has been completed, Win32WebViewSite completes the async operation for CreateWebViewAsync started at (S1).

At (S15) the host application (e.g. process for the first application30) retrieves the OutofProcess WebViewControl42from the Win32WebViewSite.

At (S16) the host application may call Navigate on the OutofProcess WebViewControl42to route navigation controls60to the Out of Process webview. For example, the Navigate call will be routed through the OutofProcess WebViewControl42and CoreWebViewControl in the host application process and is sent cross-process to CoreWebViewComponent in the Out of Process webview (e.g. process for the second application34).

It will be appreciated that the architecture illustrated inFIG. 4and the method (S1)-(S16) shown inFIG. 5using the architecture ofFIG. 4are a specific example implementation for a Win32 to UWP cross-process interface12. While the steps and architecture ofFIGS. 4 and 5are MICROSOFT specific, the described concepts may also be implemented for other incompatible framework scenarios, such as, for example, Java and C #. Further, implementations of the concepts described herein apply equally to other operating systems and programming frameworks, such as APPLE IOS and GOOGLE ANDROID environments.

FIG. 6is a flowchart of a method600implemented by a computer device. Method600may be executed using the systems described above or utilizing other suitable hardware and software elements.

At602, the method600may include executing a first application configured for a first user interface framework. In one example, the first application is built on Win32. A process for the first application30is illustrated inFIG. 2.

At604, the method600may include instantiating a host window of the first application using the first user interface framework. In one example, the instance of the host window18includes a handle (e.g. HWND) to the host window18that is recognized within the first user framework32. However, it will be appreciated that other platforms/frameworks may use other handles to manage their windows. An example instance of the host window18is illustrated inFIG. 2andFIG. 3.

At606, the method may include executing a second application, that is out of process with the first application, the second application configured for a second user interface framework that is incompatible with the first user interface framework. In one example, the second application is a web application that is built on UWP, which is incompatible with application built on Win32. In one specific example, the second user interface framework is incompatible with the first user interface framework by having no native control in the first user interface framework to host an application of the second user interface framework. That is, the first user interface framework32does not natively include a control, such as, for example, a webview controller/manager, that is configured to launch and manage a webview for an application configured for the second user interface framework36to present rendering information14and other functionality (e.g. user interface) of the second application34within the first application30.

As another specific example, of incompatible frameworks, the first user interface framework is based on a first programming language and the second user interface framework is based on a second programming language, the first programming language being incompatible with the second programming language. For example, the first application30may be configured for a user interface framework built on Java and the second application may be configured for a user interface framework built on C #, which are incompatible programming languages. However, it will be appreciated that the first and second programming languages may take the form of any suitable pair of incompatible programming languages.

At608, the method600may include instantiating a hosted window of the second application using the second user interface framework. Similarly to the host window, the hosted window may include a handle (e.g. HWND) to the hosted window16.

At610, the method600may include establishing a cross-process interface between the first application and the second application configured to exchange rendering information between the hosted window and the host window. In one example, establishing the cross-process interface includes establishing a cross-process parenting between the host window and the hosted window. For example, the cross-process interface may include a system bridge window that is controlled by an operating system of the computer device. Next, the host window may be established as a parent of the system bridge window, the system bridge window may be established as a parent of the hosted window. In this manner, the host window may be established as a parent of the hosted window through the system bridge window in a cross-process parenting relationship.

At612, the method600may include causing the host window to display the rendering information from the hosted window within the host window on a display of the computer device.FIG. 3illustrates an example of a first application window54of the process of the first application30being displayed on a display20of the computer device10. The first application window54includes first application rendering information56that is rendered according to code of the first application30. Alongside the first application rendering information56, the host window18displays second application rendering information14from the hosted window16via the cross-process interface established at step610. In this manner, rendering information from both the first application and the second application are presented via the display20in a unified view.

In one example, the cross-process interface further includes an out of process webview control. In this example, at614, the method600may include routing navigation controls from the first application to the second application. In one example, the navigation controls are web application programming interfaces selected from the group consisting of navigation functions, script invoking functions, and navigation event callbacks. The out of process webview control42may be included in system code29being executed within the process of the first application30.

At616, the method600may include routing user inputs from the area of the display associated with the hosted window to the second application directly.FIG. 3illustrates an example of a system input handler58routing user inputs based on a location of the user input on the display compared to the known positions and sizes of the host window18and its child hosted window16. The user inputs may be routed directly to the process for the second application without passing through the process for the first application if the user input is detected as being directed to the area of the host/hosted window.

FIG. 7schematically shows a non-limiting embodiment of a computing system700that can enact one or more of the methods and processes described above. Computing system700is shown in simplified form. Computing system700may embody the computer device10described above and illustrated inFIG. 2. Computing system700may take the form of one or more personal computers, server computers, tablet computers, home-entertainment computers, network computing devices, gaming devices, mobile computing devices, mobile communication devices (e.g., smart phone), and/or other computing devices, and wearable computing devices such as smart wristwatches and head mounted augmented reality devices.

Computing system700includes a logic processor702volatile memory704, and a non-volatile storage device706. Computing system700may optionally include a display subsystem708, input subsystem710, communication subsystem712, and/or other components not shown inFIG. 7.

Non-volatile storage device706includes one or more physical devices configured to hold instructions executable by the logic processors to implement the methods and processes described herein. When such methods and processes are implemented, the state of non-volatile storage device704may be transformed—e.g., to hold different data.

Volatile memory704may include physical devices that include random access memory. Volatile memory704is typically utilized by logic processor702to temporarily store information during processing of software instructions. It will be appreciated that volatile memory704typically does not continue to store instructions when power is cut to the volatile memory704.

Aspects of logic processor702, volatile memory704, and non-volatile storage device706may be integrated together into one or more hardware-logic components. Such hardware-logic components may include field-programmable gate arrays (FPGAs), program- and application-specific integrated circuits (PASIC/ASICs), program- and application-specific standard products (PSSP/ASSPs), system-on-a-chip (SOC), and complex programmable logic devices (CPLDs), for example.

When included, display subsystem708may be used to present a visual representation of data held by non-volatile storage device706. The visual representation may take the form of a graphical user interface (GUI). As the herein described methods and processes change the data held by the non-volatile storage device, and thus transform the state of the non-volatile storage device, the state of display subsystem708may likewise be transformed to visually represent changes in the underlying data. Display subsystem708may include one or more display devices utilizing virtually any type of technology. Such display devices may be combined with logic processor702, volatile memory704, and/or non-volatile storage device706in a shared enclosure, or such display devices may be peripheral display devices.

The following paragraphs provide additional support for the claims of the subject application. One aspect provides a computer device comprising a processor configured to execute a first application configured for a first user interface framework, instantiate a host window of the first application using the first user interface framework, and execute a second application, that is out of process with the first application, the second application configured for a second user interface framework that is incompatible with the first user interface framework. In this aspect, the processor is further configured to instantiate a hosted window of the second application using the second user interface framework, establish a cross-process interface between the first application and the second application configured to exchange rendering information between the hosted window and the host window, and cause the host window to display the rendering information from the hosted window within the host window on a display of the computer device. In this aspect, additionally or alternatively, the cross-process interface may include an out of process webview control configured to route navigation controls from the first application to the second application. In this aspect, additionally or alternatively, the navigation controls may be web application programming interfaces selected from the group consisting of navigation functions, script invoking functions, and navigation event callbacks. In this aspect, additionally or alternatively, the processor may be further configured to route user inputs from the area of the display associated with the hosted window to the second application directly. In this aspect, additionally or alternatively, the second user interface framework may be incompatible with the first user interface framework by having no native control in the first user interface framework to host an application of the second user interface framework. In this aspect, additionally or alternatively, the first user interface framework may be based on a first programming language and the second user interface framework may be based on a second programming language, the first programming language being incompatible with the second programming language. In this aspect, additionally or alternatively, to establish the cross-process interface, the processor may be configured to establish a cross-process parenting between the host window and the hosted window. In this aspect, additionally or alternatively, to establish the cross-process parenting, the host window may be established as a parent of a bridge window and the bridge window may be established as a parent of the hosted window, wherein the bridge window may be controlled by a system process of an operating system executed by the processor. In this aspect, additionally or alternatively, the first application may be a stand-alone executable and the second application may be an add-in. In this aspect, additionally or alternatively, the first user interface framework may be WIN32, and the second user interface framework may be UNIVERSAL WINDOWS PLATFORM.

Another aspect provides a method comprising, at a computer device including a processor, executing a first application configured for a first user interface framework, instantiating a host window of the first application using the first user interface framework, and executing a second application, that is out of process with the first application, the second application configured for a second user interface framework that is incompatible with the first user interface framework. In this aspect, the method further comprises instantiating a hosted window of the second application using the second user interface framework, establishing a cross-process interface between the first application and the second application configured to exchange rendering information between the hosted window and the host window, and causing the host window to display the rendering information from the hosted window within the host window on a display of the computer device. In this aspect, additionally or alternatively, the cross-process interface may include an out of process webview control configured for routing navigation controls from the first application to the second application. In this aspect, additionally or alternatively, the navigation controls may be web application programming interfaces selected from the group consisting of navigation functions, script invoking functions, and navigation event callbacks. In this aspect, additionally or alternatively, the method may further comprise routing user inputs from the area of the display associated with the hosted window to the second application directly. In this aspect, additionally or alternatively, the second user interface framework may be incompatible with the first user interface framework by having no native control in the first user interface framework to host an application of the second user interface framework. In this aspect, additionally or alternatively, the first user interface framework may be based on a first programming language and the second user interface framework may be based on a second programming language, the first programming language being incompatible with the second programming language. In this aspect, additionally or alternatively, establishing the cross-process interface may include establishing a cross-process parenting between the host window and the hosted window. In this aspect, additionally or alternatively, establishing the cross-process parenting may include establishing the host window as a parent of a bridge window and establishing the bridge window as a parent of the hosted window, wherein the bridge window may be controlled by a system process of an operating system executed by the processor. In this aspect, additionally or alternatively, the first user interface framework may be WIN32, and the second user interface framework may be UNIVERSAL WINDOWS PLATFORM.

Another aspect provides a computer device comprising a processor configured to execute a first application configured for a first user interface framework, instantiate a host window of the first application using the first user interface framework, and execute a system hosting application that is configured to launch an out of process webview for a second application, the second application being configured for a second user interface framework that is incompatible with the first user interface framework. In this aspect, the processor is further configured to instantiate a system bridge window of the system hosting application, instantiate a hosted window of the second application using the second user interface framework, establish a cross-process interface between a process of the first application and the out of process webview for the second application by establishing a cross-process parenting between the host window, the system bridge window, and the hosted window that is configured to exchange rendering information between the hosted window and the host window, and cause the host window to display the rendering information from the hosted window within the host window on a display of the computer device.