I spent part of a day last week attending a marketing event on desktop virtualization. You know the type of event I mean. A local partner of some big software player uses some of the co-op dollars the big player has, and they feed you lunch, and bombard you with PowerPoint about The Next Big Thing.
There’s nothing wrong with these events. In fact, I like them, because they are a good way to get answers directly from the vendor’s reps. And a lot of the time, I get a pretty good meal out of it. But I left today’s event pondering the state of desktop virtualization. More correctly, I left it pondering the need for desktop virtualization - or at least application virtualization.
In application virtualization, an “invisible” thin virtual machine runs the app, totally isolated from the system it runs on. No direct registry access, no usage of locally installed DLLs, etc. This means the app can be copied to the PC it runs on easily, run without regard to what might already be on the PC, and updated fairly easily by updating a master image of the application.
But come with me now, as we step into the Wayback Machine, and return to a simpler time.
In days of yore, Windows applications stood alone. Configuration information was carried in things we knew as INI files. Program libraries were kept in the directory with the program’s executable. An application could be installed by creating a directory, and copying the application files to the directory.
Ah, how things have changed since those days. We now have a centralized application configuration database - in the form of the registry. We also now have shared libraries - DLLs - populating our hard drives. These things have been with us on the desktop since Windows 95, and things have been complex ever since. The complexity has grown as desktop operating systems became capable of application customization based on the logged on user - sections of the registry that were user specific. And now in the timeline, it’s application virutalization. An amazing effort to abstract the registry and the DLLs and all their inherent management problems.
Think how easy it would be to “virtualize” an application if it didn’t use the registry, always looked in it’s own folder for it’s own DLLs, didn’t rely on COM, etc. etc. Pushing a “virtualized” app to the desktop would be as simple as running xcopy. Look for an example to the “portable” apps being produced to run from a USB thumb drive.
Am I the only one who looks at the history here, and feels a sense of irony?
We complicate the environment, then jump through hoops in the form of layers upon layers of desktop virtualization tools, to enable apps to run independently of the complex environment that we have created.
What were we thinking?
Although my crystal ball is usually cloudy, I’ll make a prediction here. In the future, we’ll see a desktop OS that is designed for application virtualization from the ground up. It will provide a nice UI. There won’t be a registry - at least for applications. While the OS may use a set of shared libraries, the apps won’t use those libraries - at least not like they do now. There will be some form of granular inter-process communications that can be controlled, to allow some apps to talk to others. Apps will “register” at run time and “check out” at termination.
And because the OS will be designed for application encapsulation, all the applications included with the OS will themselves be encapsulated, and therefore easily removed or replaced. And if the OS gets corrupted, it can be reinstalled without requiring the reinstallation of all the applications.
Of course, this would all require a radically different desktop OS, and backward compatibility would be a nightmare of kludgy components.
Wait - what am I thinking?