Developing for Windows 10X and the Surface Neo

Microsoft’s next generation of Windows has been teased for some time. The company started several years ago with rumors of a composable shell and a re-engineering of the Windows user space, going by the internal name WCOS (Windows Core OS). Two versions of WCOS-based OSes were announced: a now much-delayed (and possibly cancelled) version for the Surface Hub 2 wall displays and one that powers the second-generation HoloLens.

With CEO Satya Nadella’s long-stated focus on ubiquitous and ambient computing as the next model for end-user devices, it’s not surprising that Microsoft is working on an OS that can shift personalities and user experiences based on the different operating models of the devices it powers. So when the company unveiled the Surface Neo dual-screen PC at the end of 2019 alongside the Android-based Surface Duo, it wasn’t surprising to find out that it would run a WCOS-based OS, with a UI designed for dual-screen and touch-based hardware: Windows 10X.

Windows 10X development tools

Since that launch there’s been a lot of conjecture about how we’d build and deliver applications for the new platform. We can stop guessing now. Not only has Microsoft discussed in detail its Windows 10X application strategy, it has also shipped the first cut of developer tools with a new SDK and a dual-screen emulator for testing code built using the Windows 10X APIs.

Getting started with the Windows 10X and Surface Neo tools is easy enough. You need a minimum of four cores on an Intel development system running on a current Windows Insider Fast Ring build, 19.0.19555 or later, with at least 8GB of RAM. This is likely to be 21H1 for most PCs, and is from the same set of build branches as the Windows 10X version used in the emulator. On top of that, install the latest Visual Studio 2019 Preview and the current Insider preview release of the Windows 10 SDK.

Once you’ve downloaded the Microsoft Emulator, follow up by adding the Windows 10X emulator image from the Microsoft Store. Using the Store for Emulator and image should ensure that they’re automatically kept up to date. We’re still several months from the release of physical hardware and a final build of Windows 10X, so we’re expecting regular drops of updated images. An emulator manager lets you tune the amount of memory available to the virtual device, as well as whether it uses a physical GPU or not.

Writing code for Windows 10X dual-screen devices

Developing for Surface Neo and Windows 10X is going to be very similar to developing for Windows 10. It uses the same tools—even the same SDKs. Things differ in the added support for dual screens and the different design patterns associated with the new hardware. There are some issues that relate to the Windows 10X application isolation model, but most applications won’t be affected.

At the heart of the development model is a new Two-Pane View control that’s implemented as part of the new WinUI set of controls. This makes it available to both Win32 and Universal Windows Platform (UWP) applications, as well as to Web apps built on the Blazor Web assembly framework. It’s a XAML control, which automatically resizes and manages content layouts for primary and secondary views on a dual-screen device.

The control offers three views: single pane, wide with side-by-side panes, and tall with one pane above the other. Both wide and tall can be used with a single pane that spans both device screens. You won’t use the new view as your layout’s root element; Microsoft suggests using it inside a NavigationView control to give it context within your application navigation.

The panes themselves host XAML layout panels which host controls and content. As flexibility is a key aspect of Windows 10X’s application model, they should all be responsive layouts that can scale on demand, as another app running in a pane can prevent dual-screen operations. It’s worth experimenting with this control in the Windows 10X emulator to get a feel for how you would use it in your apps, perhaps adding it to an existing app so you can determine how it might operate on dual-screen hardware.

For a two-screen device like Surface Neo, it’s a good idea to design your application so that content splits neatly between the two screens. For example, an email application could use one screen to display folders and message headers and the other to display the content of a selected message.

Windows 10X has other operating modes that can take advantage of this type of view, using one screen as a controller and the other as a display surface. With editing controls on one display and the image you’re working with on the other, you can deliver a custom touch-based image editing environment, treating one of the displays as a custom keyboard. Taking advantage of portrait and landscape display options gives you many more options when working with Windows 10X.

If you’re planning on building cross-platform apps that work on both Surface Neo and Surface Duo, Microsoft’s Xamarin is developing a dual-screen SDK as part of its Xamarin.Forms tools. Code developed using this will run on both platforms, though you will need to consider different screen resolutions and how they might affect a responsive design.

With code built and ready to test, you can use the Windows 10X emulator as a debug target, using Visual Studio’s remote debug tools to connect to the Windows Device Portal on the emulated device. From the emulator you can set up Visual Studio integration (it should automatically be recognized in the Visual Studio 2019 Preview, and this makes it accessible from older versions to test existing code). Once that’s complete, it’s available as a target from the debug menu in Visual Studio. Microsoft recommends packaging apps for Windows 10X as MSIX, as this supports common Visual Studio languages and is compatible with both the Microsoft Store and direct downloads.

The Windows 10X application model

One of the more interesting aspects of Windows 10X is how it secures applications, using Windows’ own containers to isolate running applications from each other. That does put some restrictions on your code that aren’t there in earlier versions of Windows, making Windows 10X applications behave a lot more like WinRT applications in Windows 8. There’s no write access to OS-level features outside of a strict set of APIs, so you can’t have startup apps or apps that live in the toolbar notification area or modify the system registry.

You can still run Win32 apps on Windows 10X, as well as UWP (Universal Windows Platform) and Web apps. There’s no requirement to use the Microsoft Store—any installer can set up and run the application containers. Microsoft treats Windows containers as more than security boundaries; they manage resource and application lifecycles. All data for an app is hosted in the App Data folder, virtualizing the registry and managing the file system for the container. No app can affect another’s data, nor can it overwrite the OS, reducing the size of the Windows threat surface considerably.

If you’re using UWP or MSIX you get much of this on standard Windows 10. Where Windows 10X significantly differs is in its new Win32 Container. Designed to support legacy code on Windows 10X, existing apps all run inside a single container that hosts 32 bit and 64 bit code, working with any installer. There will be some compatibility issues, though Microsoft intends to keep these to a minimum. It’s built on the same thin hypervisor as WSL, with access to select parts of the Windows 10X file system as well as support for cut and paste through the container OS integration.

Windows 10X enforces a strict separation between OS, drivers, and apps. This allows rapid updates with minimal reboots, installing a new OS release and lifting and shifting the current running environment from the old OS to the new. That does require a reboot, but you can pick up work and carry on once the reboot is complete, in less than 90 seconds.

Some aspects of the new platform are still to be revealed: the Surface Neo dual-screen device and its OEM equivalents are being built around Intel’s Lakefield CPU, which offers the x86 equivalent of ARM’s big.LITTLE architecture, with a mix of high-performance and low-power cores. Microsoft has described how applications can declare an affinity for a specific core type, so that apps that don’t need much power can use the lower-performance cores. However, it hasn’t shown how to deliver support for this feature in your code yet.

With Windows 10X hardware still months away, Microsoft has sensibly decided to give developers access to an early version of the OS and the tools needed to build apps. Using a thin Hyper-V environment to host the emulator reduces overheads and should give a near-native performance. Even so, there’s still a lot for Microsoft to unveil, especially around power management. With its Build developer conference the logical place for further announcements, we can start building code now and take advantage of new Windows 10X features and SDKs as they roll out through 2020.