http://bugs.winehq.org/show_bug.cgi?id=18384
Summary: Battlenet system check: does not submit data to battle.net Product: Wine Version: 1.1.20 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: puciek@gmail.com
Created an attachment (id=20965) --> (http://bugs.winehq.org/attachment.cgi?id=20965) Backtrace
After gathering data about your enviroment, and pressing send button, application will "think" for some time and then will report that it was unable to send data and opens a page with support page regarding this problem.
http://bugs.winehq.org/show_bug.cgi?id=18384
Jaime Soriano kronoss@kronoss.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kronoss@kronoss.org
--- Comment #1 from Jaime Soriano kronoss@kronoss.org 2009-05-10 06:22:03 --- I have seen in my laptop that everything is detected except Video Card.
In logs (with +relay) I can see that an "HTTP/1.1 500 Internal Server Error" is received after a couple of POST requests against us.battle.net, could "Video Card" be a mandatory field or something?
Then the problem would be in the hardware detection part and not when sending the information.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #2 from Tymoteusz Paul puciek@gmail.com 2009-05-14 03:57:20 --- It does detect my graphic card fine (i got graph card details set in register so probabyl because of that) so this is not it.
http://bugs.winehq.org/show_bug.cgi?id=18384
Matt Cockayne matt.cockayne@hotmail.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |matt.cockayne@hotmail.co.uk
--- Comment #3 from Matt Cockayne matt.cockayne@hotmail.co.uk 2009-05-29 01:37:01 --- Same here for me...
SystemCheck gathers all of the right information but doent seem to be able to post it back to battlenet
Ubuntu 9.04 wine 1.1.22
err:richedit:ReadStyleSheet ReadStyleSheet: skipping optional destination err:richedit:ReadStyleSheet ReadStyleSheet: skipping optional destination err:richedit:ReadStyleSheet ReadStyleSheet: skipping optional destination err:richedit:ReadStyleSheet ReadStyleSheet: skipping optional destination err:richedit:ReadStyleSheet ReadStyleSheet: skipping optional destination err:richedit:ReadStyleSheet ReadStyleSheet: skipping optional destination err:richedit:ReadStyleSheet ReadStyleSheet: skipping optional destination err:richedit:ReadStyleSheet ReadStyleSheet: skipping optional destination err:richedit:ReadStyleSheet ReadStyleSheet: skipping optional destination err:richedit:ReadStyleSheet ReadStyleSheet: skipping optional destination fixme:ntdll:NtPowerInformation semi-stub: SystemPowerCapabilities fixme:win:EnumDisplayDevicesW ((null),0,0xafdf3c,0x00000000), stub! fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONNECT_TIMEOUT (10000): STUB fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT 10000
http://bugs.winehq.org/show_bug.cgi?id=18384
guillaume.laforie@laposte.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |guillaume.laforie@laposte.n | |et
http://bugs.winehq.org/show_bug.cgi?id=18384
EA Durbin ead1234@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ead1234@hotmail.com
--- Comment #4 from EA Durbin ead1234@hotmail.com 2009-05-29 14:38:52 --- This bug appears to affect the hulu desktop as well, it is stuck in a continuous loop of
fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONNECT_TIMEOUT (5000): STUB fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT 5000
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #5 from EA Durbin ead1234@hotmail.com 2009-05-29 14:43:11 --- please change component to wininet
http://bugs.winehq.org/show_bug.cgi?id=18384
Tymoteusz Paul puciek@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |wininet
--- Comment #6 from Tymoteusz Paul puciek@gmail.com 2009-05-29 14:44:34 --- Done
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #7 from Austin English austinenglish@gmail.com 2009-05-29 16:00:29 --- (In reply to comment #5)
please change component to wininet
Are you sure it's wininet? Does native fix it?
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #8 from EA Durbin ead1234@hotmail.com 2009-05-29 16:03:02 --- (In reply to comment #7)
(In reply to comment #5)
please change component to wininet
Are you sure it's wininet? Does native fix it?
No, native breaks wine and it doesn't detect an internet connection at all with native, the continuous looping messages in the console all refer to wininet.
http://bugs.winehq.org/show_bug.cgi?id=18384
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|wininet |-unknown
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #9 from EA Durbin ead1234@hotmail.com 2009-05-29 16:44:00 --- Created an attachment (id=21413) --> (http://bugs.winehq.org/attachment.cgi?id=21413) console output
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #10 from EA Durbin ead1234@hotmail.com 2009-05-29 18:05:24 --- after doing a WINEDEBUG=+wininet, it appears hulu desktop is trying to decompress gzip encoded content, it also appears there's a patch in the pipeline for this
http://www.winehq.org/pipermail/wine-patches/2009-May/073537.html
I'll test it and see if it fixes it.
http://bugs.winehq.org/show_bug.cgi?id=18384
William Pettersson william.pettersson@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |william.pettersson@gmail.co | |m
--- Comment #11 from William Pettersson william.pettersson@gmail.com 2009-05-29 18:33:11 --- I used WINEDEBUG=+wininet to trace through what's happening. I'm definitely seeing a 500 error from Blizzards servers. More curious though, I'm getting the following POST
trace:wininet:HTTP_HttpSendRequestW full request -> "POST /account/systemsurvey/submit.xml?purpose=sc2beta HTTP/1.1\r\nHost: us.battle.net\r\nContent-Length: 343\r\nUser-Agent: Blizzard Web Client\r\nCache-Control: no-cache\r\nContent-Type: application/x-www-form-urlencoded\n\nContent-Length: 343\r\n\r\n&email=123456789012345678@gmail.com&key=c6b177128"...
Now that is not my real email address, but I simply changed each letter into a number. Apparently the content-length is 343, but the data in this POST is nowhere near 343 bytes. I get the feeling that something else is still amiss.
I'll attach my wininet trace as well, if anyone wants to look through it.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #12 from William Pettersson william.pettersson@gmail.com 2009-05-29 18:35:16 --- Created an attachment (id=21415) --> (http://bugs.winehq.org/attachment.cgi?id=21415) console output with WINEDEBUG=+wininet
Sanitised, removed my email address, however my email address still has the same number of bytes.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #13 from EA Durbin ead1234@hotmail.com 2009-05-29 18:53:26 --- Is there a free download or a demo that contains the Battlenet system check?
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #14 from William Pettersson william.pettersson@gmail.com 2009-05-29 19:07:59 --- (In reply to comment #13)
Is there a free download or a demo that contains the Battlenet system check?
I do believe if you go to www.battle.net and sign up, you can access their system checks file via the beta opt-in section. Once you're signed in, there's a "Beta Profile Settings" page which has a huge yellow link with the .exe file. The .exe file does have some account-specific strings inside it, which is why I'm hesitant to share it.
I also realised that my trace output prints "..." at the end of the string, so my Content-Length is probably correct, the trace probably just isn't printing out the whole POST.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #15 from EA Durbin ead1234@hotmail.com 2009-05-29 19:16:01 --- You have to own a blizzard game to tie the account to to opt-in for beta.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #16 from Ken Sharp kennybobs@o2.co.uk 2009-05-29 19:16:23 --- Have you confirmed this works in Windows?
http://bugs.winehq.org/show_bug.cgi?id=18384
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@meelstraat.net
--- Comment #17 from Hans Leidekker hans@meelstraat.net 2009-05-30 01:48:57 --- The content-length header signifies the length of the body the request, not of the headers themselves.
Perhaps the server is confused by the doubled content-length header.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #18 from guillaume.laforie@laposte.net 2009-05-30 13:30:27 --- note that in the trace
Content-Type: application/x-www-form-urlencoded\n\nContent-Length: 343 <<<<<
it should be IMHO
Content-Type: application/x-www-form-urlencoded\r\nContent-Length: 343 <<<<<
that may explain the internal error on the serveur
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #19 from William Pettersson william.pettersson@gmail.com 2009-05-30 19:16:48 --- I've written a dirty hack to wipe out the "\n\n", and it drops off the first Content-Length: header too, so that is cleared up. I still got the same error while trying to submit (500 from server). I noticed that the second "Content-Length:" however is (L"354\n") so I wiped out that \n as well. I still get 500s from the server. No idea what to check next.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #20 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2009-05-30 19:38:28 --- Created an attachment (id=21427) --> (http://bugs.winehq.org/attachment.cgi?id=21427) possible fix for 500
(In reply to comment #18)
note that in the trace
Content-Type: application/x-www-form-urlencoded\n\nContent-Length: 343 <<<<<
it should be IMHO
Content-Type: application/x-www-form-urlencoded\r\nContent-Length: 343 <<<<<
that may explain the internal error on the serveur
Yep that may be right. It looks like the application passes \n\n instead of \r\n in the extra headers section. Does windows ignore this and actually parse the headers correctly? Maybe we should just ignore the \r and just scan for \n then.
Try this patch - apply on top of git and then apply the gzip patches. See if you still get the 500 error. If this works then I'll write up a test case and submit it. For reference, here are the gzip patches:
http://www.nabble.com/-PATCH-1-5--wininet%3A-Move-strings-to-avoid-duplicati... http://www.nabble.com/-PATCH-2-5--wininet%3A-Always-set-path-in-HttpOpenRequ... http://www.nabble.com/-PATCH-3-5--wininet%3A-Change-read_buf-type-to-BYTE.-t... http://www.nabble.com/-PATCH-4-5--wininet%3A-Added-support-for-decompressing... http://www.nabble.com/-PATCH-5-5--wininet%3A-Test-gzip-encoded-read.-td23787...
Regardless - not the problem with hulu. Hulu seems to just not work (no http errors). Still investigating.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #21 from William Pettersson william.pettersson@gmail.com 2009-05-30 19:50:12 --- Mike, I wrote a similar patch as well, just to check for "\n\n" and remove it, as per comment above. This did chance the wininet trace, so that it looked correct, but I still got the error 500s from the server. See http://pastebin.com/m50e46ee4 for the trace. I'll see if I can get time to check the gzip patches as well, see if they make a difference.
http://bugs.winehq.org/show_bug.cgi?id=18384
Mike Kaplinskiy mike.kaplinskiy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mike.kaplinskiy@gmail.com
--- Comment #22 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2009-05-30 21:08:01 --- (In reply to comment #19)
I've written a dirty hack to wipe out the "\n\n", and it drops off the first Content-Length: header too, so that is cleared up. I still got the same error while trying to submit (500 from server). I noticed that the second "Content-Length:" however is (L"354\n") so I wiped out that \n as well. I still get 500s from the server. No idea what to check next.
Can you add a trace after TRACE("full request -> %s\n", debugstr_a(ascii_req) ); to just print out ascii_req and post a wininet log? It's nice to see what it's sending so we can test in telnet. The following doesn't give me a 500:
$ telnet us.battle.net 80 Trying 12.129.242.40... Connected to us.battle.net. Escape character is '^]'. POST /account/systemsurvey/submit.xml?purpose=sc2beta HTTP/1.1 Host: us.battle.net Content-Length: 72 User-Agent: Blizzard Web Client Cache-Control: no-cache Content-Type: application/x-www-form-urlencoded
&email=123456789012345678@gmail.com&key=c6b177128asdfasdfasdfasdfasdffff HTTP/1.1 302 Moved Temporarily Date: Sun, 31 May 2009 00:43:35 GMT Server: Apache Location: https://us.battle.net/account/systemsurvey/submit.xml?purpose=sc2beta Content-Length: 0 Content-Type: application/xml
Connection closed by foreign host.
so I'm curious to see if something its sending is horribly wrong.
http://bugs.winehq.org/show_bug.cgi?id=18384
Rich Rincebrain@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Rincebrain@gmail.com
--- Comment #23 from Rich Rincebrain@gmail.com 2009-05-31 01:06:16 --- Bug is not resolved by applying gzip patches.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #24 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2009-05-31 01:13:38 --- (In reply to comment #23)
Bug is not resolved by applying gzip patches.
Ok, but what about the gzip patches and the patch posted? If it still doesn't work, can you post the WINEDEBUG=wininet output?
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #25 from Rich Rincebrain@gmail.com 2009-05-31 01:26:10 --- Created an attachment (id=21437) --> (http://bugs.winehq.org/attachment.cgi?id=21437) WINEDEBUG=wininet output with Mike's patch and gzip patches
No love, including that patch.
Log attached.
http://bugs.winehq.org/show_bug.cgi?id=18384
Mike Kaplinskiy mike.kaplinskiy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #21427|0 |1 is obsolete| |
--- Comment #26 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2009-05-31 01:40:17 --- Created an attachment (id=21438) --> (http://bugs.winehq.org/attachment.cgi?id=21438) fix headers & force content-length
(In reply to comment #25)
Created an attachment (id=21437)
--> (http://bugs.winehq.org/attachment.cgi?id=21437) [details]
WINEDEBUG=wininet output with Mike's patch and gzip patches
No love, including that patch.
Log attached.
Alright, let's try one more time. This is probably not going to help either, but I'd like to see the log with this so I can see what's so horribly wrong.
Seems like you might not need the gzip patches, but feel free to apply them just to be safe.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #27 from Rich Rincebrain@gmail.com 2009-05-31 09:36:30 --- Created an attachment (id=21451) --> (http://bugs.winehq.org/attachment.cgi?id=21451) Log with Mike's newer patch
You are correct, sir. No change.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #28 from Rich Rincebrain@gmail.com 2009-05-31 09:45:10 --- Does it possibly not like the ipaddress field being null?
I'll try capturing the HTTP stream on an actual Windows box later today and see what I get from it.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #29 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2009-05-31 15:56:36 --- (In reply to comment #28)
Does it possibly not like the ipaddress field being null?
I'll try capturing the HTTP stream on an actual Windows box later today and see what I get from it.
Yep, seems like the server is expecting something rather specialized. It errors out on anything you try to send it that it doesn't like:
$ openssl s_client -connect us.battle.net:443 POST /account/systemsurvey/submit.xml?purpose=sc2beta HTTP/1.1 Host: us.battle.net User-Agent: Blizzard Web Client Accept: */* Content-Type: application/x-www-form-urlencoded Content-Length: 352
&email=Rincebrain@gmail.com&key=5082e7d9949464602603b46590339b09&os=Windows 2.5.0.2195 (Service Pack 4)&cpuinfo=Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz&cpu=2513780250&mem=4016492544&video=NVIDIA GeForce 7800 GT&videodriver=Display&resolution=1920x1200&hdd=152290582528&hddfree=340086784&macaddress=C9CBB5B3&ipaddress=10.0.0.1&time=1243748379263
gives a 500. Same using lwp-request: lwp-request -m POST -c 'application/x-www-form-urlencoded' -H 'Host: us.battle.net' -H 'User-Agent: Blizzard Web Client' https://us.battle.net/account/systemsurvey/submit.xml?purpose=sc2beta -U -e -S -d
We definitely need an http log from a windows machine.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #30 from Rich Rincebrain@gmail.com 2009-05-31 16:18:25 --- Amusingly, dumping an HTTP log from a Windows machine is proving hard, as I can't seem to find a way to inject a listener before the request is SSL-ified.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #31 from William Pettersson william.pettersson@gmail.com 2009-05-31 16:28:50 --- The content-type is x-www-urlencoded, but I'm still seeing spaces and '@' symbols, could those be causing an issue? Or is the encoding done later?
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #32 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2009-05-31 16:52:03 --- (In reply to comment #31)
The content-type is x-www-urlencoded, but I'm still seeing spaces and '@' symbols, could those be causing an issue? Or is the encoding done later?
Stripping anything other than [a-z0-9] from names/values doesn't have an effect. Seems like their script itself is refusing the request - with the patch the request looks perfectly valid.
(In reply to comment #30)
Amusingly, dumping an HTTP log from a Windows machine is proving hard, as I can't seem to find a way to inject a listener before the request is SSL-ified.
Hmmm, well if you can't dump a log, try writing a small windows app that just repeats the calls that were done, except make it point to http and not https. That way we can (somewhat) know what is being sent.
Just read this - Maybe you can connect to https and use HttpQueryInfoW with HTTP_QUERY_FLAG_REQUEST_HEADERS | HTTP_QUERY_RAW_HEADERS_CRLF to get the request headers wininet generates. This might not give you the data though, but it'll let you see if windows adds some ssl-specific headers.
Last idea - modify your hosts file and point it to localhost. Then run some fake-ish server that just echos the request and does nothing else.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #33 from EA Durbin ead1234@hotmail.com 2009-06-01 14:08:59 --- Looks like 3 more wininet patches are submitted, relating to picky servers
http://article.gmane.org/gmane.comp.emulators.wine.patches/67739
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #34 from Rich Rincebrain@gmail.com 2009-06-02 02:19:58 --- Still a 500 error with them.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #35 from Erich Hoover ehoover@mines.edu 2009-06-06 20:25:20 --- Created an attachment (id=21616) --> (http://bugs.winehq.org/attachment.cgi?id=21616) A DLL that intercepts calls to wininet.dll
I do not have Windows anymore, but I have done this on Windows before and tested this little DLL under wine. Steps to use: 1) Rename "wininet.dll" to "wininet.dll-orig" 2) Copy the "wininet.dll" included in the attached ZIP file and place it in the original's place 3) Run the B.NET system checker from the command-line 4) Try to submit and look in the command-line for: "HttpSendRequestA data: '<data goes here>'
http://bugs.winehq.org/show_bug.cgi?id=18384
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover@mines.edu
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #36 from EA Durbin ead1234@hotmail.com 2009-06-08 11:20:23 --- Hulu appears to work flawlessly with todays wininet changes in git, does Battlenet work yet?
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #37 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2009-06-08 19:10:02 --- (In reply to comment #36)
Hulu appears to work flawlessly with todays wininet changes in git, does Battlenet work yet?
Yep, I can confirm. I'm pretty sure this bug has no effect on hulu whatsoever.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #38 from Rich Rincebrain@gmail.com 2009-06-08 19:28:21 --- Does not work with latest GIT for me.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #39 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2009-06-09 19:12:42 --- Created an attachment (id=21706) --> (http://bugs.winehq.org/attachment.cgi?id=21706) Horrible test program
This is a small horribly written test program that I used to check this bug. I first tried to mimic the behavior completely but then got lazy and just used the synchronous api. It compiles like a wine test case.
My findings - while the \n\n bug IS a wininet bug, the actual source of the 500 is not. It seems that the server is expecting something in particular from the request and the actual script bails (painfully) once it sees it doesn't get it.
Now we really need the wininet log from windows. Until then, I don't see how this bug can move forward.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #40 from Erich Hoover ehoover@mines.edu 2009-06-09 19:18:33 --- (In reply to comment #39)
...
My findings - while the \n\n bug IS a wininet bug, the actual source of the 500 is not. It seems that the server is expecting something in particular from the request and the actual script bails (painfully) once it sees it doesn't get it.
Now we really need the wininet log from windows. Until then, I don't see how this bug can move forward.
If anyone actually has Windows, I created an attachment (id=21616) that should intercept the calls to the wininet DLL before they are encrypted.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #41 from Rich Rincebrain@gmail.com 2009-06-09 22:51:53 --- Testing. Will report.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #42 from Rich Rincebrain@gmail.com 2009-06-09 23:48:47 --- And now I get a 500 from the Windows machine I try it on, which I attribute to trying to reset my profile too many times.
I'll ask Blizzard tech support about it.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #43 from Erich Hoover ehoover@mines.edu 2009-06-10 11:02:45 --- (In reply to comment #42)
And now I get a 500 from the Windows machine I try it on, which I attribute to trying to reset my profile too many times.
I'll ask Blizzard tech support about it.
If it's being blocked b/c your account has been locked for some reason then that's not a problem for our purposes (obviously you want to fix it though). As long as the data it sends to Blizzard is still correct (and there's no reason it shouldn't be) then if you log that data we can figure out why it's different under Wine.
http://bugs.winehq.org/show_bug.cgi?id=18384
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #44 from Jerome Leclanche adys.wh@gmail.com 2009-07-06 12:19:40 --- I hear it's working now. Could someone retest?
http://bugs.winehq.org/show_bug.cgi?id=18384
James Twyford jtwyford+wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jtwyford+wine@gmail.com
--- Comment #45 from James Twyford jtwyford+wine@gmail.com 2009-07-06 12:24:57 --- It is now working for me using fedora's wine-1.1.24-2.fc11.1.i586.
Dunno what changed between May and now, but huzzah none-the-less. Too bad my graphics card driver is "DISPLAY", but whatever works.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #46 from Erich Hoover ehoover@mines.edu 2009-07-06 12:28:30 --- (In reply to comment #44)
I hear it's working now. Could someone retest?
It's not working for me with Ubuntu 9.04 and Wine 1.1.25.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #47 from Tymoteusz Paul puciek@gmail.com 2009-07-06 12:47:13 --- Works for me with wine 1.1.24
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #48 from Erich Hoover ehoover@mines.edu 2009-07-06 13:39:36 --- (In reply to comment #46)
(In reply to comment #44)
I hear it's working now. Could someone retest?
It's not working for me with Ubuntu 9.04 and Wine 1.1.25.
I would like to revise my status to "working," I downloaded a new version of the executable and now it works.
http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #49 from William Pettersson william.pettersson@gmail.com 2009-07-11 23:49:19 --- Also can confirm, the old EXE still gave the same error with 1.1.24, but the new EXE (from battle.net) worked fine.
http://bugs.winehq.org/show_bug.cgi?id=18384
Tymoteusz Paul puciek@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #50 from Tymoteusz Paul puciek@gmail.com 2009-08-12 13:32:58 --- Works for me, also confirmed by other users.
http://bugs.winehq.org/show_bug.cgi?id=18384
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #51 from Alexandre Julliard julliard@winehq.org 2009-08-21 12:47:18 --- Closing bugs fixed in 1.1.28.
-
wine-bugs＠winehq.org