On Sun, Jun 3, 2012 at 6:16 PM, Jerome Leclanche adys.wh@gmail.com wrote:
This comes up in one form or the other very often, though, doesn't it? Company x releases software y with a Wine wrapper advertising "native linux support" and users get upset. Personally, I'm glad they're thinking about Linux and I think Wine fills a great role as a "transitional" step between Windows and Linux, but I don't think it's any good to encourage using Wine over making the game more portable. Besides, doesn't HIB have some rule about requiring all games to support Linux natively?
J. Leclanche
More often than not it's the case that no amount of encouragement will lead to a native port. If it were a simple matter of encouragement, I doubt there'd be a point in Wine. Often it's the case that a company produces software with the intent to do very little after release day. By very little I mean that it *might* get one or two patches after release and then it's done. The patches address usually a handful of bugs. It isn't continuation of development really. Porting software is generally a lot more involved than fixing a few bugs. Porting is more like a continuation of development that often involves nontrivial effort.
For companies that take a "fire and forget" approach to software development, Wine provides an option where there wouldn't be one otherwise. Of course everyone would love to see real maintenance and continuation of development but a realist will point out that is not what's happening. Nor would it in many cases even if Wine didn't exist.
Those that object to Wine being used to port software should ask the real question: Would the software be ported otherwise? It is not even clear that it still would have been ported. For some, you might only get a port if it's a trivial thing to do.
I'd like to point out that despite the increasing quality of Wine, it's becoming increasingly likely that software is designed to be portable and made available cross platform. It's also becoming more likely that a user can find high quality alternatives to platform locked applications. If Wine's existence is in fact discouraging native ports in a significant way then you would expect the trend to be in the other direction.
The mere existence of edge cases where Wine may have discouraged a native port does not negate the larger trend. It seems a bit silly to fuss over a small skirmish when the war is being won on a much larger, more significant, turf. The availability of high quality cross platform development tools has done more to win the battle than Wine's absence ever could hope to do.
Further the push for native ports is something that happens _after_ the application was developed using MS APIs and _after_ it was ported via Wine. (Ironically, there'd be much less fuss if the developers just kept it as a Windows only program.) If the original developer cared about being portable they would have used portable libraries from the start. As far as I can tell, there's no indication that Wine was a part of the original development decision to use non portable APIs. There's only the fears of some that it might have or will someday.
http://en.wikipedia.org/wiki/Make_a_mountain_out_of_a_molehill