Sandbox Could Be Key to the Future of Windows (Premium)

With Windows Sandbox, Microsoft is taking a big step towards doing exactly what I’ve been calling on the company to do for years: Figure out a way to isolate, or contain, legacy desktop applications from the system in a way that doesn’t require a complex and manual Desktop Bridge conversion process.

What amazes me most about this development is that Microsoft has been working on the underlying technologies necessary for this solution for decades. And I can only assume that the firm’s terrible side-track into a so-called “modern” app platform—first in Windows 8 but continued in Windows 10—is what delayed its inevitable appearance now. But there’s no reason to cry over a lost decade. Microsoft is finally on the right track.

That said, there’s a long way to go, too. From what I can tell, Sandbox functionally brings us back roughly to the initial desktop virtualization solution that Microsoft first introduced to enterprises in the early 2000s in the form Microsoft Enterprise Desktop Virtualization (MED-V).

For those unfamiliar, MED-V was based on the Virtual PC technologies that Microsoft had acquired with Connectix in 2003, adding an IT-controlled management layer. It allowed businesses to upgrade PCs to the latest Windows version while running an older Windows version, with specific applications that were incompatible with the host OS, in a virtual environment. Those applications appeared in the Start menu alongside native applications and each could run side-by-side. So it was a theoretically seamless experience for users.

Microsoft later provided a truly seamless application virtualization called Microsoft Application Virtualization (App-V). With App-V, each virtual application that was deployed to a client PC ran in its own self-contained virtual environment. So each virtual app was isolated both from the host PC and from any other virtual applications. App-V is more elegant than MED-V from the user’s perspective, and it requires fewer system resources on the host PC. But it does require a server infrastructure by which these virtual applications are “streamed” to client PCs.

Sandbox is not the same thing as MED-V or even Virtual PC. But like MED-V, it relies on a PC-hosted virtual environment that provides a full desktop experience inside of a window on the host PC which is, to that host PC, just another application.

That virtual environment is far more efficient than MED-V ever was 15 years ago.

For one, it runs on the hypervisor used by Hyper-V, offering better performance and hardware integration. And the virtual environment itself is, as Microsoft says, more “lightweight” than a full virtual machine because it doesn’t use a big virtual hard disk (VHD); instead, it just makes a copy of the necessary parts of the host PC’s installed OS.

Furthermore, where the virtual environment provided by MED-V was persistent and could thus change over time, that provided by Sandbox is new, or “pristine,” as Microsoft puts it. “It’s as clean as a brand-new installation of Windows,” Microsoft notes. It’s also disposable and temporary: When you close the Sandbox, that virtual environment disappears forever.

Finally, the goal with Sandbox is also quite different. Where MED-V (and App-V) were designed to solve a legacy application compatibility problem (using different solutions), Sandbox is designed for those who want to test a new (to them) application in a safe environment instead of installing it right on their PC.

Today, we still need a way to run legacy (i.e Win32 desktop) applications in a secure and isolated fashion in Windows. And we need this both in businesses and on home PCs used by normal users. But Microsoft ignored that strategy for years for a variety of reasons, despite having brought the Hyper-V hypervisor that’s required to the Windows client many years ago.

We can blame hubris. Thanks to its successful past as a maker of platforms, Microsoft never stopped creating new and proprietary runtimes and application models long after developers had stopped caring. Its terrible Universal Windows Platform (UWP) is both the latest and, I think, the last example.

Under Satya Nadella, Microsoft has reversed course on its insane bid to get developers to abandon old code—even for successful mega-applications like Microsoft Office and Adobe Photoshop—to embrace its new, unproven, and immature UWP apps platform. It has expanded the definition of what it means to be a “Store” app to include all kinds of new application types, including not coincidentally something called Desktop Bridge apps, which provides a path forward for developers with Win32 desktop applications.

The problem with Desktop Bridge apps, however, is that it requires developer buy-in. If Adobe, say, never bothers to adapt Photoshop to be wrapped in a Desktop Bridge container, it can never be deployed by the Microsoft Store. And it can never run in S mode, the (supposedly) secure new Windows 10 runtime environment that has never gained any traction at all for precisely this reason.

Without getting into the issues with S mode, the problem with Desktop Bridge is that it cannot be applied automatically to any application. And while I’m sure there are legal and technical reasons for this, I’ve always believed that Windows should offer a way—perhaps in S mode only—in which any application downloaded from the Internet is somehow wrapped in a container, or virtual environment, or whatever, and isolated from the system, seamlessly, for the user.

In other words, downloaded applications should be sandboxed.

Windows Sandbox, again, does not address this need. Not yet. But it does represent, I think, a first step in a new effort under the new Microsoft to begin addressing this need. This first step is for testing purposes only. But while it does require a virtual environment of some kind, that environment is at least streamlined and more efficient than similar solutions from the past. Is there some way for the client OS to “stream” the bits of itself that a virtual app needs? For this thing to become a sort of local version of App-V that makes sense for the modern PCs of today and tomorrow?

I think so. And I continue to believe that Microsoft will be able to modernize and simplify Windows itself while retaining backward compatibility with Win32 desktop applications using a solution that is something like this. That is is how Windows can finally move forward.