Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Modernizing Windows Desktop Applications with XAML Islands

Modernizing Windows Desktop Applications with XAML Islands

This item in japanese


If your only source of information is the Internet, you may be under the impression that Windows desktop development is pretty much dead. Yet according the telemetry data in Visual Studio, there are roughly 2.4 million developers actively working on desktop applications each month, up 50% from 20 months ago. (Metrics as of May, 2018.) With such a large community to support, Microsoft is looking at way to help developers integrate those assets into Windows 10.

XAML Islands

One of the biggest complaints about Microsoft Windows development is the lack of investment in Winforms and WPF; most of the new features exposed by Windows 10 are built soley for UWP. And despite the fact that we can now call UWP APIs from the .NET framework, that only works when the UI isn’t involved.

To address this, two new controls are being created: WinForms XAML Host and WPF XAML Host, which allow you to embed a UI written for UWP inside your existing WinForms/WPF application.

Wrapped UWP and Windows 7 Fallbacks

One of the reasons developers continue to use WinForms or WPF is support for Windows 7. Subsequently, a requirement for the new XAML Islands is the ability to function correctly when the application isn’t running on Windows 10.

One example is a WebView, which is available now. If the application is running on Windows 10, the web view will host the Edge browser. If you are instead running on Windows 7, an IE browser control will be loaded.

Other controls in the planning stages include MediaPlayer, InkCanvas/InkToolBar, Map, and SwapChainPanel.


Developers who have had to mix WinForms with WPF are familiar with the concept known as “airspace”, which deals with the problem of overlapping controls from difference UI frameworks within the same window.

In Win32 development, each object on the screen gets its own window handle (HWND) registered at the OS level. This HWND is associated with a rectangle on the screen where the object can render its content. Generally speaking, each WinForms control each gets its own HWND, while most WPF controls just share one HWND for the whole window.

For XAML islands (WinForms and WPF), a HWND is created for use by the UWP control. This can have some repercussions that aren’t obvious. For example, if you rotate the UWP control the HWND doesn’t rotate with it, which means the HWND needs to be larger to accommodate it.

Popup context menus can be especially difficult to deal with. These usually have their own HWND, but that HWND may not necessarily be stacked correctly with the HWND for the XAML island causing the menu to appear behind another control.

Threading Model

Currently with UWP, each top-level window is expected to have its own dedicated UI thread. Say, for example, you have a master-detail view where the detail view is written in UWP. There are several ways you can implement this:

  • Detail view shares the master view’s window: no problem.
  • Detail view has its own top-level window and doesn’t share objects: no problem.
  • Detail view has its own top-level window but shares objects with the master view: possible race conditions, UI cross-threading issues, etc.

Eventually this problem will be resolved with the introduction of lightweight windows.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Why WinForms is really still used

    by Jeff Jones,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    WinForms is still popular because the tools support rapid development - a feature that is not mature, or in the case of Xamarin.Forms, does not even exist in the XAML UI world of VS. It takes far less time to make a WinForms UI than UWP, WPF, or Xamarin UIs.

    And there is no reason for that. VB developers going back to VB1 in 1991 - 27 years ago - had a better UI designer than exists for XAML today! Existing XAML designers need to brought up to the standards and capabilities of WinForms in order to entice developers off WinForms.

    I have heard the excuse that "XAML is too complicated for a designer" - but such an excuse is a non-sequitur considering the existing XAML designers in VS.

    Come on Microsoft, put someone in charge who understands what rapid application development is, why VB gained its huge market share in the first place (hint: it wasn't the language), and understands the role that value engineering plays in making a successful, disruptive product.

  • Re: Why WinForms is really still used

    by Carlos Osuna,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    What really happened was a change of heart inside Microsoft they wanted to build a better browser and a more structured one, but still be as free as HTML.

    So XAMLs motto was “if you can code, we will render it” and not the other way as Visual Baic accustomed us from day 1. So actually creating a usable designer from that perspective is virtually impossible just like there’s never been a successful HTML UI designer.

    So that’s part of the reason WinForms still lives on.

    The other reason has more to do with a mistake made within Microsoft with XAML. Ever since WPF, MSFT has been too stubborn to understand that the flexibility of HTML is actually a hinderance not asset for modern XAML. The fact they haven’t changed the XML namespace since the sad days of Framework 3.5 prevents the designer from actually knowing if you’re coding for WPF, Silverlight (long gone), Metro (also gone), or UWP. They thought they were creating this “mighty morphing markup language” (MMML) that they forgot that not even the Use Cases were similar. WPF runs in a conventional Window, Silverlight inside a browser, Metro full screen, and UWP is back to WPF but more in a blob than an actual Win32 screen. Only Xamarin was wise enough to change the namespace.

    With that in mind you would need an extremely complex designer to even achieve basic rendering.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p