First point Dotan Cohen. Wine is not a normal platform. Treating it as such gets you into trouble. Wine is a open source platform. Wine does get regressions. One of the most important things is maintaining appdb entry telling users how to get around problems different wine version to wine version. Even in the appdb can tell uses that X version of wine does not work with his program. This also provides bug tracking linked to application. Support personal of wine always refer to the appdb it see if an application works. People buying applications also refer to it. Hacking around issues is not effective for wine. Creating test cases and submitting or repairing wine is helpful. Basically this is way different to supporting a closed source platform. Wine is a open source project and need to be treated as such. Great support comes from working with upstream. Ie wine. Wine developers are responsive. Problem with patching stuff in own code base to get around wine issue is it only make your live harder. The means to turn bits of the application on and off at will through configuration files or registry not from platform detecting is the correct way to work around wine problems. These alterations can also be handy when debuging on a windows machine with damaged files. Basically think of wine as windows that has been running on a bad harddrive and now sections don't work. But could be repaired in future or could pick up new damage. Treat it that way and support wine is not a major trip through hell. If supporting wine is avoiding providing Linux version if able. I seriously don't recommend it. Native programs beat wine. Wine has all the issues of windows with dll conflicts and other problems. Wine is also not without its overhead.
