Request for Community help - AO & Awesomonium Now Working In Wine

[Marebone]

Lupusceleri and DocJones:
Would be nice if you can get us a crash report from the AwesomiumProcess.exe's crashes. Below are instructions.

1. First run wine's debugger so that it generates some registry keys:
   $ winedbg
   It gives you a prompt "Wine-dbg>", type "quit" and hit enter.
2. Next, open Registry Editor:
   $ regedit
   Browse to HKEY_CURRENT_USER/Software/Wine/WineDbg and set AlsoDebugProcChild to 1. This makes the debugger to attach to all processes that are spawned by the parent process that is being debugged.
   Close the editor.
3. Next, download and extract AwesomiumGL.zip to some location. This is one of sample applications from Awesomium's development package. So far, I have managed to replicate same crashes with that sample as with AO's in-game browser and it's faster and easier to debug Awesomium related stuff with it.
4. Next, cd to the extracted location and run AwesomiumGL inside the debugger:
   $ winedbg AwesomiumGL.exe
   It should print something like this to terminal:
   start_process () at /home/jhakonen/wine-git/dlls/kernel32/process.c:1086
   0x7b85a38f start_process+0x4f [/home/jhakonen/wine-git/dlls/kernel32/process.c:1086] in kernel32: movl %edi,0x4(%esp)
   1086 return call_process_entry( peb, entry );
   Wine-dbg>
   Type "c" (short for continue) and hit enter.
   This comes up maybe 4 times as the Awesomium spawns processes.
5. Now you should be able to use the browser, that is if it didn't crash yet. Try scrolling a lot and visiting sites with loads of animation until it crashes.
6. When the crash comes, you should see text "Unhandled exception: ...", a register dump, stack dump, a backtrace and another debugger's prompt.
   Copy all the the stuff from terminal and attach it as a file to the bug report. And tell when the crash occurred, what you did, etc...
7. You can leave the debugger with "quit".

[Lupusceleri]

Browser didn't even start.

martijn@martijndesktop ~/.wine-ao/drive_c/AwesomiumGL $ winedbg AwesomiumGL.exe 
WineDbg starting on pid 001a
fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC90.CRT" (9.0.21022.8)
err:module:find_forwarded_export function not found for forward 'msvcrt._except_handler4_common' used by L"C:\\windows\\system32\\msvcr90.dll". If you are using builtin L"msvcr90.dll", try using the native one instead.
err:module:find_forwarded_export function not found for forward 'msvcrt._controlfp_s' used by L"C:\\windows\\system32\\msvcr90.dll". If you are using builtin L"msvcr90.dll", try using the native one instead.
err:module:find_forwarded_export function not found for forward 'msvcrt.??_V@YAXPAX@Z' used by L"C:\\windows\\system32\\msvcr90.dll". If you are using builtin L"msvcr90.dll", try using the native one instead.
err:module:find_forwarded_export function not found for forward 'msvcrt._initterm_e' used by L"C:\\windows\\system32\\msvcr90.dll". If you are using builtin L"msvcr90.dll", try using the native one instead.
err:module:find_forwarded_export function not found for forward 'msvcrt._configthreadlocale' used by L"C:\\windows\\system32\\msvcr90.dll". If you are using builtin L"msvcr90.dll", try using the native one instead.
0x7edc9254 ExitProcess+0xc14 in kernel32: movl  %edi,0x4(%esp)
Wine-dbg>c
0x7edc9254 ExitProcess+0xc14 in kernel32: movl  %edi,0x4(%esp)
Wine-dbg>

Tried adding that dll to native through winecfg, same result. Tried removing msvcr100.dll from the list, same result.

Googling the thing:

http://www.processlibrary.com/direct...svcr90/420990/

So I did: "sh ~/winetricks vcrun2005" and tried again, but no dice. Next "sh ~/winetricks vcrun2008" and tried again, no more errors so that seems to be a requisite for Awesomium..

martijn@martijndesktop ~/.wine-ao/drive_c/AwesomiumGL $ winedbg AwesomiumGL.exe 
WineDbg starting on pid 0020
0x7edc9254 ExitProcess+0xc14 in kernel32: movl  %edi,0x4(%esp)
Wine-dbg>c
0x7edc9254 ExitProcess+0xc14 in kernel32: movl  %edi,0x4(%esp)
Wine-dbg>c
0x7edc9254 ExitProcess+0xc14 in kernel32: movl  %edi,0x4(%esp)
Wine-dbg>c
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
Thread ID=0026 renamed using MS VC6 extension (name=="Chrome_DB")
Thread ID=0027 renamed using MS VC6 extension (name=="Chrome_Fi")
Thread ID=0028 renamed using MS VC6 extension (name=="Chrome_Pr")
Thread ID=002b renamed using MS VC6 extension (name=="Chrome_IO")
fixme:iphlpapi:NotifyAddrChange (Handle 0x13de81c, overlapped 0xb25070): stub
Thread ID=002d renamed using MS VC6 extension (name=="Chrome_We")
Thread ID=002d renamed using MS VC6 extension (name=="Main Thre")
Thread ID=002e renamed using MS VC6 extension (name=="Chrome_Sa")
Thread ID=0034 renamed using MS VC6 extension (name=="Chrome_Hi")
fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
fixme:file:ReplaceFileW Ignoring flags 2
0x7edc9254 ExitProcess+0xc14 in kernel32: movl  %edi,0x4(%esp)
Wine-dbg>c
fixme:file:ReplaceFileW Ignoring flags 2
Thread ID=0033 renamed using MS VC6 extension (name=="Chromium_")
Thread ID=0039 renamed using MS VC6 extension (name=="Chrome_Ch")
fixme:gdi:GdiInitializeLanguagePack stub
Thread ID=0033 renamed using MS VC6 extension (name=="Main Thre")
fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x108c7064).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:108c7064 ESP:0033eb18 EBP:00b75360 EFLAGS:00010206(  R- --  I   - -P- )
 EAX:00000000 EBX:00b752c8 ECX:00b698b8 EDX:00b69c00
 ESI:00b731e0 EDI:00b13a64
Stack dump:
0x0033eb18:  00b752a0 109f908a 00ad5900 00b13a64
0x0033eb28:  00b75360 00b73140 00000000 109b1fc6
0x0033eb38:  0033eb40 00000000 00ad5900 00b00380
0x0033eb48:  00ad5904 00b13a64 00ad5900 00ad5902
0x0033eb58:  109f8348 00000000 00ad5904 00b13a64
0x0033eb68:  00ad5900 00ad5900 109f8549 00ad5900
000c: sel=0067 base=00000000 limit=00000000 16-bit --x
Backtrace:
=>0 0x108c7064 in awesomium (+0x8c7064) (0x00b75360)
0x108c7064: movl        0x0(%eax),%edx
Wine-dbg>fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority
c
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x108c7064).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:108c7064 ESP:0033eb18 EBP:00b75360 EFLAGS:00010206(  R- --  I   - -P- )
 EAX:00000000 EBX:00b752c8 ECX:00b698b8 EDX:00b69c00
 ESI:00b731e0 EDI:00b13a64
Stack dump:
0x0033eb18:  00b752a0 109f908a 00ad5900 00b13a64
0x0033eb28:  00b75360 00b73140 00000000 109b1fc6
0x0033eb38:  0033eb40 00000000 00ad5900 00b00380
0x0033eb48:  00ad5904 00b13a64 00ad5900 00ad5902
0x0033eb58:  109f8348 00000000 00ad5904 00b13a64
0x0033eb68:  00ad5900 00ad5900 109f8549 00ad5900
000c: sel=0067 base=00000000 limit=00000000 16-bit --x
Backtrace:
=>0 0x108c7064 in awesomium (+0x8c7064) (0x00b75360)
0x108c7064: movl        0x0(%eax),%edx

Doing more "c" just repeated the last chunk of the error. AwesomiumGL Sample window just kept showing a white screen. The Windows style command prompt just showed lots of lines with "Backtrace:" and then nothing.

Doubleposting on WineHQ bugzilla.

[Marebone]

fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC90.CRT" (9.0.21022.8)
err:module:find_forwarded_export function not found for forward 'msvcrt._except_handler4_common' used by L"C:\\windows\\system32\\msvcr90.dll". If you are using builtin L"msvcr90.dll", try using the native one instead.
err:module:find_forwarded_export function not found for forward 'msvcrt._controlfp_s' used by L"C:\\windows\\system32\\msvcr90.dll". If you are using builtin L"msvcr90.dll", try using the native one instead.
err:module:find_forwarded_export function not found for forward 'msvcrt.??_V@YAXPAX@Z' used by L"C:\\windows\\system32\\msvcr90.dll". If you are using builtin L"msvcr90.dll", try using the native one instead.
err:module:find_forwarded_export function not found for forward 'msvcrt._initterm_e' used by L"C:\\windows\\system32\\msvcr90.dll". If you are using builtin L"msvcr90.dll", try using the native one instead.
err:module:find_forwarded_export function not found for forward 'msvcrt._configthreadlocale' used by L"C:\\windows\\system32\\msvcr90.dll". If you are using builtin L"msvcr90.dll", try using the native one instead.

I get that fixme message if I don't have vcrun2008 installed, but not those errors. However, AwesomiumGL should run fine without any vcruns, at least it does for me.

Tried adding that dll to native through winecfg, same result. Tried removing msvcr100.dll from the list, same result.

Wait, you have something in the Libraries section? Mine is totally empty. Try starting from clean slate, backup ~/.wine-ao and then delete it. Don't install any winetricks stuff or ies4linux or anything. Make sure you use newest development version of Wine.

martijn@martijndesktop ~/.wine-ao/drive_c/AwesomiumGL $ winedbg AwesomiumGL.exe 
WineDbg starting on pid 0020
0x7edc9254 ExitProcess+0xc14 in kernel32: movl  %edi,0x4(%esp)
Wine-dbg>c
0x7edc9254 ExitProcess+0xc14 in kernel32: movl  %edi,0x4(%esp)
Wine-dbg>c
0x7edc9254 ExitProcess+0xc14 in kernel32: movl  %edi,0x4(%esp)
Wine-dbg>c
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
Thread ID=0026 renamed using MS VC6 extension (name=="Chrome_DB")
Thread ID=0027 renamed using MS VC6 extension (name=="Chrome_Fi")
Thread ID=0028 renamed using MS VC6 extension (name=="Chrome_Pr")
Thread ID=002b renamed using MS VC6 extension (name=="Chrome_IO")
fixme:iphlpapi:NotifyAddrChange (Handle 0x13de81c, overlapped 0xb25070): stub
Thread ID=002d renamed using MS VC6 extension (name=="Chrome_We")
Thread ID=002d renamed using MS VC6 extension (name=="Main Thre")
Thread ID=002e renamed using MS VC6 extension (name=="Chrome_Sa")
Thread ID=0034 renamed using MS VC6 extension (name=="Chrome_Hi")
fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
fixme:file:ReplaceFileW Ignoring flags 2
0x7edc9254 ExitProcess+0xc14 in kernel32: movl  %edi,0x4(%esp)
Wine-dbg>c
fixme:file:ReplaceFileW Ignoring flags 2
Thread ID=0033 renamed using MS VC6 extension (name=="Chromium_")
Thread ID=0039 renamed using MS VC6 extension (name=="Chrome_Ch")
fixme:gdi:GdiInitializeLanguagePack stub
Thread ID=0033 renamed using MS VC6 extension (name=="Main Thre")
fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x108c7064).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:108c7064 ESP:0033eb18 EBP:00b75360 EFLAGS:00010206(  R- --  I   - -P- )
 EAX:00000000 EBX:00b752c8 ECX:00b698b8 EDX:00b69c00
 ESI:00b731e0 EDI:00b13a64
Stack dump:
0x0033eb18:  00b752a0 109f908a 00ad5900 00b13a64
0x0033eb28:  00b75360 00b73140 00000000 109b1fc6
0x0033eb38:  0033eb40 00000000 00ad5900 00b00380
0x0033eb48:  00ad5904 00b13a64 00ad5900 00ad5902
0x0033eb58:  109f8348 00000000 00ad5904 00b13a64
0x0033eb68:  00ad5900 00ad5900 109f8549 00ad5900
000c: sel=0067 base=00000000 limit=00000000 16-bit --x
Backtrace:
=>0 0x108c7064 in awesomium (+0x8c7064) (0x00b75360)
0x108c7064: movl        0x0(%eax),%edx
Wine-dbg>fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority
c
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x108c7064).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:108c7064 ESP:0033eb18 EBP:00b75360 EFLAGS:00010206(  R- --  I   - -P- )
 EAX:00000000 EBX:00b752c8 ECX:00b698b8 EDX:00b69c00
 ESI:00b731e0 EDI:00b13a64
Stack dump:
0x0033eb18:  00b752a0 109f908a 00ad5900 00b13a64
0x0033eb28:  00b75360 00b73140 00000000 109b1fc6
0x0033eb38:  0033eb40 00000000 00ad5900 00b00380
0x0033eb48:  00ad5904 00b13a64 00ad5900 00ad5902
0x0033eb58:  109f8348 00000000 00ad5904 00b13a64
0x0033eb68:  00ad5900 00ad5900 109f8549 00ad5900
000c: sel=0067 base=00000000 limit=00000000 16-bit --x
Backtrace:
=>0 0x108c7064 in awesomium (+0x8c7064) (0x00b75360)
0x108c7064: movl        0x0(%eax),%edx

Bleh, crashes inside Awesomium.dll instead of Wine. Can't do much about that without symbol files/source code for Awesomium.

You could try to run the sample with WINEDEBUG environment variable set to "+seh,+tid,+relay". This will make the Wine to print loads of stuff to stderr output and you should pipe the stuff to a log file.
When browsing the log file, look for that page fault message to find out where it crashed. Then go backwards from there and look for anything su****ious.
If that doesn't help, you can set WINEDEBUG to "+all", but that might be overkill.
See if you can attach the log file to the bug report or make it available in some way so I can take a peek

Oh, and more thing. Check the awesomium's log file too, maybe it might contain something that could give clues of what's going wrong.

[Lliers]

I've found that the 1.3.xx series has so many changes that some old stuff that used to work no longer works. I would recommend that people download the stable Wine 1.2.2 package and apply the 3 patches (one for Awesomium.dll crash on start, one for RawDeviceInput, one to prevent AwesomiumProcess.exe not to crash -- the last, I think had no patch last I checked, and I had to go in and delete the code myself), build all the dependencies (if you don't have them already built by a package manager) and build Wine 1.2.2.

AO runs fine. You can open the in-game store. You can mouse-look and mouse-steer. However, the problem is that none (or maybe only 1) of these patches will ever make it into wine's codebase in their current state.

The fix for the Awesomium.dll crash changes the return value of one of the stub functions. The return value seems to work because it lies to the game saying, "Oh, you want notification of an IP Address change? Sure hold on... ... ..." instead of "Oh, you want notification of an IP Address change? We don't do that yet." I don't know how this change will affect other programs, but I doubt wine devs will bless this kind of thing. The correct solution (ie. the one likely to get blessed and committed) will be to actually implement the function.

The RawDevice patch is badly coded. If you follow the bug, you will see that someone else commented that it is badly coded and probably not the best implementation.

The fix that allows the in-game store to work basically isolates the part of wine that is offensive to AwesomiumProcess.exe and comments it out. But it looks like it basically blows away any ability to debug with the resulting version of wine.

Although things have been looking up for AO on wine, there's still much work to be done. I would like to express my gratitude to all those wine-devs that have been looking into this for us.

[Marebone]

AO runs fine. You can open the in-game store. You can mouse-look and mouse-steer. However, the problem is that none (or maybe only 1) of these patches will ever make it into wine's codebase in their current state.

I concur, the patches are at best hacks to get the AO working, if AO's players here don't take more proactive role about this and starting push things forward then AO might never work without those patches anymore.

The fix for the Awesomium.dll crash changes the return value of one of the stub functions. The return value seems to work because it lies to the game saying, "Oh, you want notification of an IP Address change? Sure hold on... ... ..." instead of "Oh, you want notification of an IP Address change? We don't do that yet." I don't know how this change will affect other programs, but I doubt wine devs will bless this kind of thing. The correct solution (ie. the one likely to get blessed and committed) will be to actually implement the function.

Can you or Bratch contact someone at Wine's end and ask what it would require to get that patch to codebase? Do you need to implement the function for real or is that change of return value enough? And is there something else that needs to be done?

The fix that allows the in-game store to work basically isolates the part of wine that is offensive to AwesomiumProcess.exe and comments it out. But it looks like it basically blows away any ability to debug with the resulting version of wine.

I'm trying to poke around with this one and see if I can figure out the reason why it crashes. For now, it seems that the call stack pointers are somehow invalid and the RtlCaptureStackBackTrace function tries to read data from those invalid pointers causing an access violation exception. An easy fix could be to wrap the offending code in a __try-__except block and see if it catches the exception before stuff breaks, but dunno...

[raw_fox]

I love penguins !!!

[Lliers]

In case people haven't already figured this all out yet: this is basically what I've pieced together to get AO running in Wine and seems to work on Mac and Linux all collected in one place. Wine should only be built as a 32-Bit binary, regardless of whether you are on a 32- or 64-bit Linux or Mac OS X. Thus, all dependencies must be built as 32-bit as well. Do not attempt to configure and build 64-Bit Wine, even if you are on a 64-bit machine.

As of this writing, AO still doesn't work in the newly released Crossover 10.0 and as far as I know, no Linux distribution will automatically install a version of Wine that will run AO using just a package manager.

1) Choose which Wine version you want to install: Stable 1.2.3 or Developmental 1.3.xx and download it and build the dependencies or install them all via a package manager. If you are on a 64-bit machine and your package manager installs 64-bit binaries, you will need some way to install 32-bit versions of all the dependencies, whether it means creating a separate tree using the package manager or downloading and compiling all the dependencies yourself.

2) "Fix" the Wine source code to run AO.

2a) For Wine 1.2.3:

Apply the patches:

http://bugs.winehq.org/attachment.cgi?id=32705 (RawInputDevices)

2b) for Wine 1.3.xx

Apply the patch:

http://bugs.winehq.org/attachment.cgi?id=33905 (RawInputDevices)

3) Build and install Wine. (Go make a sandwich, troll forums, etc...)

4) Use "wine notepad" to create a fresh WINEPREFIX with a correct drive map. (not sure why, but this seems like the best way to create a WINEPREFIX)

5) use "winecfg" and open the Sound tab to configure the audio drivers.

6) Download winetricks from http://www.kegel.com/wine/winetricks and use winetricks to install the following using winetricks:

vcrun2005      (or vcrun2008 -- needed for AO)
ie6            (may be optional, but might enable patching***)
corefonts      (and optionally fontfix)
vcrun6         (if you plan on using ClickSaver)
dotnet20       (if you plan on using AOIS, Vha.Chat, etc...)

7) Install/copy/or otherwise get your Anarchy Online installation onto this system somehow, and fire it up with:

cd "/path/to/Funcom/Anarchy Online"
wine Anarchy.exe

On Wine 1.3.x, if your screen is black and only updates when you drag other windows in front of your AO client window, then use winetricks and add the following registry tweak:

orm=backbuffer

AO should not crash at start-up. Mouse-look and mouse-steer should work. Opening and using the new AO Item Store should not crash AO or wine. Long and complicated. I know. But everything seems to work.

*** In my experience, AO does not patch correctly and has problems writing preferences if your AO directory is on a FAT-32 partition. Things work right if everything is on a native partition.

[raw_fox]

If ayone has questions or problems to make it work, just ask here ^^

Lliers does the __TRY exception in signal_i386.c dont work for you ?
Anyways, nice effort

[Marebone]

Very nice instructions Lliers!

Raw_fox and I had some serious attempt to find out why AwesomiumProcess crashes even with the fix to dlls/ntdll/signal_i386.c. Finally raw_fox managed to get rid of the crash by installing corefonts via winetricks. I was also able reproduce the crash by uninstalling ttf-mscorefonts-installer via Ubuntu's package manager.

So, it appears that if the corefonts is not installed the process crashes always. So that is not optional.

Fix for dlls/ntdll/signal_i386.c is still required though, have corefonts or not.

[Lliers]

If ayone has questions or problems to make it work, just ask here ^^

Lliers does the __TRY exception in signal_i386.c dont work for you ?
Anyways, nice effort

It might, but I got the "delete-everything-and-return-0" thing working, so I declared success on that one until someone can track down the actual problem. I didn't need to install corefonts to prevent the in-game browser from crashing because I guess my distribution includes the problematic font(s), but I included the winetricks corefonts in my instructions for completeness (part of step 6).

[DocJones]

Heyas,

Good work sofar I am having some troubles appling the patches to MacPorts wine-devel branch, but i am trying it out so. I will revert with infos if i got some news from it

regards
/Z

EDIT: Can you pass along a unified diff file for the signal_i386.c modification? This would help. Thanks!

[Lliers]

--- wine-1.2.2/dlls/ntdll/signal_i386.c	2010-12-03 10:37:15.000000000 -0800
+++ wine-1.2.2_patched/dlls/ntdll/signal_i386.c	2011-01-07 07:11:47.000000000 -0800
@@ -2420,30 +2420,7 @@
  */
 USHORT WINAPI RtlCaptureStackBackTrace( ULONG skip, ULONG count, PVOID *buffer, ULONG *hash )
 {
-    CONTEXT context;
-    ULONG i;
-    ULONG *frame;
-
-    RtlCaptureContext( &context );
-    if (hash) *hash = 0;
-    frame = (ULONG *)context.Ebp;
-
-    while (skip--)
-    {
-        if (((void *)frame < NtCurrentTeb()->Tib.StackLimit) ||
-            ((void *)(frame + 1) >= NtCurrentTeb()->Tib.StackBase)) return 0;
-        frame = (ULONG *)*frame;
-    }
-
-    for (i = 0; i < count; i++)
-    {
-        if (((void *)frame < NtCurrentTeb()->Tib.StackLimit) ||
-            ((void *)(frame + 1) >= NtCurrentTeb()->Tib.StackBase)) break;
-        buffer[i] = (void *)frame[1];
-        if (hash) *hash += frame[1];
-        frame = (ULONG *)*frame;
-    }
-    return i;
+    return 0;
 }

[DocJones]

Awesome, thanks. gonna try this out now.

regards
/Z

[DocJones]

Heyas,

i created patchfiles for all five patches (iphlpapi_main.c, signal_i387.c, Makefile.in, winuser.h and input.c) and rebuild my macport wine-devel 1.3.12 distro.

:info:extract --->  Extracting wine-1.3.12.tar.bz2
:debug:extract setting option extract.args to '/opt/local/var/macports/distfiles/wine/wine-1.3.12.tar.bz2'
:debug:extract Environment: CPATH='/opt/local/include' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-devel/work/.CC_PRINT_OPTIONS' LIBRARY_PATH='/opt/local/lib' CC_PRINT_OPTIONS='YES' MACOSX_DEPLOYMENT_TARGET='10.6'
:debug:extract Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-devel/work" && /usr/bin/bzip2 -dc '/opt/local/var/macports/distfiles/wine/wine-1.3.12.tar.bz2' | /usr/bin/gnutar --no-same-owner -xf -'
:debug:patch patch phase started at Tue Feb  1 20:56:16 CET 2011
:debug:patch Executing org.macports.patch (wine-devel)
:msg:patch --->  Applying patches to wine-devel
:info:patch --->  Applying /opt/local/var/macports/sources/rsync.macports.org/release/ports/x11/wine-devel/files/patch-dlls-iphlpapi-iphlpapi_main.c.diff
:debug:patch Environment: CPATH='/opt/local/include' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-devel/work/.CC_PRINT_OPTIONS' LIBRARY_PATH='/opt/local/lib' CC_PRINT_OPTIONS='YES' MACOSX_DEPLOYMENT_TARGET='10.6'
:debug:patch Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-devel/work/wine-1.3.12" && /usr/bin/patch -p0'
:info:patch patching file dlls/iphlpapi/iphlpapi_main.c
:info:patch Hunk #1 succeeded at 2032 with fuzz 1.
:info:patch --->  Applying /opt/local/var/macports/sources/rsync.macports.org/release/ports/x11/wine-devel/files/patch-dlls-ntdll-signal_i386.c.diff
:debug:patch Environment: CPATH='/opt/local/include' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-devel/work/.CC_PRINT_OPTIONS' LIBRARY_PATH='/opt/local/lib' CC_PRINT_OPTIONS='YES' MACOSX_DEPLOYMENT_TARGET='10.6'
:debug:patch Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-devel/work/wine-1.3.12" && /usr/bin/patch -p0'
:info:patch patching file dlls/ntdll/signal_i386.c
:info:patch Hunk #1 succeeded at 2422 (offset 2 lines).
:info:patch --->  Applying /opt/local/var/macports/sources/rsync.macports.org/release/ports/x11/wine-devel/files/patch-dlls-user32-Makefile.in.diff
:debug:patch Environment: CPATH='/opt/local/include' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-devel/work/.CC_PRINT_OPTIONS' LIBRARY_PATH='/opt/local/lib' CC_PRINT_OPTIONS='YES' MACOSX_DEPLOYMENT_TARGET='10.6'
:debug:patch Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-devel/work/wine-1.3.12" && /usr/bin/patch -p0'
:info:patch patching file dlls/user32/Makefile.in
:info:patch --->  Applying /opt/local/var/macports/sources/rsync.macports.org/release/ports/x11/wine-devel/files/patch-dlls-user32-input.c.diff
:debug:patch Environment: CPATH='/opt/local/include' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-devel/work/.CC_PRINT_OPTIONS' LIBRARY_PATH='/opt/local/lib' CC_PRINT_OPTIONS='YES' MACOSX_DEPLOYMENT_TARGET='10.6'
:debug:patch Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-devel/work/wine-1.3.12" && /usr/bin/patch -p0'
:info:patch patching file dlls/user32/input.c
:info:patch --->  Applying /opt/local/var/macports/sources/rsync.macports.org/release/ports/x11/wine-devel/files/patch-include-winuser.h.diff
:debug:patch Environment: CPATH='/opt/local/include' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-devel/work/.CC_PRINT_OPTIONS' LIBRARY_PATH='/opt/local/lib' CC_PRINT_OPTIONS='YES' MACOSX_DEPLOYMENT_TARGET='10.6'
:debug:patch Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-devel/work/wine-1.3.12" && /usr/bin/patch -p0'
:info:patch patching file include/winuser.h
:info:patch Hunk #1 succeeded at 491 (offset 4 lines).

I created a fresh wine-prefix and added ie6, vcrun2005 and corefonts to it.

It still seems to hang at NotifyAddrChange:

...
fixme:d3d:swapchain_init Add OpenGL context recreation support to context_validate_onscreen_formats
fixme:d3d_surface:IWineD3DBaseSurfaceImpl_Blt Can't handle WINEDDBLT_ASYNC flag right now.
fixme:heap:HeapSetInformation 0x0 1 0x0 0
fixme:iphlpapi:NotifyAddrChange (Handle 0x87ef490, overlapped 0x2e79010): stub

I am desperate Seems i did something wrong, but can't find out where... Someone with macport skills out there?

regards
/Z

[Marebone]

Can you check that the file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org _release_ports_x11_wine-devel/work/wine-1.3.12/dlls/iphlpapi/iphlpapi_main.c that NotifyAddrChange function really returns ERROR_IO_PENDING and not ERROR_NOT_SUPPORTED.

Also check if Anarchy Online\awesomium.log contains any errors.

EDIT: And, are you sure that you actually compiled the wine? I can't see any logs about it...

[DocJones]

ofc, here is the iphlpapi_main.c part:

marc@iMac:~/AO/drive_c/Programme/Anarchy Online - Clean 18.2.2> grep -5 NotifyAddrChange /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-devel/work/wine-1.3.12/dlls/iphlpapi/iphlpapi_main.c


/******************************************************************
 *    CancelIPChangeNotify (IPHLPAPI.@)
 *
 * Cancel a previous notification created by NotifyAddrChange or
 * NotifyRouteChange.
 *
 * PARAMS
 *  overlapped [In]  overlapped structure that notifies the caller
 *
--
  return ERROR_NOT_SUPPORTED;
}


/******************************************************************
 *    NotifyAddrChange (IPHLPAPI.@)
 *
 * Notify caller whenever the ip-interface map is changed.
 *
 * PARAMS
 *  Handle     [Out] handle usable in asynchronous notification
--
 *  Failure: error code from winerror.h
 *
 * FIXME
 *  Stub, returns ERROR_NOT_SUPPORTED.
 */
DWORD WINAPI NotifyAddrChange(PHANDLE Handle, LPOVERLAPPED overlapped)
{
  FIXME("(Handle %p, overlapped %p): stub\n", Handle, overlapped);
  return ERROR_IO_PENDING;
}

and here is the log:

marc@iMac:~/AO/drive_c/Programme/Anarchy Online - Clean 18.2.2> cat awesomium.log 
[37:47:31282:FATAL:network_change_notifier_win.cc(54)] Check failed: 997L == ret (997 vs. 50)

since the log-line hasnt changed at all, i fear something with patching wasn't working properly... ? I can't see where...

[Marebone]

Looks like the file was patched correctly.
Try next to uninstall wine. Make sure that AO doesn't start after that.

Then make and install the wine from patched sources again.

[Lliers]

DocJ? Are you really sure it's hanging? Can you try dragging another window (like say the xterm from which you started wine) over the client window and see if the parts that the window passes over shows up?

If so, then you can fix it with "winetricks orm=backbuffer"

[DocJones]

Yeah, i tried dragging a window over it, but to no avail. Also, the stdout fixme line with NotifyAddrChange hints me towards something while patching failed. Unfortunately, using macports its hard to verify changes made to the code in the final staged version.

I will try the following:
- Modify the "fixme" output to clearly see if it comes from the patched version
- recreate a new WINEPREFIX after activating the (hopefully) patched version
- If both points work, but i still get the black screen i will do the "copy-dll" trick to get into the game and verify the mouse-steering problem.

I will revert back here with any additional informations...

thanks and regards
/Z

[Marebone]

- Modify the "fixme" output to clearly see if it comes from the patched version

yes, I think this choice is good way to check if you're really using correct wine binaries.

Also, in Terminal, give command:

which wine

It will tell where the the wine executable lies.

Check its modified date that it looks like it was the one that you had build.

You can also search with Finder for iphlpapi.dll (or was it iphlpapi.dll.so, can't remember) and check its modified date, it should change when you modify iphlpapi_main.c and build again.