Ask Klaus!

Ask Klaus!

Article from Issue 108/2009


Interacting with Windows


Congratulations on your magazine, of which I'm a regular reader, although I consider myself an "intermediate-newbie" in *nix. I have a question regarding MS Windows and GNU/Linux coexisting on the same computer; I could find very little clear information.

The majority of PC/laptops sold worldwide come pre-installed with Microsoft Windows OS. Usually, GNU/Linux users have two solutions: 1) Erase the pre-installed Windows OS and install the GNU/Linux distro on the full HD or 2) Create a dual-boot installation by re-sizing the HD partitions and keeping Windows installed.

Although I'm aware it's possible to run Windows apps with Wine or to run Windows with a software virtualization solution, I was wondering if – assuming that Windows is pre-installed on sda1, a GNU/Linux distro is on sda2 (sda3 and sda5 swap files), and I boot under GNU/Linux – it would be possible to run the "pre-installed Windows" through a virtualization solution (on sda1), avoiding the need to "reinstall" Windows on the virtual machine and keeping the possibility of booting under Windows.

Also, because all the software programs preinstalled on the PC/Laptop have legal licenses, is it possible to configure Wine to "exploit" the Windows DLLs and resources that are found on sda1, with the expectation that it would improve the "compatibility" of Windows apps executed with Wine under GNU/Linux? Thanks in advance.


If you want to run Windows applications on Linux, you need to provide an environment for them that matches their "native" environment. One way is by running the original Windows OS inside a virtual machine. Another way is to simulate the windows OS by replacing proprietary parts with free ones that have the same interface, like Wine. Surely, the more "free" way is when no proprietary OS is involved to run a single application that otherwise would require a Windows installation.

A common case is programs that exist only in a "Windows version" with no equivalent native Linux-based solution. For example, the updating and control software for some well-known Linux-based navigation systems is only available as a Windows program.

With Wine [1], you can run some Windows applications directly on Linux. I say "some" because, under some circumstances, it might be difficult to get to a point at which a Windows program feels comfortable enough inside Linux to run with no major problems. The installer programs of Windows applications, especially, make assumptions and run checks that lead to results that confuse the installation process. Sometimes it is easier just to copy an already installed program with its full directory structure from a Windows installation to the corresponding C: tree in Wine's fake_windows directory if the installer doesn't work.

To see whether the Windows application in question works with the current Wine version and to see how to get it running if there are problems, check out the Wine application database [2].

The standard configuration of Wine defaults to use built-in shared "Windows" (-compatible) libraries that follow, more or less, the official Windows API specifications. However, in some cases, "undocumented features" (or deprecated internal function calls) in Windows programs exist that have not been implemented inside Wine. Or, additional, proprietary library components might be present that cannot be freely distributed inside Wine. For these, you can specify the (Linux) system path for Wine to find those components, which can override or add to the built-in functions (Figure 1).

Figure 1: Wine setup.

For your use-case scenario, your "genuine" Windows installation could be mounted and given a path to Windows C: drive. But, be aware that most Windows programs expect C: to be writable, so running a Windows program in a mounted Windows partition might well change your Windows setup and break things there.

The second way is to use a virtualization like qemu, kvm, or VirtualBox to "boot" directly from a Windows partition. In this case, the complete, originally installed Windows environment from your Windows partition is available inside a single (full-screen, resizable) window on your Linux desktop. Because Windows runs as a single operating system inside a secure simulation, this is the most "compatible" way to run it. However, some problems still will have to be solved sooner or later:

  1. Different hardware. A virtual machine simulates a certain set of hardware that did not exist when Windows was installed on the computer. If you are lucky, Windows will run with some kind of generic "drivers," but an early crash because of hardware mismatches is more likely. The solution is reinstallation inside the virtual machine or installing drivers that match the virtual environment from a native run of Windows.
  2. Cut-and-paste does not work reliably between the simulated computer and the running desktop environment. At least, qemu does not support cut and paste between the real machine and the virtual. Data transfer can occur, however, over the network between the virtual and non-virtual sessions.
  3. Graphics cards and CPUs (except with full virtualization support) are slower in the virtual machine than the real one, and most of the real hardware is not accessible from Windows. As a general rule, standalone programs and those that are not too complex can run from Wine, and more that are dependent on the Windows desktop run better in virtualization. Again, this works best when Windows is reinstalled inside the virtual machine, rather than hoping that matching drivers are available in the old installation.

From smbpasswd to LDAP


Hi, Klaus! I am running an ancient (3.0.7-2) Samba PDC box and would like to migrate it to the latest version and leverage centralized authentication with LDAP (so I can have other systems point to that same auth server). Is there a painless migration path from the old version with smbpasswd authentication to 3.3 or 3.4 with LDAP, or am I better off starting from scratch? I have roughly 50 user accounts and 75+ domain member machines. My fear with starting from scratch is that, once the users authenticate against the new domain, all the settings and files on their local machines (WinXP) would need to be moved around "manually."


Fifty real user and 75 machine accounts is not much compared with large installations of 5,000+ users. Instead of running a script that just recreates the accounts in LDAP, tools like pdbedit can make migration from smbpasswd to LDAP a lot easier.

The general steps are modifying /etc/samba/smb.conf to contain the address and paths to the ready-built slapd server (with POSIX accounts and the situation-specific LDAP tree), as in Listing 1, which comes from the smb.conf documentation.

Listing 1



Now you can call:

pdbedit -i smbpasswd -e ldapsam

The ldapscripts package in Debian contains a few useful tools for LDAP and Samba. Please note that accessing LDAP requires authentication against the LDAP tree part, which needs to be modified. The whole truth is, of course, dependent on your personal setup, and you can find more verbose descriptions in the various forums around samba.org [3].

I recommend working with a copy of your server's hard disk (the configuration part) rather than doing everything directly on the original. Because the user and machine account home directories and data do not change when just migrating authentication, users should not even notice that something is different from before. If for some reason you changed user IDs during the upgrade, files might become unreadable or unwritable for users. This can be fixed quite easily with chown -R new_user_id/home/username, provided the system running Samba also fetches its user database from the same LDAP tree.

The Scourge of Exclusivity


A few months ago I purchased a Dell Mini computer with Ubuntu 8.04. One of my classes plans to have a conference call using GoToMeeting.com. I am unable to download the website's software, apparently because it is only compatible with MS or Mac OS. Is there anything I can do to link up with my fellow students? I would rather not download any MS stuff, as I am sure you will understand.


GoToMeeting seems to be a remote desktop control application in conjunction with voice over IP, similar to VNC and other desktop control/projection software under Linux (with a VoIP app such as Linphone). The website seems to be the staging point for obtaining browser plugins and setting up the initial connection. Ubuntu and some other Linux distros also have remote desktop control and display software built-in. For Skolelinux, use italc or controlaula for classroom conferences, independent from any web service. Other possibilities for the same functionality are available as completely free software. VNC is probably the most interoperable possibility; it works with Linux as well as Windows.

If your class explicitly requires GoToMeeting, which the vendor says is "Windows and Mac only," and if different systems are not allowed in your class, you are stuck with Windows or a virtual Windows machine. Even attempts to let their software run in Wine have been reported as no-go. Sorry, no solution. It's a political problem: a strategic decision of a software vendor towards a proprietary, non-portable solution. Maybe they will create a Linux version one day, maybe not.

Figure 2: Wikipedia provides a helpful table comparing remote desktop clients. Search for "Comparison of remote desktop software."

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Samba 4


  • Gaming with Wine


  • Windows apps with Wine


  • Wine


  • Ask Klaus!


comments powered by Disqus

Direct Download

Read full article as PDF: