Run Windows Apps on Linux using 2X ApplicationServer
I recently read an article describing how to run Windows apps on Linux using 2X ApplicationServer with Windows running as a virtual machine (VM) on the local system. It's a really cool sounding idea and overcomes some of the compatibility problems of Wine, but always having a Windows VM active consumes a lot of resources and may not always be the best solution. If you are running in a networked environment, and have an available computer running Windows, a better solution may be running the applications directly from that one system.
This solution is particularly effective when multiple Linux clients need occasional access to Windows apps or for doing high compute or I/O intensive tasks.
While this approach has a lot of advantages, there are many interesting usage cases and not all of them fit. Let's take a look at the tradeoffs.
Local Virtual Machine
- Portable (doesn't need to be connected to a network)
- Network speed is not a factor in performance
- Have the VM itself as an alternative for programs that don't run well over RDP (details below)
- Requires more memory for the VM
- Consumes more power on the local system due to virtualization overhead
- Higher cost (each client must have a copy of the full OS and any needed applications)
- Computation and I/O performance is lower than native
Over the Network
- Computation is offloaded to the server so it doesn't impact the client resources as much
- Small memory footprint
- Low cost (only one copy of the OS and each application is needed)
- Requires an active network connection that both the client and the server have access to
- Network speed can impact performance
- Requires a separate computer for the server
- Not all apps can be run over RDP (details below)
- Portable (doesn't need to be connected to a network)
- Best performance on graphically intensive apps (i.e. video, games)
- Low cost (only copies of the application are needed on each client)
- Small memory footprint
- Many apps, particularly newer ones, are not compatible
Installing 2X ApplicationServer
Download the 2X ApplicationServer binary from http://www.2x.com. The free version allows for up to 5 applications running at once which should be plenty for a single user system.
Run the executable and follow the onscreen instructions.
You should also make sure that the user you plan to log on as is either an Administrator or belongs to the Remote Desktop Users group.
Installing 2X ApplicationServer Linux Client
Make sure to download the ApplicationServer and not the TerminalServer binaries.
On rpm based systems
sudo rpm -i 2xApplicationServerClient3.i386.rpm
On deb based systems
sudo alien --scripts -i 2xApplicationServerClient3.i386.rpm
By installing the rpm this way on a Debian based system it can be removed later through your package manager or using apt-get. The package name is applicationserverclient.
If you get an error from the running the scripts you will need to install the .bz2 version instead. To do that, download the file into your home directory and run the following commands.
tar xvjf 2xApplicationServerClient3.tar.bz2
sudo chmod 755 install.sh
Starting the Client
Assuming you are still in the scripts directory, type the following command to get to the bin directory.
Next you need to start the client and connect to the ApplicationServer. The first line below shows the syntax you need to use and the second is an example. You'll need to adjust the values to match your system.
./appserverclient -s"Server IP" -a"Application Name" -u"User Name" -p"Password"
./appserverclient -s192.168.1.5 -a"Internet Explorer" -uAdministrator -ppassword
To prevent always having to navigate to the programs directory you could add it to your PATH. A couple other potential options I haven't tried are moving the binary to /usr/share/bin, which is alread in the PATH, or setting up symlinks from that directory.
Hopefully 2X will add support to a future version for a graphical client that can list the published apps. The Windows client already has this capability. In the meantime, I suggest creating menu entries for each of the apps you have published. It's simple to do and will save you from repeated trips to the command line every time you want to use one of the programs.
How Well Does It Work?
The first problem I experienced was that I connected to the full desktop instead of the application I requested. After a little investigation I discovered that a user cannot already be logged into the Windows system. This restriction is due to my using Windows XP Professional. It only supports a single user being logged on when using Terminal Services. Fast User Switching didn't help to bypass this limitation. I suspect the server version would allow more users to be logged in.
After logging out of the Windows system and trying again, I ran into a new problem where I connected and logged in, but the app never appeared. The problem was that port 20002 needs to be open, but Zone Alarm was blocking it. Since I couldn't figure out how to open a single port, I turned it off for the duration of the test.
This time my requested app loaded as expected.
I tried running applications from two different client machines. My desktop was connected to the server over a gigabit Ethernet network. My laptop was connected to an 802.11g wireless network. Both performed equally well. I occasionally saw a slight lag when scrolling, but it was not due to the network bandwidth. I also tested using Windows' Remote Desktop and saw the same performance.
Any app that doesn't have a lot of visual change is a good candidate for this technique. This includes Word, Excel, Outlook, and Internet Explorer, among others. I'll discuss audio and video in the next section.
Limitations Using Microsoft's RDP Protocol
RDP needs to support the program for it to work. There are problems with full screen apps that need overlay or hardware acceleration. I also had difficulty with some audio and video.
Audio and video can be played back over RDP, but it doesn't always work. I particularly had trouble playing Windows Media files, but some others had difficulty as well. As for video, it will be choppy.
I also tried running BeyondTV Link and I got an error saying that it could not start normally and that the interface would run in software only mode. It still works, but the performance and features are degraded. I wouldn't recommend this kind of use either.
2X ApplicationServer is a useful solution for those who still need access to some Windows only apps, but prefer to work in Linux. As long as the program isn't visually intensive then it can run quickly over RDP and you avoid the compatibility headaches of Wine. Testing out the apps you are interested in using Krdc or tsclient is a quick way to find out if this method will work for you.
In a networked environment loading programs from ApplicationServer can reduce a lot of management headaches by consolidating down to only one copy of Windows that needs to be kept up to date. It's also less expensive because you can use the same copy of an app whether you are connecting from a Linux desktop or laptop.
Connecting to an ApplicationServer over the network could be a good solution for a small business that primarily uses Linux, but still has a small number of Windows apps that they can't get away from. It's also useful for the home user who already has multiple networked computers with at least one running Windows.
The only real negatives versus the local VM approach are the dependance on being connected and the need for another system to be the server. For a desktop the connected requirement shouldn't be an issue, but laptops may find it troublesome if there is a frequent need to use a Windows app while traveling. These two factors will dictate which option you choose.
As I mentioned earlier, there are some key limitations to using the ApplicationServer approach, particularly when dealing with visually intensives apps. If that describes your app then you'll need to fall back to Wine or run the app directly from a VM. You should also try Wine first if you don't already own a copy of Windows.
A local virtual machine will become a better solution over time as hardware support for virtualization continues to improve, but it's not quite there yet. If you have the system resources and multiple copies of the software won't be needed then this approach can be attractive since you can run apps directly from the VM when they don't work over RDP.
Which option you choose depends upon what you want to accomplish. All of them require a little know how to get them configured, but hopefully the examples I presented can help you get started.