http://bugs.winehq.org/show_bug.cgi?id=9787
--- Comment #297 from Scott Lindeneau slindeneau@gmail.com 2008-11-23 13:23:40 ---
And Alexandre cannot provide some info how that can be resolved without modifying the wineserver? What he means by "more than should"?
There is a lot of code that gets modified. A Lot.
The basic patch is just under 300 lines of code. The code with the modified wineserver is over 1000. Check the file sizes. Andrey Turkin's code is the basic implementation. Just over 11KB. My partial is only a little over 16KB. Then once I figured out how to modify the wineserver it jumps to over 36KB.
Here is the basic problem. 1) Alexander believes The wineserver works. 2) The wineserver does work, for everything until this point. 3) A new feature is added and it doesnt work because something doesn't work as specified.
Essentially, I, a relative unknown, am telling someone who has been working on this a long time that something is broken. If a man came in off the street and said that your product is broken, you don't always take him in hand and say he is right.
Under the hood: The wineserver has an asynchronous operation structure in place. When an asynchronous command finishes, the next one is queued to start. This is what is supposed to happen. It doesn't(for sockets). I don't have the foggiest idea why. My solution was to rewrite a set of if statements that allows commands to be executed without waiting for previous statements to finish. It also allows for random removal of events from the queue. This breaks a paradigm that the asynchronous queue was built upon. Thus the patch is considered wrong.
The wineserver is so poorly documented that I didn't know I was breaking a paradigm when I did it. I thought I was fixing it (from what comments are in the code). It happened to work, but it may be a case of 'I got lucky.' and I don't have strong evidence to support my case, other than "hey it works now".