[ALUG] Picasa 2 for Linux

Mark Rogers 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 
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.

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 mailing list