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.