They’re allowed to launch external processes, but these external processes are additionally bound by the same restrictions the app is bound to.
They’re not even allowed to change their working directory. These UWP apps are all launched inside a “low integrity app container”, which basically means they have effectively no permissions on 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. At the time, “UWP applications” had special restrictions placed on them by the OS. That would immediately grant us access to UWP XAML and the whole WinUI 2 library, which has native controls, styles, and capabilities built specifically for Windows apps. We made the choice to build Windows Terminal as a UWP application. We wanted to make sure that it was visually consistent with other inbox applications and followed Fluent Design principles. 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 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. We, as the Windows Terminal team, had just started getting conpty into a place that was good enough to be useful as a translation layer between the console and a terminal application. This was around the time the first prototyping of the application that would become Windows Terminal began.
The history of WinUI and Windows Terminal goes back to December 2017. This blog post goes into the history and architecture of how these two technologies came together. WinUI and Windows Terminal have a strong relationship that goes back to the origins of Windows Terminal.
0 kommentar(er)
