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.

Wayne Stallwood wrote:

Not being a developer I am unsure but how easy is it for people to target wine as a platform rather than windows ? What limitations exist in wine that would somehow degrade the application on Windows ? Is there an automated way of actually having wine as a target at build time that could improve things ?

Having done odd bits of Windows development I've found pretty much everything I've written has just worked under Wine without modification so I have no experience of this.

Wine as a build target isn't all that meaningful; the whole point is that Windows as a target should make Wine a viable target too, although I guess you could have different build options that disabled features that didn't work in Wine or that did but were less efficient than the approach used in the Windows build. The result should still run under Windows, though.

In my experience the worst culprits seem to be installers; I have no idea whether the application would work because the installer does weird things that do not run under Wine, so you never get far enough to test the app itself.

Asking developers to QA against wine is one thing, asking them to QA against it and then either code around areas where the implementation isn't complete (whilst making sure this doesn't produce bugs when running native on windows) or participate in the reverse engineering of windows to fix the implementation where it falls short seems like almost as much effort on their part as simply designing the code to be more portable from the outset and then building for Linux native.

Wine devs are generally quite keen, particularly with large/high profile apps, to work with devs - or at least that's the impression I get.

Testing the app, feeding back the results to Wine devs and saying "I have no idea why this doesn't work but I'm the app developer and have access to the code, I can help you work out what is breaking in Wine" is probably a pretty good starting point. After all, if it runs in Windows it pretty much makes Wine the culprit, so the dev doesn't have to risk their pride (do real programmers have that kind of pride?)

I should think that many times when something doesn't work the Wine devs would quickly recognise the symptoms and either suggest a workaround or know where to go looking.

I am presuming that most implementation holes in Wine are missing stuff rather than stuff behaving differently so would it be possible to make say visual studio target wine and then there be a more than reasonable chance that the application would still run as well on Windows ?

Making something like Delphi do that might be more likely (Visual Studio's developers bosses might have something to say about VS targeting Wine...).

I think it's usually pretty easy to tell if it's a missing API call just by running the app through Wine at the commandline and looking at the errors and warnings.

I think Google say that "most" improvements have been fed back, I am not sure why it is "most" and not all unless the other changes are just to do with the way it is packaged with picassa, I am also not sure what happens when the packaged version is older than a version you already have installed.

There's little point passing back changes that have no mainstream use, they'd not be accepted upstream anyway. Whether Google are inclined to "bodge" Wine to make Picassa work I have no idea! But I assume their changes are made available as source under the conditions of the licence so I doubt there's any secrecy.

The packaged version acts just as a local library, AIUI. It certainly has no impact on the version of Wine installed, and coexists with Wine quite happily.