Wine, ChromeOS and Cross-Platform Computing in the Cloud Age
You can't run Windows applications on Google's ChromeOS, and you probably will never be able to, since the Wine emulator for loading Windows software on Linux platforms won't work with Linux-based Chromebooks. That may not matter at all to most people, but it is a reminder of how mobile and cloud-based hardware devices are making OS interoperability increasingly rare.
You can’t run Microsoft (MSFT) Windows applications on Google’s ChromeOS, and you probably will never be able to, since the Wine emulator for loading Windows software on Linux platforms won’t work with Linux-based Chromebooks. That may not matter at all to most people, but it is a reminder of how mobile and cloud-based hardware devices are making OS interoperability increasingly rare.
For the non-geeks in the audience, Wine is a program that makes it possible to run Windows software on Linux PCs. And while most people using Linux full-time are unlikely to want to run many Windows apps, since Linux offers its own line-up of software for achieving almost any task you can think of, Wine comes in handy in the cases of software such as Netflix, which lacks a native Linux client or equivalent app.
Wine has been around for more than two decades and works pretty well on most Linux desktops, laptops and servers (not that there is really any good reason for running a Windows app on a Linux server). But since Wine depends on parts of the Linux operating system that are not always available in the Linux variants used to power many smartphones, tablets, smart TVs and Chromebooks, configuring Wine for them is more problematic.
Wine developers are making progress toward implementing Wine for Android, which is one of those Linux variants, although it appears that it will be at least a little while before Wine can run Windows apps on Android just as well as it can on traditional Linux systems.
Meanwhile, for users of ChromeOS, which is also based on Linux but is substantially different from the Linux kernel code, the outlook is much more dismal. As Phoronix has reported, it will probably never be possible to make Wine run on ChromeOS in anything approaching a user-friendly way, since Google restricts the access of third-party applications to the parts of the system that Wine needs to work its magic.
Again, that’s not a pitfall that’s going to stop very many users at all from purchasing a Chromebook, since no one buys a Chromebook to run Windows apps unless he’s some sort of sadistic geek. But there is a certain irony in the fact that in the age of the cloud, which was supposed to eradicate the barriers between different computing platforms and operating systems, the devices designed with a core focus on the cloud are also the ones that, because of restrictions or exclusions within the code that powers them, are emphatically un-cross-platform. (Is that a word? It is if I use it!)
All of this, by the way, is to say nothing of the challenges ARM hardware poses to Wine, which was not made for ARM at all and currently has to rely on a virtualization hypervisor such as QEMU to work on ARM-based devices. That’s a second way that the cloud is making cross-platform compatibility such a challenge.
Errrr, wine is not an
Errrr, wine is not an emulator!
You’re right, and I usually
You’re right, and I usually point that out whenever I write about Wine. This time, doing justice to the technicalities seemed too tangential to the story itself, but thanks for the reminder.
Wine Is Not an Emulator
Wine Is Not an Emulator
The cloud is the
The cloud is the platform.
Just as more and more people use web based email and don’t have a local client installed so in the future more and more people will simply have a fast internet connected device and will communicate with a virtual machine running what ever operating system and applications you want (for a price of course) or just running a web based application of what used to be a locally installed application.
I fail to see the point of running Wine. (I’m sure there is a minority for whom it is essential but in the marketplace they are non-players whether they like to think that or not.). For most people it is not worth running Windows applications on Linux using Wine. If the Windows applications are that important you should be running Windows.
If one has mirror applications on Linux and Windows then the only real need is to be able to read and write file formats. Given all the applications available for Linux, there is little reason to run general purpose Windows applications outside of work.
Unfortunately, Linux never got enough traction for the enterprise to take notice and institute procedures for using it like they have done with BYOD for tablets and phones which don’t run Windows.
If the business world won’t get its head out of Microsoft’s rear and make Linux a default desktop environment then there is little hope that Linux will ever move beyond being a primarily back-end system.
The point of running Wine?
The point of running Wine? In my case, to play Starcraft. There is definitely no Linux equivalent.
Currently, WINE is best as a
Currently, WINE is best as a way to run Win32 code on a Mac. Wine Bottles makes this really easy, and the end result is an app that launches almost as fast as a native app – as opposed to Parallels, which needs to boot (not to mention buy) a virtual copy of Windows before your app can run.
That said, if you’re assuming Chromebooks are the future, you’re not talking about running legacy desktop apps. WINE might be able to enable some kind of linux based way to run multiple copies of a win32 app and export the UI via RDP or ICA or some other mechanism.
Where WINE has a real future is to get legacy win32 apps to run on the sure to come Android laptop and desktop machines. Either via ARM emulation or a native ARM version of Winelib that lets you build the win32 source as a native Android app. Come to think of it, the same applies for win32-Metro conversions. If they can do it for the Mac, anything’s possible. Of course, the Mac version is still X-Windows based. A better alternative would be to retarget the WINE GUI towards QT or maybe Chrome’s portable GUI layer. Then winelibs could target just about any system (maybe even ChromeOS).
Google has it’s own native
Google has it’s own native client implementation, creatively called “NativeClient”, which allows the running of native code ported over to the NativeClient virtual machine. Several native Windoze apps have been ported.
Disclaimer: I am Jeff Nelson, a former Google employee and the original inventor of ChromeOS. More analysis of ChromeOS at: blog dot jeff-nelson dot com.