http://bugs.winehq.org/show_bug.cgi?id=29168
Bug #: 29168 Summary: Star Wars: The Old Republic game client hangs at Product: Wine Version: 1.3.33 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: erik.weatherwax@gmail.com Classification: Unclassified
Created attachment 37628 --> http://bugs.winehq.org/attachment.cgi?id=37628 Console output
Upon successful launching of the game client after logging in via the game launcher, no progress is made towards loading the game after the initial splash screen: it merely sits at the initial splash with a sort of "Working" icon spinning in the lower right indefinitely. Console output is attached but doesn't seem to be much help; it is mostly just spam of:
fixme:win:GetWindowPlacement not supported on other process window 0xa0026 fixme:d3d:query_init Unhandled query type 0xc.
Originally suspected this was a server-side or game client problem since some Windows users were reporting similar issues at the beginning of this beta test weekend; however, any of numerous purported workarounds fail to work in Wine, and it seems the problem pretty uniformly affects Wine users, at least in Linux.
http://bugs.winehq.org/show_bug.cgi?id=29168
Erik Weatherwax erik.weatherwax@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Star Wars: The Old Republic |Star Wars: The Old Republic |game client hangs at |game client hangs at intro | |splash
http://bugs.winehq.org/show_bug.cgi?id=29168
wiggmpk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wiggmpk@gmail.com
--- Comment #1 from wiggmpk@gmail.com 2011-11-26 01:23:18 CST --- If you take a look inside the install direction, navigate to ../betatest/retailclient/LoadingScreens/ and rename both files, I use *.old.
Takes care of this issue.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #2 from Erik Weatherwax erik.weatherwax@gmail.com 2011-11-26 01:56:09 CST --- Tried that, but now I'm just looking at an eternal black screen instead of an eternal load screen.
http://bugs.winehq.org/show_bug.cgi?id=29168
Florian Traverse florian.traverse@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |florian.traverse@gmail.com
--- Comment #3 from Florian Traverse florian.traverse@gmail.com 2011-11-26 03:04:32 CST --- Same issue. Tried the workaround.
The launcher tries to download a new file but has an error (I don't have the stack :() and pops up a small alert with comething like biteset or bitefield error.
So I tried to rename back the .jpg from .jpg.old , but it did not work, it doesn't try anymore to download something, but I haven't the "play" button either
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #4 from wiggmpk@gmail.com 2011-11-26 04:39:47 CST --- Confirm you are renamed BOTH files in this folder, like mentioned.
It should contain: LoadingIconAnim.dds LoadingScreen.jpg
@Erik Weatherwax your symptom implies you didnt rename BOTH files. If you remove the .jpg its still loading the animation, but you can't see it now, because the image is gone (at least that sounds logical)
@Florian Traverse again, you only mention renaming the .jpg so try BOTH files like mentioned.
http://bugs.winehq.org/show_bug.cgi?id=29168
Jack niniendowarrior@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |niniendowarrior@gmail.com
--- Comment #5 from Jack niniendowarrior@gmail.com 2011-11-26 05:06:41 CST --- I would also like to point out that during the intro splash screen, the bottom left corner menu works. These buttons are visible if you get the server listing screen to appear. If you click the bottom left area of the screen, you will here a confirmation sound then press ESC to quit the game while the splash screen is running.
I suspect that the splash screen is displayed over the server listing display while the game waits for the list of servers which will never arrive. I was burnt out trying different dll combinations hoping it was a network related deficiency but I have come up with nothing.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #6 from Jack niniendowarrior@gmail.com 2011-11-26 06:02:09 CST --- @wiggmpk I just tried your workaround. Basically this will not work when BioWare is pushing out a patch. There will be an error during installation on bitfield.c or something. So if there's an update, be sure to rename the files back to what they were. I added .old on each of them to get rid of them.
With the workaround applied (after the new patch I got from BioWare), the server is now listed (there's quite a lot of them). Clicking one server and select shows a tiny blue window. Not sure what it is but so far, that's where things stopped. I will let this run a bit further to see if there are any progress.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #7 from wiggmpk@gmail.com 2011-11-26 06:29:40 CST --- (In reply to comment #6)
@wiggmpk I just tried your workaround. Basically this will not work when BioWare is pushing out a patch. There will be an error during installation on bitfield.c or something. So if there's an update, be sure to rename the files back to what they were. I added .old on each of them to get rid of them.
With the workaround applied (after the new patch I got from BioWare), the server is now listed (there's quite a lot of them). Clicking one server and select shows a tiny blue window. Not sure what it is but so far, that's where things stopped. I will let this run a bit further to see if there are any progress.
This seems to be an issue with Windows users as well right now. I am literally loosing sleep to try and work around this. I have tried many different servers (including North America & Europe) with the same blue dialog box (after clicking select) with no information being displayed. The client looks like its getting stuck and I think the loading screen might be related to this issue.
It's a good point your bring up, every patch will nerf the workaround to get to server select (but its a small baby step of progress)
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #8 from Jack niniendowarrior@gmail.com 2011-11-26 07:59:56 CST --- I'm not ready to sign this off as a server side issue. For one thing, the knowledge base isn't getting updated and I saw several servers that are full with "Calculating" written but it doesn't ever update. I also remember that on the Official Forum, the splash screen with the blue cogs should be making a return after selecting servers (which with your workaround means a blackscreen). This is basically what most of the complaints on the loading screen seems to be.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #9 from Erik Weatherwax erik.weatherwax@gmail.com 2011-11-26 10:19:08 CST --- (In reply to comment #4)
Confirm you are renamed BOTH files in this folder, like mentioned.
It should contain: LoadingIconAnim.dds LoadingScreen.jpg
@Erik Weatherwax your symptom implies you didnt rename BOTH files. If you remove the .jpg its still loading the animation, but you can't see it now, because the image is gone (at least that sounds logical)
@Florian Traverse again, you only mention renaming the .jpg so try BOTH files like mentioned.
$ ls betatest/retailclient/LoadingScreens/ LoadingIconAnim.dds.bak LoadingScreen.jpg.bak
Still no good. There is some speculation that the effectiveness of this workaround depends on whether or not one has prior characters in the game.
http://bugs.winehq.org/show_bug.cgi?id=29168
TJ johansen.priv@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johansen.priv@gmail.com
--- Comment #10 from TJ johansen.priv@gmail.com 2011-11-26 10:32:27 CST --- I've been able to load the serverlist by: a) Renaming both files in folder LoadingScreens b) Renaming only LoadingScreen.jpg
After renaming one or both of the files I've not been asked to download anything new by the launcher. I did however patch the game before trying to rename anything.
I have NOT chosen server/made any characters previously.
After selecting server I end up with a tiny empty window which was previously mentioned, could be a another problem though.
http://bugs.winehq.org/show_bug.cgi?id=29168
Stefan stefan@wilsky.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@wilsky.de
--- Comment #11 from Stefan stefan@wilsky.de 2011-11-26 11:46:55 CST --- (In reply to comment #9)
Still no good. There is some speculation that the effectiveness of this workaround depends on whether or not one has prior characters in the game.
I can also confirm that renaming or deleting both files isn't a general solution for everyone. Now I just have a black screen and the game's mouse cursor. I thought it's a problem with directx now, for I have tried everything like reinstalling wine or d3dx9 and different options in the "Libraries" tab, but other games like LotRo work fine.
I have already selected a server and created a character on my girlfriend's windows pc, perhaps it has something to do with the problem.
http://bugs.winehq.org/show_bug.cgi?id=29168
sxe sxxe@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sxxe@gmx.de
http://bugs.winehq.org/show_bug.cgi?id=29168
sxe sxxe@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|sxxe@gmx.de |
http://bugs.winehq.org/show_bug.cgi?id=29168
sxe sxxe@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sxxe@gmx.de
--- Comment #12 from sxe sxxe@gmx.de 2011-11-26 13:08:35 CST --- (In reply to comment #10)
I've been able to load the serverlist by: a) Renaming both files in folder LoadingScreens b) Renaming only LoadingScreen.jpg
After renaming one or both of the files I've not been asked to download anything new by the launcher. I did however patch the game before trying to rename anything.
I have NOT chosen server/made any characters previously.
After selecting server I end up with a tiny empty window which was previously mentioned, could be a another problem though.
I can confirm this. I get exactly the same behavior after renaming the files.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #13 from Jack niniendowarrior@gmail.com 2011-11-26 16:36:02 CST --- With the recent run, I no longer think it's a networking issue as the server list updated with the current load. Every server is full.
http://bugs.winehq.org/show_bug.cgi?id=29168
Justin Gray justinanthonygray@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |justinanthonygray@gmail.com
--- Comment #14 from Justin Gray justinanthonygray@gmail.com 2011-11-26 21:11:52 CST --- I attempted each workaround listed. I am using CrossOver to handle most of the activities. I have two accounts. One blank and one has 8 characters on it.
1: I renamed both
LoadingIconAnim.dds LoadingScreen.jpg
to LoadingIconAnim.dds.old LoadingScreen.jpg.old
2: I forced the library to use dxd9_36.dll
3: Turned off WiFi after pushing play button
4: Tried using a fresh account without any characters
I tried variations on each of these workarounds to no success.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #15 from Vitaliy Margolen vitaliy-bugzilla@kievinfo.com 2011-11-26 21:18:05 CST --- (In reply to comment #14)
I am using CrossOver
This bugzilla is for plain Wine only. Please install regular Wine, or contact Code Weavers for support.
http://bugs.winehq.org/show_bug.cgi?id=29168
Vitaliy Margolen vitaliy-bugzilla@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #16 from Vitaliy Margolen vitaliy-bugzilla@kievinfo.com 2011-11-26 21:18:42 CST --- Also confirming - multiple users having issue.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #17 from Stefan stefan@wilsky.de 2011-11-27 08:11:30 CST --- Perhaps having a black screen is not a wine only problem?
http://www.swtor.com/community/showthread.php?t=664073
already 40+ pages, the problem sounds very similar.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #18 from Erik Weatherwax erik.weatherwax@gmail.com 2011-11-27 15:41:32 CST --- (In reply to comment #17)
Perhaps having a black screen is not a wine only problem?
I can't discount that possibility. However, for each Windows user having problems with the beta, hundreds are not. On the other hand, I don't know of *any* Wine users who aren't experiencing issues.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #19 from Jack niniendowarrior@gmail.com 2011-11-27 16:24:57 CST --- I also think the black screen has more to do with the Loading screens being removed. Just my two cents. I've been looking into netstat and I don't think I've seen anything different when SWTOR attempts to connect to a server. I find that a little strange.
http://bugs.winehq.org/show_bug.cgi?id=29168
Kristian Robertsen kristian.robertsen@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kristian.robertsen@gmail.co | |m
--- Comment #20 from Kristian Robertsen kristian.robertsen@gmail.com 2011-11-27 19:50:52 CST --- I've had the same issue myself during the weekend testing. I only got around to working on it tonight, and I finally managed to get to the server screen...
The forum thread answers about updating drivers held true for me, as did the workaround suggested here; renaming LoadingIconAnim.dds LoadingScreen.jpg
I was using the ubuntu-supplied nvidia 280.xx drivers, updating to the closed source 290.xx drivers from Nvidia got me past the white/black screen (alternating depending on whether I had TwinView enabled or not) I would get after renaming the loading screen files.
Renaming the loading screen files back got me stuck again.
http://bugs.winehq.org/show_bug.cgi?id=29168
Benh ixfrom@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ixfrom@gmail.com
--- Comment #21 from Benh ixfrom@gmail.com 2011-11-28 16:23:05 CST --- (In reply to comment #9)
(In reply to comment #4)
Confirm you are renamed BOTH files in this folder, like mentioned.
It should contain: LoadingIconAnim.dds LoadingScreen.jpg
@Erik Weatherwax your symptom implies you didnt rename BOTH files. If you remove the .jpg its still loading the animation, but you can't see it now, because the image is gone (at least that sounds logical)
@Florian Traverse again, you only mention renaming the .jpg so try BOTH files like mentioned.
$ ls betatest/retailclient/LoadingScreens/ LoadingIconAnim.dds.bak LoadingScreen.jpg.bak
Still no good. There is some speculation that the effectiveness of this workaround depends on whether or not one has prior characters in the game.
Your speculation is right, i made the test with two accounts. Account 1 has prior characters, Account 2 has no character.
Account 1 shows the splash screen permanently (or a white screen if the files above are renamed).
Account 2 shows the server list when the two files are renamed. I'm able to choose a server but when i click select, i hear a sound and then nothing happens. When the files are not renamed i only see the splash screen but i can hear the server list is behind when i do a mouseover where it's supposed to be
http://bugs.winehq.org/show_bug.cgi?id=29168
Luke Bratch l_bratch@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |l_bratch@yahoo.co.uk
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #22 from Stefan stefan@wilsky.de 2011-12-13 11:37:35 CST --- (In reply to comment #21)
Your speculation is right, i made the test with two accounts. Account 1 has prior characters, Account 2 has no character.
Account 1 shows the splash screen permanently (or a white screen if the files above are renamed).
Account 2 shows the server list when the two files are renamed. I'm able to choose a server but when i click select, i hear a sound and then nothing happens. When the files are not renamed i only see the splash screen but i can hear the server list is behind when i do a mouseover where it's supposed to be
I can confirm this. I made my character with a windows pc before, on wine I could only see the splash or black screen. Now at release (preorder) and without any characters I can see the server list, too (renamed the files). After server selection nothing happens.
So the problem with splash screen has a good workaround, but here we have a new bug? With a premade character or after server selection we should see the character creation/selection screen. Here nothing happens. I also noticed that behind the server selection i could not see anything. I could be wrong, but shouldn't there be any 3d ship models or something?
http://bugs.winehq.org/show_bug.cgi?id=29168
Ahmed W. oneofone@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |oneofone@gmail.com
--- Comment #23 from Ahmed W. oneofone@gmail.com 2011-12-14 03:01:58 CST --- I can confirm this as well.
http://bugs.winehq.org/show_bug.cgi?id=29168
MrJake mrjake@kacknet.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrjake@kacknet.com
--- Comment #24 from MrJake mrjake@kacknet.com 2011-12-15 07:21:50 CST --- Game is running official release now. its no more a beta. anyone has a work around for this. I got it installed and the mouse issue has been fixed since. I just hang at that screen with that mechanical wheel spinning randomly almost laughing at me :P
Would be nice to get this working
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #25 from Ahmed W. oneofone@gmail.com 2011-12-15 10:42:52 CST --- I narrowed it down to a networking issue with winsock, but I have no idea what since there are absolutely no FIXMEs/warnings related to networking.
Using wireshark I can tell that the game connects to the server for 30-60 seconds then disconnects and leaves that loading screen on.
On windows 7 (using vmware) it connects fine and I was able to play for 6 hours without any problems, the only problem was having 10 fps on lowest settings but that's expected from vmware I suppose.
So it *is* in wine's networking code, I just have no idea how to pinpoint it.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #26 from Erik Weatherwax erik.weatherwax@gmail.com 2011-12-15 10:49:24 CST --- (In reply to comment #25)
I narrowed it down to a networking issue with winsock, but I have no idea what since there are absolutely no FIXMEs/warnings related to networking.
Using wireshark I can tell that the game connects to the server for 30-60 seconds then disconnects and leaves that loading screen on.
On windows 7 (using vmware) it connects fine and I was able to play for 6 hours without any problems, the only problem was having 10 fps on lowest settings but that's expected from vmware I suppose.
So it *is* in wine's networking code, I just have no idea how to pinpoint it.
Thanks for the confirmation, Ahmed. I just noticed the same thing (well, noticed an outbound TCP connection to an EA server in netstat) whereas in the past betas I never saw any outbound connection attempt to EA -- so that's an improvement, I guess?
Might I ask what version of vmware you're using? I use VirtualBox for my virtualization at home, but it usually chokes on any attempt to play modern games, even with the "experimental" 3d support.
http://bugs.winehq.org/show_bug.cgi?id=29168
talkingodlor@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |talkingodlor@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #27 from Ahmed W. oneofone@gmail.com 2011-12-16 02:28:54 CST --- In the 11/11 beta, it worked perfectly fine, in the following ones it did exactly the same thing, connect to last-server and disconnect 30s later and never try again
I'm running VMWare 8.0.1 with Windows 7 Enterprise (32bit), I've been playing on it for the past 12 hours or so, getting 10-20 fps at 1920x1080 with lowest settings and shadows off.
I *really* want this to run on wine, since the last working beta I ran the game on max settings and it had 30+ fps :(
Stupid bioware, why did they break it :(
http://bugs.winehq.org/show_bug.cgi?id=29168
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #28 from Bruno Jesus 00cpxxx@gmail.com 2011-12-16 04:50:19 CST --- (In reply to comment #25)
I narrowed it down to a networking issue with winsock, but I have no idea what since there are absolutely no FIXMEs/warnings related to networking.
Using wireshark I can tell that the game connects to the server for 30-60 seconds then disconnects and leaves that loading screen on.
....
So it *is* in wine's networking code, I just have no idea how to pinpoint it.
Please, attach a +winsock debug log until the game disconnects. You can gzip it if it's too big. What do you think it's causing the disconnection?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #29 from Erik Weatherwax erik.weatherwax@gmail.com 2011-12-16 10:58:53 CST --- Created attachment 37992 --> http://bugs.winehq.org/attachment.cgi?id=37992 Compressed +winsock log
WINEDEBUG=+winsock log attached.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #30 from Xolotl Loki xoloki@gmail.com 2011-12-16 21:56:52 CST --- Created attachment 37997 --> http://bugs.winehq.org/attachment.cgi?id=37997 short winsock debug log
Here's a short log containing just the connection to the server after selecting from the list. I verified this by correlating to the IP address and port from netstat:
xoloki@xocotl:~$ sudo netstat -t -n -p 2>&1 | grep win tcp 0 0 192.168.10.101:39305 159.153.124.223:8995 ESTABLISHED 3496/wineserver
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #31 from Ahmed W. oneofone@gmail.com 2011-12-16 21:58:11 CST --- Created attachment 37998 --> http://bugs.winehq.org/attachment.cgi?id=37998 cleaned up +winsock,-d3d,-win,-oss
I cleaned up the log a bit, this is the relevant part, all the other spam is before the actual client tries to connect.
http://bugs.winehq.org/show_bug.cgi?id=29168
jordi.davis_11@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jordi.davis_11@yahoo.com
--- Comment #32 from jordi.davis_11@yahoo.com 2011-12-17 03:52:54 CST --- I am having trouble on my Mac using Wine for SWTOR. I have downloaded the client using Wine, I have uploaded the launcher using Wine, I sign in. but then whenever I press play, it comes up with something saying it needs to change my graphics resolution or something to fit the screen or something like that. I press that and then it either goes to a black screen or a smaller blank white screen. I can Command/alt A out of it but its just a blank screen for the application. Is there any way I can fix this???!
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #33 from Bruno Jesus 00cpxxx@gmail.com 2011-12-17 10:05:43 CST --- It seems like the game can't find the server: trace:winsock:WS_gethostbyname "skynet01.aus.bwa" ret (nil)
I can't resolve that name either. There are several results in google about that address name problem. Maybe something is wrong before that and it then tries a default server that does not exist anymore.
It's also weird that it sends and receives 1 byte messages. But I guess that's planned. Is there a demo available for this game that triggers the problem?
http://bugs.winehq.org/show_bug.cgi?id=29168
Dan rohleder18@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rohleder18@gmail.com
--- Comment #34 from Dan rohleder18@gmail.com 2011-12-17 10:34:48 CST --- (In reply to comment #33)
It seems like the game can't find the server: trace:winsock:WS_gethostbyname "skynet01.aus.bwa" ret (nil)
I can't resolve that name either. There are several results in google about that address name problem. Maybe something is wrong before that and it then tries a default server that does not exist anymore.
It's also weird that it sends and receives 1 byte messages. But I guess that's planned. Is there a demo available for this game that triggers the problem?
Check out my comment half-way down at http://appdb.winehq.org/commentview.php?iAppId=13553&iVersionId=24528&am... This appears to be used for internal debugging at Bioware when connections go wrong. Immediately following the skynet DNS query, it tries to send some data to a private subnet. Based on the beta info, I verified I could receive the JSON objects for the server lists, it just never displays it to the user. It then proceeds to the skynet and private network comms attempts.
http://bugs.winehq.org/show_bug.cgi?id=29168
Andrew Resch andrewresch@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrewresch@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
Nicklas Larsson nicklas.larsson@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nicklas.larsson@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #35 from Nicklas Larsson nicklas.larsson@gmail.com 2011-12-17 15:24:33 CST --- Created attachment 38006 --> http://bugs.winehq.org/attachment.cgi?id=38006 Compressed +winsock,-d3d,-win,-oss,-alsa
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #36 from Bruno Jesus 00cpxxx@gmail.com 2011-12-17 17:12:35 CST --- Why the application sends and receives 1 byte packets? Does that happen in windows (one can tell using wireshark).
If you telnet to 159.153.75.94 port 8995 you will receive a 22 byte package, I can't see that in your log. There are several read requests (near to log end) but they are probably over
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #37 from Bruno Jesus 00cpxxx@gmail.com 2011-12-17 17:14:59 CST --- If you telnet to 159.153.75.94 port 8995 you will receive a 22 byte package, I can't see that in your log. There are several read requests (near to log end) but they are probably overlapped because they are not followed by "WS2_recv_base -> xxx bytes" nor 10035 (no data to read) error.
Can you rerun with wireshark in gnu/linux and check that it receives the 22 bytes before quitting?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #38 from Nicklas Larsson nicklas.larsson@gmail.com 2011-12-17 17:26:55 CST --- Created attachment 38008 --> http://bugs.winehq.org/attachment.cgi?id=38008 Wireshark(1.6.2)/tcpdump/libpcap
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #39 from Bruno Jesus 00cpxxx@gmail.com 2011-12-17 17:37:15 CST --- Please, give it a new try. Using wireshark add a "port 8995" filter. After the packets are captured use the File->Export->Plain text. It will dump in a readable format that's easier to see.
http://bugs.winehq.org/show_bug.cgi?id=29168
Nicklas Larsson nicklas.larsson@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #38008|0 |1 is obsolete| |
--- Comment #40 from Nicklas Larsson nicklas.larsson@gmail.com 2011-12-17 17:48:24 CST --- Created attachment 38009 --> http://bugs.winehq.org/attachment.cgi?id=38009 text export
http://bugs.winehq.org/show_bug.cgi?id=29168
Nicklas Larsson nicklas.larsson@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #38009|text export |wireshark text export description| |
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #41 from Bruno Jesus 00cpxxx@gmail.com 2011-12-17 19:03:17 CST --- Here they are:
Data: 03160000001511000000080000006e2d0b19469c9db9 [Length: 22]
My theory is that wine is not receiving this data because I can't see it in the winsock log. Do you have strace installed? We need to check if the application received the bytes.
If you have strace you can run: strace wine <app.exe> 2>&1 | grep 'socket|connect|recv|poll|close' > /tmp/reallylong.txt
I'm looking for a recv() call that returns that 22 bytes. If it's not there wine is really not receiving the data and the app is timing out and quitting.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #42 from Nicklas Larsson nicklas.larsson@gmail.com 2011-12-17 20:17:02 CST --- (In reply to comment #41)
If you have strace you can run: strace wine <app.exe> 2>&1 | grep 'socket|connect|recv|poll|close' > /tmp/reallylong.txt
with strace i can't get pass the first "login"(20min gave up/log pushes halv a gig)
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #43 from Bruno Jesus 00cpxxx@gmail.com 2011-12-17 20:23:52 CST --- Possibly because of the 'poll' word in grep. Retry without it, please. If it's still too big try:
strace -e read wine <app.exe> 2>&1 | grep '= 22' > /tmp/read22only.txt
It will fetch only the read which receives 22 bytes, if it's not there in the end of the process we can be sure wine didn't receive it.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #44 from Nicklas Larsson nicklas.larsson@gmail.com 2011-12-17 21:15:42 CST --- (In reply to comment #43)
Possibly because of the 'poll' word in grep. Retry without it, please.
even with "-e read" i just can't get pass the initial "login"(im not pegging io nor cpu), think of something else to try for tomorrow. i need some sleep.. good night.
http://bugs.winehq.org/show_bug.cgi?id=29168
Xolotl Loki xoloki@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xoloki@gmail.com
--- Comment #45 from Xolotl Loki xoloki@gmail.com 2011-12-18 04:34:13 CST --- I also tried to run through strace, and failed to complete login while doing so. So I looked over WS2_recv_base, and noticed something. The function has standard exit point labels (exit and error), but those are NOT the only exit points; there are two places where naked return is called, one each for success and error cases.
So I added some extra TRACE logging; I'll attach the diff to the bug. I log the return value of WS2_recv, and all the exit points. I also encode the socket value to make sure I can correlate successive log lines properly.
Here's the relavant bits:
trace:winsock:WS_connect socket 0164, ptr 0xa1cdffc { family AF_INET, address 159.153.69.80, port 8995 }, length 16 trace:winsock:WS2_recv_base socket 0164, wsabuf 0xa1cdfcc, nbufs 1, flags 0, from (nil), fromlen -1, ovl 0x57122e70, func (nil) trace:winsock:WS2_recv_base fd=223, options=0 trace:winsock:WS2_recv_base socket 0164 -> WS2_recv returned -1 bytes, errno 11 trace:winsock:WS2_recv_base socket 0164 -> returning SOCKET_ERROR, wsaErrno 259 trace:winsock:WS_shutdown socket 0164, how 2 0 trace:winsock:WS2_register_async_shutdown s 356 type 1 trace:winsock:WS_closesocket socket 0164
So when we try to connect to the server, we call
WS2_recv
which returns EAGAIN. We then go into the
if ((lpOverlapped || lpCompletionRoutine) && !(options & (FILE_SYNCHRONOUS_IO_ALERT | FILE_SYNCHRONOUS_IO_NONALERT)))
branch, which always returns SOCKET_ERROR if WS2_recv returned -1. Is this correct behavior? I don't understand enough of the context to tell.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #46 from Xolotl Loki xoloki@gmail.com 2011-12-18 04:37:57 CST --- Created attachment 38016 --> http://bugs.winehq.org/attachment.cgi?id=38016 additional trace lines
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #47 from Bruno Jesus 00cpxxx@gmail.com 2011-12-18 06:02:17 CST --- Great! If possible do further tracing in function WS2_async_recv because it's the target function for overlapped operations. It may be important to find out who is calling WS2_recv_base, possibly WSARecv or WSARecvFrom beacuse of the overlapped structure. We need to isolate the operation so we can build a simple example that demonstrates the problem, it will be easier if more people can test it =)
http://bugs.winehq.org/show_bug.cgi?id=29168
Tyler Nielsen tyler.nielsen@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tyler.nielsen@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
Xolotl Loki xoloki@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37997|0 |1 is obsolete| | Attachment #38016|0 |1 is obsolete| |
--- Comment #48 from Xolotl Loki xoloki@gmail.com 2011-12-18 19:16:12 CST --- Created attachment 38023 --> http://bugs.winehq.org/attachment.cgi?id=38023 WINEDEBUG=+winsock log with extra tracing on WS2_async_recv
Here I added some tracing in the async recv function. It looks like we are getting the 22 byte packet, and returning that result properly asynchronously.
But the next recv call also goes async, and the callback gets a result of 0. Next we close the socket.
Next I'll trace the entry points to WS2_recv_base, and see from where we're coming.
http://bugs.winehq.org/show_bug.cgi?id=29168
Xolotl Loki xoloki@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #38023|0 |1 is obsolete| |
--- Comment #49 from Xolotl Loki xoloki@gmail.com 2011-12-18 19:34:50 CST --- Created attachment 38024 --> http://bugs.winehq.org/attachment.cgi?id=38024 WINEDEBUG=+winsock log with extra tracing
Here we have the entry points mapped as well. So it appears what happens is:
1. the game calls WSARecv 2. WS2_recv_base goes async 3. WS2_async_recv is alerted, so it reads data 4. WS2_async_recv reads 22 bytes, returns them via completion function
which is good. Then:
5. the game calls WSARecv 6. WS2_recv_base goes async 7. WS2_async_recv is called with a status of 0, so it doesn't read from the net 8. WS2_async_recv returns the default result of 0 via the completion function
I'm not sure step #8 is correct. Usually returning 0 from an async read function means the socket has shut down, which would likely trigger the calling code to initiate a shutdown itself. What does it mean when WS2_async_recv is called with a status of 0? Should this propagate to the async caller as a 0 result?
http://bugs.winehq.org/show_bug.cgi?id=29168
talchas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |talchas@gmail.com
--- Comment #50 from talchas@gmail.com 2011-12-19 21:55:25 CST --- (In reply to comment #49)
Created attachment 38024 [details]
I see the same thing, but theres (at least for me) a long delay between the second recv being posted and the async response, because the 0 response is the server timing out. I see the probably-error-indicating skynet01.aus.bwa lookup well before then (about immediately after the second Recv call)
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #51 from talchas@gmail.com 2011-12-21 10:58:12 CST --- Created attachment 38061 --> http://bugs.winehq.org/attachment.cgi?id=38061 WINEDEBUG=+winsock,+tid,+timestamp,-d3d,-win
Log with timestamps/tids added.
Hmm, apparently the skynet lookup was a bit later than I thought, although still way before the server timeout. It's possible that they have a manual ~5s timeout due to receiving no new data, but I wouldn't bet on it (especially since the socket seems to be handled by a different thread, although that could just be offloading it). I'm going to do a run with +relay this evening and see if 003d was doing anything detectably interesting in those 5s.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #52 from talchas@gmail.com 2011-12-21 20:48:23 CST --- Well, I got 5GB of +relay log without ever hitting even the first winsock messages after d3d startup before my machine crashed, so yeah.
I'll keep looking into this at times, although I should note that I'm not entirely convinced this is likely to be a winsock issue.
http://bugs.winehq.org/show_bug.cgi?id=29168
Morning Hangover panickiss@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |panickiss@gmail.com
--- Comment #53 from Morning Hangover panickiss@gmail.com 2011-12-22 02:35:43 CST --- I tried today to login when servers were offline for maintenance and I got to the server list. The issue imo it's when the game tries to open the specific server that you have your character on.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #54 from Ahmed W. oneofone@gmail.com 2011-12-22 05:17:29 CST --- Yes, it is a problem with connecting to the game server, the server list uses HTTP as far as I can tell.
http://bugs.winehq.org/show_bug.cgi?id=29168
tonedef wine@causal.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@causal.ca
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #55 from talchas@gmail.com 2011-12-22 20:26:34 CST --- OK, I finally actually ran a wireshark session when connecting under windows.
A few notes: the server should only send those 22 bytes before the client replies, and they look similar on windows - 0316000000151100000008000000xxxxxxxx. The client should then respond with what looks like a header followed by a whole bunch of upper case ascii hex digits and then a bunch of dunno-what binary data. the skynet lookup occurs _normally on windows_, again about 5-6s after connecting to the 8995 server, so it doesn't mean things have failed, although it occurs at least in my run after replies to the server.
There is I suppose a remote possibility that wine is just too slow to reply, but despite the initial load time before seeing a window being ridiculously slower for me (it is reading the last meg or so of all of the .tor files 34 bytes at a time, and poorly at that), I doubt that is the case as I don't see the same disk traffic.
http://bugs.winehq.org/show_bug.cgi?id=29168
Mikaël Cluseau nwrk-public@altern.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nwrk-public@altern.org
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #56 from Xolotl Loki xoloki@gmail.com 2011-12-23 18:53:42 CST --- Created attachment 38095 --> http://bugs.winehq.org/attachment.cgi?id=38095 wireshark log of traffic on port 8995 when running under wine
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #57 from Xolotl Loki xoloki@gmail.com 2011-12-23 18:54:20 CST --- Created attachment 38096 --> http://bugs.winehq.org/attachment.cgi?id=38096 wireshark log of traffic on port 8995 when running under windows
http://bugs.winehq.org/show_bug.cgi?id=29168
Xolotl Loki xoloki@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #38024|0 |1 is obsolete| |
--- Comment #58 from Xolotl Loki xoloki@gmail.com 2011-12-23 19:00:04 CST --- Created attachment 38097 --> http://bugs.winehq.org/attachment.cgi?id=38097 WINEDEBUG=+winsock log with extra tracing on send and recv
I've attached wireshark logs filtered for port 8995, both running under wine and windows.
When running under wine, the 22 byte packet comes in, then we see two keep-alive TCP packets, then a disconnect. Under windows, though, the client responds to the 22 byte packet in 0.04 seconds with 2 data packets (1034 and 38 bytes).
Since wine was not sending the response, I added tracing to the send functions in socket.c. However, *none* of the send functions were called.
Does anyone know how I could trace the win32 calls under windows? I'm curious as to what should be called, so I can trace more.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #59 from Xolotl Loki xoloki@gmail.com 2011-12-23 20:40:45 CST --- Created attachment 38098 --> http://bugs.winehq.org/attachment.cgi?id=38098 patch with extra tracing on send and recv functions, with timestamps on the recv functions
Here's my current tracing diff. Unfortunately, current master branch no longer brings up the UI, so I'm stuck for now.
http://bugs.winehq.org/show_bug.cgi?id=29168
Agifem agifem@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |agifem@free.fr
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #60 from Ahmed W. oneofone@gmail.com 2011-12-27 08:36:53 CST --- I just got an idea, what if this bug is caused somehow by fixme:win:GetWindowPlacement not supported on other process window? SWTOR uses 2 processes, what if wine returns the server data to the wrong process?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #61 from Ahmed W. oneofone@gmail.com 2011-12-27 08:49:05 CST --- @Xolotl can you try http://www.apimonitor.com/? It's too slow on vmware for me.
http://bugs.winehq.org/show_bug.cgi?id=29168
Alan Luth alanluth@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alanluth@gmail.com
--- Comment #62 from Alan Luth alanluth@gmail.com 2011-12-27 10:02:18 CST --- Some possible interesting lines i get using the degub=all option:
fixme:iphlpapi:NotifyAddrChange (Handle 0x33e5a4, overlapped 0xd49428): stub fixme:winsock:WSALookupServiceBeginW (0x33e5c8 0x00000ff0 0x33e5c4) Stub! [1227/165828:ERROR:network_change_notifier_win.cc(111)] WSALookupServiceBegin failed with: 8 fixme:advapi:RegisterTraceGuidsW (0x1047c680, 0x111ac364, {3dada31d-19ef-4dc1-b345-037927193422}, 1, 0x1117ca$ fixme:file:MoveFileWithProgressW MOVEFILE_WRITE_THROUGH unimplemented Exception: resolve: Unknown error
http://bugs.winehq.org/show_bug.cgi?id=29168
Jeremy White jwhite@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jwhite@codeweavers.com
--- Comment #63 from Jeremy White jwhite@codeweavers.com 2011-12-27 16:09:36 CST --- One note that may be of interest. If you add +seh to a trace, you'll see that you get a thread spinning down into death.
One of those threads will do so after invoking GetThreadPreferredUILanguages. That's interesting, because that stub was added fairly recently.
If you remove that stub (effectively revert commit e24438c1d1f68ae84f7570b53b8d5e7c24680fc6), that thread no longer spins down to death, but a different thread now does :-(.
http://bugs.winehq.org/show_bug.cgi?id=29168
Reece Dunn msclrhd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |msclrhd@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle@yahoo.fr
http://bugs.winehq.org/show_bug.cgi?id=29168
Sebastiaan Blommers sebastiaan.blommers@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastiaan.blommers@gmail.c | |om
http://bugs.winehq.org/show_bug.cgi?id=29168
Andrew Eikum aeikum@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #64 from Dorek Biglari dbiglari@gmail.com 2011-12-30 18:18:23 CST --- Created attachment 38190 --> http://bugs.winehq.org/attachment.cgi?id=38190 a list of all the ws2_32 calls in the swtor.exe process
This file was generated using a proxy ws2_32.dll that passes calls into ws2_32 on to the real ws2_32 in c:\windows\system32, and logs the calls and the returns and return types. I added *'s around the function name which can be ignored.
Running this file through cat, and grepping out the unique function names, I generated a list of all the functions used in swtor.exe:
cat ws2_32_pid_6024.calls | gawk ' { print $3 } ' | sort | uniq
*__WSAFDIsSet* *accept* *bind* *closesocket* *connect* *freeaddrinfo* *getaddrinfo* *gethostbyname* *gethostname* *getpeername* *getsockname* *getsockopt* *htonl* *htons* *inet_addr* *ioctlsocket* *listen* *ntohl* *ntohs* *select* *setsockopt* *shutdown* *WSAAddressToStringA* *WSAGetLastError* *WSARecv* *WSASend* *WSASetLastError* *WSASocketA* *WSASocketW* *WSAStartup*
http://bugs.winehq.org/show_bug.cgi?id=29168
Dorek Biglari dbiglari@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dbiglari@gmail.com
--- Comment #65 from Dorek Biglari dbiglari@gmail.com 2011-12-30 18:19:53 CST --- I noticed some people have mentioned a possible problem with multiple processes of swtor.exe. In the swtor/retailclient directory, ,f you rename swtor_dual.icb to swtor_dual.icb.bak and copy swtor.icb to swtor_dual.icb the game will run in a single process. I've tested this in Windows and it works fine. I've also tried this in wine and the same hanging occurs. I think we can eliminate multiple processes as the potential issue here. Also, I have a way to trace the winsock calls in Windows that should be fast enough to run even in a virtual machine environment, I wrote a dll proxy stub for ws2_32.dll. This method will work in Windows XP, I'll post a link to my code and the call traces that I generated.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #66 from Dorek Biglari dbiglari@gmail.com 2011-12-30 18:29:51 CST --- Created attachment 38191 --> http://bugs.winehq.org/attachment.cgi?id=38191 This is the source code for a ws2_32 proxy dll that I created to monitor application calls to ws2_32.
This is the source code for a ws2_32 proxy dll that I created to monitor application calls to ws2_32. Build using cygwin:
gcc -shared -enable-stdcall-fixup -o ws2_32.dll ws2_32.c ws2_32.def
and place in the directory with launcher.exe and swtor.exe. Output files will be written to c:\ws2_32_pid_xxxx.calls. This works in Windows XP, however it may not work in Windows 7.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #67 from Dorek Biglari dbiglari@gmail.com 2011-12-30 18:31:49 CST --- Created attachment 38192 --> http://bugs.winehq.org/attachment.cgi?id=38192 This is the compiled dll from the ws2_32.c above.
Compiled using:
gcc -shared -enable-stdcall-fixup -o ws2_32.dll ws2_32.c ws2_32.def
Place in the directory with launcher.exe and swtor.exe (Or any other .exe you want to log ws2_32 calls in). Note: works in Windows XP, but may not work in Windows 7.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #68 from Dorek Biglari dbiglari@gmail.com 2011-12-30 18:36:25 CST --- (In reply to comment #63)
One note that may be of interest. If you add +seh to a trace, you'll see that you get a thread spinning down into death.
One of those threads will do so after invoking GetThreadPreferredUILanguages. That's interesting, because that stub was added fairly recently.
If you remove that stub (effectively revert commit e24438c1d1f68ae84f7570b53b8d5e7c24680fc6), that thread no longer spins down to death, but a different thread now does :-(.
I notice that GetThreadPreferredUILanguages is only on Vista platforms and above, since the game runs in Windows XP, this method shouldn't be required to run. It seems to me that setting wine to run as Windows XP would make the most sense to keep the API as minimal as possible, am I incorrect in thinking this?
http://bugs.winehq.org/show_bug.cgi?id=29168
Ian ian@ianlevesque.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ian@ianlevesque.org
http://bugs.winehq.org/show_bug.cgi?id=29168
mbisme@burke-works.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mbisme@burke-works.com
http://bugs.winehq.org/show_bug.cgi?id=29168
mbokman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mbokman@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #69 from Austin English austinenglish@gmail.com 2012-01-02 12:17:35 CST --- (In reply to comment #68)
(In reply to comment #63)
One note that may be of interest. If you add +seh to a trace, you'll see that you get a thread spinning down into death.
One of those threads will do so after invoking GetThreadPreferredUILanguages. That's interesting, because that stub was added fairly recently.
If you remove that stub (effectively revert commit e24438c1d1f68ae84f7570b53b8d5e7c24680fc6), that thread no longer spins down to death, but a different thread now does :-(.
I notice that GetThreadPreferredUILanguages is only on Vista platforms and above, since the game runs in Windows XP, this method shouldn't be required to run. It seems to me that setting wine to run as Windows XP would make the most sense to keep the API as minimal as possible, am I incorrect in thinking this?
Wine supports more applications than just SWTOR. In particular, that stub was needed for bug 28648.
Unless you mean the game shouldn't be using it since it's told it's on XP. The game may be dynamically loading it, seeing it as available and attempts to use it (rather than hardcoding based on Windows version).
http://bugs.winehq.org/show_bug.cgi?id=29168
Stephen Smith stephenmsmith@blueyonder.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stephenmsmith@blueyonder.co | |.uk
--- Comment #70 from Stephen Smith stephenmsmith@blueyonder.co.uk 2012-01-02 20:44:11 CST --- (In reply to comment #69)
(In reply to comment #68)
(In reply to comment #63)
One note that may be of interest. If you add +seh to a trace, you'll see that you get a thread spinning down into death.
One of those threads will do so after invoking GetThreadPreferredUILanguages. That's interesting, because that stub was added fairly recently.
If you remove that stub (effectively revert commit e24438c1d1f68ae84f7570b53b8d5e7c24680fc6), that thread no longer spins down to death, but a different thread now does :-(.
I notice that GetThreadPreferredUILanguages is only on Vista platforms and above, since the game runs in Windows XP, this method shouldn't be required to run. It seems to me that setting wine to run as Windows XP would make the most sense to keep the API as minimal as possible, am I incorrect in thinking this?
Wine supports more applications than just SWTOR. In particular, that stub was needed for bug 28648.
Unless you mean the game shouldn't be using it since it's told it's on XP. The game may be dynamically loading it, seeing it as available and attempts to use it (rather than hardcoding based on Windows version).
It was being disabled as a work around to try and get back the bug on connecting to the game server. Currently that bug appears to be blocked by stuck loader screen see comment 1 for issue and workaround, the issue you mention with GetThreadPreferredUILanguages and its mentioned even on thats funcs absence another thread fails. So for one or more reasons this bug seems currently blocked until the launcher can be loaded and people can test connecting again. Should the bugs be split or are there more logs you want?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #71 from Dorek Biglari dbiglari@gmail.com 2012-01-02 21:21:32 CST ---
Wine supports more applications than just SWTOR. In particular, that stub was needed for bug 28648.
Unless you mean the game shouldn't be using it since it's told it's on XP. The game may be dynamically loading it, seeing it as available and attempts to use it (rather than hardcoding based on Windows version).
Yes that is what I meant, that the function is unlikely the root cause of the hanging since it isn't present in Windows XP. I agree it is likely dynamically loaded based on OS version. I have the OS set to Windows XP in winecfg, since it does run on XP.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #72 from Dorek Biglari dbiglari@gmail.com 2012-01-03 00:54:32 CST ---
Unless you mean the game shouldn't be using it since it's told it's on XP. The game may be dynamically loading it, seeing it as available and attempts to use it (rather than hardcoding based on Windows version).
I misread your comment previously, and I think you are correct, it does dynamically load it *not* based on the OS. Even though my wine is set to Windows XP, it does call GetThreadPreferredUILanguages:
003d:Call KERNEL32.GetProcAddress(7ed30000,189ed558 "GetThreadPreferredUILanguages") ret=188d50bb 003d:Call KERNEL32.GetThreadPreferredUILanguages(00000034,0a2bdff8,0a2be068,0a2be000) ret=188d510c 003d:fixme:thread:GetThreadPreferredUILanguages 52, 0xa2bdff8, 0xa2be068 0xa2be000 003d:Ret KERNEL32.GetThreadPreferredUILanguages() retval=00000001 ret=188d510c
It calls it a second time further below as well.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #73 from Jeremy White jwhite@codeweavers.com 2012-01-03 09:10:49 CST --- Sorry to spur a red herring chase; while it is true that it calls this stub, an stubbing it does seem to change behavior, it does not seem to affect the fundamental behavior.
I think it's just a red herring.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #74 from Agifem agifem@free.fr 2012-01-04 02:58:58 CST --- I've been looking at it more and more closely for the past few days, and I still think the problem is, like was observed earlier, in the socket. More precisely, in the WS2_async_recv function.
In Xolotl's trace from 23rd december, we can see how Wine interprets differently two calls to WS2_async_recv : The first one, called with a status of 257, Wine reads 22 bytes of data, and returns. The second one, called with a status of 0, Wine doesn't seem to even try reading, and returns. Although both return with the same status, I can't help thinking the second case is doing something wrong, for example failing to initialize a data buffer, one that the game would be puzzled to find as a return value.
Also, but it's probably my lack of knowledge of the inner workings of Wine, why is the WS2_async_recv called with a status as a parameter ? It doesn't make much sense to me.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #75 from Sebastiaan Blommers sebastiaan.blommers@gmail.com 2012-01-04 05:32:42 CST --- Hi, I just looked at the code in latest git (socket.c). I don't know if it helps but the code is pretty clear about what it does with the status codes (found in ntstatus.h).
The code switches on STATUS_ALERTED (0x00000101)) and STATUS_PENDING (0x00000103) else it would just return itself.
My conclusion is that the first connection try is false. The socket just won't connect and pops up with wrong statusses (at least, cannot be processed by async logically).
From the log from Xolotl:
trace:winsock:WS2_recv_base socket 03e8 -> WS2_recv returned -1 bytes, errno 11 trace:winsock:WS2_recv_base socket 03e8 -> returning SOCKET_ERROR, wsaErrno 259 trace:winsock:WS2_async_recv socket 03e8, status 257
SOCKET_ERROR pops status 257 which is: #define STATUS_PATH_NOT_COVERED ((NTSTATUS) 0xC0000257). Maybe a path/link/port or credential is missing/incomplete/incorrect?
My question: is STATUS_PATH_NOT_COVERED == code 257 (because of 0xC0000257)
Sebastiaan
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #76 from Agifem agifem@free.fr 2012-01-04 05:49:08 CST --- This is hexadecimal. 257 in decimal stands for STATUS_ALERTED (0x00000101).
The calls to WS2_recv_base always fail/terminate/abort, because it's an asynchronous socket/connexion. After aborting, it calls WS2_async_recv, the real function that does the data reception.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #77 from talchas@gmail.com 2012-01-04 09:46:42 CST --- It is called with status 0 because the socket has closed and if you read the wineserver socket code, it calls with 0 in the case of POLLERR/POLLHUP.
If you watch the log or turn on timestamps, (and particularly if you correlate them with a wireshark log running at the same time) you'll see that this happens a while after the 22 read, and at the same time as wireshark reports the socket being closed by the server. So for whatever reason it is not replying to the message sent by the server (_maybe_ just not fast enough) and/or not realizing the message was sent (although the behavior looks right).
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #78 from Sebastiaan Blommers sebastiaan.blommers@gmail.com 2012-01-05 08:42:57 CST --- I found something in the wireshark logs that might be of help. If you take a look at the communication going on windows and wine you can see that the first 5 lines are exactly the same. Now comes the strange part.
On windows line 6 0.078365 192.168.10.101 159.153.124.223 TCP 1100 39283 > 8995 [PSH, ACK] Seq=1 Ack=23 Win=5888 Len=1034 TSval=138362322 TSecr=1355350512
This line is missing in the wine log of wireshark, [PSH, ACK] is missing. Wine does not do the final acknowledgement of the connection and therefore times out after 30 seconds and sends a TCP keep alive ACK.
30.060985 159.153.124.223 192.168.10.101 TCP 66 [TCP Keep-Alive] 8995 > 51450 [ACK] Seq=22 Ack=1 Win=5888 Len=0 TSval=1353896825 TSecr=138213923
There must be something wrong in the winsock2 implementation on wine preventing sending the last data to the server.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #79 from Agifem agifem@free.fr 2012-01-05 08:52:23 CST --- It's not just an aknowledgment. It also sends a little over 1Kbyte of data. It's not the socket answering, it's the application talking back to the server.
I didn't have the time on the winedebug trace, so I hadn't noticed the status 0 call was happening so late. Now that I think about it, there's nothing suggesting it's a socket anomaly. The WSARecv is called correctly, and responds correctly (it seems), then the game doesn't send more data.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #80 from Sebastiaan Blommers sebastiaan.blommers@gmail.com 2012-01-05 09:20:28 CST --- @Agifem: yes thank you for pointing that out.
Maybe some sort of hook that's not being called? (Thinking of it after reading socket.c code:
*/ The actual definition of WSASendTo, wrapped in a different function name * so that internal calls from ws2_32 itself will not trigger programs like * Garena, which hooks WSASendTo/WSARecvFrom calls. */ static int WS2_sendto ..............
http://bugs.winehq.org/show_bug.cgi?id=29168
Jason r6express@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |r6express@yahoo.com
--- Comment #81 from Jason r6express@yahoo.com 2012-01-05 13:44:41 CST --- I don't see a valid completion function (arg is nil) or an event handler (arg is 0000) specified to the WSA recieve func, so I'm not sure how the caller is supposed to know that the async read has finished.
Regardless, I forced a 10 second delay prior to the first read on the login port 8995 and this allowed it to read the first 22 bytes without going into the async operation. WS2_recv_base then correctly returns 0 and err is set to 0 as well. But the login data (1k chunk) still is not sent by the swtor process.
It's possible that there is some subtle difference between the wine and windows WSA implementations, but it's still just as possible that the swtor process is getting the full 22 bytes back into it's hands correctly and a follow-up error (without log) is occuring, such as a routine to compress or encrypt the 1k block that it is supposed to send back over the socket.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #82 from Jeremy White jwhite@codeweavers.com 2012-01-05 14:56:28 CST --- (In reply to comment #81)
I don't see a valid completion function (arg is nil) or an event handler (arg is 0000) specified to the WSA recieve func, so I'm not sure how the caller is supposed to know that the async read has finished.
If you look a bit before the connect() call, you'll see a CreateIoCompletionPort call that associates the socket with an Io completion port. That is sufficient, on Windows, to provide a way to find those 22 bytes after they come in. I do see an indication that a GetQueuedCompletionStatus is called, and returns those 22 bytes, so we do seem to be correctly reporting that the 22 bytes arrive.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #83 from Xolotl Loki xoloki@gmail.com 2012-01-09 15:36:53 CST --- (In reply to comment #82)
Thanks for looking at this Jeremy; it's good to have skilled eyes in addition to the internet hordes.
I sacrificed my swap partition to install windows a couple of weeks ago, and I've been playing in XP since. I noticed that I often see aborts when running under XP; windows pulls me back to the desktop, with an error dialog saying something like "ABORT: NULL pointer at socket.c/385". So it's entirely possible that TOR itself has bugs in its network code path, and it's subtle differences in error paths that's causing the troubles.
I'm going to try testing with Jeremy's +seh debug flag. I suspect that the thread which is reading the socket on port 8995 dies after recving the 22 byte packet, before it can send the login data. Hopefully this death will be related to some wine function.
Does anyone have any other suggestions?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #84 from Jason r6express@yahoo.com 2012-01-09 15:59:49 CST --- (In reply to comment #83)
I have ran the swtor process with trace+winsock,trace+relay, along with my custom socket.c that forces a delay to make sure the 22 byte read occurs synchronously. I found that the same thread doing the read (and the long pause/sleep I coded in) continues on after the read and starts opening up the swtor .ini settings files located in c:\users...\Local Settings\Application Data\SWTOR\swtor\settings. It also opens up the disk cache files also in that dir tree. Eventually the thread ceases to do anything interesting (based on relay output).
The next test I planned to do is to block socket.c from responding back with those 22 bytes to determine if the behavior changed. If it did then that would tell me the swtor process is in fact getting the bytes. I haven't had a chance to run that test.
I also wanted to force that socket read thread to crash/break during the read so I could see what else was happening up the stack. But I am new to Wine and haven't figured out how to make the debugger stop breaking every time it encounters a floating point exception (of which there a boatload when running with winedbg). All those apparently harmless (I say apparently since the program doesn't seem to complain when running with just wine) exceptions make it a hassle to use the debugger.
FYI, the wine output/log file ends up around 5-6GB by the time it gets to messing around with the socket on port 8995.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #85 from Sebastiaan Blommers sebastiaan.blommers@gmail.com 2012-01-10 03:35:28 CST --- Ok, that's very informative! .. I noticed this difference between the client_settings.ini files. No idea of it brings us anything.
Original on WinXP and Win7 [Renderer] D3DFullScreen = true Height = 900 NativeHeight = 1080 NativeWidth = 1920 TextureAnisotropy = 16 Width = 1600 WindowX = 0 WindowY = 0 MeshLODQuality = 1 SpeedTreeDistanceScale = 1. doShadows = false FullScreen = true FarClipScale = 25. VerticalSyncState = false EnableBloom = true TextureQuality = 0 UseMinSpecShaders = false PlantDensity = 100 doBlobShadows = true
[Game] MoviesFolder = ....\Movies SwtorRegKey = SOFTWARE\BioWare\Star Wars - The Old Republic
Now the one that is created using Wine (it's limited compared to): [Renderer] D3DFullScreen = true EnableBloom = false Height = 768 NativeHeight = 720 NativeWidth = 1280 RefreshRate = 120 TextureQuality = 1 UseMinSpecShaders = true VerticalSyncState = true Width = 1024 WindowX = 0 WindowY = 0
My tought: could it be that the swtor.exe process is trying to read the last known configuration (the character/account ini files are also there) but cannot complete the initial phase of the client_setting therefore canceling the other routines?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #86 from Sebastiaan Blommers sebastiaan.blommers@gmail.com 2012-01-10 05:07:49 CST --- I played around a bit with the settings ini files. No change.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #87 from Sebastiaan Blommers sebastiaan.blommers@gmail.com 2012-01-10 08:21:21 CST --- I installed the test version. The difference I have now with latest from git is that the normal version gives me a black screen (because I renamed the LoaderScreens to .old) but with the latest test version I go straight to the server selection screen. Also I see that the live version goes to 99% cpu and does not communicate at all with the server (no packets through wireshark) but the test version does (normal communication except ACK FIN at the end) and returns an empty list. Anyone else can confirm this? (maybe it's just my build).
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #88 from Sebastiaan Blommers sebastiaan.blommers@gmail.com 2012-01-11 03:38:02 CST --- Ok I can confirm that the latest test version (1.1) works on latest git for me. I receive the server list on the first tab, after selecting it nothing happens but at least I get a server listing again.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #89 from Jeremy White jwhite@codeweavers.com 2012-01-11 09:18:28 CST --- (In reply to comment #88)
Ok I can confirm that the latest test version (1.1) works on latest git for me. I receive the server list on the first tab, after selecting it nothing happens but at least I get a server listing again.
That's very interesting; I'm having trouble getting the test version down to try that myself, but hope to do so shortly. Have you tried the test versions previously? If so, how did they behave?
I'm wondering if there is something fundamentally different about all test versions such that they don't show the bug, or if we can hope that the swtor guys have fixed something on their end and as soon as 1.1 hits the streets we'll be past this issue.
Cheers,
Jeremy
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #90 from Sebastiaan Blommers sebastiaan.blommers@gmail.com 2012-01-11 09:26:18 CST --- As far as i can remember the older test versions didn't work but that was on another version of wine i tested on. Maybe authentication is different on live vs. test
http://bugs.winehq.org/show_bug.cgi?id=29168
Michael Bond mikejbond@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mikejbond@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #91 from Xolotl Loki xoloki@gmail.com 2012-01-12 16:56:10 CST ---
Ok I can confirm that the latest test version (1.1) works on latest git for me. I receive the server list on the first tab, after selecting it nothing happens but at least I get a server listing again.
How does this constitute "working"? We've been able to get to the server listing by move the loading screen files for pretty much the duration of this bug.
Are you saying that you got to the server list without having to move the loading screen files?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #92 from Xolotl Loki xoloki@gmail.com 2012-01-12 16:57:22 CST --- (In reply to comment #91)
Are you saying that you got to the server list without having to move the loading screen files?
Sorry, just read your earlier comment.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #93 from Jeremy White jwhite@codeweavers.com 2012-01-13 09:44:33 CST --- Yes, we have found that renaming the screens makes no difference. We also haven't gotten joy with the test server, although it's been hard to test.
It seems to us that if the servers are down, then you get through to the blank server screen, otherwise you don't. I wonder if renaming the images just happened to coincide with some server down time for you, Xolotl Loki.
This is proving to be a hard one; it's hard to figure out why an app *doesn't* do something; it's much easier when it does something and something bad happens. We just need that one glimmer of insight...
http://bugs.winehq.org/show_bug.cgi?id=29168
Marco D moonbane@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |moonbane@gmx.net
http://bugs.winehq.org/show_bug.cgi?id=29168
orlando.cruz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |orlando.cruz@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #94 from Alan Luth alanluth@gmail.com 2012-01-19 15:31:43 CST --- update 1.1 doesn't change the behavior, still looking at the eternal loading screen.
http://bugs.winehq.org/show_bug.cgi?id=29168
fermadas@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fermadas@hotmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
b bdkelsey@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bdkelsey@hotmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
hash HASH.DuOrden@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |HASH.DuOrden@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #95 from Night and Day nightrise22-daylight23@yahoo.com 2012-01-25 02:20:24 CST --- Created attachment 38543 --> http://bugs.winehq.org/attachment.cgi?id=38543 New console output after 1/24/2012 patch
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #96 from Night and Day nightrise22-daylight23@yahoo.com 2012-01-25 02:21:58 CST --- Comment on attachment 38543 --> http://bugs.winehq.org/attachment.cgi?id=38543 New console output after 1/24/2012 patch
New behavior with today's patch, instead of hanging on the loading screen it seems to start to connect and then the game crashes completely. It appears to be related to the "RemoteRendererServer.icb" component. I've attached the console output, is anyone else seeing anything like this?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #97 from Xolotl Loki xoloki@gmail.com 2012-01-25 16:44:18 CST --- No change for me with the 1/24 patch. wine-1.3.37 gets stuck on the loading screen if the files are present, and a black screen if they are not. wine git master freezes when I click Play on the launcher login screen.
With WINEDEBUG='+seh' on wine-1.3.37, I see the following repeating endlessly on the console while the loading screen spins:
trace:seh:raise_exception code=80000003 flags=0 addr=0x6fc310 ip=006fc311 tid=000b trace:seh:raise_exception eax=000000ff ebx=00000000 ecx=00000035 edx=00000001 esi=ffffffff edi=02530910 trace:seh:raise_exception ebp=0a19e888 esp=0a19e864 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00000286 trace:seh:call_stack_handlers calling handler at 0xe363cc code=80000003 flags=0 trace:seh:__regs_RtlUnwind code=c0000027 flags=2 trace:seh:__regs_RtlUnwind calling handler at 0x7bc71fe0 code=c0000027 flags=2 trace:seh:__regs_RtlUnwind handler at 0x7bc71fe0 returned 1
http://bugs.winehq.org/show_bug.cgi?id=29168
Michael Flowers mikesflowers@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mikesflowers@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
Johan Gill johan.gill@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johan.gill@gmail.com
--- Comment #98 from Johan Gill johan.gill@gmail.com 2012-01-26 07:47:21 CST --- Trying to grasp the variety of behaviours:
I see the image in the right corner, but it's not spinning. Is it spinning for someone else?
My only dll overrides are for the d3dx9 dlls, what are yours?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #99 from Xolotl Loki xoloki@gmail.com 2012-01-26 20:21:06 CST --- The lower right hand image is spinning for me, and always has (when the loading screen files are present).
I'm not currently using any DLL overrides.
At this point, I'm really at an impasse. I'm happy to spend gobs of time working on this, but I'm not overly familiar with wine source or runtime.
For example, when I run under winedbg, I see various threads being created and renamed:
Thread ID=0027 renamed using MS VC6 extension (name=="BrowserDB") Thread ID=002a renamed using MS VC6 extension (name=="Cef_FileT") Thread ID=002b renamed using MS VC6 extension (name=="Cef_IOThr") Thread ID=002c renamed using MS VC6 extension (name=="AppCacheD") Thread ID=0037 renamed using MS VC6 extension (name=="PipelineT") Thread ID=0038 renamed using MS VC6 extension (name=="AudioDeco") Thread ID=0039 renamed using MS VC6 extension (name=="VideoDeco") Thread ID=003b renamed using MS VC6 extension (name=="AudioThre")
However, I can't see any way to associate them with the thread that's constantly crashing:
Unhandled exception: page fault on read access to 0x064f742c in 32-bit code (0x064f742c). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:064f742c ESP:04d1ea3c EBP:04d1ea48 EFLAGS:00010216( R- -- I -A-P- ) EAX:00000000 EBX:7bca5ff4 ECX:00000000 EDX:00000000 ESI:7ff6cf10 EDI:064f7410 Stack dump: 0x04d1ea3c: 00000000 00002710 00000000 04d1ea58 0x04d1ea4c: 7bc71f60 05477b88 7ff6cf10 04d1eb28 0x04d1ea5c: 7bc7219d 064f7410 05477b88 00000000 0x04d1ea6c: 00000000 ffffffff 7bc88f40 7b83ab40 0x04d1ea7c: 7bca5ff4 7ff6cf10 064f7410 04d1eb28 0x04d1ea8c: db6edaa8 f6f8fe56 00000000 00000000 Backtrace: =>0 0x064f742c (0x04d1ea48) 1 0x7bc71f60 call_thread_func_wrapper+0xb() in ntdll (0x04d1ea58) 2 0x7bc7219d call_thread_func+0x7c(entry=0x64f7410, arg=0x5477b88, frame=0x4d1eb48) [/build/buildd/wine1.3-1.3.37/dlls/ntdll/signal_i386.c:2532] in ntdll (0x04d1eb28) 3 0x7bc71f3e RtlRaiseException+0x21() in ntdll (0x04d1eb48) 4 0x7bc7bf45 start_thread+0xf4(info=0x7ff6cfb8) [/build/buildd/wine1.3-1.3.37/dlls/ntdll/thread.c:405] in ntdll (0x04d1f398) 5 0xf757e96e start_thread+0xbd(arg=0x4d1fb70) [/build/buildd/eglibc-2.11.1/nptl/pthread_create.c:300] in libpthread.so.0 (0x04d1f498) 0x064f742c: addb %al,0x0(%eax)
Do the SS/DS/ES registers hold the thread ID?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #100 from Vitaliy Margolen vitaliy-bugzilla@kievinfo.com 2012-01-26 21:41:56 CST --- Use WINEDEBUG=+tid to tell where messages are coming from. Segment registers point to a segment descriptors and have nothing to do with thread IDs.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #101 from Johan Gill johan.gill@gmail.com 2012-01-27 00:37:43 CST --- (In reply to comment #99)
The lower right hand image is spinning for me, and always has (when the loading screen files are present).
I'm not currently using any DLL overrides.
Are you really sure about this? It looks like D3DX is reading the animation from a DDS format, and the builtin D3DX can't handle that.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #102 from Xolotl Loki xoloki@gmail.com 2012-01-27 19:52:19 CST ---
I'm not currently using any DLL overrides.
Are you really sure about this? It looks like D3DX is reading the animation from a DDS format, and the builtin D3DX can't handle that.
I'm looking at the 'Libraries' tab of winecfg, there is nothing in the 'Existing overrides:' box. Should I look in a config file somewhere to be sure?
This is with wine-1.3.37, but I've used everything from 1.3.33 on, including many random git builds.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #103 from Xolotl Loki xoloki@gmail.com 2012-01-27 19:52:49 CST --- (In reply to comment #100)
Use WINEDEBUG=+tid to tell where messages are coming from.
Thanks, that should help immensely correlating messages to threads.
http://bugs.winehq.org/show_bug.cgi?id=29168
webgeek1234@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |webgeek1234@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
sporth@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sporth@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
Jason J jason.james@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jason.james@gmail.com
--- Comment #104 from Jason J jason.james@gmail.com 2012-02-01 22:16:54 CST --- Any progress being made on this?
http://bugs.winehq.org/show_bug.cgi?id=29168
Scott scott@chaos-dragon.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott@chaos-dragon.com
http://bugs.winehq.org/show_bug.cgi?id=29168
h.v.bruinehsen@fu-berlin.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |h.v.bruinehsen@fu-berlin.de
http://bugs.winehq.org/show_bug.cgi?id=29168
Marco Di Fresco marco.difresco@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marco.difresco@gmail.com
--- Comment #105 from Marco Di Fresco marco.difresco@gmail.com 2012-02-20 12:31:04 CST --- Any news? :-/
I am not an expert in debugging, but if you want just tell me what do you need I and I will do any test necessary.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #106 from Xolotl Loki xoloki@gmail.com 2012-02-20 23:47:06 CST --- I keep looking at this from time to time, but still no real progress.
I'm still focusing on the server handshake on port 8995. I had previously determined that TOR calls WSARecv, and is returned the 22 byte server header asynchronously. TOR immediately calls WSARecv again, and after a minute the connection times out, and is closed.
Debugging with +tid, I discovered something new today: the thread that does the second WSARecv call on the 8995 socket is *not* the same as the thread which is delivered the 22 byte header. I then added +seh, and discovered:
0045:trace:winsock:WS2_async_recv socket 0178 not PENDING so return ws2_async_apc as *apc and pass status 0 and result 22 through iosb 0045:trace:winsock:WS2_async_recv socket 0178 returning status 0 000d:trace:winsock:WSARecv socket 0178, calling WS2_recv_base 000d:trace:winsock:WS2_recv_base socket 0178, wsabuf 0xa4ce630, nbufs 1, flags 0, from (nil), fromlen -1, ovl 0x526a0f50, func (nil) [2012-02-20 18:54:57] 0045:trace:seh:raise_exception eax=000000ff ebx=00000000 ecx=00000000 edx=01784065 esi=00000400 edi=7b8351f0 0045:trace:seh:raise_exception eax=000000ff ebx=00000000 ecx=00000000 edx=01789457 esi=00000400 edi=7b8351f0 0045:trace:seh:raise_exception eax=000000ff ebx=00000000 ecx=00000000 edx=0178d980 esi=00000400 edi=7b8351f0
Basically, the thread that receives the data crashes, and another thread tries to read again. However, the data is already gone, so the new IO thread gets nothing, and we never progress. I was lucky to see this, because it was only the value of edx happening to match the socket handle I was grepping.
So I ran again with +relay, and after sifting through 11GB of data, I found nothing particularly useful:
000d:Ret KERNEL32.GetCurrentThreadId() retval=0000000d ret=10004837 000d:Call KERNEL32.GetCurrentThreadId() ret=1000033:Ret KERNEL32.GetLastError() retval=00000000 ret=78543849 000d:Call KERNEL32.SetEvent(00000328) ret=00365655 000d:Ret KERNEL32.SetEvent() retval=00000001 ret=00365655 000d:Call user32.GetClientRect(000a0052,0a2ce950) ret=006fa5f6 000d:Ret user32.GetClientRect() retval=00000001 ret=006fa5f6 000d:Call KERNEL32.QueryPerformanceCounter(0a2ce8f8) ret=006f9a14 000d:Ret KERNEL32.QueryPerformanceCounter() retval=00000001 ret=006f9a14 000d:trace:seh:raise_exception code=80000004 flags=0 addr=0x70a9c1 ip=0070a9c1 tid=000d
So I'm at an impasse again. I think I know what's going on; the IO thread crashes after getting the server header, never sending the reply, and another thread times out waiting for more data. But I don't see anything suspicious going on right before the crash, which means the trail is cold again.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #107 from Xolotl Loki xoloki@gmail.com 2012-02-20 23:52:30 CST --- I also tried something completely different; I tried using winecfg to do DLL overrides of various combinations of the networking DLLs. Often overriding one DLL would require additional overrides.
But after many hours of trying ws2_32 and others, I was never able to get past the auth windows, much less server login. So this seems like anothe3r dead end.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #108 from Dmitry Timoshkov dmitry@baikal.ru 2012-02-21 01:26:39 CST --- (In reply to comment #106)
000d:trace:seh:raise_exception code=80000004 flags=0 addr=0x70a9c1 ip=0070a9c1 tid=000d
So I'm at an impasse again. I think I know what's going on; the IO thread crashes after getting the server header, never sending the reply, and another thread times out waiting for more data. But I don't see anything suspicious going on right before the crash, which means the trail is cold again.
This is not a crash, 80000004 is EXCEPTION_SINGLE_STEP, somebody is playing with CPU context flags?
http://bugs.winehq.org/show_bug.cgi?id=29168
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |matteo.mystral@gmail.com
--- Comment #109 from Matteo Bruni matteo.mystral@gmail.com 2012-02-21 07:30:33 CST --- (In reply to comment #108)
(In reply to comment #106)
000d:trace:seh:raise_exception code=80000004 flags=0 addr=0x70a9c1 ip=0070a9c1 tid=000d
So I'm at an impasse again. I think I know what's going on; the IO thread crashes after getting the server header, never sending the reply, and another thread times out waiting for more data. But I don't see anything suspicious going on right before the crash, which means the trail is cold again.
This is not a crash, 80000004 is EXCEPTION_SINGLE_STEP, somebody is playing with CPU context flags?
Yeah, the thread initially doing the WSArecv actually generates those single step exceptions. Those happen on Windows too, AFAICT, and they don't seem to be a problem anyway (except making debugging more annoying, of course...)
Xolotl, you're right that the thread which calls WSArecv is not the same as the thread receiving the completion notification. But then this second thread posts an application-generated completion message to the first thread, which gets it. But nothing happens. The first thread also waits (non blocking) on a mutex which is never waited/signaled by other threads. That may play a role here, but it could also be completely unrelated.
http://bugs.winehq.org/show_bug.cgi?id=29168
Carsten Juttner carjay@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |carjay@gmx.net
--- Comment #110 from Carsten Juttner carjay@gmx.net 2012-03-05 15:42:42 CST --- Hi, I've been looking for the cause for some weeks now, too, and found the answer.
SWTOR seemingly reads part of its timing information directly from the KUSER_SHARED_DATA mapping. This is a special virtual address mapping which is present in all processes and used internally by Windows user space libraries. Basically a system stat page exported by the NT kernel to user space.
It can be found at virtual address 0x7ffe0000. In Wine this page is initialized once (it holds a lot more information than just timing) but after that there do not seem to be any more updates. Also the InterruptTime field (time since boot) is never set up at all.
SWTOR seems to base its send timers on exactly this source. Now, obviously a timing source that never progresses leads to timers never elapsing which is a good explanation why things do not work properly.
For demonstration purposes I've attached a small proof of concept which makes things work by simply updating the fields whenever the process enters an "EnterCriticalSection"-API call.
Before you get all excited, this is of course not a proper way to do things. On Windows this information is set from within the kernel which cannot be done for wine in a similar way.
Hopefully someone more familiar with Wine internals has an idea where and how to set this up properly.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #111 from Carsten Juttner carjay@gmx.net 2012-03-05 15:46:19 CST --- Created attachment 39208 --> http://bugs.winehq.org/attachment.cgi?id=39208 Proof of concept for KUSER_SHARED_DATA updates
simple proof of concept showing that the initial server connect is working successful once the timer fields in KUSER_SHARED_DATA are updated properly.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #112 from Xolotl Loki xoloki@gmail.com 2012-03-05 16:43:41 CST --- Thanks Carsten, I'm patching and rebuilding wine as we speak, and I'll let you know if it works for me.
I'm trying 1.4-rc4; is that the branch you were working on?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #113 from Carsten Juttner carjay@gmx.net 2012-03-05 17:33:13 CST --- (In reply to comment #112)
Thanks Carsten, I'm patching and rebuilding wine as we speak, and I'll let you know if it works for me.
I'm trying 1.4-rc4; is that the branch you were working on?
I usually work directly on the git repository and was testing against the current master at c991d115b but before that I had a version from a month ago.
It should not make much of a difference.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #114 from Xolotl Loki xoloki@gmail.com 2012-03-05 17:42:49 CST --- I made it past server selection, was able to choose a character, and now I have successfully logged in.
Thanks Carsten! If you would like, I'll happily PayPal you $100 for figuring this out.
Wine devs: any chance of fixing this for 1.4, or Crossover XI?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #115 from Jeremy White jwhite@codeweavers.com 2012-03-05 17:51:37 CST --- Well done indeed, Carsten!
This doesn't look surgical enough to make it into either of those releases, although I think only Alexandre can answer that for certain.
We may try to provide a hack for customers to experiment with CrossOver XI.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #116 from Dmitry Timoshkov dmitry@baikal.ru 2012-03-05 21:08:05 CST --- (In reply to comment #111)
Created attachment 39208 [details] Proof of concept for KUSER_SHARED_DATA updates
simple proof of concept showing that the initial server connect is working successful once the timer fields in KUSER_SHARED_DATA are updated properly.
May be adding the updating timers functionality to server.c,wine_server_call() would be more correct.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #117 from Xolotl Loki xoloki@gmail.com 2012-03-05 21:47:04 CST --- Does wine implement KUSER_SHARED_DATA as shared memory? If so, then it should be updated by wineserver, not client wine threads.
The memory is allocated by the following call in thread.c:
addr = (void *)0x7ffe0000; size = 0x10000; NtAllocateVirtualMemory( NtCurrentProcess(), &addr, 0, &size, MEM_RESERVE|MEM_COMMIT, PAGE_READWRITE );
I see no mention of shared memory in NtAllocateVirtualMemory, so I'm guessing no. Accoding to the docs I found, these fields are supposed to be updated every *100ns*. If we try to do that in every thread, it's just not going to work.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #118 from hash HASH.DuOrden@gmail.com 2012-03-06 10:37:42 CST --- Well, I also tested this "Proof of concept for KUSER_SHARED_DATA updates" patch and I wasn't able to get any further than before. So it do not work for me, sadly.
If there is something wrong with the way I compile Wine just tell me. I'll gladly apologize and be actually happy been mistaken.
git clean -fd git checkout -f && git fetch && git rebase origin git reset --hard origin/master git apply ../KUSER_SHARED_DATA.patch export CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" ./configure --prefix=/opt/wine --with-xinput2 --without-openal --with-opengl --with-oss --with-mpg123 && make depend && make && make install
I also tried to issue ./tools/make_requests after git apply, it didn't changed anything.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #119 from Morning Hangover panickiss@gmail.com 2012-03-06 11:33:02 CST --- (In reply to comment #111)
Created attachment 39208 [details] Proof of concept for KUSER_SHARED_DATA updates
simple proof of concept showing that the initial server connect is working successful once the timer fields in KUSER_SHARED_DATA are updated properly.
Patched latest wine git, working as intended. Played around 1h framerate is not much worse than the windows version.
Thanks Carsten.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #120 from Carsten Juttner carjay@gmx.net 2012-03-06 12:08:40 CST --- (In reply to comment #114)
I made it past server selection, was able to choose a character, and now I have successfully logged in.
Thanks Carsten! If you would like, I'll happily PayPal you $100 for figuring this out.
Thanks for the offer but please rather donate it to a charity of your own choosing. My day job pays well so I don't have a need.
Besides it was a great learning experience. :)
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #121 from Carsten Juttner carjay@gmx.net 2012-03-06 12:58:23 CST --- (In reply to comment #118)
Well, I also tested this "Proof of concept for KUSER_SHARED_DATA updates" patch and I wasn't able to get any further than before. So it do not work for me, sadly.
If there is something wrong with the way I compile Wine just tell me. I'll gladly apologize and be actually happy been mistaken.
git clean -fd git checkout -f && git fetch && git rebase origin git reset --hard origin/master git apply ../KUSER_SHARED_DATA.patch export CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" ./configure --prefix=/opt/wine --with-xinput2 --without-openal --with-opengl --with-oss --with-mpg123 && make depend && make && make install
I also tried to issue ./tools/make_requests after git apply, it didn't changed anything.
For a release build I don't set any CFLAGS, I just run the ./configure-script (I have a 64 bit Linux box but it seems to detect things just fine).
I also used winetricks to install all kinds of DirectX and Microsoft runtime related libs.
Maybe something shows up in your wine log that may give a clue what is happening? Note that the window placement and directx query warnings are ok.
One thought, since I already have a character on a server I didn't test if the original server selection (when you do not have a character) is visible (which was an issue before, I had to rename the jpg to get to the selection screen).
Using the proof of concept patch at least once having a character on a server I do not require this trick anymore though. Also logging out and going back to the server selection works ok.
I didn't do anything special to make it run apart from what was already suggested (e.g. running the launcher in a desktop).
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #122 from Carsten Juttner carjay@gmx.net 2012-03-06 13:44:26 CST --- (In reply to comment #116)
(In reply to comment #111)
Created attachment 39208 [details] Proof of concept for KUSER_SHARED_DATA updates
simple proof of concept showing that the initial server connect is working successful once the timer fields in KUSER_SHARED_DATA are updated properly.
May be adding the updating timers functionality to server.c,wine_server_call() would be more correct.
I had a similar idea but I'm still trying to get a better understanding of how the wine server works. For now I'd just want to share the results of my research.
So just to state the obvious before Alexandre hits me with a haversack :) the patch cannot be merged like that, using EnterCriticalSection this way is completely wrong.
Further notes: Windows of course does not update the times at 10 MHz granularity.
I wrote a little test application that confirms (on Vista) what http://www.dcl.hpi.uni-potsdam.de/research/WRK/2007/08/getting-os-informatio... says: the values are updated at a 15.625ms interval which is 64 Hz.
http://bugs.winehq.org/show_bug.cgi?id=29168
dan toreador@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |toreador@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #123 from hash HASH.DuOrden@gmail.com 2012-03-07 07:59:41 CST --- (In reply to comment #121)
(In reply to comment #118)
Well, I also tested this "Proof of concept for KUSER_SHARED_DATA updates" patch.....
For a release build I don't set any CFLAGS, I just run the ./configure-script (I have a 64 bit Linux box but it seems to detect things just fine).
I also used winetricks to install all kinds of DirectX and Microsoft runtime related libs.
Maybe something shows up in your wine log that may give a clue what is happening? Note that the window placement and directx query warnings are ok.
One thought, since I already have a character on a server I didn't test if the original server selection (when you do not have a character) is visible (which was an issue before, I had to rename the jpg to get to the selection screen).
Using the proof of concept patch at least once having a character on a server I do not require this trick anymore though. Also logging out and going back to the server selection works ok.
I didn't do anything special to make it run apart from what was already suggested (e.g. running the launcher in a desktop).
I have 32 bit Gentoo install and I use OSS4, I've removed CFLAGS declaration, this haven't changed anything. Could you please specify what you installed aside from SWTOR?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #124 from hash HASH.DuOrden@gmail.com 2012-03-07 08:22:38 CST --- Created attachment 39227 --> http://bugs.winehq.org/attachment.cgi?id=39227 A log starting SWTOR and not connecting to server with wine compiled with "Proof of concept for KUSER_SHARED_DATA updates" patch.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #125 from Carsten Juttner carjay@gmx.net 2012-03-07 13:21:11 CST --- Just rebuilt against the 1.4 release tag and used a fresh winedir.
I then used winetricks to add the Microsoft runtimes "vcrun2008" and "d3dx9". That's it.
Your log looks like the expected output but seems to only contain the STDOUT parts but not what goes to STDERR.
To get the full output you can redirect it to log.txt similar to this:
wine explorer /desktop=launcher.exe,1280x1024 launcher.exe >log.txt 2>&1
BTW: if that's your real username in the log you should remove both username and password entries. That's debug output from swtor, not wine and may identify you!
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #126 from hash HASH.DuOrden@gmail.com 2012-03-07 15:35:49 CST --- Comment on attachment 39227 --> http://bugs.winehq.org/attachment.cgi?id=39227 A log starting SWTOR and not connecting to server with wine compiled with "Proof of concept for KUSER_SHARED_DATA updates" patch.
wine: cannot find L"C:\windows\system32\winemenubuilder.exe" err:wineboot:ProcessRunKeys Error running cmd L"C:\windows\system32\winemenubuilder.exe -a -r" (2) [0307/141243:ERROR:network_change_notifier_win.cc(111)] WSALookupServiceBegin failed with: 8 err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded Exception: resolve: Unknown error Exception: resolve: Unknown error | Variable USERNAME set to '****' | Variable PASSWORD set to '****' | Variable PLATFORM set to 'gamepad.swtor.com:443' | Variable ENVIRONMENT set to 'swtor' | Variable LANG set to 'en-us' | Variable TORSETS set to 'main,en-us' | Executing batch file 'swtor_dual.icb':
|> set shardaddress @${server}:${port}:${instance} | Variable SHARDADDRESS set to '@::' |> server install HeroEngine | Successfully installed server application: HeroEngine
|> server start HeroEngine://test1@null::IpcConsole:1 dual=true username=${username} password=${password} shardaddress=${shardaddress} environment=${environment} platform=${platform} lang=${lang} torsets=${torsets} | Successfully started server: HeroEngine://test1@null::IpcConsole:1
|> autotick | Beginning auto-tick. Use <Ctrl-shift-x> to break. | Executing batch file 'RemoteRendererServer.icb':
|> server install RemoteRenderer | Successfully installed server application: RemoteRenderer
|> server start RemoteRenderer://test1@shared::IpcConsole:1 | Successfully started server: RemoteRenderer://test1@shared::IpcConsole:1
|> autotick | Beginning auto-tick. Use <Ctrl-shift-x> to break. Connection 0 to RemoteRenderer accepted! Connecting process name is: swtor.exe Creating interfaces... bwa::RemoteMetricsCallbacksHandler::IID bwa::RemoteRendererInterface::IID err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #127 from hash HASH.DuOrden@gmail.com 2012-03-07 15:40:28 CST --- Idiotic bugzilla mechanic, nothing can't be deleted... No that out put is made this way: &>./SWTOR.log it's shorter version of:
log.txt 2>&1
But thanks for info about runtimes, will try to do that with clean prefix.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #128 from Dorek Biglari dbiglari@gmail.com 2012-03-08 00:11:16 CST --- I can also confirm latest working wine with Carsten's patch works great. For me the game framerate is more than acceptable. The only changes made to get the game to run after patching were creating a Virtual Desktop the same size as my screen size and adding d3dx9_38.dll as a native dll. Thanks Carsten! I hope Bioware doesn't break it again with a future patch.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #129 from Sebastiaan Blommers sebastiaan.blommers@gmail.com 2012-03-08 09:38:21 CST --- It is working for me also. FPS is reasonable, might be 90% of what i'm getting on Windows 7. I use Ironhide to optirun start wine. After touching Antialiasing the graphics went a bit crazy with artifacts but other then that it is running pretty smooth. Starting up the game takes a while but after hitting the character screen everything seems ok.
http://bugs.winehq.org/show_bug.cgi?id=29168
hash HASH.DuOrden@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39227|0 |1 is obsolete| |
--- Comment #130 from hash HASH.DuOrden@gmail.com 2012-03-08 11:19:34 CST --- Created attachment 39245 --> http://bugs.winehq.org/attachment.cgi?id=39245 Another log starting SWTOR with wine compiled with "Proof of concept for KUSER_SHARED_DATA updates" patch.
This log is produced without WINEDEBUG set.
By the way, is every one of you for who this works happen to run 64 bit linux? I'm actually don't know what to think and how to diagnose why this doesn't work for me. :(
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #131 from Johan Gill johan.gill@gmail.com 2012-03-08 11:33:36 CST --- (In reply to comment #130)
By the way, is every one of you for who this works happen to run 64 bit linux? I'm actually don't know what to think and how to diagnose why this doesn't work for me. :(
Are you running in a virtual desktop? That seems to work best.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #132 from hash HASH.DuOrden@gmail.com 2012-03-08 11:54:57 CST --- yes
http://bugs.winehq.org/show_bug.cgi?id=29168
Jonathan Marchand jonathlela@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathlela@gmail.com
--- Comment #133 from Jonathan Marchand jonathlela@gmail.com 2012-03-08 12:23:58 CST --- It works fine with me with this patch in debian amd64. I have a recent git wine compiled with some ia32 libs, I have installed dxd9 with winetricks. I don't use a virtual desktop. I launch the game with : wine ~/.wine/Program\ Files/Electronic\ Arts/BioWare/Star\ Wars\ - \The\ Old\ Republic/launcher.exe
It runs without any glitches and about as the same speed as in windows (slightly slower).
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #134 from Erik Weatherwax erik.weatherwax@gmail.com 2012-03-08 12:43:44 CST --- Add me to the list of people for whom Carsten's proof of concept patch has the game working successfully. Steps I followed:
(1) Remove old SWTOR wineprefix with pathetic attempts at DLL overrides to get game to work. (2) Create and configure clean wineprefix: turning on virtual desktop is the only config change I made here. (3) Override d3dx9_36 via winetricks -- this is the only DLL override I needed. (4) Run SWTOR_setup.exe available on SWTOR website in the new prefix. (5) Copy Program Files/Electronic Arts/BioWare/ folder from Win7 partition I was (regrettably) forced to use to Program Files/Electronic Arts/BioWare/ folder in new wineprefix, because I'm too impatient to download the game assets again or patch from initial retail. (6) Apply Carsten's patch against a copy of wine 1.4 source and perform straight ./configure && make, no special CFLAGS or installation, because I'm told by far more knowledgeable people that the patch isn't suitable for mainline Wine. (7) cd to the SWTOR install directory, run: $PATCHED_WINE_PATH/wine launcher.exe (8) Hit "play" very quickly to avoid bug 29169 (reported fixed but I'm still running into it, need to open another bug report). (9) Enjoy.
For the record, this is a Gentoo x86_64 system. I did notice the same graphical artifacts Sebastiaan mentioned on first launching the game with AA at high: turning off AA corrected it, and I was later able to set AA to low without the artifacting resuming. This is on an nVidia GT240 with the 295.20 proprietary driver.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #135 from Sebastiaan Blommers sebastiaan.blommers@gmail.com 2012-03-08 12:50:50 CST --- Running on 64 bit Ubuntu yes. Maybe start over with clean git
Steps:
1) git clone 2) git apply KUSERPATCH 3) ./configure 4) sudo make install 5) wget http://winetricks.org/winetricks 6) chmod +x winetricks 7) start winetricks and remove all application stuff -> cleans up .wine or just delete the .wine folder. 7) winetricks vcrun2008 d3dx9 8) winetricks -> config set virtual desktop and set to xp
That's all i did.
*Ironhide/Bumblebee users: I run using optirun32 so I installed virtualgl-libs:i386 because optirun64 didn't work for me.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #136 from Mikaël Cluseau nwrk-public@altern.org 2012-03-08 13:21:48 CST --- This patch works for me too under gentoo gnu/linux 64 bits. Applied on git commit ecc2fae44bc337bf4f07e24572dc4b4776fe269a. Login, character selection, playing (well, at least 10 minutes, I had to go after ;)).
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #137 from hash HASH.DuOrden@gmail.com 2012-03-08 14:15:08 CST --- Only difference with me is I am using 32 bit Gentoo, beyond that I'm lost. :(
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #138 from Xolotl Loki xoloki@gmail.com 2012-03-08 22:27:10 CST --- I've been playing with Carsten's patch all week, but I keep seeing a random UI freeze that lasts anywhere from 1 to 60 seconds. The game plays normally for a while (sometimes hours), but once it starts freezing it does so too often to continue playing.
Has anyone else seen, and/or worked around this issue? I thought it might be because Carsten's patch doesn't appear to set the time fields in the proper order; from what I read, it should be done like
user_shared_data->SystemTime.High2Time = now.HighPart; user_shared_data->SystemTime.LowPart = now.LowPart; user_shared_data->SystemTime.High1Time = now.HighPart;
rather than
user_shared_data->SystemTime.LowPart = now.LowPart; user_shared_data->SystemTime.High1Time = user_shared_data->SystemTime.High2Time = now.HighPart;
But that didn't solve the freezing. So I've been working on an alternate patch using NtSetTimer to set the times at a regular interval. However, I can't get past the 8995 server handshake. I'll post the patch if I get it working.
In the meantime, a question: does anyone know what the scope is of the user_shared_data memory area? Is it local to the thread/process, or is it shared? Every thread reserves it then writes to it in thread_init.
http://bugs.winehq.org/show_bug.cgi?id=29168
talchas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|talchas@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #139 from Xolotl Loki xoloki@gmail.com 2012-03-09 02:25:37 CST --- (In reply to comment #138)
Every thread reserves it then writes to it in thread_init.
Just realized that only the initial thread reserves and writes the virtual memory address.
I also realized what's different between my NtSetTimer and Carsten's patch: Carsten's ends up calling update_shared_data_time every couple of microsecs:
0045:fixme:ntdll:update_shared_data_time 129757528561624540 0045:fixme:ntdll:update_shared_data_time 129757528561624570 0045:fixme:ntdll:update_shared_data_time 129757528561624640 0045:fixme:ntdll:update_shared_data_time 129757528561624670
My NtTimer code, when set to fire every 100 nanosecs:
NtQuerySystemTime( &when ); when.QuadPart += 1;
status = NtSetTimer(handle, &when, (PTIMER_APC_ROUTINE)shared_data_timer_apc, handle, 0, 0, NULL);
only fires every 150 microsecs:
000f:fixme:ntdll:update_shared_data_time 129757541427830810 000f:fixme:ntdll:update_shared_data_time 129757541427832270 000f:fixme:ntdll:update_shared_data_time 129757541427833710 000f:fixme:ntdll:update_shared_data_time 129757541427835170
If I set it to fire every 10 microsecs it actually does better:
000f:fixme:ntdll:update_shared_data_time 129757548414991300 000f:fixme:ntdll:update_shared_data_time 129757548414992020 000f:fixme:ntdll:update_shared_data_time 129757548414992820 000f:fixme:ntdll:update_shared_data_time 129757548414993800
Next I'll try a dedicated thread which just sets the times and does a nanosleep...
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #140 from Sebastiaan Blommers sebastiaan.blommers@gmail.com 2012-03-09 04:16:28 CST --- Very good idea, that might fix the delay and the issues it introduces. Thank you for keeping us posted about the progress.
http://bugs.winehq.org/show_bug.cgi?id=29168
Skuzzie skuzzie@internode.on.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |skuzzie@internode.on.net
--- Comment #141 from Skuzzie skuzzie@internode.on.net 2012-03-09 04:21:51 CST --- (In reply to comment #138)
I've been playing with Carsten's patch all week, but I keep seeing a random UI freeze that lasts anywhere from 1 to 60 seconds. The game plays normally for a while (sometimes hours), but once it starts freezing it does so too often to continue playing.
Yeah, been playing a few hours now...I have noticed it runs fine until I get into a fight, then it starts freezing up, the longer the fight goes the more it freezes up, seems to increase in occurrance and duration very quickly.
http://bugs.winehq.org/show_bug.cgi?id=29168
xoffox@softhome.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xoffox@softhome.net
--- Comment #142 from xoffox@softhome.net 2012-03-09 10:51:26 CST --- (In reply to comment #141)
(In reply to comment #138)
I've been playing with Carsten's patch all week, but I keep seeing a random UI freeze that lasts anywhere from 1 to 60 seconds. The game plays normally for a while (sometimes hours), but once it starts freezing it does so too often to continue playing.
Yeah, been playing a few hours now...I have noticed it runs fine until I get into a fight, then it starts freezing up, the longer the fight goes the more it freezes up, seems to increase in occurrance and duration very quickly.
The patch works well with stock wine 1.4 on my Debian-amd64 testing system. I was playing for hours, I did not notice more freeze than when I play under Windows 7. The freeze are probably related to the game, not to the patch.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #143 from tonedef wine@causal.ca 2012-03-09 11:35:27 CST --- I'm in the same boat as hash. I can login fine but, I get a plain desktop and a cursor after logging in. After waiting ~10mins the screen goes black and nothing further happens. Any ideas on what could be going wrong? When I log in from Windows it goes straight to my character selection screen (not the server selection screen). Could this be the problem? I'm using NVidia 290.10 drivers in Arch 64bit to drive an NVidia 9600 GSO. Any ideas?
http://bugs.winehq.org/show_bug.cgi?id=29168
julusp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julusp@gmail.com
--- Comment #144 from julusp@gmail.com 2012-03-10 02:56:54 CST --- No problem with the patch on Mac OS X 10.7.3 with Radeon 6750, game plays well, excellent framerates. Only issue i found is *insane* loading times. the bigger location, the longer it will takes, (Nar Shadaa - 15 minutes, and sometimes disconnect).
I dont think that te texture is related to this patch. only things i see in logs are: fixme:win:GetWindowPlacement not supported on other process window 0x90060 fixme:d3d:query_init Unhandled query type 0xc. warn:d3d:wined3d_query_create Failed to initialize query, hr 0x8876086a. warn:d3d9:query_init Failed to create wined3d query, hr 0x8876086a. warn:d3d9:IDirect3DDevice9Impl_CreateQuery Failed to initialize query, hr 0x8876086a. fixme:d3d:resource_check_usage Unhandled usage flags 0x8. warn:d3d9:IDirect3DDevice9Impl_SetFVF 0 is not a valid FVF
which spawns like crazy trough the loading screen. Personally i think this is another bug.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #145 from Carsten Juttner carjay@gmx.net 2012-03-10 07:43:28 CST --- (In reply to comment #138)
order; from what I read, it should be done like
user_shared_data->SystemTime.High2Time = now.HighPart; user_shared_data->SystemTime.LowPart = now.LowPart; user_shared_data->SystemTime.High1Time = now.HighPart;
You are right, I remember I wanted to scrutinize this a bit more but obviously failed to do so and ended up copying and pasting the original wine source code from the initial initialisation.
So let's do this now. We have L, H1 and H2. Obviously on the "kernel" side this is coherent (since the now-structure is not changing).
Writing L, H1, H2 (as in the patch) concurrently with the expected H1, L, H2 read sequence (in a different thread) leads to 4 cases:
4 relevant points in time: - H1 old, L old, H2 old: ok - H1 old, L new, H2 old: nok, but will not(!) be detected - H1 new, L new, H2 old: nok - H1 new, L new, H2 new: ok
So indeed this code is obviously wrong and whoever wrote this probably thought that it would not matter because it was intended as a one time initial write.
Shows that copying and paste code without reviewing is a bad practice. :)
For the intended write order H2, L, H1 and read order H1, L, H2 this cannot happen (but see below): - H1 old, L old, H2 old: ok - H1 old, L old, H2 new: nok - H1 old, L new, H2 new: nok - H2 new, L new, H2 new: ok
Since this only becomes an issue at the moment the HighTime-Part actually changes this could in theory happen every (1<<32)/10e6 = 429 seconds which is roughly every 7 minutes.
So for a reader application this will appear like the system jumps in time by about 7 minutes.
Sadly, even if the order is corrected in the patch I think this will not be enough since due to the hackish nature several updates could happen concurrently.
Because, if several threads enter a critical section and thus update the page at the same time this may invalidate the strict order guarantee (since a second thread may overwrite H2 with an old value after another thread set it to a new one). So there is still a chance that H and L do not fit.
For a final implementation this also needs to take memory reference reordering and cache coherence issues into account. IIRC x86 is safe here as long as the compiler does not reorder the assembler instructions but for other platforms this may differ.
Some memory fences should help.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #146 from Carsten Juttner carjay@gmx.net 2012-03-10 08:21:28 CST --- (In reply to comment #143)
I'm in the same boat as hash. I can login fine but, I get a plain desktop and a cursor after logging in. After waiting ~10mins the screen goes black and nothing further happens. Any ideas on what could be going wrong? When I log in from Windows it goes straight to my character selection screen (not the server selection screen). Could this be the problem? I'm using NVidia 290.10 drivers in Arch 64bit to drive an NVidia 9600 GSO. Any ideas?
As a guideline, what happens after hitting "Play" here is: - 15-20 seconds: plain desktop background (blue) - ~1 second: black screen - 20-25 second: initial game loading screen
After that the character selection is visible.
Where "here" is a quad core i7-2630QM CPU with an Nvidia GeForce GTX460M and 270.41.06 drivers. It's an older Ubuntu 11.04 system with a custom kernel.
Hashs log appeared to be similar to my own so no ideas here. :-|
You could try to activate some debug flags concerning directx (e.g. d3d9) and try to gather from the logs if something goes wrong during initialization that might tell why things go wrong.
http://bugs.winehq.org/show_bug.cgi?id=29168
Andy darkdelusions@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |darkdelusions@gmail.com
--- Comment #147 from Andy darkdelusions@gmail.com 2012-03-10 14:07:49 CST --- The patch worked successfully for me on fedora 16 64 bit.
The only issue I have is if the game is not launched in a virtual desktop the launcher does not draw correctly. So I just run the game using the following command
env WINEPREFIX=$HOME/.wine-swtor wine explorer /desktop=SWTOR,1920x1080 "C:\Program Files\Electronic Arts\BioWare\Star Wars - The Old Republic\launcher.exe"
http://bugs.winehq.org/show_bug.cgi?id=29168
Balsha balsha-gajin@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |balsha-gajin@hotmail.com
--- Comment #148 from Balsha balsha-gajin@hotmail.com 2012-03-10 14:11:20 CST --- I'm a complete noob in both Ubuntu and Wine. So if anyone could explain how to install this KUSER patch step-by-step, I would greatly apreciate it. I'm using Ubuntu 11.10 and wine 1.4rc6.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #149 from Balsha balsha-gajin@hotmail.com 2012-03-10 14:13:53 CST --- I'm a complete noob in both Ubuntu and Wine. So if anyone could explain how to install this KUSER patch step-by-step, I would greatly apreciate it. I'm using Ubuntu 11.10 and wine 1.4rc6.
http://bugs.winehq.org/show_bug.cgi?id=29168
Fernando Martins fernando@cmartins.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fernando@cmartins.nl
--- Comment #150 from Fernando Martins fernando@cmartins.nl 2012-03-10 17:17:03 CST --- @Balsha: please do not use the bug comments to ask for help. Use the wine forum:
http://forum.winehq.org/viewforum.php?f=2&sid=c5b6e78ac4b901da88fa3a770c...
But first read http://wiki.winehq.org/Patching for help on applying patches.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #151 from Xolotl Loki xoloki@gmail.com 2012-03-10 17:37:39 CST --- Created attachment 39300 --> http://bugs.winehq.org/attachment.cgi?id=39300 KUSER_SHARED_DATA updates using a dedicated thread per swtor process
Here's my current patch. It updates KUSER_SHARED_DATA with a dedicated thread per swtor process. It works better for me than Carsten's patch, but it still suffers from freezing, though the frequency varies: a starter character on Tython can play for hours, but a Sith Assassin on Hoth starts freezing almost immediately.
The thread's priority can be controller via the env variable
WINE_USER_DATA_THREAD_PRIORITY
Default is 20.
The sleep time in nanosecond can be controlled via
WINE_USER_DATA_THREAD_NSLEEP
Default is 15625000 (15.625 ms).
I've included my NtTimer code, commented out. I'm not sure why it didn't work, since apparently the updates really don't need to be very fast.
The update thread is only spawned for the swtor processes. To determine this, I had to look in the CommandLine process variable. I had to manually convert the UNICODE_STRING to ANSI; when I tried to use RtlUnicodeToMultiByteN it segfaulted.
I think this is a more general fix than Carsten's, since there will be no overlapping writes (single writer thread per process). But it still doesn't solve the freezing issue, which I'm no longer sure is related. I've noticed that during the freezing, the RemoteRenderer process stops consuming CPU, so it seems like something is deadlocked in the renderer.
Can people please try my patch and report your results?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #152 from julusp@gmail.com 2012-03-10 17:48:49 CST --- Compiling it now, will let you know with the result, anyway the freezing can be theoreticaly caused by 256MB GPU cards, friend confirmed that on his Nvidia 320M 256MB recieves spam when freezed (the VideoSizeRam is set correctly):
fixme:d3d:resource_check_usage Unhandled usage flags 0x8. err:d3d:resource_init Out of adapter memory
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #153 from julusp@gmail.com 2012-03-10 18:20:50 CST --- (In reply to comment #151)
Created attachment 39300 [details] KUSER_SHARED_DATA updates using a dedicated thread per swtor process .... Can people please try my patch and report your results?
With your patch applied on vanilla wine1.4 source code, i cant get past launcher - i get Unable to launch game when i hit play.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #154 from julusp@gmail.com 2012-03-10 19:34:27 CST --- Created attachment 39303 --> http://bugs.winehq.org/attachment.cgi?id=39303 wine log for KUSER_SHARED_DATA updates using a dedicated thread per swtor ...
As you can see, it tryies two times to register thread and then nothing more happens and launcher will show "unable to launch the game" error, i can run it with aditional debug, just please tell me which one you want.
(And no, i am not concerned about showing the password, as i use security key auth, it is always different :)
http://bugs.winehq.org/show_bug.cgi?id=29168
julusp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39303|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #155 from tonedef wine@causal.ca 2012-03-10 20:07:41 CST --- I managed to solve my issues of "black screen after login" so I thought I'd come back and let people know what worked for me. Hopefully this works for hash. Aside from recompiling with KUSER_SHARED_DATA patch I had to also drop my gcc version from 4.6.3 to 4.5.2 before compilation. This is actually a known bug in gcc. I think the relevant log line is:
fixme:dbghelp:elf_search_auxv can't find symbol in module
For more information see http://appdb.winehq.org/objectManager.php?sClass=version&iId=19444.
http://bugs.winehq.org/show_bug.cgi?id=29168
Xolotl Loki xoloki@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39300|0 |1 is obsolete| |
--- Comment #156 from Xolotl Loki xoloki@gmail.com 2012-03-11 04:08:13 CDT --- Created attachment 39308 --> http://bugs.winehq.org/attachment.cgi?id=39308 KUSER_SHARED_DATA updates using a dedicated thread for all processes
Removed the CommandLine parsing, spawn a thread for all processes.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #157 from Xolotl Loki xoloki@gmail.com 2012-03-11 04:12:19 CDT ---
With your patch applied on vanilla wine1.4 source code, i cant get past launcher - i get Unable to launch game when i hit play.
I updated the patch, can you try again? Hopefully you were just having trouble with the CommandLine parsing, so I removed that piece. Not sure what else could have caused a crash anyway :)
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #158 from Carsten Juttner carjay@gmx.net 2012-03-11 05:57:27 CDT --- (In reply to comment #155)
I managed to solve my issues of "black screen after login" so I thought I'd come back and let people know what worked for me. Hopefully this works for hash. Aside from recompiling with KUSER_SHARED_DATA patch I had to also drop my gcc version from 4.6.3 to 4.5.2 before compilation.
Yes, since I was using an older Ubuntu installation my gcc was by default the mentioned version 4.5.2.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #159 from Carsten Juttner carjay@gmx.net 2012-03-11 07:55:14 CDT --- (In reply to comment #157)
I updated the patch, can you try again? Hopefully you were just having trouble with the CommandLine parsing, so I removed that piece. Not sure what else could have caused a crash anyway :)
This patch won't work as is on my Ubuntu system since it tries to set the scheduling policy to SCHED_FIFO which isn't allowed by the process limits (it will return "no permission" when calling pthread_create).
If I remove the scheduling setup, the login to character selection works (didn't test more).
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #160 from julusp@gmail.com 2012-03-11 09:09:27 CDT --- (In reply to comment #157)
With your patch applied on vanilla wine1.4 source code, i cant get past launcher - i get Unable to launch game when i hit play.
I updated the patch, can you try again? Hopefully you were just having trouble with the CommandLine parsing, so I removed that piece. Not sure what else could have caused a crash anyway :)
Now it wont even launch anything, producing nothing but empty log.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #161 from julusp@gmail.com 2012-03-11 09:21:21 CDT --- (In reply to comment #160)
(In reply to comment #157)
With your patch applied on vanilla wine1.4 source code, i cant get past launcher - i get Unable to launch game when i hit play.
I updated the patch, can you try again? Hopefully you were just having trouble with the CommandLine parsing, so I removed that piece. Not sure what else could have caused a crash anyway :)
Now it wont even launch anything, producing nothing but empty log.
Even if i remove the schedpolicy as Carsten did i will get only fixme:thread:thread_init unable to spawn thread: Undefined error: 0 (0)
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #162 from Xolotl Loki xoloki@gmail.com 2012-03-11 19:13:44 CDT --- Created attachment 39316 --> http://bugs.winehq.org/attachment.cgi?id=39316 KUSER_SHARED_DATA updates using a dedicated thread for all processes with no attributes
I removed all the pthread attribute code, and all the commented out NtTimer code.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #163 from hash HASH.DuOrden@gmail.com 2012-03-11 19:41:56 CDT --- (In reply to comment #155)
I managed to solve my issues of "black screen after login" so I thought I'd come back and let people know what worked for me. Hopefully this works for hash. Aside from recompiling with KUSER_SHARED_DATA patch I had to also drop my gcc version from 4.6.3 to 4.5.2 before compilation. This is actually a known bug in gcc. I think the relevant log line is:
fixme:dbghelp:elf_search_auxv can't find symbol in module
For more information see http://appdb.winehq.org/objectManager.php?sClass=version&iId=19444.
Thank you! That solved it, in my system I've had gcc-4.5.3. so I've compiled 4.5.2 in /opt/gcc/4.5.2 and then compiled wine this way: CFLAGS="-march=native -O2 -pipe --enable-frame-pointer" CXXFLAGS="${CFLAGS}" ./configure --prefix=/opt/wine${WINE_BUILD_TYPE} \ --with-xinput2 --without-openal --with-opengl --with-oss --with-mpg123 \ CC=/opt/gcc-4.5.2/bin/gcc CXX=/opt/gcc-4.5.2/bin/c++ CPP=/opt/gcc-4.5.2/bin/cpp && \ make depend && make
Now I can login with WINE! Finally I can dish-out VMWare! All thanks to tonedef who found tiny piece of gold in wine-bugzilla!
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #164 from julusp@gmail.com 2012-03-11 19:49:22 CDT --- (In reply to comment #162)
Created attachment 39316 [details] KUSER_SHARED_DATA updates using a dedicated thread for all processes with no attributes
I removed all the pthread attribute code, and all the commented out NtTimer code.
Argh, you will kill me. The code works, the code before works too. I am using Mac OSX 10.7, gcc-4.2 and wineskin, i was running your code in DEBUG and that is why it wont work, i accidently launched the game without debug and i was surprised it works!?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #165 from julusp@gmail.com 2012-03-11 19:52:12 CDT --- Created attachment 39317 --> http://bugs.winehq.org/attachment.cgi?id=39317 OSX Debug trace
If you want to look on this issue, why your code breaks debug, i attached the +all log (it generates just few lines).
Anyway, the insane loading times for big locations remains. Maybe another bug?
http://bugs.winehq.org/show_bug.cgi?id=29168
silentz0r d.misdanitis@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |d.misdanitis@gmail.com
--- Comment #166 from silentz0r d.misdanitis@gmail.com 2012-03-11 19:59:58 CDT --- (In reply to comment #165)
Created attachment 39317 [details] OSX Debug trace
If you want to look on this issue, why your code breaks debug, i attached the +all log (it generates just few lines).
Anyway, the insane loading times for big locations remains. Maybe another bug?
The insane loading times might be from wine producing too much output. Try disabling ALL output from wine, and run swtor. Please let us know if this resolves your issue.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #167 from julusp@gmail.com 2012-03-11 20:13:10 CDT --- (In reply to comment #166)
(In reply to comment #165)
Created attachment 39317 [details] OSX Debug trace
If you want to look on this issue, why your code breaks debug, i attached the +all log (it generates just few lines).
Anyway, the insane loading times for big locations remains. Maybe another bug?
The insane loading times might be from wine producing too much output. Try disabling ALL output from wine, and run swtor. Please let us know if this resolves your issue.
I tryied WINEDEBUG=-all and the load time is still taking long time (more than 5 minute to load Nar Shaddaa) swtor.exe @swtor_dual.icb is taking 100% of cpu core, and swtor.exe @RemoteRendererServer.icb is almost idle
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #168 from Vitaliy Margolen vitaliy-bugzilla@kievinfo.com 2012-03-11 23:04:46 CDT --- (In reply to comment #166)
Anyway, the insane loading times for big locations remains. Maybe another bug?
Yes, please open a new bug.
http://bugs.winehq.org/show_bug.cgi?id=29168
Panama Craig Panama.Craig00@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Panama.Craig00@gmail.com
--- Comment #169 from Panama Craig Panama.Craig00@gmail.com 2012-03-12 03:42:28 CDT --- Ok, so I decided recently that I would go ahead and change back over to Ubuntu from Win7 once SWTOR was found to be working. I did a fresh install of Ubuntu 10.04 Lucid Lucy. I started out getting wine 1.4 and making sure to get the build dependencies, and then updated my nvidia drivers to the most current version. I then compiled a version of wine-git with the proof of concept patch and performed an override on the dlls with wine for the d3dx9_36 dll and the vcrun2008 dll.
After all that and of course, much more customization of Ubuntu's look for me. I decided to go ahead and install SWTOR. The install went through and I renamed the LoadingScreenIcon.dds and the LoadingScreen.jpg files to be preceded with the extension ".bak". From here I loaded the game and am now stuck at a black screen. I would continue to troubleshoot whats going on here, but I am getting extremely tired and have taken every possible step that I can take. Carefully and slowly... I don't know how to run debug logging, but I don't mind doing it. With the drivers, the git build, the renamed files, and the ability to get all the way in game... I suspect I should be able to get to the server list at least and get turned away because I didn't compile my git build properly or something, but I should be getting past where I am right now at the very least.
Thank you for any assistance!
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #170 from julusp@gmail.com 2012-03-12 07:06:21 CDT --- (In reply to comment #169)
The install went through and I renamed the LoadingScreenIcon.dds and the LoadingScreen.jpg files to be preceded with the extension ".bak". From here I loaded the game and am now stuck at a black screen.
Don't rename that files, it is not needed anymore, and you will not know if you have render problems (like hash and tonedef) or something else, also try take look at comment #155 and #163 maybe it is related to your issue.
http://bugs.winehq.org/show_bug.cgi?id=29168
dlzerocool dl.zerocool@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool@gmail.com
--- Comment #171 from dlzerocool dl.zerocool@gmail.com 2012-03-12 08:15:04 CDT --- I would like to know more about why GCC 4.6 exactly broke things up, and why this flag help : CFLAGS="--enable-frame-pointer"
As far as I remember enabling frame-pointer resulted in a broken wine, not the opposite. But I might be wrong.
Also, as someone already reported this to FSF ? And if yes, where, because I am desperately looking for it, and eventually give some help to solve this annoying bug. (Having to revert to any other GCC version just to compile wine is not a solution, since a GNU/Linux distribution would have build all other packages with the newer version.)
http://bugs.winehq.org/show_bug.cgi?id=29168
Vitaliy Margolen vitaliy-bugzilla@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |30148
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #172 from Vitaliy Margolen vitaliy-bugzilla@kievinfo.com 2012-03-12 08:24:49 CDT --- (In reply to comment #171) For example see bug 22053.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #173 from dlzerocool dl.zerocool@gmail.com 2012-03-12 08:30:25 CDT --- (In reply to comment #172)
(In reply to comment #171) For example see bug 22053.
Thank you, I did already found that bug, but look at the http://bugs.winehq.org/show_bug.cgi?id=22053#c27 (comment 27) you'll see that he is using "-fomit-frame-pointer".
It a really weird bug, and apparently none is speaking about what code lines are exactly broken or not interpreted like they should by gcc 4.6
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #174 from dlzerocool dl.zerocool@gmail.com 2012-03-12 09:08:44 CDT --- (In reply to comment #169)
I haven't been able to pass the loading screen either. I am using an ArchlinuxX64. Compiled with GCC 1.5.0 and tried every patch available here. Including the last one from "Xoloti Loki".
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #175 from dlzerocool dl.zerocool@gmail.com 2012-03-12 09:20:45 CDT --- (In reply to comment #174)
(In reply to comment #169)
I haven't been able to pass the loading screen either. I am using an ArchlinuxX64. Compiled with GCC 1.5.0 and tried every patch available here. Including the last one from "Xoloti Loki".
My bad, I might have been a bit tired yesterday, I just revert all my changes, cleaned wine (make clean) and apply the patch again, compiled the wine with GCC 4.5.0 and it's working.
But it's generating a HUGE amount of logs : Which are mainly generated by this fixme, fixme:win:GetWindowPlacement not supported on other process window 0x60086
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #176 from hash HASH.DuOrden@gmail.com 2012-03-12 09:22:38 CDT --- Well, for me it dosn't matter which gcc to use 4.5.2 or 4.5.3 as long as I use CFLAGS="--enable-frame-pointer", I haven't yet tested with 4.6 simply because in Gentoo 4.6 hard masked as unstable and unsuitable for production use.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #177 from Sebastiaan Blommers sebastiaan.blommers@gmail.com 2012-03-12 09:58:10 CDT --- (In reply to comment #176)
Well, for me it dosn't matter which gcc to use 4.5.2 or 4.5.3 as long as I use CFLAGS="--enable-frame-pointer", I haven't yet tested with 4.6 simply because in Gentoo 4.6 hard masked as unstable and unsuitable for production use.
32 or 64 bit? @dlzerocool: WindowPlacement = known other issue
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #178 from hash HASH.DuOrden@gmail.com 2012-03-12 10:12:02 CDT --- 32bit
http://bugs.winehq.org/show_bug.cgi?id=29168
mbisme@burke-works.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|mbisme@burke-works.com |
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #179 from Panama Craig Panama.Craig00@gmail.com 2012-03-12 21:46:44 CDT --- (In reply to comment #170)
(In reply to comment #169)
The install went through and I renamed the LoadingScreenIcon.dds and the LoadingScreen.jpg files to be preceded with the extension ".bak". From here I loaded the game and am now stuck at a black screen.
Don't rename that files, it is not needed anymore, and you will not know if you have render problems (like hash and tonedef) or something else, also try take look at comment #155 and #163 maybe it is related to your issue.
I know what my problem is... It is that I compiled wine and git under gcc 4.6 instead of 4.5.2 or .3 ... I need to recompile them both, but I don't know how to do that. Here is where I left off at last night before giving up completely.
I just downloaded and extracted gcc 4.5.2 into my /home/*username*/gcc-4.5.2/ then cd'd to that folder in the terminal and performed the commands to compile gcc-4.5.2 into the system. Also did a sudo make and sudo make install on gcc-4.5.2... So now when I recompile wine-git I should be able to use 4.5.2 instead of 4.6, but where I am stuck at is finding out how to just recompile wine-git... Do I need to remove wine-git before I recompile it? Or do I just recompile over it? Do I need to specify that wine-git be compiled with 4.5.2 instead of 4.6 since I now have both? What are the commands to do all this? Do I need to compile wine all over again as well, not just git?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #180 from hash HASH.DuOrden@gmail.com 2012-03-13 00:37:52 CDT --- (In reply to comment #179)
(In reply to comment #170)
(In reply to comment #169)
The install went through and I renamed the LoadingScreenIcon.dds and the LoadingScreen.jpg files to be preceded with the extension ".bak". From here I loaded the game and am now stuck at a black screen.
Don't rename that files, it is not needed anymore, and you will not know if you have render problems (like hash and tonedef) or something else, also try take look at comment #155 and #163 maybe it is related to your issue.
I know what my problem is... It is that I compiled wine and git under gcc 4.6 instead of 4.5.2 or .3 ... I need to recompile them both, but I don't know how to do that. Here is where I left off at last night before giving up completely.
I just downloaded and extracted gcc 4.5.2 into my /home/*username*/gcc-4.5.2/ then cd'd to that folder in the terminal and performed the commands to compile gcc-4.5.2 into the system. Also did a sudo make and sudo make install on gcc-4.5.2... So now when I recompile wine-git I should be able to use 4.5.2 instead of 4.6, but where I am stuck at is finding out how to just recompile wine-git... Do I need to remove wine-git before I recompile it? Or do I just recompile over it? Do I need to specify that wine-git be compiled with 4.5.2 instead of 4.6 since I now have both? What are the commands to do all this? Do I need to compile wine all over again as well, not just git?
I cannot say that replacing your system gcc with older version just to compile single program is good idea, if in distribution of your choice gcc-4.6 is default then there is a reason for that and by performing sudo make install you playing with fire there!
Instead you should've used --prefix when you run configure, you did run ./configure script before make in gcc-4.5.2, did you? Here how I run configure when I thought needed gcc-4.5.2: ./configure --prefix=/opt/gcc-4.5.2 --enable-languages=c,c++,fortran and thanks to --prefix when you sudo make install it will install it in /opt/gcc-4.5.2 consecutively to compile wine you will need to point it's configure to where to look for gcc: ./configure --prefix=/opt/wine CC=/opt/gcc-4.5.2/bin/gcc CXX=/opt/gcc-4.5.2/bin/c++ CPP=/opt/gcc-4.5.2/bin/cpp
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #181 from h.v.bruinehsen@fu-berlin.de 2012-03-13 05:17:26 CDT --- I'm not sure, if the lockups are really wine related. In the beginning I had them, too (Gameplay on Korriban grew sluggish over time, Dromund Kaas was nearly unplayable from the beginning on). Without changing anything directly wine related (still using Carstes patch) the problem disappeared after some system updates (kernel from 3.0.4 to 3.2.6, both with Con Kolivas patchset, new glibc, gcc from 4.5.2 to 4.6.3 with graphite and some other). Now everythings runs fine (sometimes minor stuttering, but that is most likely hardware related). Therefore I believe that the problem is not wine-related or some kind of race-condition (which will make it much harder to debug, I fear)...
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #182 from hash HASH.DuOrden@gmail.com 2012-03-13 07:46:41 CDT --- (In reply to comment #181)
I'm not sure, if the lockups are really wine related. In the beginning I had
...
with Con Kolivas patchset, new glibc, gcc from 4.5.2 to 4.6.3 with graphite and
...
I'm sorry to ask not about what your post is, but have you tried compile wine with gcc-4.6.3 and Carstes patch?
http://bugs.winehq.org/show_bug.cgi?id=29168
Justin Gray justinanthonygray@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|justinanthonygray@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #183 from Panama Craig Panama.Craig00@gmail.com 2012-03-13 10:40:04 CDT --- Honestly, at this point... I am going to reinstall Ubuntu and start over clean. I am running 10.04 right now, but it seems that most people are having success with 11.04 or 11.10 more than I am having success with Lucid Lucy. I may also just go with 12.04 and see how that works out as well. Not sure though to be honest.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #184 from Sebastiaan Blommers sebastiaan.blommers@gmail.com 2012-03-13 11:55:03 CDT --- Post your results. Testing 12.04 also, no problems thus far.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #185 from h.v.bruinehsen@fu-berlin.de 2012-03-13 12:52:43 CDT --- The git-checkout from today compiled fine with gcc-4.6.2 and Carstens patch. I'm using Gentoo and only patched the ebuild - there are two Gentoo-specific patches applied also: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/wine/f... and http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/wine/f...
If it's not one of them, it's maybe the Gentoo-spec file for gcc.
Otherwise my point wasn't the ability to compile wine with newer ggc-versions, but the fix for the slowdown-problem without touching wine...
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #186 from julusp@gmail.com 2012-03-13 13:22:33 CDT --- (In reply to comment #185)
Otherwise my point wasn't the ability to compile wine with newer ggc-versions, but the fix for the slowdown-problem without touching wine...
That is not good solution. This may works with linux distributions, but with othet os like BSD or MAC OS X where you are stuck with gcc-4.2 this will not work.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #187 from h.v.bruinehsen@fu-berlin.de 2012-03-13 13:53:10 CDT ---
That is not good solution. This may works with linux distributions, but with othet os like BSD or MAC OS X where you are stuck with gcc-4.2 this will not work.
And searching for a fix in Wine for a problem that may be not caused by Wine is a good solution? I'm not saying that the problem may not be caused by Wine - but if it can be fixed by other means, it seems to be at least some kind of race condition or a problem with one of the used libraries.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #188 from julusp@gmail.com 2012-03-13 13:57:59 CDT --- (In reply to comment #187)
And searching for a fix in Wine for a problem that may be not caused by Wine is a good solution? I'm not saying that the problem may not be caused by Wine - but if it can be fixed by other means, it seems to be at least some kind of race condition or a problem with one of the used libraries.
I dont know what issues you see, on mac the only issue is with loading times, but when loaded the performance is nearly windows like. No slowdowns only minor stuttering ( major when taxi moving but that does not affect gameplay)
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #189 from hash HASH.DuOrden@gmail.com 2012-03-13 14:42:36 CDT --- (In reply to comment #185)
The git-checkout from today compiled fine with gcc-4.6.2 and Carstens patch. I'm using Gentoo and only patched the ebuild - there are two Gentoo-specific patches applied also: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/wine/f... and http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/wine/f...
If it's not one of them, it's maybe the Gentoo-spec file for gcc.
Otherwise my point wasn't the ability to compile wine with newer ggc-versions, but the fix for the slowdown-problem without touching wine...
So you saying that you compiled otherwise stock, from Gentoo perspective view, WINE with gcc-4.6.2 and all works? Could you provide emerge --info please?
PS: And by the way, if you just want to add one patch to any packet in Gentoo you do not have to copy in to /usr/local/portage and alter it's .ebuild file, all you need to do is create directory in etc like this for wine: /etc/portage/patches/app-emulation/wine/ and place in it your patch, and next time emerge will compile it with your patch.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #190 from Panama Craig Panama.Craig00@gmail.com 2012-03-13 19:02:37 CDT --- Created attachment 39344 --> http://bugs.winehq.org/attachment.cgi?id=39344 Terminal Log
Ok, so here I am again...
I freshly installed Ubuntu desktop 11.10 and have updated my nvidia drivers to 295.20 again, and then installed git, and then applied the patch, compiled wine through git, then installed wine. Installed SWTOR, then did the d3dx9 override and launch the game via cd'ing to the game directory then ~/wine-git/wine explorer /desktop=4,1360x768 launcher.exe. From there, I log into the game, and it takes a moment, but the game will finally open and it gets to the loading screen and begins to load, then just stops and the game will crash... The terminal leaves behind the message in the attachment I logged.
Is this because I did the steps for ./configure and make on git for wine before I ever even installed wine? I did apply the patch before performing either of those steps too btw. Whats going on? I just want to play mah gamez! LoL
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #191 from Sebastiaan Blommers sebastiaan.blommers@gmail.com 2012-03-14 04:18:22 CDT --- Strange, might be driver/hardware related then. Did you try to use Crossover XI? (there is a trial that supports swtor from these patches). Also try another driver version, I use the exact same one but it might just be that in your case.
http://www.codeweavers.com/compatibility/browse/name/?forum=1;app_id=7626;mh...
Best regards, Sebastiaan
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #192 from h.v.bruinehsen@fu-berlin.de 2012-03-14 10:11:57 CDT --- Created attachment 39360 --> http://bugs.winehq.org/attachment.cgi?id=39360 Emerge --info output from working Gentoo 64~
(In reply to comment #189)
Could you provide emerge --info please?
I attached the output. Otherwise I think we should discuss Gentoo specific things (except it's related to this bug) privately or via gentoo lists/forums/irc.
PS: And by the way, if you just want to add one patch to any packet in Gentoo you do not have to copy in to /usr/local/portage and alter it's .ebuild file, all you need to do is create directory in etc like this for wine: /etc/portage/patches/app-emulation/wine/ and place in it your patch, and next time emerge will compile it with your patch.
This only works, when the ebuild calls 'epatch_user' (which wine-9999.ebuild acually does). Old habits are also hard to put down..
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #193 from hash HASH.DuOrden@gmail.com 2012-03-14 10:45:15 CDT --- (In reply to comment #192)
Created attachment 39360 [details] Emerge --info output from working Gentoo 64~
....
This only works, when the ebuild calls 'epatch_user' (which wine-9999.ebuild acually does). Old habits are also hard to put down..
I asked about emerge --info just to look in your CFLAGS since I didn't know your level of Linux understanding I thought it'll easer way of looking in that. So as you use gcc-4.6 and you don't use --enable-frame-pointer it is mean one of three options: 1. gcc-4.6 can compile WINE without braking it. :) 2. some default CFLAGS from Gentoo profile insert --enable-frame-pointer by default. 3. Some of your CFLAGS or combination of them made gcc compile WINE without braking it. :)
http://bugs.winehq.org/show_bug.cgi?id=29168
André Fettouhi A.Fettouhi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |A.Fettouhi@gmail.com
--- Comment #194 from André Fettouhi A.Fettouhi@gmail.com 2012-03-16 12:51:18 CDT --- I'm trying to build wine version 1.4 against the patch from Carsten but I keep getting this error:
can't find file to patch at input line 7 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/critsection.c b/dlls/ntdll/critsection.c |index fb69b31..5d7783b 100644 |--- a/dlls/ntdll/critsection.c |+++ b/dlls/ntdll/critsection.c -------------------------- File to patch:
I'm just using this command to patch with:
cat proof_of_concept.patch |patch -p1
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #195 from Sebastiaan Blommers sebastiaan.blommers@gmail.com 2012-03-16 12:53:23 CDT --- (In reply to comment #194)
I'm trying to build wine version 1.4 against the patch from Carsten but I keep getting this error:
can't find file to patch at input line 7 Perhaps you used the wrong -p or --strip option? The text leading up to this was:
|diff --git a/dlls/ntdll/critsection.c b/dlls/ntdll/critsection.c |index fb69b31..5d7783b 100644 |--- a/dlls/ntdll/critsection.c |+++ b/dlls/ntdll/critsection.c
File to patch:
I'm just using this command to patch with:
cat proof_of_concept.patch |patch -p1
http://wiki.winehq.org/Patching
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #196 from Henri Verbeet hverbeet@gmail.com 2012-03-16 13:00:07 CDT --- (In reply to comment #195)
cat proof_of_concept.patch |patch -p1
Actually, you almost always want to use "git apply" instead of "patch" for applying patches to a git tree.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #197 from André Fettouhi A.Fettouhi@gmail.com 2012-03-16 13:02:12 CDT --- But I'm not patching against the latest git? I'm patching against wine 1.4.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #198 from André Fettouhi A.Fettouhi@gmail.com 2012-03-16 14:37:14 CDT --- I just build Carstens patch against wine 1.4 and tried to launch swtor. I can't get to the server selection screen at all plus I am experiencing very very long load times as mentioned in another wine bug. I am running Arch Linux 64 bit with gcc 4.6.3. The output from the terminal gives me an infinite loop of...
fixme:d3d:resource_check_usage Unhandled usage flags 0x8. err:d3d:resource_init Out of adapter memory
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #199 from julusp@gmail.com 2012-03-16 18:03:26 CDT --- (In reply to comment #198)
I just build Carstens patch against wine 1.4 and tried to launch swtor. I can't get to the server selection screen at all plus I am experiencing very very long load times as mentioned in another wine bug. I am running Arch Linux 64 bit with gcc 4.6.3. The output from the terminal gives me an infinite loop of...
fixme:d3d:resource_check_usage Unhandled usage flags 0x8. err:d3d:resource_init Out of adapter memory
Obviously out of gpu memory (some 256MB cards are not working), or try to set correct VideoMemorySize in registry.
For others: Discuss only things related to this issue, please don't ask for steps how to build wine, this is not help forum.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #200 from Xolotl Loki xoloki@gmail.com 2012-03-16 21:48:23 CDT --- I think the current patches do a reasonable job of fixing the initial server handshake, so we should apply some version of them and close this bug. At this point it's degenerating into a forum session on patching and video cards.
Wine devs: is there anything you find unacceptable about my last patch? The only concern I have is that clock_nanosleep on an absolute timer might be a better choice than the current nanosleep call, since the update time will drift.
But I don't know if there is drift when windows updates the values either. Carsten, did your test program exhibit such drift? I.e. did they do 64 full updates every second, so the values would fall on every second boundary?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #201 from silentz0r d.misdanitis@gmail.com 2012-03-17 07:42:51 CDT --- (In reply to comment #198)
I just build Carstens patch against wine 1.4 and tried to launch swtor. I can't get to the server selection screen at all plus I am experiencing very very long load times as mentioned in another wine bug. I am running Arch Linux 64 bit with gcc 4.6.3. The output from the terminal gives me an infinite loop of...
fixme:d3d:resource_check_usage Unhandled usage flags 0x8. err:d3d:resource_init Out of adapter memory
I have made a package called gcc45-multilib. Build it using yaourt -G gcc45-multilib, then cd into that dir and makepkg -si
After cd into ~/wine-git and run ./configure CC=gcc-4.5.2 CXX=c++-4.5.2 CPP=cpp-4.5.2 and you're done.
If you want a more detailed explanation I wrote a guide on my blog, which I won't post here. Google my nick along with " swtor linux".
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #202 from André Fettouhi A.Fettouhi@gmail.com 2012-03-17 12:09:24 CDT --- I just tried rebuild wine 1.5.0 with Xolotl Loki patch (39316) using gcc 4.6.3 on Arch Linux 64 bit and the game actually works now :-). Have only played very little of the game but load times seem to be ok. Loading the game after login takes quite a whole though +5 minutes at least.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #203 from André Fettouhi A.Fettouhi@gmail.com 2012-03-17 12:14:47 CDT --- I forgot to add that exiting/logging out the game hangs, e.g. swtor.exe, launcher.exe and winserver.exe keep on running...
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #204 from Carsten Juttner carjay@gmx.net 2012-03-17 19:18:20 CDT --- (In reply to comment #200)
But I don't know if there is drift when windows updates the values either. Carsten, did your test program exhibit such drift? I.e. did they do 64 full updates every second, so the values would fall on every second boundary?
A quick test shows that on my Vista system each update seems to add a value of either 156000 or 156001 to InterruptTime and always 156000 for SystemTime.
This would hint that the "real" update is not occurring at 64Hz but rather around 64.102564Hz. Anyway, the values are quite consistent.
I guess there is not a lot of drift because the timer interrupt is hardware generated.
But I do not think it matters much since these timers are not documented officially so as long as they get updated around 64 Hz things should work ok.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #205 from Bruno Jesus 00cpxxx@gmail.com 2012-03-19 06:24:42 CDT --- (In reply to comment #200)
Wine devs: is there anything you find unacceptable about my last patch? The only concern I have is that clock_nanosleep on an absolute timer might be a better choice than the current nanosleep call, since the update time will drift.
You can follow the guidelines from http://wiki.winehq.org/SubmittingPatches and send it to wine-patches. Or send first to wine-devel with RFC in the beggining of the subject so others can take a look on it.
http://bugs.winehq.org/show_bug.cgi?id=29168
Trograin boban.alempijevic@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |boban.alempijevic@gmail.com
--- Comment #206 from Trograin boban.alempijevic@gmail.com 2012-03-20 07:09:04 CDT --- Been trying this patch added to 1.4 source and used with Wineskin in OSX 10.7 with an ATI HD 5770 1024Mb GPU. Now the game starts good ( if using Virtual window and a set resolution doesn't matter what size as long as there is one), login, character creation the whole thin goes real nice. I can start the game as well . Now the problem I have and that a lot of other people most likely have as well is the stuttering. I have been trying to read through this thread and I am wiling to try to help out even though my skills are on an amateur level ( Though I have sys admin skills in background, these type of coding /hacking/software stuff is NOT my strong side :D ). I ran a debug in wineskin while running the game but it spat out a 22Mb large file. If I knew what areas in the Debug file would be of interest to this community I would gladly post it somewhere on the net and link it here.
TI have been using the Wineskin as I said and the one that seems to be working nicely ( WITH stuttering) is this one: http://portingteam.com/index.php/files/file/7187-star-wars-the-old-republic/....
Now the stuttering is in starting areas okey, happens for a second or two once a minute, but go off to a main world and we talk MAIN stuttering ala Headache!
Yes the stuttering part seems to be less in Linux, My bro did the patching and got the game to run under the patched wine on his Kubuntu 11 what ever the latest version now a days is:D. His stuttering is almost non existing compared to mine. It seems to have a larger impact on the OSX wine community though.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #207 from julusp@gmail.com 2012-03-20 07:22:12 CDT --- (In reply to comment #206)
Been trying this patch added to 1.4 source and used with Wineskin in OSX 10.7 with an ATI HD 5770 1024Mb GPU. Now the game starts good ( if using Virtual window and a set resolution doesn't matter what size as long as there is one), login, character creation the whole thin goes real nice. I can start the game as well . Now the problem I have and that a lot of other people most likely have as well is the stuttering. I have been trying to read through this thread and I am wiling to try to help out even though my skills are on an amateur level ( Though I have sys admin skills in background, these type of coding /hacking/software stuff is NOT my strong side :D ). I ran a debug in wineskin while running the game but it spat out a 22Mb large file. If I knew what areas in the Debug file would be of interest to this community I would gladly post it somewhere on the net and link it here.
TI have been using the Wineskin as I said and the one that seems to be working nicely ( WITH stuttering) is this one: http://portingteam.com/index.php/files/file/7187-star-wars-the-old-republic/....
Now the stuttering is in starting areas okey, happens for a second or two once a minute, but go off to a main world and we talk MAIN stuttering ala Headache!
Yes the stuttering part seems to be less in Linux, My bro did the patching and got the game to run under the patched wine on his Kubuntu 11 what ever the latest version now a days is:D. His stuttering is almost non existing compared to mine. It seems to have a larger impact on the OSX wine community though.
The wineskin port is made by me. The uploaded version uses the first patch as other ones breaks winedebug and does not bring any perfomance boost nor solve any issues. The other patches break vanilla wine as well (wine available trough macports). So this problem is not related to custom wineskin build process
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #208 from Trograin boban.alempijevic@gmail.com 2012-03-20 07:35:06 CDT --- Julus, I did not say that this problem is related to custom wineskin build process :) Iam still eager to try to help out though in any way I can.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #209 from julusp@gmail.com 2012-03-20 08:01:01 CDT --- (In reply to comment #208)
Julus, I did not say that this problem is related to custom wineskin build process :) Iam still eager to try to help out though in any way I can.
Anyway the stuttering and performance problems does not belong to this thread as that is separate bug.
The current problem is that all patches except the proof of concept breaks winedebug on osx (wine exits with dbus error)
http://bugs.winehq.org/show_bug.cgi?id=29168
julusp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39317|0 |1 is obsolete| |
--- Comment #210 from julusp@gmail.com 2012-03-20 11:30:50 CDT --- Created attachment 39477 --> http://bugs.winehq.org/attachment.cgi?id=39477 failing debug on OSX
All patches from Xolotl Loki breaks wine on OSX with following error:
/opt/local/bin/wine: line 5: 85970 Bus error: 10 DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib:/usr/lib" "/opt/local/libexec/wine/wine" "$@"
if the wine is run with WINEDEBUG="-all" then wine will start correctly.
Proof of concept from Carsten Juttner work ok though.
Attached more complete debug log when run WINEDEBUG="+all" winecfg
can somebody look what is causing problem ?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #211 from Carsten Juttner carjay@gmx.net 2012-03-20 18:10:41 CDT --- (In reply to comment #210)
Created attachment 39477 [details] failing debug on OSX
All patches from Xolotl Loki breaks wine on OSX with following error:
/opt/local/bin/wine: line 5: 85970 Bus error: 10 DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib:/usr/lib" "/opt/local/libexec/wine/wine" "$@"
if the wine is run with WINEDEBUG="-all" then wine will start correctly.
Proof of concept from Carsten Juttner work ok though.
Attached more complete debug log when run WINEDEBUG="+all" winecfg
can somebody look what is causing problem ?
If it only works with debugging messages turned off I'd suspect one of the added FIXME messages.
An easy test would be to comment out all FIXME-lines from the patch and see if it works now. Then try to add them back one by one (actually only the FIXMEs that contain format specifiers like "%s" have a high probability to cause a Bus Error so one should try to add these back first).
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #212 from Xolotl Loki xoloki@gmail.com 2012-03-20 18:41:52 CDT --- Created attachment 39481 --> http://bugs.winehq.org/attachment.cgi?id=39481 KUSER_SHARED_DATA updates using a dedicated thread with no debugging
I removed all the FIXME and getenv calls, hopefully this will work for OSX.
http://bugs.winehq.org/show_bug.cgi?id=29168
Xolotl Loki xoloki@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39481|0 |1 is obsolete| |
--- Comment #213 from Xolotl Loki xoloki@gmail.com 2012-03-20 18:50:27 CDT --- Created attachment 39482 --> http://bugs.winehq.org/attachment.cgi?id=39482 KUSER_SHARED_DATA updates using a dedicated thread with no debugging
Correct diff between my code and wine-1.4-rc6.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #214 from julusp@gmail.com 2012-03-22 10:03:59 CDT --- (In reply to comment #213)
Created attachment 39482 [details] KUSER_SHARED_DATA updates using a dedicated thread with no debugging
Correct diff between my code and wine-1.4-rc6.
Confirming fixed WINEDEBUG on OSX (against wine-1.5.0)
http://bugs.winehq.org/show_bug.cgi?id=29168
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #215 from Jerome Leclanche adys.wh@gmail.com 2012-04-18 22:07:46 CDT --- (In reply to comment #214) Huh? was this fixed?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #216 from Xolotl Loki xoloki@gmail.com 2012-04-18 22:14:55 CDT --- The latest patch attached to this bug appears to fix the intro hang for Linux and OSX. It cannot be applied to wine though, since it uses a pthread in the wine process.
I'm working with wine-dev to push a wineserver shared memory patch which fixes this for good. Though I got sign-off on the design, I have been unable to get NtMapViewOfSection to cooperate, so the patch has been languishing.
Any wine devs looking at this bug who grok NtMapViewOfSection please check out my latest patch on wine-dev.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #217 from Johan Gill johan.gill@gmail.com 2012-05-15 08:16:38 CDT --- Any news? I see on the patch list for wine that there is a patch to "Separate image relocation from NtMapViewOfSection" pending. Does that have anything to do with this?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #218 from Xolotl Loki xoloki@gmail.com 2012-05-16 15:28:41 CDT --- No, none of the wine devs has helped me with my NtMapViewOfSection problems, and I haven't had any time to look at it myself lately.
The current patch (and my improved version which does clock_nanosleep) does an adequate job of playing SWTOR post the 1.2 patch; the extended freezing appears to be gone. Framerate in PvP can drop very low though (4 fps, with a GTX 680!).
Has anyone experimented with DLL overrides to get PvP performance to an acceptable level?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #219 from Marco D moonbane@gmx.net 2012-05-18 01:36:32 CDT --- (In reply to comment #218)
No, none of the wine devs has helped me with my NtMapViewOfSection problems, and I haven't had any time to look at it myself lately.
The current patch (and my improved version which does clock_nanosleep) does an adequate job of playing SWTOR post the 1.2 patch; the extended freezing appears to be gone. Framerate in PvP can drop very low though (4 fps, with a GTX 680!).
Has anyone experimented with DLL overrides to get PvP performance to an acceptable level?
I think it's a CPU-scaling/multithread issue. In Ops I can usually get better Performance, if I set each swtor-process per "taskset ..." to its own CPU-core.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #220 from hash HASH.DuOrden@gmail.com 2012-06-07 11:59:41 CDT --- As of wine-1.5.5-214-g876f0f2 patch from comment #213 isn't applicable: error: patch failed: server/async.c:256 error: server/async.c: patch does not apply include/wine/server_protocol.h updated
http://bugs.winehq.org/show_bug.cgi?id=29168
sporth@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|sporth@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #221 from Xolotl Loki xoloki@gmail.com 2012-06-07 13:17:06 CDT --- (In reply to comment #220)
As of wine-1.5.5-214-g876f0f2 patch from comment #213 isn't applicable: error: patch failed: server/async.c:256 error: server/async.c: patch does not apply include/wine/server_protocol.h updated
The patch from comment #213 did not patch those files, so I'm not sure what the problem is.
I'm attaching my current clock_nanosleep patch against 1.5.5 just in case.
http://bugs.winehq.org/show_bug.cgi?id=29168
Xolotl Loki xoloki@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39308|0 |1 is obsolete| | Attachment #39316|0 |1 is obsolete| |
--- Comment #222 from Xolotl Loki xoloki@gmail.com 2012-06-07 13:18:20 CDT --- Created attachment 40435 --> http://bugs.winehq.org/attachment.cgi?id=40435 KUSER_SHARED_DATA updates using a clock_nanosleep against wine-1.5.5
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #223 from Xolotl Loki xoloki@gmail.com 2012-06-07 20:07:32 CDT --- (In reply to comment #219)
Has anyone experimented with DLL overrides to get PvP performance to an acceptable level?
I think it's a CPU-scaling/multithread issue. In Ops I can usually get better Performance, if I set each swtor-process per "taskset ..." to its own CPU-core.
When booted into Windows XP, I get minimum 20 fps in warzones. On the same computer, this drops to around 5 fps in Ubuntu under Wine (minimum).
Trying taskset like such:
xoloki@xocotl:~/src/mrx/build$ ps auwx | grep swtor xoloki 8935 0.0 0.0 8704 900 pts/1 R+ 17:44 0:00 grep swtor xoloki 29822 50.4 8.4 1916864 1389392 pts/5 RLl 15:20 72:26 C:\Program Files\Electronic Arts\BioWare\Star Wars - The Old Republic\swtor\RetailClient\swtor.exe @swtor_dual.icb xoloki 29839 74.1 4.5 2188764 756428 pts/5 SLl 15:20 106:20 swtor.exe @RemoteRendererServer.icb xoloki@xocotl:~/src/mrx/build$ taskset -pc 2 29822 pid 29822's current affinity list: 3 pid 29822's new affinity list: 2 xoloki@xocotl:~/src/mrx/build$ taskset -pc 3 29839 pid 29839's current affinity list: 3 pid 29839's new affinity list: 3
I didn't see any noticeable difference in framerate in warzones (still dropped to around 5 during large fights). I have 4 CPUs, so I chose 3 and 4.
Does anyone get good (i.e. comparable to Windows on same hardware) framerates in PvP?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #224 from Marco D moonbane@gmx.net 2012-06-08 09:31:54 CDT --- Well I have an Vista on the same machine and have severe improvements in operations when I use taskset.
I dislike the SWTOR-PvP so I cannot really compare but in operations (EV,KP) I get about 30 frames in Vista and around 25 in Wine. Without taskset I stay at ~15 frames.
Debian Sid, vanilla 3.4, Q6600 GF 8800 Ultra with 302.11
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #225 from André Fettouhi A.Fettouhi@gmail.com 2012-07-10 10:51:44 CDT --- Can anyone get the launcher working after todays patch in swtor (1.3.2)? I just get a black screen with gold ornaments at the edge.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #226 from Xolotl Loki xoloki@gmail.com 2012-07-10 11:17:07 CDT --- I just tried with wine-1.5.7 and my clock_nanosleep patch, and after the launcher updated it became blacked out as described. Completely unusable.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #227 from julusp@gmail.com 2012-07-10 12:19:52 CDT --- (In reply to comment #226)
I just tried with wine-1.5.7 and my clock_nanosleep patch, and after the launcher updated it became blacked out as described. Completely unusable.
Can be workarounded by setting virtual desktop resolution to 800x600. Otherwise the window content will be moved or rendered black.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #228 from Xolotl Loki xoloki@gmail.com 2012-07-10 12:38:50 CDT --- (In reply to comment #227)
Can be workarounded by setting virtual desktop resolution to 800x600. Otherwise the window content will be moved or rendered black.
Confirmed workaround works on ubuntu-12.04.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #229 from julusp@gmail.com 2012-07-10 13:28:14 CDT --- (In reply to comment #222)
Created attachment 40435 [details] KUSER_SHARED_DATA updates using a clock_nanosleep against wine-1.5.5
Does not compile on MacOSX against wine 1.5.8:
thread.c: In function ‘shared_data_thread’: thread.c:117: warning: implicit declaration of function ‘clock_gettime’ thread.c:117: error: ‘CLOCK_MONOTONIC’ undeclared (first use in this function) thread.c:117: error: (Each undeclared identifier is reported only once thread.c:117: error: for each function it appears in.) thread.c:129: warning: implicit declaration of function ‘clock_nanosleep’ thread.c:129: error: ‘TIMER_ABSTIME’ undeclared (first use in this function)
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #230 from Xolotl Loki xoloki@gmail.com 2012-07-10 18:10:24 CDT ---
KUSER_SHARED_DATA updates using a clock_nanosleep against wine-1.5.5
Does not compile on MacOSX against wine 1.5.8:
clock_nanosleep is part of POSIX.1-2001 (IEEE Std 1003.1-2001). It looks like OS X only supports POSIX.1 (IEEE Std 1003.1-1988). So the clock_nanosleep patch will not work on OS X.
Does the previous patch (KUSER_SHARED_DATA updates using a dedicated thread with no debugging) no longer work? I can regenerate it against a new wine version if needed.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #231 from julusp@gmail.com 2012-07-10 18:15:51 CDT --- (In reply to comment #230)
Does the previous patch (KUSER_SHARED_DATA updates using a dedicated thread with no debugging) no longer work? I can regenerate it against a new wine version if needed.
The previous patch still works. No need for regenerating it.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #232 from Xolotl Loki xoloki@gmail.com 2012-07-10 19:31:43 CDT --- (In reply to comment #223)
Does anyone get good (i.e. comparable to Windows on same hardware) framerates in PvP?
I fixed this today, and it had nothing to do with wine.
The culprit was an interaction between swtor.exe, my CPU, and Linux. My CPU allows the OS to scale down the CPU frequency during low loads. For some reason, swtor.exe convinced the OS it didn't need full power, so the OS left all cores idling at 800 MHz (3GHz CPU).
This didn't happen with WoW, though I do remember occasional slowdowns that might have been freq scaling.
The solution was to turn off "Cool and Quiet" in the BIOS, and lock all cores at 3 GHz. Hopefully this will not burn out my CPU, but the system is 3 years old so whatever.
Not sure if XP did a better job of scaling the CPU, or if it just didn't bother trying. But I really don't care, because now I can PvP without booting into XP :)
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #233 from André Fettouhi A.Fettouhi@gmail.com 2012-07-11 00:37:31 CDT --- (In reply to comment #227)
(In reply to comment #226)
I just tried with wine-1.5.7 and my clock_nanosleep patch, and after the launcher updated it became blacked out as described. Completely unusable.
Can be workarounded by setting virtual desktop resolution to 800x600. Otherwise the window content will be moved or rendered black.
How do you then change the resolution of the virtual desktop once the game has launched? I play the game at my native resolution 1680x1050 in fullscreen mode with a 1680x1050 virtual desktop. How do I get that back after login?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #234 from Xolotl Loki xoloki@gmail.com 2012-07-11 00:53:07 CDT ---
How do you then change the resolution of the virtual desktop once the game has launched? I play the game at my native resolution 1680x1050 in fullscreen mode with a 1680x1050 virtual desktop. How do I get that back after login?
I was able to invoke my window manager's fullscreen command via Alt-F11, which then gave me a fullscreen toplevel window with no borders.
This is Xfce on xubuntu-10.04. Other desktop/window managers may have different accels.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #235 from André Fettouhi A.Fettouhi@gmail.com 2012-07-11 01:01:50 CDT --- (In reply to comment #234)
How do you then change the resolution of the virtual desktop once the game has launched? I play the game at my native resolution 1680x1050 in fullscreen mode with a 1680x1050 virtual desktop. How do I get that back after login?
I was able to invoke my window manager's fullscreen command via Alt-F11, which then gave me a fullscreen toplevel window with no borders.
This is Xfce on xubuntu-10.04. Other desktop/window managers may have different accels.
Using KDE, so I did a similar thing. So works for now as well. Would be nice if this issue could be fixed permanently.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #236 from rawfox rawfox@freenet.de 2012-12-04 17:25:02 CST --- Created attachment 42706 --> http://bugs.winehq.org/attachment.cgi?id=42706 KUSER_SHARED_DATA_18 against -> wine-1.5.18
Due to improvements in wine-1.5.18 the /dlls/ntdll/thread.c was touched and the KUSER_SHARED_DATA patch wont apply anymore.
The KUSER_SHARED_DATA patch is still needed due to http://bugs.winehq.org/show_bug.cgi?id=29168 what is still present in wine-1.5.18 .
KUSER_SHARED_DATA_18 is tested and applies correctly here for wine-1.5.18
Pre-requisits are unchanged, needs vcrun2008 and d3dx9
http://bugs.winehq.org/show_bug.cgi?id=29168
eroen@eroen.eu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eroen@eroen.eu
--- Comment #237 from eroen@eroen.eu 2012-12-07 16:05:03 CST --- (In reply to comment #236)
Created attachment 42706 [details] KUSER_SHARED_DATA_18 against -> wine-1.5.18
I can confirm this (unsettlingly heavily) modified patch applies cleanly to wine-1.5.19 (with the patches Gentoo shipped for 1.5.18). Cursory testing shows swtor starting and running similar to under 1.5.8 with previous patch.
http://bugs.winehq.org/show_bug.cgi?id=29168
gregor gregor.binder@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gregor.binder@gmx.net
http://bugs.winehq.org/show_bug.cgi?id=29168
Andy Wilkinson andy@wtribe.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andy@wtribe.com
--- Comment #238 from Andy Wilkinson andy@wtribe.com 2013-01-30 21:30:00 CST --- (In reply to comment #236)
Created attachment 42706 [details] KUSER_SHARED_DATA_18 against -> wine-1.5.18
This patch applies to wine-1.5.22, but SWTOR appears to hang at the loading screen nonetheless.
Here's some pretty vanilla wine output. Let me know if you want it run differently:
http://bugs.winehq.org/show_bug.cgi?id=29168
Alex alexzk@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexzk@mail.ru
--- Comment #239 from Alex alexzk@mail.ru 2013-03-15 14:26:54 CDT --- Game still suffers from pereodic lags.
If you will open CPU graph over time on 2nd monitor, you will see that there are "downpeaks" when lagg happens. CPU usage drops from 80% on my machine to 20% and inside game fps drops from 40 to 0-5. Looks like game takes sleep() somewhere atm.
So I decided to try 1st patch from here (proof of conecept). It gave me downpeaks like each couple seconds. Dedicated thread (last patch) gives downpeaks each 45 seconds about.
So I combined them: dedicated thread + critical section: thread.c: static void update_shared_data_time(void) ->>> void update_shared_data_time(void)
and
critsection.c
extern struct _KUSER_SHARED_DATA *user_shared_data; extern void update_shared_data_time(void); ....... NTSTATUS WINAPI RtlEnterCriticalSection( RTL_CRITICAL_SECTION *crit ) { update_shared_data_time();
That looks much better. I don't see downpeaks last 30 minutes at all. May be somebody smarter can improve idea and put more calls to function somewhere else ? Also it works with 1.5.20 couldn't run with 1.5.25.
http://bugs.winehq.org/show_bug.cgi?id=29168
JR zorael@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zorael@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
Forrest Loomis cybercyst@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cybercyst@gmail.com
--- Comment #240 from Forrest Loomis cybercyst@gmail.com 2013-04-09 16:40:08 CDT --- Since wine 1.5.25 I was getting "fixme:dbghelp:elf_search_auxv can't find symbol in module" in the console after I logged in with my username and password and when the loading spinner would lock on the loading screen.
With 1.5.24 I could use swtor_fix.exe from this thread http://ubuntuforums.org/showthread.php?t=2097068 along with stock wine to get SW:TOR running up to the character selection screen.
After performing a git bisect, I found the change was in this commit: cfec148b8baeb86ee9d775f9cf527b80e043f5a4 by Piotr Caban piotr@codeweavers.com.
Also, reverting the latest git revision with the following command: "git show cfec148b8baeb86ee9d775f9cf527b80e043f5a4 | patch -p1 -R" yields a working wine installation.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #241 from julusp@gmail.com 2013-04-10 08:49:58 CDT --- (In reply to comment #240)
Also, reverting the latest git revision with the following command: "git show cfec148b8baeb86ee9d775f9cf527b80e043f5a4 | patch -p1 -R" yields a working wine installation.
If I am reading it correctly, setting msvcp90 to native in winecfg would do after that commit.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #242 from Forrest Loomis cybercyst@gmail.com 2013-04-10 09:04:19 CDT --- Yeah, I had msvcp90 set to native and it was crashing as well. I have that dll override deleted now and it seems to launch without vcrun2008 from winetricks as well.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #243 from Alex alexzk@mail.ru 2013-04-10 11:21:12 CDT --- Btw, game is going smoother with that exe as for me than using wine patch.
I suggest to run fix as next:
wine swtor_fix.exe > /dev/null 2> /dev/null < /dev/null & disown
so you don't need to open 2nd console.
http://bugs.winehq.org/show_bug.cgi?id=29168
StewVed stewved@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stewved@gmail.com
--- Comment #244 from StewVed stewved@gmail.com 2013-07-18 13:33:06 CDT --- This bug is still here for everyone playing Star Wars: The Old Republic even using the latest Wine (1.6 RC5)
Ubuntu 13.04 64-bit using env WINEARCH=win32 because the game needs it, along with: winetricks vcrun2008 d3dx9 msls31 Also the swtor_fix.exe 'patch' thing for this Bug (#29168)
my launcher to run the game - to workaround Bug #31186 and also put the password directly into the clipboard on loading the launcher :D (Needs xsel installed) --------------------------- #!/bin/bash cd ~/wines && env WINEARCH=win32 WINEPREFIX=~/wines/swtor wine "swtor_fix.exe" & echo -n 'YourPasswordHere' | xsel -i -b & xrandr -s 800x600 cd 'Where You installed the game' && env WINEARCH=win32 WINEPREFIX=~/wines/swtor wine launcher.exe xrandr -s 1280x1024 wait
killall swtor_fix.exe -----------------------------
Download the game for free from http://www.swtor.com/ - so anyone can test this.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #245 from hash HASH.DuOrden@gmail.com 2013-07-18 15:29:18 CDT --- (In reply to comment #244)
This bug is still here for everyone playing Star Wars: The Old Republic even using the latest Wine (1.6 RC5)
Ubuntu 13.04 64-bit using env WINEARCH=win32 because the game needs it, along with: winetricks vcrun2008 d3dx9 msls31 Also the swtor_fix.exe 'patch' thing for this Bug (#29168)
Sadly but swtor_fix.exe isn't working for me, it just hangs with "Waiting for tread to end." for eternity not doing anything. Still have to use last wine build with which patches from here still working.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #246 from StewVed stewved@gmail.com 2013-07-18 15:45:38 CDT --- (In reply to comment #245)
Sadly but swtor_fix.exe isn't working for me, it just hangs with "Waiting for tread to end." for eternity not doing anything. Still have to use last wine build with which patches from here still working.
swtor_fix.exe has to be on a completely seperate thread to the game, and does nothing until SWTOR.exe has been called by the Launcher when you press 'Play'.
Methods to try: # Use the single ampersand & at the end of it to make the command on a seperate 'thread'. my all-in-one launcher does that :)
# Just use a completely seperate terminal and kick it up in there: Open a new terminal and put in: cd [where it is saved] && env WINEARCH=win32 WINEPREFIX=~/wines/swtor wine "swtor_fix.exe"
it will then say waiting for threads... then open a NEW terminal and start the launcher in that one. Once logged in and you press play, the launcher closes and calls swtor.exe (with a load of parameters). If you check back with the terminal that has swtor_fix.exe, it should now say a PID found or somert.
Please also be aware to run swtor_fix.exe in 32-bit along with the game if you are using a 64-bit OS :D
Hope this helps!
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #247 from hash HASH.DuOrden@gmail.com 2013-07-18 16:46:10 CDT --- (In reply to comment #246)
(In reply to comment #245)
swtor_fix.exe has to be on a completely seperate thread to the game, and does nothing until SWTOR.exe has been called by the Launcher when you press 'Play'.
With my script, I made to run games with WINE, swtor_fix.exe is runned at the same time as launcher.exe as a separate process. It echoes in terminal, in my case in log file: Waiting for swtor...
Methods to try: # Use the single ampersand & at the end of it to make the command on a seperate 'thread'. my all-in-one launcher does that :)
# Just use a completely seperate terminal and kick it up in there: Open a new terminal and put in: cd [where it is saved] && env WINEARCH=win32 WINEPREFIX=~/wines/swtor wine "swtor_fix.exe"
I don't need that: env WINEARCH=win32 as my linux is 32 bit.
it will then say waiting for threads... then open a NEW terminal and start the launcher in that one. Once logged in and you press play, the launcher closes and calls swtor.exe (with a load of parameters). If you check back with the terminal that has swtor_fix.exe, it should now say a PID found or somert.
Yes, as swtor.exe starts swtor_fix.exe logs: ---------------- Found, PID: 114 Waiting for threads to end.. ^^^^^^^^^^^^^^^^ And thats all it dose.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #248 from StewVed stewved@gmail.com 2013-07-18 16:55:08 CDT --- (In reply to comment #247)
Yes, as swtor.exe starts swtor_fix.exe logs:
Found, PID: 114 Waiting for threads to end.. ^^^^^^^^^^^^^^^^ And thats all it dose.
yeah... that is all swtor_fix.exe does in the Terminal until you exit the game.
It should allow you to get to the Character selection screen once the game loads up - which can take a few minutes: After pressing 'play' on the Launcher, the game itself takes some 40+ seconds before the game's loading screen appears on my computer; before that, it seems as if nothing is happening at all. After that, it takes about another minute to load up the Character screen. If you see that, swtor_fix.exe has done it's job :)
The game should run fine from then on - until you hover your mouse over something that has a popup :D
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #249 from hash HASH.DuOrden@gmail.com 2013-07-18 17:19:06 CDT --- (In reply to comment #248)
(In reply to comment #247)
Yes, as swtor.exe starts swtor_fix.exe logs:
.....
yeah... that is all swtor_fix.exe does in the Terminal until you exit the game.
..... No char selection screen here, I can wait forever and nothing gonna happen.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #250 from StewVed stewved@gmail.com 2013-07-18 17:39:22 CDT --- (In reply to comment #249)
No char selection screen here, I can wait forever and nothing gonna happen.
Are you using the latest Wine (1.6 RC5 at time of writing) with no extra patches built in it, and a dedicated wineprefix just for SWTOR where you have put in DirectX 9 and VCrun2008?
not sure if it works with 1.4.1 for instance... also maybe try the Repair Installation in the Launcher's settings - maybe a file is corrupt.
Once, I was fooling with my launcher and didn't have the fix running. it did just as you'd expect - only the loading screen with the little spinning icon spinning so you know it hasn't crashed. Luckily my terminal history had the swtor_fix.exe command in it, so I pressed ctrl+alt+t and pressed the up arrow, then enter (I couldn't see, but that brought up a new terminal, then the up arrow rewrote the last command, then enter executed it) It worked and within a couple of seconds the character screen came up :D
If your loading screen icon (Botton-Right) is not spinning, I think I had that when I forgot to put DX9 and vcrun2008 into the SWTOR wineprefix .. maybe that was where I put in msls31 thinking about it - no idea where that came from otherwise... lol.
That is the end of my knowledge on SW:TOR, and I sincerely hope you get the game up and running... and the Wine Dev geniuses fix our issues in the future :D
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #251 from Marco Di Fresco marco.difresco@gmail.com 2013-07-20 18:03:36 CDT --- Hi, I have Gentoo 64 bits and swtor_fix.exe stopped working (meaning it doesn't help - technically it keep being executed without errors) since Wine >= 1.5.25 and the following emul-linux-x86-* (I don't remember which one are required by Wine): app-emulation/emul-linux-x86-baselibs-20130224 app-emulation/emul-linux-x86-soundlibs-20130224 app-emulation/emul-linux-x86-gtklibs-20130224 app-emulation/emul-linux-x86-qtlibs-20130224 app-emulation/emul-linux-x86-sdl-20130224 app-emulation/emul-linux-x86-xlibs-20130224 app-emulation/emul-linux-x86-db-20130224 app-emulation/emul-linux-x86-medialibs-20130224 app-emulation/emul-linux-x86-opengl-20130224
I don't know if it is a regression with Wine itself or with those emul-linux-x86-* since such 20130224 version is required by Wine >= 1.5.25. Wine <= 1.5.24 required the version 20121202 of those libs and in this case swtor_fix.exe worked correctly.
For sometime I have been able to stay with Wine 1.5.24 and those lib at 20121202 version by masking the updates, but since few weeks ago other programs on my system started to require the 20130224 version to be updated so it wasn't feasible to keep the old version. Of course since then I couldn't play SWTOR (it wasn't a problem until this evening since I was on temporary break from the game).
I am no expert in debugging, but if I can help just tell me what test I have to do.
P.S.: I don't know if it helps but Wine >= 1.5.25 and those libs on version 20130224 give me problems also with Lord of the Rings Online: it get frequently terminated without errors.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #252 from Alex alexzk@mail.ru 2013-07-21 02:38:09 CDT --- Just install PlayOnLinux, it can keep couple wines, for example I have like 10 versions for different games. And yes, last good for swtor is 1.5.25, laters I tried randomly do not work.
http://bugs.winehq.org/show_bug.cgi?id=29168
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #253 from joaopa jeremielapuree@yahoo.fr 2013-07-21 05:53:51 CDT --- If it is a regression, regression testing would be more profitable than adding more reports.
http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #254 from Marco Di Fresco marco.difresco@gmail.com 2013-07-21 07:24:50 CDT --- Tried with PlayOnLinux and Wine 1.5.24 and still I can't get to the characters screen.
I may assume then that it is not a regression with Wine itself, but it is those app-emulation/emul-linux-x86-*-20130224 that nullify the benefits of swtor_fix.exe.
Unfortunately, as I said, other programs beside Wine started to require the 20130224 version of those libs so I cannot stay with the previous version.
I have no idea how to debug those app-emulation/emul-linux-x86-* to find the root of the problem. Any idea?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #255 from Alex alexzk@mail.ru 2013-07-21 09:19:42 CDT --- Maybe try to apply patch directly to wine (see all those above). If it works - than wine has somewhere data protection, so internal exe can't modify shared memory (maybe it creates new memory block for each exe now), if patch doesn't go too - then need search for regression.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #256 from Alex alexzk@mail.ru 2013-07-21 09:23:58 CDT --- Also did you try 32 bit wine? I had to use chroot 32 to apply patches and compile it, so I assume game won't run using pure 64 bit wine :/
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #257 from Marco Di Fresco marco.difresco@gmail.com 2013-07-22 05:16:16 CDT --- I'll try to compile it manually.
Still, on PlayOnLinux I did tried to use the pre-compiled 32 bit version of Wine 1.5.24, but it didn't work and the system (meaning out of Gentoo's package manager) Wine 1.5.24 at the time was actually the 64 bit version with 32 bit support (in fact when I originally created the Wine prefix for TOR I had to use export WINEARCH=win32 first, otherwise Wine would have created a 64 prefix like the others I have on my system).
I'll let you know when I have finished the compiling test.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #258 from Marco Di Fresco marco.difresco@gmail.com 2013-07-22 08:35:41 CDT --- I'll try to compile it manually.
Still, on PlayOnLinux I did tried to use the pre-compiled 32 bit version of Wine 1.5.24, but it didn't work and the system (meaning out of Gentoo's package manager) Wine 1.5.24 at the time was actually the 64 bit version with 32 bit support (in fact when I originally created the Wine prefix for TOR I had to use export WINEARCH=win32 first, otherwise Wine would have created a 64 prefix like the others I have on my system).
I'll let you know when I have finished the compiling test.
UPDATE: When I try to apply the patch, I get the following error: patching file dlls/ntdll/Makefile.in Hunk #1 FAILED at 2. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/Makefile.in.rej patching file dlls/ntdll/thread.c Hunk #3 FAILED at 265. Hunk #4 succeeded at 364 (offset 7 lines). 1 out of 4 hunks FAILED -- saving rejects to file dlls/ntdll/thread.c.rej
I tried with both the latest version and 1.5.24
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #259 from Marco Di Fresco marco.difresco@gmail.com 2013-07-22 08:40:23 CDT --- Sorry for the repeated block of text.
When I tried to post a new comment with the patch error, the previous text was already included in the writing area and I thought that the website was making me editing the previous comment by default.
P.S.: just for the sake of curriosity, why the patch isn't already included on the Wine source code itself?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #260 from Alex alexzk@mail.ru 2013-07-22 08:47:40 CDT --- I think latest patch file itself was for 1.5.18 or even below (so it failes with latest changes), you can open it to compare, you will need add 1 static function to thread.c which updates timings into KUSER_SHARED_DATA, add custom thread which will call this function and add creation of this thread to initialization.
Not too hard to make it manually if you want for latest wines.
Just copy-paste it from tracker to ur sources.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #261 from Marco Di Fresco marco.difresco@gmail.com 2013-07-23 14:12:16 CDT --- Tried directly with 1.5.18 and I correctly applied the patch and compiled. Tor now correctly launch.
I kept the modified 1.5.18 on its own source folder so I can use it for Tor and on the same time still have the latest wine system-wide automatically managed by the package manager for any other program; ergo the best of both worlds.
Thanks Alex for your support.
The curiosity still remain on why the patch isn't already integrated on Wine; anyone knows?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #262 from Alex alexzk@mail.ru 2013-07-23 14:52:00 CDT --- I think because patch itself is dumb :/ Nobody wants to update timer's counter using separated thread. Idea must be revised by someone with deep wine's knowledge and he must to proper update when all timings are done (my opinion).
My guess was to make exe-debugger, which puts HW breakpoints at this address on access and updates it when SWTOR tries to read it. But well, i'm lazy too :D
----------- Also you can try now just exe with NOT patched 1.5.18 - it should go. And if it is, this means latest wines changed something related to shared memory:
1. No shares - each exe gets own copy. 2. Enchanced Security - exe can't modify "kernel" memory. 3. Most unlikelly - address of the share is changed.
As usually while it goes on 1.5.18 - who cares :)
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #263 from Marco Di Fresco marco.difresco@gmail.com 2013-07-24 06:41:18 CDT --- I did some test:
1.5.18 - Unpatched and without swtor_fix.exe it cannot run the game as it stay stuck to the loading screen (the cog on the bottom right corner is spinning). - Both KUSER_SHARED_DATA and swtor_fix.exe (used alternatively to each other) solve the problem.
1.5.19 - Unpatched and without swtor_fix.exe it cannot run the game as it stay stuck to the loading screen (the cog on the bottom right corner is spinning). - KUSER_SHARED_DATA cannot longer be applied; - swtor_fix.exe solve the problem.
1.5.24 - Unpatched and without swtor_fix.exe it cannot run the game as it stay stuck to the loading screen (the cog on the bottom right corner is spinning). - KUSER_SHARED_DATA cannot longer be applied; - swtor_fix.exe solve the problem.
1.5.25 - Unpatched and without swtor_fix.exe it cannot run the game as it stay stuck to the loading screen (the cog on the bottom right corner is NOT spinning). - KUSER_SHARED_DATA cannot longer be applied; - swtor_fix.exe is loaded without errors, but no longer solve the issue.
1.6 (LATEST) - Unpatched and without swtor_fix.exe it cannot run the game as it stay stuck to the loading screen (the cog on the bottom right corner is NOT spinning). - KUSER_SHARED_DATA cannot longer be applied; - swtor_fix.exe is loaded without errors, but no longer solve the issue.
As the problems in 1.5.25 and 1.6 appear to be identical, I may guess that no version in between offer any difference; unless of course some official Wine developer come out pointing a specific version that was supposed to work differently, so in that case we can do a regression test.
Until the bug is officially fixed, or at least until there is a positive change toward it, to play the game and still keep the latest Wine version system-wide, I suggest to: - Download the source code for Wine <= 1.5.24 (or <= 1.5.18 if you want to use KUSER_SHARED_DATA patch instead of swtor_fix.exe); - Apply the KUSER_SHARED_DATA patch (only if you have chosen the version <= 1.5.18 and you don't want to use swtor_fix.exe); - Either leave the compiled version on its own source code (by NOT issuing 'make install') or go back to the ./configure and add '--prefix=/opt/[whatever directory that doesn't conflict with system-wide wine]') - Make a script (or modify if you already use one) that call the custom Wine version by absolute path (and eventually execute swtor_fix.exe of you opted for that fix).
P.S.: as I was posting this it came to my mind that a regression test can be done between 1.5.25 and 1.5.24 to see what is breaking swtor_fix.exe; since it would take a lot of time and since swtor_fix.exe is an unofficial fix anyway, is it worth doing it?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #264 from Alex alexzk@mail.ru 2013-07-24 09:25:55 CDT --- Well, for the start you could add "printf" to each 2nd line into swtor_fix source and print out everything, every value, every line executed (like debugger). And check/compare where is error coming. It is also possible it will not though. This will mean exe is "sandboxed" against other exes.
It will be a start to find changings.
http://bugs.winehq.org/show_bug.cgi?id=29168
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #265 from Dan Kegel dank@kegel.com 2013-07-24 10:58:24 CDT --- Yes, finding the commit that broke things would probably be illuminating.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #266 from Forrest Loomis cybercyst@gmail.com 2013-07-24 11:29:00 CDT --- (In reply to comment #265)
Yes, finding the commit that broke things would probably be illuminating.
Guys, please look at comment #240. I did the git bisect and found the commit that was breaking loading for me. Reverting that commit also leads to a SWTOR that will work.
Can anyone confirm that?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #267 from Forrest Loomis cybercyst@gmail.com 2013-07-24 12:18:10 CDT --- (In reply to comment #265)
Yes, finding the commit that broke things would probably be illuminating.
Guys, please look at comment #240. I did the git bisect and found the commit that was breaking loading for me. Reverting that commit also leads to a SWTOR that will work.
Can anyone confirm that?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #268 from Alex alexzk@mail.ru 2013-07-24 12:25:54 CDT --- SWTOR uses vc runtimes, it is possible that it will not work with "built-in" as that commit sets to use.
Intresting, maybe this KSHARED_USER_DATA should be done inside those runtimes? :/ Here is that commit:
commit cfec148b8baeb86ee9d775f9cf527b80e043f5a4 Author: Piotr Caban piotr@codeweavers.com Date: Mon Feb 18 10:26:17 2013 +0100
msvcp90: Prefer builtin version.
diff --git a/dlls/msvcp90/msvcp90_main.c b/dlls/msvcp90/msvcp90_main.c index cb6377f..7a7aafe 100644 --- a/dlls/msvcp90/msvcp90_main.c +++ b/dlls/msvcp90/msvcp90_main.c @@ -84,8 +84,6 @@ BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
switch (fdwReason) { - case DLL_WINE_PREATTACH: - return FALSE; /* prefer native version */ case DLL_PROCESS_ATTACH: init_cxx_funcs(); init_lockit();
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #269 from Dan Kegel dank@kegel.com 2013-07-24 12:26:54 CDT --- Oh, thanks. The commit was http://www.winehq.org/pipermail/wine-cvs/2013-February/093779.html
Marco, does setting msvcp90.dll to native (e.g. 'winetricks msvcp90=native') help?
http://bugs.winehq.org/show_bug.cgi?id=29168
tonedef wine@causal.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|wine@causal.ca |
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #270 from Marco Di Fresco marco.difresco@gmail.com 2013-07-24 16:57:19 CDT --- (In reply to comment #269)
Oh, thanks. The commit was http://www.winehq.org/pipermail/wine-cvs/2013-February/093779.html
Marco, does setting msvcp90.dll to native (e.g. 'winetricks msvcp90=native') help?
Yes it does. I am trying with the latest Wine 1.6 (without KUSER_SHARED_DATA patch, but with swtor_fix.exe) and I can correctly get to the characters screen and login into the game.
Thanks.
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #271 from Alex alexzk@mail.ru 2013-07-24 17:29:46 CDT --- wow, wine 1.6.rc5 gives like 3x FPS on fleet compairing to older...cool :)
So to recup:
swtor_fix.exe AND winetricks msvcp90=native
to make it run
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #272 from Alex alexzk@mail.ru 2013-07-24 17:45:25 CDT --- Okey ...just got BAD sound using 1.6.rc5 ...it's like "shaking" and drop to 5 fps on voidstar wz, possibly it is problem of WZ/game itself. It was such long ago even on windows. I must say with older wine I had to restart game after VS WZ time-to-time because it became too laggy.
Can you guys pay attention on it?
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #273 from Alex alexzk@mail.ru 2013-07-24 18:23:23 CDT --- Looks like it is bug in:
winealsa+pulseaudio+kmix+usb headset.. even "test sound" button keeps draining memory, switched device from "analog" to "digital" output and works for now :/ So nvm above comment for this one :)
http://bugs.winehq.org/show_bug.cgi?id=29168
b bdkelsey@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|bdkelsey@hotmail.com |
http://bugs.winehq.org/show_bug.cgi?id=29168
Bjoern Bidar theodorstormgrade@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |theodorstormgrade@googlemai | |l.com
http://bugs.winehq.org/show_bug.cgi?id=29168
Alan Jackson ajackson1972@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ajackson1972@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #274 from eroen eroen@faith.eroen.eu --- Created attachment 47704 --> http://bugs.winehq.org/attachment.cgi?id=47704 KUSER_SHARED_DATA_18 for >=wine-1.7.1
This issue is still present in current SWTOR with wine-1.7.13.
Find attached the earlier patch merged with and regenerated from wine-1.7.13, should apply since wine-1.7.1.
http://bugs.winehq.org/show_bug.cgi?id=29168
Michael Bond mikejbond@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|mikejbond@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=29168
chad.g9@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chad.g9@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=29168
roger@mailinator.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roger@mailinator.com
--- Comment #275 from roger@mailinator.com --- Is this basically duplicate?
https://bugs.winehq.org/show_bug.cgi?id=13398
https://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #276 from silentz0r d.misdanitis@gmail.com --- (In reply to roger from comment #275)
Is this basically duplicate?
SWTOR and SWKOTOR are two different games.
https://bugs.winehq.org/show_bug.cgi?id=29168
michal harustiak.michal@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |harustiak.michal@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=29168
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=29168
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net Summary|Star Wars: The Old Republic |Multiple games and |game client hangs at intro |applications need realtime |splash |updates to KSYSTEM_TIME | |members in | |KUSER_SHARED_DATA (Star | |Wars: The Old Republic game | |client, GO 1.4+ runtime)
--- Comment #277 from Anastasius Focht focht@gmx.net --- Hello folks,
I'm refining the summary here since there exist multiple games/applications relying on this "feature" (= collect dupes here).
Obviously still present as of Wine 1.7.43
Regards
https://bugs.winehq.org/show_bug.cgi?id=29168
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leonbogaert+winehq@gmail.co | |m
--- Comment #278 from Anastasius Focht focht@gmx.net --- *** Bug 38272 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=29168
Joe Terwilliger jolyon@nixbox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jolyon@nixbox.com
--- Comment #279 from Joe Terwilliger jolyon@nixbox.com --- Created attachment 51589 --> https://bugs.winehq.org/attachment.cgi?id=51589 1.7.44 thread.c patch, OS X compatible
Possibly why the preexisting patches have not been accepted is clock_gettime and clock_nanosleep are not directly supported in OS X. I am not sure why the clock_gettime nor the update_time_spec routine since it doesn't seem to be used at all.
I've trimmed the fat and converted the sleep / update loop back to nanosleep and this patch is working fine for me on 1.7.31 and 1.7.44 on OS X 10.9.5 and 10.10.3
Patch was tested running Star Wars: The Old Republic latest versions (without swtorfix.exe running, of course.)
Could someone test on Linux?
https://bugs.winehq.org/show_bug.cgi?id=29168
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #280 from leonbogaert+winehq@gmail.com --- When Ubuntu fixes it's package conflict (https://bugs.launchpad.net/ubuntu/+source/mesa-lts-utopic/+bug/1424059) needed for building wine I'll test it.
https://bugs.winehq.org/show_bug.cgi?id=29168
Qian Hong fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=29168
Adam Bolte abolte@systemsaviour.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |abolte@systemsaviour.com
https://bugs.winehq.org/show_bug.cgi?id=29168
EoD EoD@xmw.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |EoD@xmw.de
--- Comment #281 from EoD EoD@xmw.de --- (In reply to Joe Terwilliger from comment #279)
Created attachment 51589 [details] 1.7.44 thread.c patch, OS X compatible
Possibly why the preexisting patches have not been accepted is clock_gettime and clock_nanosleep are not directly supported in OS X. I am not sure why the clock_gettime nor the update_time_spec routine since it doesn't seem to be used at all.
I've trimmed the fat and converted the sleep / update loop back to nanosleep and this patch is working fine for me on 1.7.31 and 1.7.44 on OS X 10.9.5 and 10.10.3
Patch was tested running Star Wars: The Old Republic latest versions (without swtorfix.exe running, of course.)
Could someone test on Linux?
I tested it on Gentoo with kernel 4.2.5 and wine 1.7.45: It fixes the problem with launching swtor (without swtor_fix.exe)!
https://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #282 from EoD EoD@xmw.de --- Also the GO test program from bug 38272 does work with the new patch.
https://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #283 from leonbogaert+winehq@gmail.com --- I used the patch on HEAD on Ubuntu 14.04 and the Go test program outputs the correct information now.
Is there something that can be done to get the patch accepted?
https://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #284 from Andrew Eikum aeikum@codeweavers.com --- I haven't been following this issue closely. There's a great thread about this here:
https://www.winehq.org/pipermail/wine-devel/2012-March/094788.html
It sounds like there was no solution found that wouldn't potentially break other applications.
wine-staging has some patches in this area that take a different approach. They don't appear to have been submitted upstream.
https://github.com/wine-compholio/wine-staging/tree/master/patches/ntdll-Use...
It's not clear to me if those patches are intended fix this issue.
https://bugs.winehq.org/show_bug.cgi?id=29168
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@fds-team.de
--- Comment #285 from Michael Müller michael@fds-team.de --- The reason no suitable approach was found so far is not that it could break other applications, but instead that it introduces overhead for all apps. This could cause some slowdown.
The Staging patch is unrelated to this bug report.
https://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #286 from EoD EoD@xmw.de --- If it causes only overhead, can't it be possible to enable this feature "on demand" as a fallback?
Something like: If the error message has been hit several time, enable the feature.
https://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #287 from Joe Terwilliger jolyon@nixbox.com --- I can attest that the wine-staging team has implemented some of the kshared data routine, but it is incomplete and does not solve the problem the latest patch here fixed. I have patched it successfully a few times in the wine-staging releases, but it has fallen out of date due to some other extreme restructuring of that source file by the wine-staging team.
I fail to see how the latest patch here would significantly impact performance as the Windows subsystem already is apparently performing this same operation at some level, possibly in the network layer? I did experiment in raising the refresh interval wondering if that could improve performance, but it breaks the fix which leads me to believe the original code for this patch is somehow derived directly from the Windows source or compiled code. The only thing I can think of this not being accepted is this is perhaps not the right location for this particular patch.
At any rate, I agree that this could be an opt-in performance patch only enabled if specified via winecfg settings or some other switch on wine startup.
https://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #288 from Sebastian Lackner sebastian@fds-team.de --- (In reply to EoD from comment #286)
If it causes only overhead, can't it be possible to enable this feature "on demand" as a fallback?
Something like: If the error message has been hit several time, enable the feature.
Imho that is the only way to do it "properly", but its much more complicated. There is no error message or specific code path to know if an application depends on it. Its just a memory access, and installing exception handlers and/or write watches seems a bit ugly.
(In reply to Joe Terwilliger from comment #287)
I can attest that the wine-staging team has implemented some of the kshared data routine, but it is incomplete and does not solve the problem the latest patch here fixed.
As already mentioned, the couple of Wine Staging patches in the same area are unrelated, and for a different issue.
I have patched it successfully a few times in the wine-staging releases, but it has fallen out of date due to some other extreme restructuring of that source file by the wine-staging team.
Not sure which "extreme restructuring" you mean, but rebasing any of the proposed patches on top of Wine Staging is absolutely no problem. Ask me privately (email or IRC) if you need help with that.
I fail to see how the latest patch here would significantly impact performance as the Windows subsystem already is apparently performing this same operation at some level, possibly in the network layer?
The difference is that Windows doesn't need a separate thread for it, its updated by the kernel directly. On Wine, such a refresh timer would run in each process. Also in those where its absolutely unnecessary, like Wine internal processes (explorer.exe, ... and so on).
I did experiment in raising the refresh interval wondering if that could improve performance, but it breaks the fix which leads me to believe the original code for this patch is somehow derived directly from the Windows source or compiled code.
It works totally different on Windows, there is nothing to "copy" from Windows sources. Please note that the Wine patch submission rules also don't allow to look at Windows sources, so if anybody did that, it would mean that the patch can no longer be accepted.
The only thing I can think of this not being accepted is this is perhaps not the right location for this particular patch.
At any rate, I agree that this could be an opt-in performance patch only enabled if specified via winecfg settings or some other switch on wine startup.
If possible, extra winecfg settings or registry keys should usually avoided.
https://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #289 from Joe Terwilliger jolyon@nixbox.com --- Thanks Sebastian for clearing that up! The situation regarding this fix has been puzzling many of us for some ~~time~~ years.
I honestly have no idea how the source patch for this was derived, I merely cleaned it up and made it workable on OSX. My comment was based on probably incorrect assumptions I came to whilst adjusting the parameters in final tests.
https://bugs.winehq.org/show_bug.cgi?id=29168
Jellemoisson@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Jellemoisson@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=29168
Thomas Kowaliczek linuxdonald@posteo.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |linuxdonald@posteo.de
https://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #290 from Bjoern Bidar theodorstormgrade@googlemail.com --- Created attachment 54531 --> https://bugs.winehq.org/attachment.cgi?id=54531 updated patch on top of latest wine-staging
I updated the patch on top of the latest wine staging patches.
https://bugs.winehq.org/show_bug.cgi?id=29168
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
--- Comment #291 from Robert Walker bob.mt.wya@gmail.com --- Created attachment 55748 --> https://bugs.winehq.org/attachment.cgi?id=55748 wine-1.9.19-ntdll_thread_update_shared_data_time.patch
I've updated the original patch for Wine 1.9.19 (Staging).
Re-factored and tidied up the code a bit to conform to Wine coding conventions. Now has a shift and multiply implementation of the divide by 10000 computation. Well it might be more efficient than gcc - who knows?
Using Gentoo with Wine-Staging 1.9.19. I tested the latest build of SWTOR - appears to do the job - as well as swtor_fix.exe anyway ... Gameplay doesn't appear to be too affected by the constant (15ms) thread wakeups!!
https://bugs.winehq.org/show_bug.cgi?id=29168
juju96@mac.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juju96@mac.com
--- Comment #292 from juju96@mac.com --- Created attachment 56054 --> https://bugs.winehq.org/attachment.cgi?id=56054 Install Application
This is the install application for Star Wars - The Old Republic.
https://bugs.winehq.org/show_bug.cgi?id=29168
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=29168
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dmitry@baikal.ru, | |erich.e.hoover@wine-staging | |.com Status|NEW |STAGED Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/ntdll-User_Sha | |red_Data
https://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #293 from Joe Terwilliger jolyon@nixbox.com --- Latest Staging 2.8 build fixes the SWTOR client login bug for me on MacOS; SWTORFIX is no longer needed !! Thanks Christian Lackner for the effort!
https://bugs.winehq.org/show_bug.cgi?id=29168
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|spetreolle@yahoo.fr |
https://bugs.winehq.org/show_bug.cgi?id=29168
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ntdll Staged patchset|https://github.com/wine-com |https://github.com/wine-sta |pholio/wine-staging/tree/ma |ging/wine-staging/tree/mast |ster/patches/ntdll-User_Sha |er/patches/ntdll-User_Share |red_Data |d_Data Summary|Multiple games and |Multiple games and |applications need realtime |applications need realtime |updates to KSYSTEM_TIME |updates to KSYSTEM_TIME |members in |members in |KUSER_SHARED_DATA (Star |KUSER_SHARED_DATA (Star |Wars: The Old Republic game |Wars: The Old Republic game |client, GO 1.4+ runtime) |client, Blizzard games: | |Diablo III, StarCraft II, | |WoW, Overwatch, GO 1.4+ | |runtime) Keywords| |obfuscation
--- Comment #294 from Anastasius Focht focht@gmx.net --- Hello folks,
obviously still present. Updating some fields:
* corrected link to Wine-Staging patchset * added more games affected by this to summary
Staging has some patch dependencies on https://github.com/wine-staging/wine-staging/blob/master/patches/ntdll-User_...
* Depends: ntdll-Hide_Wine_Exports * Depends: ntdll-x86_64_ExceptionInformation
These are not needed for the apps/games listed here.
I've tested/debugged with minimal patchsets from existing tickets and this one against vanilla Wine 3.4
I think the current maintainers of Wine-Staging, Alistair and Zebediah should talk with Alexandre about a feasible solution. A number of major games, especially from Blizzard require this feature to work. People will stick to Wine-Staging to be able to play their games with result that they run all their other stuff (apps) with Wine-Staging too.
$ wine --version wine-3.4
Regards
https://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #295 from Bjoern Bidar theodorstormgrade@googlemail.com --- Since when is this needed for wow? This about the KUSER_SHARED_DATA feature needed by games like swtor. Wow needs the exception fixes that this patch depends on it's current ( older patches didn't depend on this).
https://bugs.winehq.org/show_bug.cgi?id=29168
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #296 from Zebediah Figura z.figura12@gmail.com --- (In reply to Anastasius Focht from comment #294)
Hello folks,
obviously still present. Updating some fields:
- corrected link to Wine-Staging patchset
- added more games affected by this to summary
Staging has some patch dependencies on https://github.com/wine-staging/wine-staging/blob/master/patches/ntdll- User_Shared_Data/definition
- Depends: ntdll-Hide_Wine_Exports
- Depends: ntdll-x86_64_ExceptionInformation
These are not needed for the apps/games listed here.
The dependencies are basically to make sure that all patches can be applied/compiled at once, so sometimes patchsets have 'dependencies' that aren't actually necessary.
I've tested/debugged with minimal patchsets from existing tickets and this one against vanilla Wine 3.4
I think the current maintainers of Wine-Staging, Alistair and Zebediah should talk with Alexandre about a feasible solution. A number of major games, especially from Blizzard require this feature to work. People will stick to Wine-Staging to be able to play their games with result that they run all their other stuff (apps) with Wine-Staging too.
It would indeed be nice if someone could come up with a feasible solution to this problem. I doubt that person will be me, however. Besides which there are many other widely-used staging patches that will be much easier to upstream.
https://bugs.winehq.org/show_bug.cgi?id=29168
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Multiple games and |Multiple games and |applications need realtime |applications need realtime |updates to KSYSTEM_TIME |updates to KSYSTEM_TIME |members in |members in |KUSER_SHARED_DATA (Star |KUSER_SHARED_DATA (Star |Wars: The Old Republic game |Wars: The Old Republic game |client, Blizzard games: |client, Blizzard games: |Diablo III, StarCraft II, |32-bit Diablo III, 32-bit |WoW, Overwatch, GO 1.4+ |WoW, Overwatch, GO 1.4+ |runtime) |runtime)
--- Comment #297 from Anastasius Focht focht@gmx.net --- Hello Bjoern,
--- quote --- Since when is this needed for wow? This about the KUSER_SHARED_DATA feature needed by games like swtor. Wow needs the exception fixes that this patch depends on it's current ( older patches didn't depend on this). --- quote ---
I downloaded multiple Blizzard games: the 64-bit and 32-bit variants if available. For testing I used a 64-bit WINEPREFIX with full install and a helper 32-bit WINEPREFIX with has symlinks to allow testing both versions (32-bit and 64-bit) if present.
I should have been more explicit though, the are some differences when 32-bit or 64-bit version is used. Some of Blizzard's major titles/games seem to share parts of the anti-cheat/debugging code.
=== Overwatch (64-bit): ===
--- snip --- ./drive_c/Program Files (x86)/Overwatch/Overwatch Launcher.exe: PE32 executable (GUI) Intel 80386, for MS Windows ./drive_c/Program Files (x86)/Overwatch/Overwatch.exe: PE32+ executable (GUI) x86-64, for MS Windows --- snip ---
NOTE: requires additional patches
=== StarCraft II (32-bit and 64-bit): ===
--- snip --- ./drive_c/Program Files (x86)/StarCraft II/Support64/SC2Switcher_x64.exe: PE32+ executable (GUI) x86-64, for MS Windows ./drive_c/Program Files (x86)/StarCraft II/StarCraft II.exe: PE32 executable (GUI) Intel 80386, for MS Windows ./drive_c/Program Files (x86)/StarCraft II/Versions/Base62848/SC2_x64.exe: PE32+ executable (GUI) x86-64, for MS Windows ./drive_c/Program Files (x86)/StarCraft II/Versions/Base62848/SC2.exe: PE32 executable (GUI) Intel 80386, for MS Windows ./drive_c/Program Files (x86)/StarCraft II/Support/SC2Switcher.exe: PE32 executable (GUI) Intel 80386, for MS Windows --- snip ---
--- snip --- $ wine ./StarCraft\ II.exe OnlineService.SSO=true -launch -uid --- snip ---
--- snip --- $ wine64 ./Support64/SC2Switcher_x64.exe --- snip ---
Correction: SC II seems to work without KUSER_SHARED_DATA patch (runs at least until login screen) -> sorry about that.
=== Diablo III (32-bit and 64-bit): ===
--- snip --- ./drive_c/Program Files (x86)/Diablo III/x64/Diablo III64.exe: PE32+ executable (GUI) x86-64, for MS Windows ./drive_c/Program Files (x86)/Diablo III/Diablo III Launcher.exe: PE32 executable (GUI) Intel 80386, for MS Windows ./drive_c/Program Files (x86)/Diablo III/Diablo III.exe: PE32 executable (GUI) Intel 80386, for MS Windows --- snip ---
NOTE: requires additional patches
--- snip --- $ wine ./Diablo\ III.exe OnlineService.SSO=true -launch -uid diablo3_enus ... 00ff:err:seh:setup_exception_record stack overflow 1188 bytes in thread 00ff eip 7bc9219a esp 00240e8c stack 0x240000-0x241000-0x340000 --- snip ---
32-bit version started working when KUSER_SHARED_DATA patch was applied on top.
--- snip --- $ wine64 ./Diablo\ III64.exe OnlineService.SSO=true -launch -uid diablo3_enus ... 0009:err:seh:setup_exception stack overflow 2032 bytes in thread 0009 eip 00007f2e9158fa76 esp 0000000000140e20 stack 0x140000-0x141000-0x240000 --- snip ---
=== World of Warcraft (32-bit and 64-bit): ===
--- snip --- ./drive_c/Program Files (x86)/World of Warcraft/Wow-64.exe: PE32+ executable (GUI) x86-64, for MS Windows ./drive_c/Program Files (x86)/World of Warcraft/World of Warcraft Launcher.exe: PE32 executable (GUI) Intel 80386, for MS Windows ./drive_c/Program Files (x86)/World of Warcraft/Wow.exe: PE32 executable (GUI) Intel 80386, for MS Windows --- snip ---
NOTE: requires additional patches
--- snip --- $ wine ./Wow.exe
# hangs in live-loop (most recent update 2018-03-26T18:35:44Z|7.3.5.26124 ) or stack-overflow (before weekend) --- snip ---
32-bit version started working when KUSER_SHARED_DATA patch was applied on top.
--- snip --- $ wine64 ./Wow-64.exe ... 0009:err:seh:setup_exception stack overflow 1920 bytes in thread 0009 eip 00007f6e1b5e5a76 esp 0000000000140e90 stack 0x140000-0x141000-0x240000 --- snip ---
I cherry-picked single patches from Wine-Staging without dependencies to figure out the minimum set and drop unneeded dependencies. The 64-bit exception code patch alone which is listed as dependency didn't resolve the issue for the 64-bit versions.
I'm correcting the summary to explicitly refer to 32-bit Diablo III, 32-bit WoW and Overwatch until further results.
Regards
https://bugs.winehq.org/show_bug.cgi?id=29168
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fincer89@hotmail.com
--- Comment #298 from Anastasius Focht focht@gmx.net --- *** Bug 44849 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=29168
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fabienmoal@wanadoo.fr
--- Comment #299 from Matteo Bruni matteo.mystral@gmail.com --- *** Bug 44861 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=29168
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=29168
zzzzzyzz@hacari.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz@hacari.org
https://bugs.winehq.org/show_bug.cgi?id=29168
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lmnet89@gmail.com
--- Comment #300 from Anastasius Focht focht@gmx.net --- *** Bug 45905 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=29168
Andrey andrey.gursky@e-mail.ua changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrey.gursky@e-mail.ua
https://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #301 from Andrey Gusev andrey.goosev@gmail.com --- Sniper Elite 4 is affected.
https://bugs.winehq.org/show_bug.cgi?id=29168
pattietreutel katyaberezyaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=29168
auxsvr@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |auxsvr@yahoo.com
https://bugs.winehq.org/show_bug.cgi?id=29168
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |diego.lazcanoarcos@gmail.co | |m
--- Comment #302 from Matteo Bruni matteo.mystral@gmail.com --- *** Bug 47132 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=29168
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |protel02@gmail.com
--- Comment #303 from Matteo Bruni matteo.mystral@gmail.com --- *** Bug 46586 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=29168
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Multiple games and |Multiple games and |applications need realtime |applications need realtime |updates to KSYSTEM_TIME |updates to KSYSTEM_TIME |members in |members in |KUSER_SHARED_DATA (Star |KUSER_SHARED_DATA (Star |Wars: The Old Republic game |Wars: The Old Republic game |client, Blizzard games: |client, Blizzard games, GO |32-bit Diablo III, 32-bit |1.4+ runtime) |WoW, Overwatch, GO 1.4+ | |runtime) |
https://bugs.winehq.org/show_bug.cgi?id=29168
silentz0r d.misdanitis@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|d.misdanitis@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #304 from Andrey Gusev andrey.goosev@gmail.com --- Far Cry Primal requires this.
https://bugs.winehq.org/show_bug.cgi?id=29168
--- Comment #305 from Anastasius Focht focht@gmx.net --- *** Bug 44438 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=29168
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Multiple games and |Multiple games and |applications need realtime |applications need realtime |updates to KSYSTEM_TIME |updates to KSYSTEM_TIME |members in |members in |KUSER_SHARED_DATA (Star |KUSER_SHARED_DATA (Star |Wars: The Old Republic game |Wars: The Old Republic game |client, Blizzard games, GO |client, Blizzard games, GO |1.4+ runtime) |1.4+ runtime, Denuvo | |Anti-Tamper x64 #2)
--- Comment #306 from Anastasius Focht focht@gmx.net --- Hello folks,
let's keep fingers crossed. Recently, there have been multiple attempts by Rémi Bernon from CodeWeavers to get support for user shared data updates into mainline Wine. It's currently at "v4":
https://www.winehq.org/pipermail/wine-devel/2020-April/thread.html#165600
It would make a number of apps/games/protection schemes work that don't depend on fake dlls/syscall thunk patches.
Regards
https://bugs.winehq.org/show_bug.cgi?id=29168
sxe sxxe@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|sxxe@gmx.de |
https://bugs.winehq.org/show_bug.cgi?id=29168
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |a1c46c3806a054c16fab9fd9d83 | |88e55eb473536 Status|STAGED |RESOLVED Component|ntdll |wineserver Resolution|--- |FIXED
--- Comment #307 from Anastasius Focht focht@gmx.net --- Hello folks,
this should be fixed by commit https://source.winehq.org/git/wine.git/commitdiff/a1c46c3806a054c16fab9fd9d8... ("server: Add USD support with timestamp updates.")
Thanks Rémi. Let's not forget the initial contribution/groundwork by Sebastian, Michael and Andrew from Wine-Staging team.
I've tested with Denuvo protected games, such as DOOM 2016 Steam demo that don't require other Wine-Staging patches. They run further now with mainline.
$ wine --version wine-5.8-63-g26b26a2e0e
Regards
https://bugs.winehq.org/show_bug.cgi?id=29168
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #308 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.9.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla