Out of the box, these were the default locations of “My Music”, etc.:
I didn’t like that, however, because that means applications may clutter up my home directory. Already, iTunes had created /home/tyler/iTunes for its own use. I wanted it to use /home/tyler/iTunes instead, though, so I did:
By going to winecfg / Desktop integration, I was able to change them to change the location of my shell folders. Now they are:
Wine is an Open Source implementation of the Windows API on top of X, OpenGL, and Unix. Think of Wine as a compatibility layer for running Windows programs. Wine does not require Microsoft Windows, as it is a completely free alternative implementation of the Windows API consisting of 100% non-Microsoft code, however Wine can optionally use native Windows DLLs if they are available. Wine provides both a development toolkit for porting Windows source code to Unix as well as a program loader, allowing many unmodified Windows programs to run on x86-based Unixes, including Linux, FreeBSD, Mac OS X, and Solaris. ….
Myth 1: “Wine is slow because it is an emulator”
Some people mean by that that Wine must emulate each processor instruction of the Windows application. This is plain wrong. As Wine’s name says: “Wine Is Not an Emulator”: Wine does not emulate the Intel x86 processor. It will thus not be as slow as Wabi which, since it is not running on a x86 Intel processor, also has to emulate the processor. Windows applications that do not make system calls will run just as fast as on Windows (no more no less).
Some people argue that since Wine introduces an extra layer above the system a Windows application will run slowly. It is true that, in theory, Windows applications that run in Wine or are recompiled with Winelib will not be able to achieve the same performance as native Unix applications. But that’s theory. In practice you will find that a well written Windows application can beat a badly written Unix application at any time. The efficiency of the algorithms used by the application will have a greater impact on its performance than Wine.
Also, and that’s what people are usually interested in, the combination Wine+Unix may be more efficient that Windows. Just as before it’s just how good/bad their respective algorithms are. Now to be frank, performance is not yet a Wine priority. Getting more applications to actually work in Wine is much more important right now. For instance most benchmarks do not work yet in Wine and getting them to work at all should obviously have a higher priority than getting them to perform well.
But for those applications that do work and from a purely subjective point of view, performance is good. There is no obvious performance loss, except for some slow graphics due to unoptimized Wine code and X11 driver translation performance loss (which can be a problem sometimes, though).
Myth 3: “Emulators like VMWare are better”
Sure they’re better… if you like purchasing a full copy of an operating system just to run it under a virtual machine. Not to mention you need to purchase a copy of VMWare to make it work.
Oh, and don’t forget the huge performance hit you take to run an application on a full-blown operating system running on top of an operating system.
However, having said that there are instances where emulators are quite useful. Developers can create sandboxes to run applications in, test other operating systems without rebooting, etc. But having a full-blown emulator just to run a word processor probably isn’t the best solution.
Myth 6: “Wine will always be playing catch up to Windows and can’t possibly succeed at running new applications”
The architecture of Wine makes adding new APIs (or DLLs) fairly easy. Wine developers rapidly add functions as needed, even applications requiring the latest functionality are usually reported working within a few months of release. Examples of this include Office XP and Max Payne (a DirectX 8.0 game) – both of which were fairly new as of this writing (5/2002.)
In addition, Wine supports using native DLLs when the built-in versions don’t function properly. In many cases, it’s possible to use native DLL versions to gain access to 100% of the functions an application requires.
Myth 7: “Because Wine only implements a small percentage of the Windows APIs, it’s always going to suck”
APIs are like a library – it’s always nice to have as many books on the shelves as possible, but in reality a few select books are referenced over and over again. Most applications are written to the lowest common denominator in order to have the widest audience possible. Windows XP support is simply not that important – most applications only require Windows 95 or Windows 98. Currently Wine supports over 90% of the calls found in popular Windows specifications such as ECMA-234 and Open32. Wine is still adding Win32 APIs, but a lot of the work right now involves fixing the existing functions and making architecture changes.
Myth 8: “Wine is only for Windows 3.1 / Wine will never support Win64”
Wine started back in the days when Windows 95 did not exist yet. And although Windows NT (and thus the Win32 API) already existed, it only supported Windows 3.1 applications. Anyway, almost no-one used Windows NT in that time anyway.
But these days are long gone. Since August 2005, Wine advertises its version as Windows 2000, and for several years before this it was Windows 98, so really Win32 is the primary thing Wine supports. Support for Windows 3.1 applications is still around, of course, as is some support for DOS applications.
Win64 support would allow Wine to run native Windows 64-bit executables, and as of February 2006, Wine does not yet have this support. That’s okay, since there are very few commercially available Win64 applications. One exception, Unreal Tournament 2004, is available in a native Linux 64-bit version, so nobody (except maybe a Wine hacker) should want to run the Windows version anyway.
This doesn’t mean that Wine will not work on 64-bit systems. It does. See this entry in the Wine Wiki for more info.