http://bugs.winehq.org/show_bug.cgi?id=22580
Summary: RegisterWaitForSingleObject() with tmo=0 causes 100% CPU load Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs@winehq.org ReportedBy: joakim.tjernlund@transmode.se
Created an attachment (id=27708) --> (http://bugs.winehq.org/attachment.cgi?id=27708) RegisterWaitForSingleObject() fix special tmo == 0 case.
At http://msdn.microsoft.com/en-us/library/aa332406%28VS.71%29.aspx one can read: "If the timeOutInterval parameter is not zero (0) and the executeOnlyOnce parameter is false, the timer is reset every time the event is signaled or the time-out interval elapses."
timeOutInterval == 0 makes the above false and the timer should NOT be reset, the attached patch fixes that.
http://bugs.winehq.org/show_bug.cgi?id=22580
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.1.43
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #1 from Vitaliy Margolen vitaliy@kievinfo.com 2010-05-04 22:28:40 --- Do you have a test case? Which program is affected?
http://bugs.winehq.org/show_bug.cgi?id=22580
joakim.tjernlund@transmode.se changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.43 |unspecified
--- Comment #2 from joakim.tjernlund@transmode.se 2010-05-05 00:56:48 --- https in IE6.
With some luck it will help other problem apps using lots of CPU, there are a few in bugzilla.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #3 from joakim.tjernlund@transmode.se 2010-05-06 12:04:37 --- Are there no devs here, interested in this?
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #4 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-06 22:44:26 --- (In reply to comment #3)
Are there no devs here, interested in this?
Please read the comments and answer the questions.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #5 from joakim.tjernlund@transmode.se 2010-05-07 01:17:13 --- hmm, I thought I did.
Test case is IE6 using https, installed with ies4linux. I know ies4linux isn't supported but that is besides the point.
The text "If the timeOutInterval parameter is not zero (0) and the executeOnlyOnce parameter is false, the timer is reset every time the event is signaled or the time-out interval elapses." is pretty clear.
Also it makes sense from a logical point of view. Using a zero timeout will cause an endless loop as impl. today and that does not make sense. Either one can forbid timeout == 0 or add some special handling. Clearly only the latter is appropriate and the text outlines the special handling.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #6 from Jeff Zaroyko jeffz@jeffz.name 2010-05-07 01:20:07 --- A test case is usually in the form a standalone executable or integrated into the wine conformance tests so that you can show the behavior on Wine and then on Windows to confirm your hypothesis.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #7 from joakim.tjernlund@transmode.se 2010-05-07 02:43:42 --- well that I don't have. I don't do Windows at all, I just tracked this bug down and I think this should be enough to make some informed decision.
So far I got zip technical response. Some of you guys must be able to agree or disagree if this is a bug or not, if the impl. is OK or not based on what is already present.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #8 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-07 03:36:12 --- (In reply to comment #7)
well that I don't have. I don't do Windows at all, I just tracked this bug down and I think this should be enough to make some informed decision.
So, who is doing the call with that parameters?
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #9 from Alexandre Julliard julliard@winehq.org 2010-05-07 03:37:42 --- (In reply to comment #7)
well that I don't have. I don't do Windows at all, I just tracked this bug down and I think this should be enough to make some informed decision.
So far I got zip technical response. Some of you guys must be able to agree or disagree if this is a bug or not, if the impl. is OK or not based on what is already present.
We can't do that without knowing how Windows behaves, and the way to determine that is to write a regression test. MSDN cannot be trusted.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #10 from joakim.tjernlund@transmode.se 2010-05-07 03:59:41 --- Comment #7 It is crypt32.dll, see bug 13687
Comment #8 Sure you can, based on what I have reported it is likely a Wine bug. If you need a some sort of Wine regression test case I can't help you there. Please make one, can't be much work for a Wine dev.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #11 from joakim.tjernlund@transmode.se 2010-05-07 04:41:59 --- (In reply to comment #9)
(In reply to comment #7)
well that I don't have. I don't do Windows at all, I just tracked this bug down and I think this should be enough to make some informed decision.
So far I got zip technical response. Some of you guys must be able to agree or disagree if this is a bug or not, if the impl. is OK or not based on what is already present.
We can't do that without knowing how Windows behaves, and the way to determine that is to write a regression test. MSDN cannot be trusted.
BTW, I would expect MSDN to omit stuff from the SPECs but not specify something and then omit that from the impl.
Isn't it much more like that whoever impl. the above mentioned function in Wine didn't read the SPEC properly?
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #12 from Alexandre Julliard julliard@winehq.org 2010-05-07 05:55:29 --- (In reply to comment #11)
BTW, I would expect MSDN to omit stuff from the SPECs but not specify something and then omit that from the impl.
Isn't it much more like that whoever impl. the above mentioned function in Wine didn't read the SPEC properly?
You'd be surprised how wrong MSDN can be at times. It may or may not be right in this case, the only way to find out is to write a test. Arguing here won't help.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #13 from joakim.tjernlund@transmode.se 2010-05-07 06:54:12 --- Created an attachment (id=27790) --> (http://bugs.winehq.org/attachment.cgi?id=27790) Attempt to write a test case
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #14 from joakim.tjernlund@transmode.se 2010-05-07 07:04:16 --- I guess the attached test case needs some polish but if none cares about this(which is the impression I have) can you at least error out in this particular case as otherweise such action will bring down wine as it stands today?
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #15 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-07 07:29:44 --- (In reply to comment #14)
I guess the attached test case needs some polish but if none cares about this(which is the impression I have) can you at least error out in this particular case as otherweise such action will bring down wine as it stands today?
How is that test case supposed to pass with the suggested fix and fail without it?
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #16 from Alexandre Julliard julliard@winehq.org 2010-05-07 07:34:27 --- (In reply to comment #14)
I guess the attached test case needs some polish but if none cares about this(which is the impression I have) can you at least error out in this particular case as otherweise such action will bring down wine as it stands today?
It's not that no one cares, but you can't expect other developers to drop everything they are doing and rush to fix your favorite bug. There are more than enough bugs to keep everybody busy.
You are the one who wants this fixed, so you are the one responsible for seeing it through. The test case is a good start, now finish it, once it works submit it along with the fix, and keep trying until it's accepted. Don't expect others to do your homework for you.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #17 from joakim.tjernlund@transmode.se 2010-05-07 08:19:20 --- (In reply to comment #15)
(In reply to comment #14)
I guess the attached test case needs some polish but if none cares about this(which is the impression I have) can you at least error out in this particular case as otherweise such action will bring down wine as it stands today?
How is that test case supposed to pass with the suggested fix and fail without it?
This: ok(!only_once, "wait should have timed out once\n"); only_once++; should generate a printout iff timeout_function_once is called more than one.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #18 from joakim.tjernlund@transmode.se 2010-05-07 08:47:56 --- (In reply to comment #16)
(In reply to comment #14)
I guess the attached test case needs some polish but if none cares about this(which is the impression I have) can you at least error out in this particular case as otherweise such action will bring down wine as it stands today?
It's not that no one cares, but you can't expect other developers to drop everything they are doing and rush to fix your favorite bug. There are more than enough bugs to keep everybody busy.
I don't but no one has indicated that it will be looked upon/considered at some point. Instead I got the impression that unless I do all the stuff with test case etc. and proved beyond doubt that there is a problem, nothing will done.
You are the one who wants this fixed, so you are the one responsible for seeing it through. The test case is a good start, now finish it, once it works submit it along with the fix, and keep trying until it's accepted. Don't expect others to do your homework for you.
As a casual Wine user I think I have done more than my home work. If you had said upfront that it looks like a Wine bug but you are sure but will look upon it at some point, I had no problem with that.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #19 from Austin English austinenglish@gmail.com 2010-05-07 11:58:50 --- FWIW, there's WineTestBot, which has several windows VM's to allow you to test your testcases: http://testbot.winehq.org/
I submitted you testcase. It fails on some versions of windows (Vista, Windows 7, Windows Server 2008): https://testbot.winehq.org/JobDetails.pl?Key=1941
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #20 from joakim.tjernlund@transmode.se 2010-05-07 14:44:17 --- So it seems like they have changed semantics as of Vista. I would think that my case isn't really allowed or undefined on those platforms. Can you think of a valid use?
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #21 from joakim.tjernlund@transmode.se 2010-05-07 15:03:48 --- hmm, in those failed cases even unregister fails so it seems one should not use tmo == 0 in later versions. So my test case isn't valid for later versions of windows dunno how to encode that into the test case.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #22 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-07 23:03:03 --- (In reply to comment #21)
hmm, in those failed cases even unregister fails so it seems one should not use tmo == 0 in later versions. So my test case isn't valid for later versions of windows dunno how to encode that into the test case.
The problem may be related to win9x version of crypt32.dll. Try with win2k+ version instead and see how it goes.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #23 from joakim.tjernlund@transmode.se 2010-05-08 04:22:33 --- (In reply to comment #22)
(In reply to comment #21)
hmm, in those failed cases even unregister fails so it seems one should not use tmo == 0 in later versions. So my test case isn't valid for later versions of windows dunno how to encode that into the test case.
The problem may be related to win9x version of crypt32.dll. Try with win2k+ version instead and see how it goes.
No, the problem is that <= XP expects tmo = 0 to behave as my patch does and never Windows has changed behavior. See comment #19 It seems like tmo = 0 and !execcuteOnce is an invalid combo as even unregister fails.
If the above is correct, then my patch improves Wine for all Windows versions. Older SW that do use tmo = 0 and !execcuteOnce works and newer SW does not use this combo at all as it seems invalid.
Does anyone have a better explanation for what tmo = 0 and !execcuteOnce is expected to do on >= Vista?
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #24 from joakim.tjernlund@transmode.se 2010-05-08 05:03:05 --- Here is a clue. According to http://msdn.microsoft.com/en-us/library/aa332406%28VS.71%29.aspx
Platforms: Windows 98, Windows NT 4.0, Windows Millennium Edition, Windows 2000, Windows XP Home Edition, Windows XP Professional, Windows Server 2003 family
and this, which has a different definition http://msdn.microsoft.com/en-us/library/ms685061%28VS.85%29.aspx Minimum supported client Windows 2000 Professional
Minimum supported server Windows 2000 Server
So there appears to be 2 different spec's for this function. Can Wine handle that?
http://bugs.winehq.org/show_bug.cgi?id=22580
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.1.43 Severity|normal |enhancement
--- Comment #25 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-09 23:27:20 --- The problem is related to usage of native crypt32.dll -> enhancement.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #26 from Andrew Nguyen arethusa26@gmail.com 2010-05-09 23:37:19 --- Frankly, this is probably a duplicate of bug 11916 or bug 13687.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #27 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-10 00:59:57 --- (In reply to comment #26)
Frankly, this is probably a duplicate of bug 11916 or bug 13687.
Probably, but this one has at least some investigation results with a partially working test case.
http://bugs.winehq.org/show_bug.cgi?id=22580
joakim.tjernlund@transmode.se changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.43 |unspecified Severity|enhancement |normal
--- Comment #28 from joakim.tjernlund@transmode.se 2010-05-10 01:30:23 --- (In reply to comment #27)
(In reply to comment #26)
Frankly, this is probably a duplicate of bug 11916 or bug 13687.
Probably, but this one has at least some investigation results with a partially working test case.
Guys, please read this bug carefully. It is not quite the same as the above two bugs.
ies4linux was used to track this problem down but I think I have proven that there is a problem with RegisterWaitForSingleObject. The test run in comment #19 shows that.
I argue that my patch is an overall improvement as the current impl. is broken on <= XP and newer Windows app doesn't use this particular combo as it breaks with 100% CPU load.
http://bugs.winehq.org/show_bug.cgi?id=22580
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.1.43 Severity|normal |enhancement
--- Comment #29 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-10 02:11:02 --- (In reply to comment #28)
ies4linux was used to track this problem down but I think I have proven that there is a problem with RegisterWaitForSingleObject. The test run in comment #19 shows that.
I argue that my patch is an overall improvement as the current impl. is broken on <= XP and newer Windows app doesn't use this particular combo as it breaks with 100% CPU load.
The bug is triggered by usage of a native crypt32.dll, the workarond is simple and obvious - don't do that.
In reality this bug is invalid, we can't fix the bugs in native dlls, and the testing shows that Wine behaviour is correct and matches what new Windows implementations do. But since you have a partially working test case, let it be open, but with low priority. Feel free to continue working on this.
http://bugs.winehq.org/show_bug.cgi?id=22580
joakim.tjernlund@transmode.se changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.43 |unspecified Severity|enhancement |normal
--- Comment #30 from joakim.tjernlund@transmode.se 2010-05-10 02:27:13 --- (In reply to comment #29)
(In reply to comment #28)
ies4linux was used to track this problem down but I think I have proven that there is a problem with RegisterWaitForSingleObject. The test run in comment #19 shows that.
I argue that my patch is an overall improvement as the current impl. is broken on <= XP and newer Windows app doesn't use this particular combo as it breaks with 100% CPU load.
The bug is triggered by usage of a native crypt32.dll, the workarond is simple and obvious - don't do that.
In reality this bug is invalid, we can't fix the bugs in native dlls, and the testing shows that Wine behaviour is correct and matches what new Windows implementations do. But since you have a partially working test case, let it be open, but with low priority. Feel free to continue working on this.
Oh, so Wine is not for <= XP, only newer Windows? Where do you draw the line?
http://bugs.winehq.org/show_bug.cgi?id=22580
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.1.43 Severity|normal |enhancement
--- Comment #31 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-10 03:28:52 --- (In reply to comment #30)
Oh, so Wine is not for <= XP, only newer Windows? Where do you draw the line?
Wine is not for Windows, Wine is for applications. Wine supports the API quirks only if there is an application that depends on them. In your case that's not even an application, but a native Windows DLL which depends on some old/broken/undocumented behaviour.
Please don't change the bug version/severity anymore.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #32 from joakim.tjernlund@transmode.se 2010-05-10 04:25:23 --- (In reply to comment #31)
(In reply to comment #30)
Oh, so Wine is not for <= XP, only newer Windows? Where do you draw the line?
Wine is not for Windows, Wine is for applications. Wine supports the API
OK, apps written on <= XP isn't supported? That is effectively what you are saying.
quirks only if there is an application that depends on them. In your case that's not even an application, but a native Windows DLL which depends on some old/broken/undocumented behaviour.
It is not that old (<=XP) and not broken and not undocmented. Haven't you read the URL:s I posted or the test in comment #19?
How do you know that the native Windows DLL is broken and not wine? How do you know there aren't more apps out there using this? There are a few 100% cpu usage bugs in bugzilla.
Please don't change the bug version/severity anymore.
Sorry, I didn't realize I had done that.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #33 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-10 04:41:57 --- (In reply to comment #32)
OK, apps written on <= XP isn't supported? That is effectively what you are saying.
That's not what I've said. There is no applications not working due to this bug. There is a win9x DLL. That effectively makes this bug invalid, since we can't fix the bugs in Windows DLLs, or add win9x specific behaviour to make one broken win9x DLL work although built-in DLL which works just fine.
quirks only if there is an application that depends on them. In your case that's not even an application, but a native Windows DLL which depends on some old/broken/undocumented behaviour.
It is not that old (<=XP) and not broken and not undocmented. Haven't you read the URL:s I posted or the test in comment #19?
How do you know that the native Windows DLL is broken and not wine?
Your test case shows that.
How do you know there aren't more apps out there using this? There are a few 100% cpu usage bugs in bugzilla.
There could be a lot of reasons leading to 100% cpu usage, there is no need to speculate about that.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #34 from joakim.tjernlund@transmode.se 2010-05-10 04:59:18 --- (In reply to comment #33)
(In reply to comment #32)
OK, apps written on <= XP isn't supported? That is effectively what you are saying.
That's not what I've said. There is no applications not working due to this bug. There is a win9x DLL. That effectively makes this bug invalid, since we can't fix the bugs in Windows DLLs, or add win9x specific behaviour to make one broken win9x DLL work although built-in DLL which works just fine.
It is not broken. It is using the function according to the spec.
quirks only if there is an application that depends on them. In your case that's not even an application, but a native Windows DLL which depends on some old/broken/undocumented behaviour.
It is not that old (<=XP) and not broken and not undocmented. Haven't you read the URL:s I posted or the test in comment #19?
How do you know that the native Windows DLL is broken and not wine?
Your test case shows that.
No, it shows that <= XP behaves according to the spec.
How do you know there aren't more apps out there using this? There are a few 100% cpu usage bugs in bugzilla.
There could be a lot of reasons leading to 100% cpu usage, there is no need to speculate about that.
Sure, but just a few lines up you claimed there are no apps suffering from this bug. Care to expand on that?
Bottom line is that MS changed the SPEC and impl. of this function in later Windows. I think the new SPEC is a bug as I can't think of a use case wanting this behavior as it just causes 100% CPU pegging.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #35 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-10 06:36:24 --- (In reply to comment #34)
No, it shows that <= XP behaves according to the spec.
That also means that applications can't depend on this behaviour, since the behaviour is different across platforms.
How do you know there aren't more apps out there using this? There are a few 100% cpu usage bugs in bugzilla.
There could be a lot of reasons leading to 100% cpu usage, there is no need to speculate about that.
Sure, but just a few lines up you claimed there are no apps suffering from this bug. Care to expand on that?
That's simple, you haven't listed a single application affected by this bug. Any other bug with 100% cpu usage needs its own investigation.
Bottom line is that MS changed the SPEC and impl. of this function in later Windows. I think the new SPEC is a bug as I can't think of a use case wanting this behavior as it just causes 100% CPU pegging.
Then this bug could be closed as a WONTFIX. You have found something that doesn't exist anymore.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #36 from joakim.tjernlund@transmode.se 2010-05-10 07:29:51 --- (In reply to comment #35)
(In reply to comment #34)
No, it shows that <= XP behaves according to the spec.
That also means that applications can't depend on this behaviour, since the behaviour is different across platforms.
Sure, for anything new one cannot rely on this behaviour.
How do you know there aren't more apps out there using this? There are a few 100% cpu usage bugs in bugzilla.
There could be a lot of reasons leading to 100% cpu usage, there is no need to speculate about that.
Sure, but just a few lines up you claimed there are no apps suffering from this bug. Care to expand on that?
That's simple, you haven't listed a single application affected by this bug.
That is hardly the same as your claim that no other apps is affected.
Any other bug with 100% cpu usage needs its own investigation.
yes, but this is one idea to test.
Bottom line is that MS changed the SPEC and impl. of this function in later Windows. I think the new SPEC is a bug as I can't think of a use case wanting this behavior as it just causes 100% CPU pegging.
Then this bug could be closed as a WONTFIX. You have found something that doesn't exist anymore.
Now you are back to not supporting apps written on <= XP. You cannot have it both ways.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #37 from Austin English austinenglish@gmail.com 2010-05-10 10:32:51 --- The problem is that there's no application that's been found depending on this behavior. Only IE6, which is using a native dll, and probably in an unsupported/undocumented way (as several Microsoft applications have done before).
The testcase is a good start, so we can verify what Windows does. If there is an application depending on the behavior for <=XP, and others depending on Vista+ behvaior, the fix could be made to depend on the version. There are a couple cases of this already in wine, but in general, wine tries not to emulate every version of windows perfectly, but rather the 'current' working spec. If there is an application depending on a specific behavior that is in the specified windows version, then implementing multiple behaviors may be needed.
http://bugs.winehq.org/show_bug.cgi?id=22580
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch, testcase
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #38 from joakim.tjernlund@transmode.se 2010-05-10 12:12:23 --- (In reply to comment #37)
The problem is that there's no application that's been found depending on this behavior. Only IE6, which is using a native dll, and probably in an unsupported/undocumented way (as several Microsoft applications have done before).
The testcase is a good start, so we can verify what Windows does. If there is an application depending on the behavior for <=XP, and others depending on Vista+ behvaior, the fix could be made to depend on the version. There are a couple cases of this already in wine, but in general, wine tries not to emulate
Where are those cases?
every version of windows perfectly, but rather the 'current' working spec. If there is an application depending on a specific behavior that is in the specified windows version, then implementing multiple behaviors may be needed.
Would be interesting to add the patch and see if anything breaks. That is probably the only way we will know.
I don't think it will work to ask people when they have a 100% CPU problem to test my patch as this will soon be history and nobody will remember.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #39 from Austin English austinenglish@gmail.com 2010-05-10 13:25:13 --- (In reply to comment #38)
(In reply to comment #37)
The problem is that there's no application that's been found depending on this behavior. Only IE6, which is using a native dll, and probably in an unsupported/undocumented way (as several Microsoft applications have done before).
The testcase is a good start, so we can verify what Windows does. If there is an application depending on the behavior for <=XP, and others depending on Vista+ behvaior, the fix could be made to depend on the version. There are a couple cases of this already in wine, but in general, wine tries not to emulate
Where are those cases?
Search for use of GetVersion(): http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=grep&s...
for example: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/kernel32/volume.c#l461
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #40 from joakim.tjernlund@transmode.se 2010-05-11 01:35:27 --- (In reply to comment #39)
(In reply to comment #38)
(In reply to comment #37)
The problem is that there's no application that's been found depending on this behavior. Only IE6, which is using a native dll, and probably in an unsupported/undocumented way (as several Microsoft applications have done before).
The testcase is a good start, so we can verify what Windows does. If there is an application depending on the behavior for <=XP, and others depending on Vista+ behvaior, the fix could be made to depend on the version. There are a couple cases of this already in wine, but in general, wine tries not to emulate
Where are those cases?
Search for use of GetVersion(): http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=grep&s...
for example: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/kernel32/volume.c#l461
OK, but that is more that a couple a cases I would say. Not sure how the GetVersion() test should look like in this case though, but it looks doable.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #41 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-11 01:39:39 --- (In reply to comment #40)
OK, but that is more that a couple a cases I would say. Not sure how the GetVersion() test should look like in this case though, but it looks doable.
First you need to find an application that depends on that.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #42 from joakim.tjernlund@transmode.se 2010-05-11 02:24:26 --- (In reply to comment #41)
(In reply to comment #40)
OK, but that is more that a couple a cases I would say. Not sure how the GetVersion() test should look like in this case though, but it looks doable.
First you need to find an application that depends on that.
I got one but but it does qualify :) I think the app will have to find me.
I do wonder if GetVersion() works in all parts of Wine?
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #43 from Juan Lang juan_lang@yahoo.com 2010-05-14 12:18:04 --- (In reply to comment #42)
I do wonder if GetVersion() works in all parts of Wine?
Of course it does.
It would be far more helpful to focus on the crypt32 error, i.e. to see why the builtin version of crypt32 doesn't work. Please open a new bug for that, and attach a +crypt log to it.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #44 from joakim.tjernlund@transmode.se 2010-05-14 13:19:44 --- (In reply to comment #43)
(In reply to comment #42)
I do wonder if GetVersion() works in all parts of Wine?
Of course it does.
OK, good to know
It would be far more helpful to focus on the crypt32 error, i.e. to see why the builtin version of crypt32 doesn't work. Please open a new bug for that, and attach a +crypt log to it.
The crypt32 error comes from calling RegisterWaitForSingleObject() with tmo == 0 this is legal on < Vista and implies executeOnlyOnce. However never Windows has dropped the "implies executeOnlyOnce" so you get a loop that consumes 100% CPU. Still no one has justified the new behavior as as something useful, I think it is useless and newer apps just avoids it. Someone please prove me wrong.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #45 from Juan Lang juan_lang@yahoo.com 2010-05-14 18:27:48 --- (In reply to comment #44)
The crypt32 error comes from calling RegisterWaitForSingleObject() with tmo == 0
No, that's not a crypt32 error. That's an error that comes when you use _native_ crypt32. builtin crypt32 never calls RegisterWaitForSingleObject. Again, please test this with builtin crypt32, and report the error that happens with it, in a separate bug please.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #46 from joakim.tjernlund@transmode.se 2010-05-15 02:24:11 --- (In reply to comment #45)
(In reply to comment #44)
The crypt32 error comes from calling RegisterWaitForSingleObject() with tmo == 0
No, that's not a crypt32 error. That's an error that comes when you use _native_ crypt32. builtin crypt32 never calls RegisterWaitForSingleObject. Again, please test this with builtin crypt32, and report the error that happens with it, in a separate bug please.
I am way past that. I have already identified the problem and provided a fix. There is also a test report that Windows < Vista behaves as my patch does.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #47 from Andrew Nguyen arethusa26@gmail.com 2010-05-15 05:49:32 --- (In reply to comment #46)
I am way past that. I have already identified the problem and provided a fix. There is also a test report that Windows < Vista behaves as my patch does.
Juan is not talking about the problem stemming from native (that is, Windows's implementation) crypt32's behavior, but rather whatever problems that come from using builtin (that is, Wine's implementation) crypt32. Most likely the motivation for using native comes from defects in Wine, so identifying those would be helpful.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #48 from joakim.tjernlund@transmode.se 2010-05-15 09:11:20 --- (In reply to comment #47)
(In reply to comment #46)
I am way past that. I have already identified the problem and provided a fix. There is also a test report that Windows < Vista behaves as my patch does.
Juan is not talking about the problem stemming from native (that is, Windows's implementation) crypt32's behavior, but rather whatever problems that come from using builtin (that is, Wine's implementation) crypt32. Most likely the motivation for using native comes from defects in Wine, so identifying those would be helpful.
That seems like a waste of time, such things has been tired before, see http://bugs.winehq.org/show_bug.cgi?id=13687 for instance.
The main problem remains the same: tmo=0 isn't handled by Wine like Windows < Vista does. Any app that relies on the old convention will experience the 100% CPU or similar. If you really want to help, you should try my patch on all those 100% CPU bugs in bugzilla and see if that helps.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #49 from Andrew Nguyen arethusa26@gmail.com 2010-05-15 09:42:13 --- (In reply to comment #48)
That seems like a waste of time, such things has been tired before, see http://bugs.winehq.org/show_bug.cgi?id=13687 for instance.
The main problem remains the same: tmo=0 isn't handled by Wine like Windows < Vista does. Any app that relies on the old convention will experience the 100% CPU or similar. If you really want to help, you should try my patch on all those 100% CPU bugs in bugzilla and see if that helps.
No, bug 13687 pertains to the use of native crypt32. I'm not dismissing the validity of this report, but, since the motivation for using native crypt32 in the first place is because of problems using Wine's implementation of crypt32, exposing defects in the builtin version not a bad thing to do.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #50 from joakim.tjernlund@transmode.se 2010-05-15 10:00:32 --- (In reply to comment #49)
(In reply to comment #48)
That seems like a waste of time, such things has been tired before, see http://bugs.winehq.org/show_bug.cgi?id=13687 for instance.
The main problem remains the same: tmo=0 isn't handled by Wine like Windows < Vista does. Any app that relies on the old convention will experience the 100% CPU or similar. If you really want to help, you should try my patch on all those 100% CPU bugs in bugzilla and see if that helps.
No, bug 13687 pertains to the use of native crypt32. I'm not dismissing the
Read harder, he tries with and without native crypt32
validity of this report, but, since the motivation for using native crypt32 in the first place is because of problems using Wine's implementation of crypt32, exposing defects in the builtin version not a bad thing to do.
We are way past native crypt32 or not, I have identified a bug in Wine and you don't want to fix it until someone can find an app that you approve of suffers the same fate as crypt32 does. I think the burden lies on Wine to prove that none of the 100% CPU bugs are affected by this bug.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #51 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-15 23:10:36 --- Have *you* tried to use built-in crypt32.dll? Does it work for *you*?
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #52 from joakim.tjernlund@transmode.se 2010-05-16 05:19:11 --- (In reply to comment #51)
Have *you* tried to use built-in crypt32.dll? Does it work for *you*?
Can't we stop focusing on crypt32? We are beyond that since long ago but since you ask, I did try it briefly and and it seemed to work but it was just a quick test.
http://bugs.winehq.org/show_bug.cgi?id=22580
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #53 from Juan Lang juan_lang@yahoo.com 2010-05-17 16:26:55 --- (In reply to comment #52)
Can't we stop focusing on crypt32? We are beyond that since long ago but since you ask, I did try it briefly and and it seemed to work but it was just a quick test.
In that case, this bug is invalid. It only appears when you use native crypt32 from old versions of Windows. Newer versions of Windows do not work this way, as your test case demonstrated.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #54 from joakim.tjernlund@transmode.se 2010-05-17 16:55:43 --- (In reply to comment #53)
(In reply to comment #52)
Can't we stop focusing on crypt32? We are beyond that since long ago but since you ask, I did try it briefly and and it seemed to work but it was just a quick test.
In that case, this bug is invalid. It only appears when you use native crypt32 from old versions of Windows. Newer versions of Windows do not work this way, as your test case demonstrated.
In your small world it is, but what if I found an app that did the same? Is this app also invalid? The newer Windows you refer to is a minority of all Windows systems.
http://bugs.winehq.org/show_bug.cgi?id=22580
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #55 from Nikolay Sivov bunglehead@gmail.com 2010-05-17 17:07:12 --- (In reply to comment #54)
In your small world it is, but what if I found an app that did the same? Is this app also invalid? The newer Windows you refer to is a minority of all Windows systems.
And what if you won't ever found it? Workaround will be useless in this case.
Feel free to reopen if you really found it.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #56 from joakim.tjernlund@transmode.se 2010-05-17 18:34:14 --- (In reply to comment #55)
(In reply to comment #54)
In your small world it is, but what if I found an app that did the same? Is this app also invalid? The newer Windows you refer to is a minority of all Windows systems.
And what if you won't ever found it? Workaround will be useless in this case.
Feel free to reopen if you really found it.
That was not an answer. If you really think that this native crypt32 dll is then only app that uses this feature, why don't you confirm it by working through the open 100% CPU bugs and actually verify that this is the case? And before you ask, it is not my job to do that for you.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #57 from Austin English austinenglish@gmail.com 2010-05-17 19:39:16 --- (In reply to comment #56)
(In reply to comment #55)
(In reply to comment #54)
In your small world it is, but what if I found an app that did the same? Is this app also invalid? The newer Windows you refer to is a minority of all Windows systems.
And what if you won't ever found it? Workaround will be useless in this case.
Feel free to reopen if you really found it.
That was not an answer. If you really think that this native crypt32 dll is then only app that uses this feature, why don't you confirm it by working through the open 100% CPU bugs and actually verify that this is the case? And before you ask, it is not my job to do that for you.
Developer time is spread thin enough as is. If you want that patch in wine, you need to find an application using that behavior, and you haven't done so.
Your effort would be better spent getting your testcase into wine, and/or testing other 100% cpu bugs to confirm your theory.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #58 from joakim.tjernlund@transmode.se 2010-05-18 01:56:51 --- (In reply to comment #57)
(In reply to comment #56)
(In reply to comment #55)
(In reply to comment #54)
In your small world it is, but what if I found an app that did the same? Is this app also invalid? The newer Windows you refer to is a minority of all Windows systems.
And what if you won't ever found it? Workaround will be useless in this case.
Feel free to reopen if you really found it.
That was not an answer. If you really think that this native crypt32 dll is then only app that uses this feature, why don't you confirm it by working through the open 100% CPU bugs and actually verify that this is the case? And before you ask, it is not my job to do that for you.
Developer time is spread thin enough as is. If you want that patch in wine, you need to find an application using that behavior, and you haven't done so.
Your effort would be better spent getting your testcase into wine, and/or testing other 100% cpu bugs to confirm your theory.
The testcase is worthless as it would just report what we already know. Asking me to find yet another app that has this particular use is too much. Consider that you don't even want to check your 100% CPU bugs wrt. to this problem.
Here is a hint for you though that might be acceptable. Add a trace for tmo == 0 && !executeOnce. Then you will quickly see/find potential problem apps. I am not doing that for you though.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #59 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-18 02:17:57 --- (In reply to comment #58)
The testcase is worthless as it would just report what we already know. Asking me to find yet another app that has this particular use is too much.
So far there is exactly 0 (zero) apps affected by this problem. Once again, crypt32.dll is a system library (and not an application), and it looks like win9x version of the DLL uses undocumented quirk of RegisterWaitForSingleObject() implementation which doesn't exist on newer Windows versions.
And once again, there is no any justification or need to use win9x version of crypt32.dll under Wine, built-in version works just fine. Try to use it for instance under Vista, then in the case of a bug report it Microsoft, let us know how it goes.
Consider that you don't even want to check your 100% CPU bugs wrt. to this problem.
Feel free to do that in your own free time, Wine is an open source project developed by volunteers. Be our guest.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #60 from joakim.tjernlund@transmode.se 2010-05-18 03:20:22 --- (In reply to comment #59)
(In reply to comment #58)
The testcase is worthless as it would just report what we already know. Asking me to find yet another app that has this particular use is too much.
So far there is exactly 0 (zero) apps affected by this problem. Once again,
You don't know that. You are just guessing.
crypt32.dll is a system library (and not an application), and it looks like win9x version of the DLL uses undocumented quirk of RegisterWaitForSingleObject() implementation which doesn't exist on newer Windows versions.
Come on, why do you keep repeating this false claim? It is documented and verified for Windows < Vista. You think XP is dead? Think again.
And once again, there is no any justification or need to use win9x version of crypt32.dll under Wine, built-in version works just fine. Try to use it for instance under Vista, then in the case of a bug report it Microsoft, let us know how it goes.
This I can agree with but once again, we have left this particular dll behind us. It is just one way of triggering this particular bug.
Consider that you don't even want to check your 100% CPU bugs wrt. to this problem.
Feel free to do that in your own free time, Wine is an open source project developed by volunteers. Be our guest.
I just a causal Wine user from time to time. It is even more unlikely I will do that than a Wine developer that cares does it. It is a bug in Wine, plain and simple.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #61 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-18 04:49:36 --- (In reply to comment #60)
So far there is exactly 0 (zero) apps affected by this problem. Once again,
You don't know that. You are just guessing.
Unless proven otherwise this a matter of the fact. Please stop speculating.
crypt32.dll is a system library (and not an application), and it looks like win9x version of the DLL uses undocumented quirk of RegisterWaitForSingleObject() implementation which doesn't exist on newer Windows versions.
Come on, why do you keep repeating this false claim?
That's the fact. Please read again all the comments in this report.
It is documented and verified for Windows < Vista.
No one, except win9x version of crypt32.dll uses RegisterWaitForSingleObject() that way. Please read once again in the comments how much MSDN could be trusted regarding API behaviour, all the Wine history is about that.
You think XP is dead? Think again.
You went too far with your speculations. We are talking about specific API behaviour a win9x version of a single DLL depends upon.
And once again, there is no any justification or need to use win9x version of crypt32.dll under Wine, built-in version works just fine. Try to use it for instance under Vista, then in the case of a bug report it Microsoft, let us know how it goes.
This I can agree with but once again, we have left this particular dll behind us. It is just one way of triggering this particular bug.
You forgot (once again) to list the other ones. If you don't know them please stop speculating.
Consider that you don't even want to check your 100% CPU bugs wrt. to this problem.
Feel free to do that in your own free time, Wine is an open source project developed by volunteers. Be our guest.
I just a causal Wine user from time to time. It is even more unlikely I will do that than a Wine developer that cares does it.
Please read the comment #16 once again.
It is a bug in Wine, plain and simple.
So much for a report resolved as INVALID.
http://bugs.winehq.org/show_bug.cgi?id=22580
--- Comment #62 from joakim.tjernlund@transmode.se 2010-05-18 13:51:33 --- (In reply to comment #61)
(In reply to comment #60)
So far there is exactly 0 (zero) apps affected by this problem. Once again,
You don't know that. You are just guessing.
Unless proven otherwise this a matter of the fact. Please stop speculating.
You are speculating too.
crypt32.dll is a system library (and not an application), and it looks like win9x version of the DLL uses undocumented quirk of RegisterWaitForSingleObject() implementation which doesn't exist on newer Windows versions.
Come on, why do you keep repeating this false claim?
That's the fact. Please read again all the comments in this report.
It is false that it is an undocumented quirk which I made clear in my next sentence.
It is documented and verified for Windows < Vista.
No one, except win9x version of crypt32.dll uses RegisterWaitForSingleObject() that way. Please read once again in the comments how much MSDN could be trusted regarding API behaviour, all the Wine history is about that.
Possibly no one but win9x uses RegisterWaitForSingleObject() in this way.
You think XP is dead? Think again.
You went too far with your speculations. We are talking about specific API behaviour a win9x version of a single DLL depends upon.
What I meant is that any app that was written for and built on XP could also use this "feature".
And once again, there is no any justification or need to use win9x version of crypt32.dll under Wine, built-in version works just fine. Try to use it for instance under Vista, then in the case of a bug report it Microsoft, let us know how it goes.
This I can agree with but once again, we have left this particular dll behind us. It is just one way of triggering this particular bug.
You forgot (once again) to list the other ones. If you don't know them please stop speculating.
I didn't forget but the statement still holds, any app using the same "feature" will not work in Wine. I don't know if there are any but it is not impossible.
Consider that you don't even want to check your 100% CPU bugs wrt. to this problem.
Feel free to do that in your own free time, Wine is an open source project developed by volunteers. Be our guest.
I just a causal Wine user from time to time. It is even more unlikely I will do that than a Wine developer that cares does it.
Please read the comment #16 once again.
It is a bug in Wine, plain and simple.
So much for a report resolved as INVALID.
I didn't agree to that, but I accept it. We just don't agree whether Wine should try to address this before some approved app has been proven to need this to be on the safe side or wait until someone actually hits this, which may never happen.
I don't have anything more to add, hopefully this will be the last time this issue is discussed, time will tell.
-
wine-bugs＠winehq.org