http://bugs.winehq.org/show_bug.cgi?id=2398
------- Additional Comments From phil@ldex.terica.net 2005-30-09 21:50 ------- The problem is that :
a) The previous version worked for this app and potentially many others before the change. The current version doesn't and there is no workaround/fix except downgrading Wine. That kind of breakage would put off a good number of people from using wine for any kind of development purpose. It would have been better to retain the choice until bugs in the new code were hammered out (such as this one). If I were a commercial vendor looking at something like Winelib for porting an application, I suspect I would be less than encouraged by this all-or-nothing approach to evolving the system. I don't dispute that many other apps have seen their behaviour improve with the change - I'm simply suggesting that having two systems side-by-side would be a better option at the moment. Once this and other issues have been resolved in the new code, the old code could be removed.
b) The old working version of Wine is not packaged for current distributions. The user is left with a choice of attempting to install a package for an older distribution (potentially also conflicting with any newer version of wine that they care to install) or with compiling from source. That's not particularly friendly and those users coming from Windows who are determined enough to go this far will be few and far between (noting that Windows folks are not generally disposed to filing bug reports following years of being ignored by many vendors). If there is no technical way of having both systems implemented in Wine (with the old system being chosen by a command line switch or environment variable), then what about having the last-known-good version of Wine available for current distributions (and being able to be side-installed with the current version of Wine)?
-
Wine Bugs