Thinstall + Wine = Windows apps without Windows?

At my training class in Brisbane last month, one of the students, Sharin Yeoh, demoed Microsoft Office 2007 running locally on a Linux desktop via Thinstall packages on Wine. My inner geek response was "This is the coolest thing I've ever seen!"

At my training class in Brisbane last month, one of the students, Sharin Yeoh, demoed Microsoft Office 2007 running locally on a Linux desktop via Thinstall packages on Wine. My inner geek response was "This is the coolest thing I've ever seen!" As we watched Sharin poke around the applications, the whole class sort of had a simultaneous thought: "If we can run Windows apps in Linux, why do we need Windows?"

This sounds like a crazy idea, and probably not realistic. But it's fun to think about...

First things first, what is Thinstall and Wine? Most of you probably know that Thinstall is VMware's application virtualization product. It lets you package Windows applications into single-file EXEs that can then be copied or streamed to any Windows desktop. The apps run right out of the packages and don't conflict with apps that are natively installed on the Windows machine.

Wine is an open source implementation of the Microsoft Windows API that can be used to run Windows applications on non-Windows platforms, like Mac and Linux.

So to get Office 2007 on Linux, Sharin used Thinstall to build a standard Office 2007 Thinstall package, then she installed Wine on Linux and ran the "thinstalled" Office EXE on Wine. Simple! ;)

Ironically (and a bit off topic but very cool), Thinstall and Wine are not too different conceptually. They both emulate a Windows API calls in their wrappers, although Thinstall's purpose for doing so is to ensure that apps don't conflict with each other or native apps, and Wine's purpose is to translate all the native Windows API calls into calls the host OS can understand. Thinstall's CTO (and now VMware employee) Jonathan Clark has a great blog post about the similarities between Thinstall and Wine.

And since we're still wandering off topic, I should point out that I'm only focusing on how Thinstall runs on Wine because it's the only app virtualization product I'm familiar with that will even run on Wine. The other major app virtualization players: SoftGrid, Citrix streaming, and Altiris SVS all use a file system filter driver to intercept and redirect file system and registry calls the application makes. That's fine enough for isolating apps on Windows, but unfortunately it means those products won't work on Wine since Wine is a user mode-only implementation that doesn't work with drivers. How does Thinstall get around this? Remember, Thinstall has its own implementation of many Windows API calls, so it operates at the API interface to the app, before the app even has a chance to touch the file system. (By the way, my sense is that Xenocode might get around this too based on what I've read about their product, but I've never used it so I don't know for sure.)

Back on topic now.

How feasible is this "Windows apps without Windows"?

Not feasible at all, really.

First of all, Thinstall was not designed to run Windows apps in Wine. Besides being completely unsupported, there are plenty of cases where apps run fine via Thinstall on Windows, but they don't run on Wine.

And then there's the complexity of running Thinstall and Wine. This may lead you to wonder why you should even bother with Thinstall? Why not just use Wine? By adding Thinstall to the mix, you could deploy the same package to all desktops--Windows and Linux. And there are some other compatibility benefits you could get, like the fact that in Wine it's often the installation of the application installation that fails, not the actual app execution itself. Since Thinstall removes the "installation" portion from Wine, there could be a benefit there. And Thinstall virtualizes a bit more than Wine, so there could be cases where an app that won't run on Wine natively will run in Thinstall on Wine.

But really this is crazy. It's a lot of work. Who in the world would go to all this trouble.. Thinstall + Wine + Linux + who knows what? And what about the new Office Genuine Advantage?

Instead of going to all this trouble, why not just run VMware Workstation for Linux with a locked-down Windows VM with seamless windows just for those few specific Windows apps you need in Linux? (Kind of like that whole "employee-owned PC thing.")

What's the point?

But using a Windows VM on a Linux workstation is not what this article is about. This article is about a future without Windows, and Windows running in a locked-down VM is still Windows. This leads to the larger question: Who cares?

Who cares about a world without Windows? Well, probably Microsoft. And the Slashdot community. They'd love to see a Linux-based world.

You know who doesn't care? Enterprises. Enterprises couldn't care less about Linux on the desktop. Why is that? First of all, many enterprises are already starting to break the cycle of always upgrading to the latest version of Windows. Vista has less than 10% of the enterprise desktop market today, and more companies every day are just saying "Screw it! We're waiting for Windows 7."

But the reason that enterprises don't care about Linux is because all their apps are Windows apps. So a non-Windows desktop was never (or will never be?) an option for them. Even for companies whose devices run Linux (or Mac), they're still running some Windows apps somewhere, which means they're still paying for a Windows client license somewhere (either VECD or TS CAL).

And really at the end of the day, a Windows desktop costs what, $100 per year, per user? That's nothing. Probably cheaper than Thinstall actually. And much cheaper than trying to cobble together your own solution based on a billion different little GPL versions of everything you need.

So I guess Windows is here to stay, at least for the next five years. Next week let's talk about RIAs!

Dig Deeper on Application Management



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: