On Mon, 2008-07-14 at 10:06 +0100, Mark Rogers wrote:
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.
It wasn't intentional but in most cases it is true for most aspects of wine. My belief is that in circumstances where wine is faster it is because the underlying Operating System is more efficient or is doing less (no spyware/av scans, norton hogging half the memory etc) and not that the Wine implementation of the Windows API is somehow more efficient. That may not always be true of course and I am not saying that the wine devs couldn't produce faster implementations, just that as you say that is not their priority.
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 have heard that before but I am not sure I understand why. Direct3D implementation for example will presumably have to translate everything to OpenGL because it can't talk to the hardware directly and the linux drivers for say an Nvidia card aren't going to understand DirectX are they ? So ultimately it will have to be another layer surely ? If nothing else that means that the GFX will be more CPU bound than when running on windows or am I missing something ?
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.
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 ?
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.
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 ?
sorry for any naivety there..as I say I am not a developer
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.
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.