[ALUG] Picasa 2 for Linux
ALUGlist at digimatic.co.uk
Mon Jul 14 11:28:50 BST 2008
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
More information about the main