Patent Description:
<CIT> discloses that a method and apparatus for adapting and hosting legacy user interface controls is provided. Legacy user interface controls are exposed within a new window manager as native user interface objects. A bridge between a hosted legacy user interface control and the legacy window manager intercepts messages intended for the hosted user interface control. The messages are filtered to determine if they should be passed to the new window manager. If a message is to be forwarded, the message is forwarded to a root Visual Gadget in the new window manager. The message is processed and routed down the window tree to an adapter control for hosting the legacy user interface control. The adapter control processes the message and routes the message to any listener objects attached to the adapter. If the message has not been completely handled, the message is "bubbled" up the window tree for additional processing.

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) <NUM>, IE <NUM>, 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 <NUM>, IE <NUM>, 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 device <NUM>, shown in <FIG>, is provided. As will be described in more detail below, the computer device <NUM> is configured to establish a cross-process interface <NUM> between two or more applications configured for non-compatible user interface frameworks. In the illustrated example, the cross-process interface <NUM> is configured to exchange rendering information <NUM> from a hosted window <NUM> of a second application built on UWP with a host window <NUM> of a first application built on Win32 to cause the host window <NUM> of the first application to display the rendering information <NUM> from the hosted window <NUM> of the second application within the host window <NUM> on a display <NUM> of the computer device <NUM>. It will be appreciated that the cross-process interface <NUM> is not limited to UWP and Win32, but may also be established between other non-compatible frameworks via other implementations of the cross-process interface <NUM>.

<FIG> illustrates a schematic view of the computer device <NUM>. The computer device <NUM> includes a processor <NUM>, volatile storage/non-volatile storage devices <NUM>, an input device <NUM>, the display <NUM>, and other suitable computer components to implement the methods and processes described herein. The input device <NUM> may 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 processor <NUM> is configured to execute an operating system <NUM> and instructions for applications stored on the volatile storage/non-volatile storage devices and/or retrieved from a server device via a network.

As illustrated in <FIG>, the processor <NUM> is further configured to execute a first application <NUM> configured for a first user interface framework <NUM>. The first application <NUM> is configured to integrate content, such as a user interface or other functionality, from a second application <NUM> configured for a second user interface framework that is incompatible with the first user interface framework <NUM>. The first application <NUM> may take the form of a legacy application built on a legacy technology such as Win32, and the second application <NUM> may take the form of a modern web application built on a modern technology such as UWP. The first application <NUM> may take the form of a stand-alone executable such as MICROSOFT OFFICE or MICROSOFT EXCEL application for Win32, and the second application <NUM> may be a web-based add-in such as a currency calculator built on UWP. However, it will be appreciated that the first and second application <NUM> and <NUM> may take other forms, and may be configured for other incompatible first and second user interface frameworks <NUM> and <NUM>.

The second user interface framework <NUM> is incompatible with the first user interface framework <NUM> by having no native control in the first user interface framework <NUM> to host an application of the second user interface framework <NUM>. That is, the first user interface framework <NUM> does not natively include a control, such as, a webview controller/manager, that is configured to launch and manage a webview for an application configured for the second user interface framework <NUM> to present rendering information <NUM> and other functionality (e.g. user interface) of the second application <NUM> within the first application <NUM>.

The first user interface framework <NUM> is based on a first programming language and the second user interface framework <NUM> is based on a second programming language, the first programming language being incompatible with the second programming language. The first application <NUM> may 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 application <NUM>, the processor <NUM> is configured to instantiate a host window <NUM> of the first application <NUM> using the first user interface framework <NUM>. The instance of the host window <NUM> includes a handle (e.g. HWND) to the host window <NUM> that is recognized within the first user framework <NUM>. However, it will be appreciated that other platforms/frameworks may use other handles to manage their windows. The host window <NUM> includes a size and location that may be initially set by the first application <NUM>, and moved or resized via user input <NUM> to the input device <NUM>.

As discussed above, the first user interface framework <NUM> may not include a native control for launching a webview of an application built on the second user interface framework <NUM>. Thus, the operating system <NUM> includes system code for an out of process webview control <NUM> and a system hosting application control <NUM> that may be executed within the process of the first application <NUM>. The out of processor webview control <NUM> and the system hosting application control <NUM> may include application programming interface (API) functions that are recognized by the first user interface framework <NUM>.

After instantiating the host window <NUM>, the processor <NUM> executing code for the first application <NUM> may be configured to being a process for establishing a cross-process interface <NUM> by activating an instance of the system hosting application control <NUM>. The instance of the system hosting application control <NUM> may be configured to launch a system hosting application process <NUM> which is a system process configured to host and manage out of process webviews for applications built on the second user interface framework <NUM>. The system hosting application control <NUM> and the system hosting application process <NUM> may be configured to launch and manage a plurality of webviews for one or more applications built on the second user interface framework <NUM>. The system hosting application control <NUM> is a runtime class that the first application <NUM> process may use to manage the system hosting application program <NUM> and the one or more webview processes launched by the system hosting application program <NUM>. The first application <NUM> may use properties of the system hosting application control <NUM> to size and position the one or more launched webviews for the second application <NUM>, 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 process <NUM> is a DirectX UWP application included in the operating system <NUM> being executed by the computer device <NUM> that is configured to host webviews for applications built on UWP. However, it will be appreciated that the system hosting application process <NUM> may be built on technologies other than UWP in other incompatible framework scenarios, such as Java and C#. The system hosting application process <NUM> includes system hosting application components <NUM> that may be configured to forward notifications from the system hosting application control <NUM>, such as notifications for size, position, visibility, etc. of the webview, to the one or more launched webview processes for the second application <NUM> so that the one or more webview processes are may be correctly resized, repositioned, etc..

After launching a webview process for the second application <NUM>, the processor <NUM> is further configured to execute the second application <NUM>, that is out of process with the first application <NUM>. As discussed previously, the second application <NUM> is configured for the second user interface <NUM> framework that is incompatible with the first user interface framework <NUM>. The executed code for the second application <NUM> may include various functionality, user interfaces, visual content, etc., that may be provided to the first application <NUM> via the cross-process interface <NUM>.

When launching the webview process for the second application <NUM>, the processor <NUM> is further configured to instantiate a hosted window <NUM> of the second application <NUM> using the second user interface framework <NUM>. Similarly to the host window <NUM>, the hosted window <NUM> may 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 window <NUM> may be returned or otherwise sent to the instance of the system hosting application process <NUM>. As illustrated in <FIG>, the system hosting application process <NUM> may create an instance of a system bridge window <NUM> that is owned by the system. In one example, the system hosting application process <NUM> may be configured to establish a cross-process parenting <NUM> between the system bridge window <NUM> and the hosted window <NUM> using their corresponding backing HWNDs. The bridge window may be configured to act as a translation layer between the operating system <NUM> and the hosted window <NUM>, such that the hosted windows <NUM> receives appropriate window messages and events from the system in the same manner as when the second application <NUM> is run in a non-hosted scenario.

Next, the processor <NUM> may be configured to call a SetParent function of the system hosting application control <NUM> within the first application <NUM> process that passes the backing HWND of the host window <NUM> to the system hosting application process <NUM>, and causes the system hosting application process <NUM> to establish a cross-process parenting <NUM> between the host window <NUM> and the system bridge window <NUM> using the corresponding backing HWNDs. In this manner, the processor <NUM> is configured to establish a cross-process interface <NUM> between the host window <NUM> and the hosted window <NUM>, configured to exchange rendering information <NUM> between the hosted window <NUM> and the host window <NUM>. As illustrated, to establish the cross-process interface <NUM> the processor <NUM> is configured to establish the cross-process parenting <NUM> between the host window <NUM> and the hosted window <NUM>, such as, for example, through the system bridge window <NUM> as described above. That is, the host window <NUM> may be established as a parent of the hosted window <NUM> through the cross-process parenting <NUM> methods described above, such that rendering information <NUM> generated when executing the code for the second application <NUM> and sent to the hosted window <NUM> is also exchanged with the parent host window <NUM>.

Once the cross-process interface <NUM> between the host window <NUM> and the hosted window <NUM> has been established, the processor <NUM> is configured to cause the host window <NUM> to display the rendering information <NUM> from the hosted window <NUM> within the host window <NUM> on a display <NUM> of the computer device <NUM>. In one example, the process for the first application <NUM> may be further configured to create a first application window <NUM> that is configured to present first application rendering information <NUM> that is rendered based on the code of the first application <NUM>. Thus, the first application <NUM> being displayed view the display <NUM> may include both the first application window <NUM> and the host window <NUM>, such that both the first application rendering information <NUM> and the second application rendering information <NUM> is displayed to the user of the computer device in a unified format such that the user perceives that only one application is running.

As illustrated in <FIG>, the display <NUM> may display the first application window <NUM> for the first application <NUM> being executed by the processor <NUM>. The first application window <NUM> for the first application <NUM> may contain the first application rendering information <NUM> that was rendering according to the code of the first application <NUM>. The first application window <NUM> further contains the host window <NUM> at a designated location and with a designated size relative to the first application window <NUM>. As discussed above, the designated size and location may be communicated to the hosted window <NUM> via the instance of the system hosting application control <NUM> within the process of the first application <NUM>.

The rendering information <NUM> generated according to the code of the second application <NUM> may be exchanged between the hosted window <NUM> and the host window <NUM> via the established cross-process interface <NUM>, and the rendering information <NUM> may be displayed in the host window <NUM> in the first application window <NUM> for the first application <NUM>, such that a unified view of both the first application rendering information <NUM> and the second application rendering information <NUM> are presented to the user of the computer device <NUM> in a unified format.

As illustrated in <FIG>, the user may enter user input <NUM> to the computer device <NUM> via the input device <NUM>, which, for example, make take the form of a mouse input device. Using the input device <NUM>, the user may enter the user input <NUM> via clicking on particular locations of the display <NUM>. The user input <NUM> is processed by a system input handler <NUM>, which may be configured to compare the locations of user inputs <NUM> with the known location of the host window <NUM> and the hosted window <NUM> to determine whether the user inputs <NUM> are directed to the hosted window <NUM>. For example, the system input handler <NUM> of the operating system <NUM> may be configured to determine an area of the display associated with the hosted window <NUM>, such as, for example, via the system bridge window <NUM> or the system hosting application process <NUM> owned by the operating system <NUM>, and compare the determined area to the location of the user input <NUM>. The system input handler <NUM> may be further configured to route user inputs <NUM> from the area of the display <NUM> associated with the hosted window <NUM> to the hosted window <NUM> directly. That is, the system input handler <NUM> may route user inputs <NUM> that are determined to be directed towards the hosted window <NUM> directly to the hosted window <NUM> without passing through the first application <NUM> and the host window <NUM>. As illustrated in <FIG>, the example user input 40A is located within the area of the display <NUM> associated with the hosted window <NUM>, and is thus routed to the hosted window <NUM> and the second application <NUM> directly from the operating system <NUM>. On the other hand, the example user input 40B is located outside of the area of the display <NUM> associated with the hosted window <NUM>, and is thus routed to the first application <NUM> from the operating system <NUM>.

Turning back to <FIG>, after the system hosting application control <NUM>, the system hosting application process <NUM>, and the webview process for the second application <NUM> have been launched according to the processes discussed above, the system hosting application control <NUM> is further configured to create the out of process webview control <NUM> configured to route navigation controls <NUM> from the first application <NUM> to the second application <NUM>. As illustrated, the out of process webview control <NUM> of the cross-process interface <NUM> is included in the system code <NUM> being run within the process of the first application <NUM>. The system hosting application control <NUM> may be configured to initialize the out of process webview control <NUM> with the instance of the webview process for the second application <NUM> that was launched by the system hosting application control <NUM>.

The out of process webview control <NUM> may be configured to make calls to the webview process of the second application <NUM> that is out of process from the process of the first application <NUM> that includes the out of process webview control <NUM>, and receive callbacks from the webview process to perform web related API functions. The out of process webview control <NUM> may include API functions that are recognized by the first application <NUM> that is configured for the user interface framework <NUM>. Using the API functions exposed by the out of process webview control <NUM>, the process for the first application <NUM> may interact with the out of process webview control <NUM> to route navigation controls <NUM> to the webview process of the second application <NUM>. The navigation controls <NUM> are 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 are routed as navigation controls <NUM> from the process of the first application <NUM> to the webview process of the second application <NUM>.

In the manner described above, the process of the first application <NUM> may interact with and exchange rendering information with a webview process of the second application <NUM> that is built on an incompatible user interface framework by establishing the cross-process interface <NUM> including the out of process webview control <NUM> and the system hosting application control <NUM>.

<FIG> and <FIG> illustrate a schematic view of a specific WINDOWS implementation of the cross-process interface <NUM>. It will be appreciated that the broader concepts described in the specific implementation of <FIG> and <FIG> for establishing a cross-process interface <NUM> may also be applied to other frameworks, such as, for example, Java and C#, with modifications to suit the specific characteristics of those frameworks.

At (S <NUM>) 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 control <NUM>).

At (S3) the instance of the Win32WebViewSite is configured to launch a Win32WebViewHost App (e.g. system hosting application <NUM>) and receive an instance of the Win32WebViewHost app as IHostedApp in <FIG>. 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 device <NUM>.

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 window <NUM> and 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 application <NUM>) with the CoreWebViewComponentCallback. The system bridge window <NUM> is attached (e.g. cross-process parenting <NUM>) to a backing HWND of a hosted window <NUM> of the process for the second application <NUM>.

At (S10) the WebViewManager returns a CoreWebViewComponent and the ComponentSite to the WebViewHost. The WebViewHost connects the ComponentSite to the system bridge window <NUM> of the Win32WebViewHost app.

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

At (S <NUM>) the Win32Web ViewSite will create an instance of the OutofProcess WebViewControl <NUM> runtime class.

At (S13) the Win32WebViewSite will initialize the OutofProcess WebViewControl <NUM> with the CoreWebView ComponentCallback and CoreWebViewComponent. The OutofProcess WebViewControl <NUM> will make an instance of CoreWebViewControl with the CoreWebViewComponentCallback and the CoreWebViewComponent.

After (S1) - (S13) have been completed, the Win32WebViewHost app (e.g. system hosting application <NUM>) 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 parenting <NUM>) to the backing HWND of the host window <NUM> of the host application process (e.g. process for first application <NUM>) 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 application <NUM>) retrieves the OutofProcess WebViewControl <NUM> from the Win32WebViewSite.

At (S16) the host application may call Navigate on the OutofProcess WebViewControl <NUM> to route navigation controls <NUM> to the Out of Process webview. For example, the Navigate call will be routed through the OutofProcess WebViewControl <NUM> and 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 application <NUM>).

It will be appreciated that the architecture illustrated in <FIG> and the method (S1) - (S16) shown in <FIG> using the architecture of <FIG> are a specific example implementation for a Win32 to UWP cross-process interface <NUM>. While the steps and architecture of <FIG> and <FIG> are 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> is a flowchart of a method <NUM> implemented by a computer device. Method <NUM> is executed using the systems described above or utilizing other suitable hardware and software elements.

At <NUM>, the method <NUM> includes executing a first application configured for a first user interface framework. The first application is built on Win32. A process for the first application <NUM> is illustrated in <FIG>.

At <NUM>, the method <NUM> includes instantiating a host window of the first application using the first user interface framework. The instance of the host window <NUM> includes a handle (e.g. HWND) to the host window <NUM> that is recognized within the first user framework <NUM>. However, it will be appreciated that other platforms/frameworks may use other handles to manage their windows. An instance of the host window <NUM> is illustrated in <FIG> and <FIG>.

At <NUM>, the method includes 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. The second application is a web application that is built on UWP, which is incompatible with application built on Win32. 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 framework <NUM> does not natively include a control, such as, a webview controller/manager, that is configured to launch and manage a webview for an application configured for the second user interface framework <NUM> to present rendering information <NUM> and other functionality (e.g. user interface) of the second application <NUM> within the first application <NUM>.

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. The first application <NUM> may 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.

At <NUM>, the method <NUM> includes 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 window <NUM>.

At <NUM>, the method <NUM> includes 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 incudes establishing a cross-process parenting between the host window and the hosted window. 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.

At <NUM>, the method <NUM> may 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> illustrates an example of a first application window <NUM> of the process of the first application <NUM> being displayed on a display <NUM> of the computer device <NUM>. The first application window <NUM> includes first application rendering information <NUM> that is rendered according to code of the first application <NUM>. Alongside the first application rendering information <NUM>, the host window <NUM> displays second application rendering information <NUM> from the hosted window <NUM> via the cross-process interface established at step <NUM>. In this manner, rendering information from both the first application and the second application are presented via the display <NUM> in a unified view.

The cross-process interface further includes an out of process webview control. At <NUM>, the method <NUM> includes routing navigation controls from the first application to the second application. 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 control <NUM> may be included in system code <NUM> being executed within the process of the first application <NUM>.

At <NUM>, the method <NUM> may include routing user inputs from the area of the display associated with the hosted window to the second application directly. <FIG> illustrates an example of a system input handler <NUM> routing user inputs based on a location of the user input on the display compared to the known positions and sizes of the host window <NUM> and its child hosted window <NUM>. 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.

The methods and processes described herein may be tied to a computing system of one or more computing devices.

<FIG> schematically shows a computing system <NUM> that can enact one or more of the methods and processes described above. Computing system <NUM> embodies the computer device <NUM> described above and illustrated in <FIG>. Computing system <NUM> may 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.

For example, the logic processor is configured to execute instructions that are part of one or more applications, programs, routines, libraries, objects, components, data structures, or other logical constructs.

Claim 1:
A computer device (<NUM>) comprising:
a processor (<NUM>) configured to:
execute an operating system at the computer device;
execute a first application (<NUM>) within the operating system executed by the processor of the computer device, the first application configured for a first user interface framework (<NUM>);
instantiate a host window (<NUM>) of the first application (<NUM>) using the first user interface framework (<NUM>);
execute a second application (<NUM>) within the operating system executed by the processor of the computer device that is out of process with the first application (<NUM>), the second application (<NUM>) configured for a second user interface framework (<NUM>) that is incompatible with the first user interface framework (<NUM>), wherein the first user interface framework and the second user interface framework are incompatible at least by having no native control in the first user interface framework (<NUM>) to host the second application of the second user interface framework (<NUM>);
instantiate a hosted window (<NUM>) of the second application (<NUM>) using the second user interface framework (<NUM>);
establish a cross-process interface (<NUM>) configured to exchange communications including rendering information (<NUM>) between the hosted window (<NUM>) of the second application being run in a first process of the operating system and the host window (<NUM>) of the first application being run in a second process of the operating system that is out of process with the first process; and
cause the host window to display the rendering information (<NUM>) rendered by the second application and exchanged from the hosted window (<NUM>) to the host window by the cross-process interface within the host window (<NUM>) on a display (<NUM>) of the computer device (<NUM>);
wherein the cross-process interface includes an out of process webview control configured to route navigation controls from the first application to the second application.