http://bugs.winehq.org/show_bug.cgi?id=20653
Summary: Warcraft 3 freezes after successful login into Battle.net Product: Wine Version: unspecified Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: wylda@volny.cz
Created an attachment (id=24658) --> (http://bugs.winehq.org/attachment.cgi?id=24658) Working version has two extra line of console output.
Hi, when trying to help with recent bug 20616, i found out, that there is recent regression. So because it does not happen in wine-1.1.32 and wine-1.1.33 is still not released, i left version as unspecified. Please correct if wrong...
So when you enter Battle.net's user name and password it should show you next screen with battle net news, ladder, creating games etc. In this point the whole game freeze and cpu is 100%. After 3 minutes of waiting patience gone...
1. Please consider KEYWORDS: +REGRESSION
2. Did a regression test between 1.1.32 and wine-1.1.32-499-gffb2cfc
9059892ec1da79567279aaeb96f46791718bc7a1 is first bad commit commit 9059892ec1da79567279aaeb96f46791718bc7a1 Author: Juan Lang juan.lang@gmail.com Date: Wed Oct 28 09:17:30 2009 -0700
crypt32: Implement CertVerifyCertificateChainPolicy for CERT_CHAIN_POLICY_SSL.
:040000 040000 08257a2cfdbe7eac90f8a0f1304a31e9938f1836 6579870626e4e52d16109f75404e9f0fdb67f2e7 M dlls
3. No other bug report suffers from this commit.
4. Revert of this patch on top of wine-1.1.32-499-gffb2cfc fails due to other code changes.
5. Adding author of this patch to CC and normally i vote at this point, but if memory serves me well, i think i read in other bug report: "don't vote for own bug report". Although i did not noticed/read any prohibition of this behavior.
Adding console diff between working and freezing Warcraft 3 Region of Chaos.
http://bugs.winehq.org/show_bug.cgi?id=20653
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |juan_lang@yahoo.com
http://bugs.winehq.org/show_bug.cgi?id=20653
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |crypt32 Version|unspecified |1.1.32
--- Comment #1 from Juan Lang juan_lang@yahoo.com 2009-11-10 17:06:15 --- Please set your Wine version.
Your log has: fixme:crypt:CRYPT_CriticalExtensionsSupported unsupported critical extension "2.5.29.32"
That's a known problem. It was mentioned in bug 19517, although that's a different app so this isn't a dup.
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #2 from Wylda wylda@volny.cz 2009-11-10 17:15:03 --- (In reply to comment #1)
Please set your Wine version.
I see you set 1.1.32, but this version works OK.
Your log has: fixme:crypt:CRYPT_CriticalExtensionsSupported unsupported critical extension "2.5.29.32"
This is not a problem, because it works well with it. As you can see from diff it is in both - in working and also in freezing. So it does not have influence on freezing, does it?
That's a known problem. It was mentioned in bug 19517, although that's a different app so this isn't a dup.
Well it should not be duplicate, because the problem here is caused by commit 9059892ec1da79567279aaeb96f46791718bc7a1, which is not mentioned in bug 19517.
http://bugs.winehq.org/show_bug.cgi?id=20653
Jean-Noel Rivasseau elvanor2007@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |elvanor2007@gmail.com
--- Comment #3 from Jean-Noel Rivasseau elvanor2007@gmail.com 2009-11-10 17:40:42 --- About bug 20616: did you manage to get past it? It somehow seems so, since the 100%CPU problem you mention seems to happen after the critical memory access problem I get...
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #4 from Juan Lang juan_lang@yahoo.com 2009-11-10 17:59:40 --- (In reply to comment #2)
I see you set 1.1.32, but this version works OK.
That's true. That's because the head of git doesn't have a version yet, so its version is 1.1.32-something. Basically, it's the closest version.
This is not a problem, because it works well with it. As you can see from diff it is in both - in working and also in freezing. So it does not have influence on freezing, does it?
I suspect it does, though I'm not sure. Before commit 9059892ec1da79567279aaeb96f46791718bc7a1, CertVerifyCertificateChainPolicy returned FALSE. Now it returns TRUE.
Please attach a +crypt,+chain log.
Well it should not be duplicate, because the problem here is caused by commit 9059892ec1da79567279aaeb96f46791718bc7a1, which is not mentioned in bug 19517.
That's more for others bug bashers around here. If I mention another bug, they might close this as dup. I'm trying to prevent that.
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #5 from Wylda wylda@volny.cz 2009-11-10 18:16:24 --- Created an attachment (id=24659) --> (http://bugs.winehq.org/attachment.cgi?id=24659) console log with export WINEDEBUG="+crypt,+chain"
(In reply to comment #4)
Please attach a +crypt,+chain log.
With pleasure... See attached: export WINEDEBUG="+crypt,+chain"
That's more for others bug bashers around here. If I mention another bug, they might close this as dup. I'm trying to prevent that.
Ahhh i see and know what you are talking about ;) Pretty frustrating sometime :-/
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #6 from Juan Lang juan_lang@yahoo.com 2009-11-10 19:07:21 --- (In reply to comment #5) Thanks. From your log:
trace:crypt:CertVerifyCertificateChainPolicy returning 1 (00000000)
That's really odd. CertVerifyCertificateChainPolicy returns TRUE, with no errors. Why does that make the app hang?
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #7 from Juan Lang juan_lang@yahoo.com 2009-11-10 19:22:07 --- (In reply to comment #6)
CertVerifyCertificateChainPolicy returns TRUE, with no errors. Why does that make the app hang?
Continuing that line of thinking: I suspect that it's hanging because it's trying to reach https://locate.madserver.net. Before it gave up because of crypt32 failing to validate the certificate. Now it succeeds, and continues on to the next step, whatever that is, and it's the next step that's hanging.
Perhaps a +relay log beginning with CertVerifyCertificateChainPolicy would give some indication what it's trying to do.
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #8 from Wylda wylda@volny.cz 2009-11-10 19:25:00 --- (In reply to comment #6)
Why does that make the app hang?
Hope that its just rhetorical question ;) otherwise me as a non-programmer person can not give you an answer :-/
I can just say, that in that moment game take 100% of one of four cores and nothing happens. My patience lasted 4 minutes max and than i killed it.
Also i could send you same trace just before that commit, so you can compare. Working version continues to:
fixme:crypt:CertVerifyCertificateChainPolicy unimplemented for 4 fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for 8000000a
So can't be problem here? Don't know if your patch added possibility for CertVerifyCertificateChainPolicy=4 and it screwed war3... Well better save bytes in bugzilla memory that write bullshit here ;) Sorry if total nonsense.
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #9 from Wylda wylda@volny.cz 2009-11-10 19:43:11 --- Created an attachment (id=24661) --> (http://bugs.winehq.org/attachment.cgi?id=24661) +relay log "begining" with CertVerifyCertificateChainPolicy
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #10 from Juan Lang juan_lang@yahoo.com 2009-11-10 19:49:11 --- (In reply to comment #9) This has:
0009:Call crypt32.CertVerifyCertificateChainPolicy(00000004,051f8568,0033f9bc,0033f988) ret=6f7ef837 fixme:crypt:CertVerifyCertificateChainPolicy unimplemented for 4
This must be from 1.1.32, yes? Interesting for comparison, but could you also do it with 1.1.32-499-gffb2cfc?
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #11 from Wylda wylda@volny.cz 2009-11-10 20:10:12 --- Created an attachment (id=24662) --> (http://bugs.winehq.org/attachment.cgi?id=24662) +relay log from wine-1.1.32-499-gffb2cfc "begining" with CertVerifyCertificateChainPolicy
This time log is taken from wine-1.1.32-499-gffb2cfc.
Log in attached in comment #9 is truly from wine-1.1.32.
PS: Initially i spoke about game freezing, but the log was still growing, i.e. game is alive and takes 100% of CPU.
http://bugs.winehq.org/show_bug.cgi?id=20653
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|crypt32 |-unknown
--- Comment #12 from Juan Lang juan_lang@yahoo.com 2009-11-10 20:21:39 --- Indeed, the app is moving on after verifying the certificate chain, e.g.:
0009:Call secur32.QueryContextAttributesA(006a6694,00000004,0033fac0) ret=6f7ef8c0 0009:Ret secur32.QueryContextAttributesA() retval=00000000 ret=6f7ef8c0 0009:Call ntdll.RtlAllocateHeap(006a0000,00000000,00004119) ret=78134d83 0009:Ret ntdll.RtlAllocateHeap() retval=006a8f80 ret=78134d83 0009:Call secur32.EncryptMessage(006a6694,00000000,0033fad4,00000000) ret=6f7ef974 0009:Call KERNEL32.GetProcessHeap() ret=7dab5dcd 0009:Ret KERNEL32.GetProcessHeap() retval=00110000 ret=7dab5dcd 0009:Call ntdll.RtlAllocateHeap(00110000,00000000,000000eb) ret=7dab5de6 0009:Ret ntdll.RtlAllocateHeap() retval=050b20f0 ret=7dab5de6 0009:Call KERNEL32.GetProcessHeap() ret=7dab6003 0009:Ret KERNEL32.GetProcessHeap() retval=00110000 ret=7dab6003 0009:Call ntdll.RtlFreeHeap(00110000,00000000,050b20f0) ret=7dab601c 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7dab601c 0009:Ret secur32.EncryptMessage() retval=00000000 ret=6f7ef974 0009:Call ws2_32.send(00004190,006a8f80,000001e5,00000000) ret=6f7ef99d
It appears to be using schannel to send some data via SSL to the server, but it never gets any response, at least not in the log you attached. I have no idea why, nor what it's sending.
I'm resetting the component, since I'm pretty sure the crypt32 change just let warcraft stumble onto some other bug.
http://bugs.winehq.org/show_bug.cgi?id=20653
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.32 |1.1.33
--- Comment #13 from Wylda wylda@volny.cz 2009-11-15 04:21:07 ---
When 1.1.33 is released, i can change version to 1.1.33. I performed test right now and 1.1.32 works and 1.1.33 hangs as described in comment #0. What do we do with it Juan? ;)
--private keyword: bisected
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #14 from Juan Lang juan_lang@yahoo.com 2009-11-15 19:08:40 --- (In reply to comment #13)
What do we do with it Juan?
I don't know. I'm certain the patch caused the regression, and I'm equally certain that it's needed, by other apps, so reverting it isn't really an option.
You could try to see what the app is sending to the server, to try to guess what the server doesn't like about the data. That'd probably require hacking schan_EncryptMessage in dlls/secur32/schannel.c to output the buffers it's given.
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #15 from Wylda wylda@volny.cz 2009-11-16 07:08:58 --- (In reply to comment #14)
You could try to see what the app is sending to the server, to try to guess what the server doesn't like about the data.
I'll gladly do that, but i can handle only with tcpdump/wireshrak ...
That'd probably require hacking schan_EncryptMessage in dlls/secur32/schannel.c to output the buffers it's given.
...but not with wine's code. Can wine provide keys used in cypher comunication which could be latter used for decyphering tcpdump's content? Thanks for advice.
Anyway i am still looking into the traces in comment #9 and comment #11. And i dont understand it at all... But still thinking about - you said that it's not in crypt32 (and did reset of component), so why:
* crypt32.CertVerifyCertificateChainPolicy returns 1 in "freezing" warcraft vs * crypt32.CertVerifyCertificateChainPolicy returns 0 in "working" warcraft
Why inside CertVerifyCertificateChainPolicy is working warcraft doing things like "string manipulation" and "accessing registry"... But freezing warcraft does not do here "nothing useful" (based on trace).
http://bugs.winehq.org/show_bug.cgi?id=20653
kapta ulo_kapta@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ulo_kapta@hotmail.com
--- Comment #16 from kapta ulo_kapta@hotmail.com 2009-11-16 08:16:50 --- I can confirm this behavior/regression with Wine 1.33.
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #17 from Juan Lang juan_lang@yahoo.com 2009-11-16 11:10:53 --- (In reply to comment #15)
...but not with wine's code. Can wine provide keys used in cypher comunication which could be latter used for decyphering tcpdump's content? Thanks for advice.
No, because they're actually derived by GnuTLS, not by Wine. You'd have to hack the function I mentioned to trace the input before it's given to GnuTLS. (Or I could probably hack up a patch, when I find the time.)
Anyway i am still looking into the traces in comment #9 and comment #11. And i dont understand it at all... But still thinking about - you said that it's not in crypt32 (and did reset of component), so why:
- crypt32.CertVerifyCertificateChainPolicy returns 1 in "freezing" warcraft
vs
- crypt32.CertVerifyCertificateChainPolicy returns 0 in "working" warcraft
Because returning 1 results in warcraft doing something different. The freezing is happening within warcraft, not in Wine.
Before the change, warcraft figured the site it was trying to contact had a bogus certificate, so it didn't bother sending anything to it, and let you play as normal.
After the change, warcraft correctly decides that the site it's trying to contact has a valid certificate, so sends it some unknown, encrypted data, and waits for a response. The response never comes. Why is that? It's impossible to know with certainty without knowing the code on the server side. That's why I suggested looking at the data Wine wants to send: it might be possible to guess. For example, perhaps it's sending the version of Windows or some DLLs, and the server decides it's unsupported? But that's just a guess on my part.
You could also hack CertVerifyCertificateChainPolicy to return 0, but you've have to maintain that hack for every version of Wine going forward. There are other apps that depend on this working correctly, and the change was more correct than what it was doing before, so reverting it is not an option.
http://bugs.winehq.org/show_bug.cgi?id=20653
EtherealTouch@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |EtherealTouch@gmail.com
--- Comment #18 from EtherealTouch@gmail.com 2009-11-19 13:00:46 --- I can also confirm this with 1.1.33. Game hangs immediately after succesful login to Bnet. I thought at first this might be because of the advertisements... Every time before this issue came about, the game would slow down for a moment after logging in to Bnet- and I thought it might have been because of the data retrieval from the servers. Is wine-gecko messing with this in any way (yes, I know, silly question).
No output to provide, at work, don't have my Linux lappy with me.
http://bugs.winehq.org/show_bug.cgi?id=20653
CommonOddity EtherealTouch@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #19 from CommonOddity EtherealTouch@gmail.com 2009-11-19 13:17:43 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #20 from Wylda wylda@volny.cz 2009-11-19 22:18:53 --- Hi Juan, when i saw bug 20622, i immediately think about relation between W3. So i applied that secur32 patch on non-working wine and things changed. Now it does not look like frozen all the time in battle net.
After patching game moves normally for 1sec, then 3sec freeze, 1sec normal, 3sec freeze... and this repeat. During the freeze, console vomits:
fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority
So you were right about dlls/secur32/schannel.c :) I hope that chromium help us to solve this ;)
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #21 from Wylda wylda@volny.cz 2009-11-19 22:45:09 --- Created an attachment (id=24851) --> (http://bugs.winehq.org/attachment.cgi?id=24851) Console output from wine-1.1.33-259-g7782ebe
I tried latest git (wine-1.1.33-259-g7782ebe) and now even that 3sec freeze disappeared. Now only things which remain are repetitive console messages.
http://bugs.winehq.org/show_bug.cgi?id=20653
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@meelstraat.net
--- Comment #22 from Hans Leidekker hans@meelstraat.net 2009-11-20 02:20:56 --- Please try this patch from bug 20748: http://bugs2.winehq.org/attachment.cgi?id=24832
If it still fails, attach a WINEDEBUG=+secur32 trace here.
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #23 from Wylda wylda@volny.cz 2009-11-20 22:13:10 --- Created an attachment (id=24875) --> (http://bugs.winehq.org/attachment.cgi?id=24875) Console output from wine-1.1.33-301-gd963e97 with WINEDEBUG=+secur32
(In reply to comment #22)
If it still fails,
Hi Hans, as i said before in wine-1.1.33-259-g7782ebe that 3sec freeze disappeared and only problem that remains (cosmetic) are those fast repetitive console messages:
fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority
fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do!
Applying patch http://bugs2.winehq.org/attachment.cgi?id=24832 change appearing of those messages. So instead of zillions there are only 4 pairs or maybe they are appearing pretty slowly now (first quick login and logout gave only 3 pairs messages). Anyway that patch improved it!
attach a WINEDEBUG=+secur32 trace here.
Because they are still appearing i attached required log.
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #24 from Hans Leidekker hans@meelstraat.net 2009-11-21 03:57:32 ---
Hi Hans, as i said before in wine-1.1.33-259-g7782ebe that 3sec freeze disappeared and only problem that remains (cosmetic) are those fast repetitive console messages:
fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority
That's likely because it fails to connect and retries, in a loop.
Applying patch http://bugs2.winehq.org/attachment.cgi?id=24832 change appearing of those messages. So instead of zillions there are only 4 pairs or maybe they are appearing pretty slowly now (first quick login and logout gave only 3 pairs messages). Anyway that patch improved it!
It might even be fixed, can you use Warcraft now after login on battle.net? The log you attached is clean and the fixme's that remain should be harmless.
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #25 from Wylda wylda@volny.cz 2009-11-24 17:19:05 --- (In reply to comment #24)
It might even be fixed, can you use Warcraft now after login on battle.net?
Current git (wine-1.1.33-404-gac85305) allows me to connect to battle net and join a room with chat.
With your patch (http://bugs2.winehq.org/attachment.cgi?id=24832 ) applied on top of current git, i can also connect to battle net and join a room with chat and as a bonus, the patch eliminates lot of those messages! (fixme:secur32:schan_InitializeSecurityContextW...)
http://bugs.winehq.org/show_bug.cgi?id=20653
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #26 from Hans Leidekker hans@meelstraat.net 2009-11-25 00:57:28 --- Fixed then.
http://bugs.winehq.org/show_bug.cgi?id=20653
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |
--- Comment #27 from Hans Leidekker hans@meelstraat.net 2009-11-25 01:06:01 --- That was too fast.
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #28 from Wylda wylda@volny.cz 2009-11-25 04:06:19 --- (In reply to comment #27)
That was too fast.
Hmmmm.... :) Well i'm not strictly againt closing, because initial reported problem was fixed. Maybe something to take into account:
* closing can mean, that other people playing with 1.1.33 will start opening a new one
* attachment.cgi?id=24832 is still not in git, so if this is open, patch should not be forgotten
* can remaind you, that there are still some schan_InitializeSecurityContextW fixmes, that can be easily fixed ;) (maybe??)
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #29 from Hans Leidekker hans@meelstraat.net 2009-11-25 04:17:59 --- We should close this bug when the patch is committed. The fixmes you still see are harmless in this case.
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #30 from kapta ulo_kapta@hotmail.com 2009-12-10 12:54:58 --- I can confirm too, that this bug is now fixed with wine 1.1.34
http://bugs.winehq.org/show_bug.cgi?id=20653
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED
--- Comment #31 from Dmitry Timoshkov dmitry@codeweavers.com 2009-12-11 02:34:21 --- Reported fixed.
http://bugs.winehq.org/show_bug.cgi?id=20653
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |
--- Comment #32 from Juan Lang juan_lang@yahoo.com 2009-12-11 09:12:50 --- I think marking it fixed is premature. The patch attached to this bug hasn't been sent in yet, and at least one other user reported similar symptoms (in bug 20616.) Reopening until more users report similar success.
http://bugs.winehq.org/show_bug.cgi?id=20653
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |crypt32
http://bugs.winehq.org/show_bug.cgi?id=20653
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|crypt32 |secur32
--- Comment #33 from Juan Lang juan_lang@yahoo.com 2009-12-11 14:54:13 --- Setting to more likely component, the crypt32 stuff was correct, it just induces an error that was never reached before.
http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #34 from Wylda wylda@volny.cz 2009-12-11 16:27:53 --- Created an attachment (id=25173) --> (http://bugs.winehq.org/attachment.cgi?id=25173) Console output during battlnet gaming
Hi, as i said in comment #21:
I tried latest git (wine-1.1.33-259-g7782ebe) and now even that 3sec freeze disappeared. Now only things which remain are repetitive console messages.
Since this comment we can consider it fixed. Shortly after this commit followed Hans Leidekker's patch which significantly reduced console messages from "zillion" to few. But it was considered as cosmetic only and had no impact to battle net login.
So now i tried 1.1.34 and currnet git (wine-1.1.34-309-g9352509) and both works fine (login=OK and also played few games cca 15min online). Well i noticed some new console error messages, which i attach. They has nothing to do with this bug report (i had one crash, which i cant reproduce so not worth to open a new one --just only if you noticed something really serious there).
http://bugs.winehq.org/show_bug.cgi?id=20653
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED
--- Comment #35 from Juan Lang juan_lang@yahoo.com 2009-12-11 16:33:33 --- Okay, okay, fixed :)
http://bugs.winehq.org/show_bug.cgi?id=20653
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #36 from Alexandre Julliard julliard@winehq.org 2009-12-18 13:07:50 --- Closing bugs fixed in 1.1.35.
http://bugs.winehq.org/show_bug.cgi?id=20653
Simon Simon80@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Simon80@gmail.com
--- Comment #37 from Simon Simon80@gmail.com 2010-01-04 14:45:14 --- *** Bug 21242 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=20653
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |9059892ec1da79567279aaeb96f | |46791718bc7a1
-
wine-bugs＠winehq.org