https://bugs.winehq.org/show_bug.cgi?id=37185
Bug ID: 37185 Summary: DirectPlayCreate fails to create instance in the game "Swing" Product: Wine Version: 1.6.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-dplay Assignee: wine-bugs@winehq.org Reporter: olivier.verriest@remoteloop.net
Created attachment 49422 --> https://bugs.winehq.org/attachment.cgi?id=49422 relay trace
The DirectPlay IPX/Modem/Serial multiplayer mode doesn't work in the Software2000 game `Swing' and `Swing Plus'. In the German release of the game, the game just throws two error boxes:
... 0009:Call dplayx.DirectPlayCreate(0032f74c,0044d958,00000000) ret=0041322f ^^^^^^^^ ^^^^^^^^ |lpGUIDSP |ref to IDirectPlay interface ... err:dplay:DirectPlayCreate Failed to get Enum for SP: DP_OK 0009:Ret dplayx.DirectPlayCreate() retval=887700fa ret=0041322f ^^^^^^^^ !!! DPERR_UNAVAILABLE !!! 0009:Call user32.MessageBoxA(0001005c,0032f728 "Fehler beim Starten von DirectPlay. (Error 3)",00434168 "Attention",00000000) ret=00411c89 ... 0009:Call user32.MessageBoxA(0001005c,0032f738 "Fehler beim Starten von DirectPlay. (Error 1)",00434168 "Attention",00000000) ret=00411c89
The complete trace can be found in the attachment.
This error can be reproduced, either by starting the game without cdrom (in which case it starts in network-mode), or by starti nt the game normally, and then trying to launch a new network game. Unfortunately there are no demo or free versions of this game to include here (Software 2000 doesn't exist anymore, but distributing abandonware is probably not legal in all countries).
This error might be related to Bug 4066, but the dplay error is different in this case. Installing the native DirectPlay stack with winetricks (sh winetricks directplay) does not help.
https://bugs.winehq.org/show_bug.cgi?id=37185
--- Comment #1 from Olivier olivier.verriest@remoteloop.net --- Created attachment 49423 --> https://bugs.winehq.org/attachment.cgi?id=49423 relay trace when running the game with winetricks directplay
Maybe interesting to add: when running the game with the winetricks directplay overrides, the game still throws the same message boxes, but doesn't show the DirectPlayCreate error (or any other "err:") in the relay trace.
https://bugs.winehq.org/show_bug.cgi?id=37185
--- Comment #2 from Bruno Jesus 00cpxxx@gmail.com ---
0009:Ret ws2_32.bind() retval=ffffffff ret=5df0893c
A bind() call is failing, please attach a +winsock log. Have you tried in wine 1.7.25?
https://bugs.winehq.org/show_bug.cgi?id=37185
--- Comment #3 from Bruno Jesus 00cpxxx@gmail.com --- The game requires IPX, so remember to have a kernel with IPX support and correct configured interfaces.
https://bugs.winehq.org/show_bug.cgi?id=37185
--- Comment #4 from Olivier olivier.verriest@remoteloop.net --- Created attachment 49424 --> https://bugs.winehq.org/attachment.cgi?id=49424 winsock log when run with wintricks directplay
https://bugs.winehq.org/show_bug.cgi?id=37185
--- Comment #5 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Olivier from comment #4)
Created attachment 49424 [details] winsock log when run with wintricks directplay
You didn't configure your network interface to support IPX. A bit of text taken from https://appdb.winehq.org/objectManager.php?sClass=version&iId=149:
To get ipx network support, IPX will have to be enabled in the kernel, and you need some userspace utilities, usually called ipx-utils; and IPX must be started (there should be an initscript).
*ubuntu users can use the commands:
sudo apt-get install ipx; sudo modprobe ipx; sudo ipx_interface add -p eth0 802.2 0x12345678
(change eth0 for the name of your ethernet/wireless card)
The frame type (802.2) needs to be equal for everyone. It is recommended to use ethernet II instead of 802.2. If playing with computers with Windows, make sure their frame type is set to what you have, and not 'automatic'. It may cause issues if you forget it.
https://bugs.winehq.org/show_bug.cgi?id=37185
--- Comment #6 from Olivier olivier.verriest@remoteloop.net --- Thank you very much for your prompt response. Adding an IPX address indeed solved the problem for the wintricks stack (I didn't know this game only used IPX). Still, the game seems to hanger after opening the 'looking for network games' popup, I may have to look into that.
Should I mark this bug as 'resolved'? The wintricks library now works, the default wine dplay libraries still don't work (those didn't get past DirectPlayCreate).
I've compiled the wine version from git to check: the results are the same: it still fails at DirectPlayCreate().
https://bugs.winehq.org/show_bug.cgi?id=37185
--- Comment #7 from Bruno Jesus 00cpxxx@gmail.com --- Can you reproduce the same problem without winetricks directplay?
The previous problem was about missing configurations which would make this bug invalid, but since fixing the config still didn't fix it we can still use this bug to continue research.
Wine-git will at least give a slightly better winsock log (no need to attach).
https://bugs.winehq.org/show_bug.cgi?id=37185
OlivierV olivier.verriest@remoteloop.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #49422|0 |1 is obsolete| |
--- Comment #8 from OlivierV olivier.verriest@remoteloop.net --- Created attachment 49430 --> https://bugs.winehq.org/attachment.cgi?id=49430 +relay trace, run with wine-1.7.25-33-g16000c6
I've reinstalled the application in a vanilla directory with wine-git, without any winetricks overrides: - I've set up an IPX stack as required - I've set up compatibility modes and color modes as required - When launching a new network game, the same error as before is thrown.
I've updated the "+relay" attachment, but the relevant error remains the same:
err:dplay:DirectPlayCreate Failed to get Enum for SP: DP_OK
The "+winsock" log is pointless here: the game doesn't even initialize a socket yet.
This error can be reproduced, simply by launching the game and navigating to the multiplayer menu. For those that want to try it themselves, I've uploaded an iso of the cdrom contents: http://www.mediafire.com/download/b2vu1055ojl66e6/swing.tar.xz Mind that, depending on the law in your country, it may be illegal to download this file (I certainly have no intention of breaking the law here).
My sincere thanks for helping out a rookie as myself.
https://bugs.winehq.org/show_bug.cgi?id=37185
OlivierV olivier.verriest@remoteloop.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.6.2 |1.7.25
https://bugs.winehq.org/show_bug.cgi?id=37185
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #9 from Bruno Jesus 00cpxxx@gmail.com --- There are 2 different errors here, when native directplay is installed the IPX configuration on the host OS has to be setup correctly. That is less interesting.
The actual bug is that without native directplay the call to DirectPlayCreate fails, and it fails because the application passes a nonsense GUID as service provider. This does not happen in Windows, where the app passes the IPX provider correctly.
It looks like the GUID is retrieved from a DirectPlayEnumarateA call, wine is returning the correct GUID (tested by adding extra debug trace in dplay.c).
The bug is: Why when running in Wine a crazy GUID is passed to DirectPlayCreate?
https://bugs.winehq.org/show_bug.cgi?id=37185
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #10 from Anastasius Focht focht@gmx.net --- Hello folks,
thanks for the email Bruno to interrupt my coffee break ... j/k :)
--- quote --- The bug is: Why when running in Wine a crazy GUID is passed to DirectPlayCreate? --- quote ---
The game provided SP enum callback does something stupid: instead of copying the service provider GUID it stores the address in an internal structure for later use. Actually it's an array of structures, with 'IPX' structure entry being indexed.
The GUID variable lives on stack within DirectPlayEnumerateAW() context so the data only remains valid during the enumerate API call.
Source: http://source.winehq.org/git/wine.git/blob/7e17eec75005e0e1c16b9b56422544246...
--- snip --- 5768 static HRESULT DirectPlayEnumerateAW(LPDPENUMDPCALLBACKA lpEnumCallbackA, 5769 LPDPENUMDPCALLBACKW lpEnumCallbackW, 5770 LPVOID lpContext) 5771 { ... 5803 /* Traverse all the service providers we have available */ 5804 dwIndex = 0; 5805 while (1) 5806 { 5807 WCHAR subKeyName[255]; /* 255 is the maximum key size according to MSDN */ 5808 DWORD sizeOfSubKeyName = sizeof(subKeyName) / sizeof(WCHAR); 5809 HKEY hkServiceProvider; 5810 GUID serviceProviderGUID; 5811 WCHAR guidKeyContent[(2 * 16) + 1 + 6 /* This corresponds to '{....-..-..-..-......}' */ ]; 5812 DWORD sizeOfGuidKeyContent = sizeof(guidKeyContent); 5813 LONG ret_value; ... 5845 CLSIDFromString(guidKeyContent, &serviceProviderGUID ); ... 5853 if (lpEnumCallbackA) 5854 { 5855 DWORD sizeOfDescription = 0; 5856
5873 if (!lpEnumCallbackA(&serviceProviderGUID, descriptionA, 6, 0, lpContext)) 5874 goto end; ... --- snip ---
This obviously can't work with code that makes the assumption that the address and the referenced content is still accessible outside of DirectPlayEnumerateAW() context.
Since the data is read from registry and not very "dynamic" during runtime, it's probably fine to retrieve and store it upon dplay creation (heap, list) to be returned in DirectPlayEnumerateAW(). This also avoids the registry queries each time DirectPlayEnumerateAW() is getting called.
Regards
https://bugs.winehq.org/show_bug.cgi?id=37185
--- Comment #11 from Bruno Jesus 00cpxxx@gmail.com --- Thank you Anastasius, I hope it was not very boring.
https://bugs.winehq.org/show_bug.cgi?id=37185
Saulius K. saulius2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |saulius2@gmail.com
--- Comment #12 from Saulius K. saulius2@gmail.com --- Very nice. Can anyone explain me further: why on earth does this work in Windows? Or doesn't it?
Could it be related to differences in memory mgmt? Or just to differently organized call-chain which manages to avoid data corruption just by a chance?
Sorry for asking to think you about Windows internals -- my head just ran out of ideas.
https://bugs.winehq.org/show_bug.cgi?id=37185
--- Comment #13 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Saulius K. from comment #12)
Very nice. Can anyone explain me further: why on earth does this work in Windows? Or doesn't it?
Somehow in Windows the memory that is returned in the callback keeps allocated, maybe it's a fixed buffer that is loaded when the application first asks for the enumeration. I'm in the ways of fixing this, my first attempt was (which works currently) http://source.winehq.org/patches/data/108441 Now I have to change a few things and add tests.
https://bugs.winehq.org/show_bug.cgi?id=37185
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |2d08038bac1beb2916114338564 | |2701190f8a4c1 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #14 from Bruno Jesus 00cpxxx@gmail.com --- Fixed by http://source.winehq.org/git/wine.git/commitdiff/2d08038bac1beb2916114338564...
Anastasius, thanks for the analysis once again.
https://bugs.winehq.org/show_bug.cgi?id=37185
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.35.
-
wine-bugs＠winehq.org