[ALUG] Picasa 2 for Linux
mark at quarella.co.uk
Mon Jul 14 12:02:19 BST 2008
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
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
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
Mark Rogers // More Solutions Ltd (Peterborough Office) // 0845 45 89 555
Registered in England (0456 0902) at 13 Clarke Rd, Milton Keynes, MK1 1LG
More information about the main