https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #84 from kenoi kenoiyan@aesautomation.com.au --- (In reply to Austin English from comment #83)
Frankly, if you're not a developer (and especially if you're not able to build wine), then you shouldn't make declarative statements about what wine's development policies are.
Wine's policy is to match windows behavior, even if it's not ideal. I'm not a wined3d developer, so I'll leave it to them to decide if this is a WONTFIX.
With all due respect, I would call a bug that hasn't been fixed in 11 years a WONTFIX!
I may not be a Wine developer, but that doesn't mean I'm not a software developer, and can't see the larger problem here. Would you implement a "fix" to Wine that compromises Wine's memory management just so faulty software could run on Wine? That makes the Wine server slow down like Windows does with use?
It goes against what Linux and Wine stand for by design. This is why this bug has not been fixed in all this time.
I'm all for hope, but not rooted in ignorance, in closing my eyes and wishing for something that will never come. We need to deal with this bug in another way than waiting for the Wine developers to implement a patch that compromises Wine's performance. We need to provide a means to an easy solution for users to fix the Storm engine's compatibility with Wine, without needing to compile Wine from the source.
That fix will either come by fixing the serious faults in the Storm engine (if someone has access to the source), or by providing a binary that users can download and copy/install to fix Wine's compatibility with this engine (at the cost of Wine's memory performance) on their computer.
I stand for being practical, not hopeless wishful thinking.