I'll write a wrap-up blog, but at the moment, I've made incremental progress. Current failure (using winehacks repo as a starting point, and adding a small bit of code from there) is: fixme:winsock:AcceptEx Failed to query async: c0000008 Not sure if this is a) firewall (Seeing strange martions from .254) b) the AcceptEx implementation, which promises (and looks like) it properly supports async c) most likely, the TransmitPackets/TransmitFile implementation I'm starting with (details below), which admittedly "fakes" the async. However from that perspective it simply means your supposedly "async kickoff call" followed by "calls to callback" just needs to call the callback before returning(?) since the call blocked... anyway The sad thing about the fix to bug 5048 (CLICK) (http://bugs.winehq.org/show_bug.cgi?id=5048), which is the one asking for a TransmitFile implementation, is that it relies on a call to this same (SIO_GET_EXTENSION_FUNCTION_POINTER) : the implementation boils down to: /* Use the implementation provided by ws2_32 */ if (WSAIoctl(s, SIO_GET_EXTENSION_FUNCTION_POINTER, (void*)&guid, sizeof(guid), &fn, sizeof(fn), &len, NULL, NULL)) return fn(...); return FALSE; - the commiter did end with "now on to implementation side", but that was about 2 years 3 months ago Two people out there have tried implementing TransmitFile/TransmitPackets. This guy http://wine.1045685.n5.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=54669 put his implementation in dlls/mswsock/mswsock.c. Latest I could find from him was in 2006, and there were several reasons his patch was rejected, mostly poor timing (busy week??) ... The better place is where the other guy (http://wine.1045685.n5.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=34498, specifically (CLICK) (http://wine.1045685.n5.nabble.com/ws2-32-Partial-implementation-of-TransmitFile-TransmitPackets-try-2-tt1759683.html) ) tried, at dlls/socket/socket.c (sitting next to the SIO_EXTENSION call, since wine .dll relocation is reputedly (?) tricky to deal with). In any case, both have failed to get in for various reasons. However, latest attempt was 17/7/2008, and the only trace I can find is this feedback from Alexandre: http://www.winehq.org/pipermail/wine-devel/2008-July/067452.html In any case, this looked like an interesting starting point. winehacks gave me a basis where SIO_EXTENSION... has a (working or non, debatable, see below) AcceptEx, enough that this has helped folks play Warcraft 3 and similar (e.g. bug ), and here was a (apparently incorrect) attempt at an implementation of TransmitFile/TransmitPackets. So, I've: 1. Fetched the repo at http://repo.or.cz/w/wine/hacks.git 2. Applied the changes from the patch manually to: (wine-src)/include/mswsock.h, (wine-src)/dlls/ws2_32/socket.c 3. Got a good make out of dlls/ws2_32. 4. Moved my ws2_32.dll.so out of the way, and dropped this one in place, in /usr/lib32/wine (it is about twice the size 499k vs 199k). I didn't do anything special on .configure or make depends, so I'm not sure if debug switches are on by default, but that seemed relatively large. In any case, I can now do the following: 1. Launch steam. This gets me an active process in the wine prefix. I'm assuming wineserver has something to do with this, because, I can then: 2. BEFORE Starting DA:O Ultimate Nightmare for Wine, find shell, launch: WINEPREFIX=~/.PlayOnLinux/wineprefix/Steam wine net start daoupdatersvc 2.a Side note, I noticed at this point, that in addition to the ports mentioned here:(http://social.bioware.com/forum/1/topic/58/index/359507), my firewall starts rejecting TCP traffic on 9946 from my machine; the target IP is not nslookup-able, but tracert goes right to EA. So, I opened that up. 3. Verify it started by running the above again. You'll get a message saying service started. (Try this prior to starting steam, and you will see your virtual desktop (if you run that way) start and stop, and each time it will state "successfully started service") 5. If you've launched steam from command (e.g. WINEPREFIX=~/.PlayOnLinux/wineprefix/Steam wine "c:\\Program Files\\Steam\\steam.exe"), I see that the fixme::TransmitFile warnings have gone away, and now I see AcceptEx warnings. More info: Here's console output from running the daupdatersvc: Before this /usr/lib32/wine/ws2_32.dll.so replacement: me@minotaur:~/.PlayOnLinux/wineprefix/Steam/drive_c/Program Files$ WINEPREFIX=/home/me/.PlayOnLinux/wineprefix/Steam/ wine net start daupdatersvc The Dragon Age: Origins - Content Updater service is starting. fixme:sync:CreateMemoryResourceNotification (0) stub fixme:shell:URL_ParseUrl failed to parse L"System.ServiceProcess" fixme:shell:URL_ParseUrl failed to parse L"System" fixme:shell:URL_ParseUrl failed to parse L"DAUpdater.Engine" fixme:shell:URL_ParseUrl failed to parse L"System.Configuration" fixme:shell:URL_ParseUrl failed to parse L"System.Xml" fixme:winsock:WSAIoctl SIO_GET_EXTENSION_FUNCTION_POINTER: unimplemented TransmitFile The Dragon Age: Origins - Content Updater service was started successfully. After this /usr/lib32/wine/ws2_32.dll.so replacement: me@minotaur:~/.PlayOnLinux/wineprefix/Steam/drive_c/Program Files$ WINEPREFIX=/home/me/.PlayOnLinux/wineprefix/Steam/ wine net start daupdatersvc The Dragon Age: Origins - Content Updater service is starting. fixme:sync:CreateMemoryResourceNotification (0) stub fixme:shell:URL_ParseUrl failed to parse L"System.ServiceProcess" fixme:shell:URL_ParseUrl failed to parse L"System" fixme:shell:URL_ParseUrl failed to parse L"DAUpdater.Engine" fixme:shell:URL_ParseUrl failed to parse L"System.Configuration" fixme:shell:URL_ParseUrl failed to parse L"System.Xml" fixme:winsock:AcceptEx Failed to query async: c0000008 The Dragon Age: Origins - Content Updater service was started successfully. rloh@minotaur:~/.PlayOnLinux/wineprefix/Steam/drive_c/Program Files$ NOTE!! DESPITE .PlayOnLinux in the path, note I am NOT using it to launch. I typically use POL for things like easy setup & install, Point & Click winecfg when I'm feeling lazy, and closing all processes in a wineprefix (can someone give me a reliable ps filter? open file handles or ..? maybe specify cwd of each process.. and filter based on what each prefix is..?) Doing a tail -f or refreshing the file in gedit/gvim/etc ~/BioWare/Dragon Age/Logs/DragonAge_1.log spins the following in a series (once for each addon) DA Download Manager (DADM) Attempting to connect to DADM Control Server! DA Download Manager (DADM) Connected to DADM Control Server! DA Download Manager (DADM) Failed to configure DADM! DA Download Manager (DADM) Disconnected from DADM Control Server! followed by the wallet balance check. I did notice the wallet balance checks happening (without future dadm messages) while hitting refresh on available content page (which shows everything with a points value), thought I can't be positive now with all the iterations I've tried, whether that's because I didn't do something like logout/login in between. Which I've tried btw, (logout, login), it just yeilds more of those blocks of DADM messages/wallet balance checks. The heart of this problem looks like some very simple service code that just wants to pick up what's likely an authentication file.... Going to look at the implementation of TransmitPackets a bit closer, see if I can make it async... Anyone who has thoughts/more info, please provide =)
