{"id":6104,"date":"2020-09-08T11:24:51","date_gmt":"2020-09-08T18:24:51","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/commandline\/?p=6104"},"modified":"2020-09-08T11:24:51","modified_gmt":"2020-09-08T18:24:51","slug":"building-windows-terminal-with-winui","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/commandline\/building-windows-terminal-with-winui\/","title":{"rendered":"Building Windows Terminal with WinUI"},"content":{"rendered":"

WinUI and Windows Terminal have a strong relationship that goes back to the origins of Windows Terminal. This blog post goes into the history and architecture of how these two technologies came together.<\/p>\n

History<\/h2>\n

The history of WinUI<\/a> and Windows Terminal goes back to December 2017. This was around the time the first prototyping of the application that would become Windows Terminal began. We, as the Windows Terminal team, had just started getting conpty<\/a> into a place that was good enough to be useful as a translation layer between the console and a terminal application. We knew that we wanted to have conpty be able to power a new terminal application, allowing us to build a new user experience for the command line on Windows.<\/p>\n

When we were in the earliest planning stages for Terminal, we knew right off the bat that we wanted to be able to build a modern application that used the best features the Windows platform had to offer. We wanted to make sure that it was visually consistent with other inbox applications and followed Fluent Design principles.<\/p>\n

We made the choice to build Windows Terminal as a UWP application. That would immediately grant us access to UWP XAML and the whole WinUI 2 library<\/a>, which has native controls, styles, and capabilities built specifically for Windows apps. At the time, “UWP applications” had special restrictions placed on them by the OS. These security features ensured that UWP apps delivered by the Microsoft Store were unable to access restricted locations within the OS, or leave artifacts laying around on disk, to simplify the uninstall process. These UWP apps are all launched inside a “low integrity app container”, which basically means they have effectively no<\/em> permissions on the OS. They’re not even allowed to change their working directory. They’re allowed to launch external processes, but these external processes are additionally bound by the same restrictions the app is bound to.<\/p>\n

Therefore, if we wanted to build Terminal as a UWP app in 2018, then any of the shells that we would spawn (like cmd.exe, powershell.exe or bash) would be unable to do anything to the system. Could you imagine using your shell without being able to change directories, read file contents, or launch any other processes that you could interact with? Obviously, this was a non-starter for us.<\/p>\n

We spent a good portion of that year discussing our options with a number of teams across the Windows organization. We considered options like a special restricted capability for launching full-trust processes from a UWP. We tried pushing on allowing UWP apps to run outside the app container. However, most of the routes we pursued ended up either as a gaping security hole, or as something that would require years of effort across the organization. (In fact, many of these discussions helped lead to the effort now known as “Project Reunion<\/a>“, as well as the WinUI 3 effort<\/a> that extends the modern UI framework to Desktop apps).<\/p>\n

XAML Islands<\/h2>\n

Fortunately for us, the solution was actually closer than we thought. Just down the hall from us was the WinUI team, and little did we know, they had been building XAML Islands<\/a> for the better part of the previous year. XAML Islands would enable a traditional Win32-style application to host UWP XAML content within its window without the traditional restrictions of a UWP application. As it turns out, this was exactly<\/em> what we needed.<\/p>\n

What we ended up building was an application that was composed of two parts:<\/p>\n