Wayne Stallwood wrote:
Wine isn't an emulator or a virtual machine, it is a reimplementation of the windows API that wraps the Windows executable and translates all the system calls to linux ones, because the core architecture is the same this is possible and a full platform emulation isn't required.
This wording implies to me (probably not intentionally) that Wine is still an extra layer compared with Windows and brings performance drawbacks compared with a native environment.
Windows is, from the point of view of an application developer, a set of libraries of standard functions for stuff like drawing windows and managing user input (and network communications, sound, etc). A pretty big library, of-course, but it means that applications that use the Windows API tend to have a standard look and feel, and (in theory anyway) when you go from (say) Windows 3.x to Windows 9.x to XP to Vista the applications keep working (the APIs are still there) but the applications look new, because they use the new window decorations.
In other words, Windows is (as any operating system is) a layer between the hardware and the application. Wine, by implementing the Windows API on Linux and other platforms, means that applications that look for the "draw a window" function that Windows provides will find one that works the same and the application need never know anything is different.
In many cases that is case of mapping Windows functions to the equivalent Linux ones, as surprisingly enough there are functions to draw windows in X as well, they just have different names and parameter lists so a little magic between the two is needed. However there are also other functions that are implemented within Wine (rather than just mapped elsewhere). Whether a Windows application is faster in Windows or Linux therefore depends on which calls it makes, and whether the functions used are written "better" in Wine than in Windows (not uncommon), or if the underlying Linux function being mapped to is written better than its Windows counterpart.
In practise most Windows applications that run under Wine do run slower, albeit often not noticeably, under Wine, but that is a function more of the development that takes place on Wine being focused more on implementing the missing functions than on improving the ones that work, albeit slower. It is quite possible with the way Wine is implemented for it to be faster in some or most (all?) cases than Windows for the same application, but it's not there yet. It is quite feasible, for example, that in time the DirectX equivalents in Wine will allow Windows games to be faster on Linux than under Windows.
I only bother making this point because there is a general "understanding" that Wine is necessarily weaker than Wine, and that does not need to be the case. Not least because should games developers (for example) choose to target it then they have access to the underlying source code to improve on areas that are not working well for their application, something they cannot do with Windows. A Wine-based "Windows" game could be shipped with a complete optimised operating system and I'm sure that the result would be better than trying to run on a typical Windows desktop with all its little applications running in the background (not to mention viruses and spyware slowing the system down). Google ships a suitable version of Wine with Picassa to simplify the installation but I'm sure eny improvements they made to Wine along the way have been fed back for the general use by the rest of us in other Wine-based applications.