May 2014 - Wine-Bugs - list.winehq.org

[Bug 36042] Grand Theft Auto IV (Steam) crashes on startup with native xlive (GFWL 3.x)

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=36042 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Grand Theft Auto IV (Steam) |Grand Theft Auto IV (Steam) |crashes on startup with |crashes on startup with |native xlive |native xlive (GFWL 3.x) --- Comment #11 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, reassigning as dupe of bug 33034 since this is about native GFWL. I already tested a fix successfully with GTA IV Steam. Regards *** This bug has been marked as a duplicate of bug 33034 *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 31, 2014

[Bug 33034] Multiple GFWL (Games For Windows Live) 3.x games crash or exit silently on startup (DiRT 2/3, GTA IV Steam)

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=33034 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation CC| |focht(a)gmx.net Component|-unknown |ntdll Summary|DiRT 3 fails at launch |Multiple GFWL (Games For | |Windows Live) 3.x games | |crash or exit silently on | |startup (DiRT 2/3, GTA IV | |Steam) --- Comment #3 from Anastasius Focht <focht(a)gmx.net> --- Hello Andrey, it's Microsoft Games for Windows LIVE (GFWL) 3.x being the deal breaker here. Your terminal output and the app behaviour (silent exit) indicates this. --- snip --- ... fixme:advapi:RegisterTraceGuidsA (0x143ce70, (nil), {d5b9ac76-d546-4891-bb8c-bfd865e5c7d5}, 3, 0x1982b00, (null), (null), 0x198f850,): stub fixme:advapi:RegisterEventSourceW ((null),L"XLive"): stub fixme:advapi:ReportEventW (0xcafe4242,0x0002,0x0000,0x80000002,(nil),0x0004,0x00000000,0x33cfb4,(nil)): stub fixme:advapi:DeregisterEventSource (0xcafe4242) stub fixme:advapi:UnregisterTraceGuids 0: stub --- snip --- I bought 'DiRT 2' a few days ago which has the same issue and spent some hours debugging it. Tidbit: the game has SecuROM copy protection which works nicely with Wine. --- snip --- -=[ ProtectionID v0.6.5.5 OCTOBER]=- (c) 2003-2013 CDKiLLER & TippeX Build 31/10/13-21:09:09 Ready... Scanning -> C:\Program Files\Codemasters\DiRT2\dirt2_game.exe File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 22983984 (015EB530h) Byte(s) -> File Appears to be Digitally Signed @ Offset 015EA000h, size : 01530h / 05424 byte(s) [File Heuristics] -> Flag : 00000100000000001001000000000100 (0x04009004) [Entrypoint Section Entropy] : 6.49 [Debug Info] Characteristics : 0x0 | TimeDateStamp : 0x4B042091 | MajorVer : 0 / MinorVer : 0 -> (0.0) Type : 2 -> CodeView | Size : 0x4A (74) AddressOfRawData : 0xFEBEB8 | PointerToRawData : 0xFEBEB8 CvSig : 0x53445352 | SigGuid 3CD8ECB5-3B2E-4742-B349A785D8FB0F84 Age : 0x1 | Pdb : d:\perforce\dirt2\programming\data\dirt2_game.pdb [!] Games For Windows Live detected ! [CompilerDetect] -> Visual C++ 8.0 (Visual Studio 2005) - Scan Took : 1.196 Second(s) [00000070Ch tick(s)] [533 scan(s) done] Scanning -> C:\Program Files\Codemasters\DiRT2\dirt2.exe File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 6055256 (05C6558h) Byte(s) -> File Appears to be Digitally Signed @ Offset 05C5000h, size : 01558h / 05464 byte(s) [File Heuristics] -> Flag : 00000000000000000000000000000101 (0x00000005) [Entrypoint Section Entropy] : 6.62 [!] SecuROM Detected - Version 07.40.0009 [!] Possible CD/DVD-Key or Serial Check -> Invalid serial [CompilerDetect] -> Visual C++ 7.1 (Visual Studio 2003) - Scan Took : 0.543 Second(s) [00000021Fh tick(s)] [533 scan(s) done] --- snip --- The game installs .NET Framework 3.5 and GFWL 3.x on its own. After startup it silently exits at the point where XLive is being initialized. --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/Codemasters/DiRT2 $ WINEDEBUG=+tid,+seh,+relay,+server,+snoop wine ./dirt2.exe >>log.txt 2>&1 ... 0009:Call KERNEL32.CreateProcessW(00000000,7ffc0000 L"\"dirt2_game.exe\" ",00000000,00000000,00000001,00000204,00000000,0091e0f0 L"C:\\Program Files\\Codemasters\\DiRT2",0091fb74,0040fd40) ret=004022c5 ... 002c: init_process_done() = 0 ... 0009:Ret KERNEL32.CreateProcessW() retval=00000001 ret=004022c5 ... 002c:Call KERNEL32.OpenFileMappingW(00000004,00000000,0033d854 L"-=[SMS_dirt2_game.exe_SMS]=-") ret=00b062de ... 002c:Ret KERNEL32.OpenFileMappingW() retval=00000140 ret=00b062de ... 002c:Call PE DLL (proc=0x1c6a924,module=0x1c20000 L"xlive.dll",reason=PROCESS_ATTACH,res=0x1) ... 002c:CALL xlive.5297(<unknown, check return>) ret=006af424 002c:Call advapi32.RegisterTraceGuidsA(01d372c6,00000000,01c260ec,00000003,02281aa4,00000000,00000000,0228d1a0) ret=01d3734b 002c:fixme:advapi:RegisterTraceGuidsA (0x1d372c6, (nil), {d5b9ac76-d546-4891-bb8c-bfd865e5c7d5}, 3, 0x2281aa4, (null), (null), 0x228d1a0): stub 002c:Ret advapi32.RegisterTraceGuidsA() retval=00000000 ret=01d3734b ... 002c:Call KERNEL32.CreateEventW(00000000,00000001,00000000,00162830 L"Global\\XLive-S-1-5-21-0-0-0-1000") ret=01d16843 ... 002c:Call KERNEL32.CreateFileW(0033defc L"C:\\windows\\system32\\xlive.dll.CAT",80000000,00000001,00000000,00000003,00000080,00000000) ret=01d086c5 ... 002c:Call KERNEL32.CreateFileW(0033dcf4 L"C:\\windows\\system32\\xlive.dll",80000000,00000001,00000000,00000003,00000080,00000000) ret=01d08103 ... 002c:Call KERNEL32.K32GetModuleInformation(ffffffff,01c20000,0033da38,0000000c) ret=01d08374 ... 002c:Ret KERNEL32.K32GetModuleInformation() retval=00000001 ret=01d08374 ... 002c:Call KERNEL32.K32EnumProcessModules(ffffffff,0033d8d8,000003fc,0033dce4) ret=0225a64c ... 002c:Ret KERNEL32.K32EnumProcessModules() retval=00000001 ret=0225a64c ... 002c:Call KERNEL32.CreateFileW(0033dcf8 L"C:\\Program Files\\Codemasters\\DiRT2\\dirt2_game.exe.CAT",80000000,00000001,00000000,00000003,00000080,00000000) ret=01d086c5 ... 002c:Call KERNEL32.CreateFileW(0033df00 L"C:\\Program Files\\Codemasters\\DiRT2\\dirt2_game.exe.CFG",80000000,00000001,00000000,00000003,00000080,00000000) ret=01d2dfa7 ... 002c:Call oleaut32.SysAllocString(001c6970 L"<Liveconfig>\r\n\t<titleid>434D0820</titleid>\r\n\t<titleversion>10000085</titleversion>\r\n\t<enableCrossPlatformSystemLink>false</enableCrossPlatformSystemLink>\r\n\t<SSA>1</SSA>\r\n\t<lankey>xxxxx</lankey>\r\n\t<OriginalXliveTarget>3.1.0089.0</OriginalXliveTarget>\r\n\t<"...) ret=01d35c18 ... 002c: load_dll( mapping=0000, base=7cf90000, name=001c9b60, size=790528, dbg_offset=0, dbg_size=0, filename=L"C:\\windows\\system32\\msxml3.dll" ) 002c: load_dll() = 0 ... 002c:Call KERNEL32.CreateFileW(0033df00 L"C:\\Program Files\\Codemasters\\DiRT2\\dirt2_game.exe",80000000,00000001,00000000,00000003,00000080,00000000) ret=01d08103 ... 002c:Call KERNEL32.CreateFileW(0033dcf8 L"C:\\Program Files\\Codemasters\\DiRT2\\dirt2_game.exe.CAT",80000000,00000001,00000000,00000003,00000080,00000000) ret=01d08a91 ... 002c:Call KERNEL32.LoadLibraryW(0033d634 L"C:\\Program Files\\Codemasters\\DiRT2\\dirt2_game.exe") ret=01d0a6fb 002c:Ret KERNEL32.LoadLibraryW() retval=00400000 ret=01d0a6fb 002c:Call KERNEL32.lstrcmpiW(001a48fe L"dirt2_game.exe",01c22f10 L"shimeng.dll") ret=01d0a019 002c:Ret KERNEL32.lstrcmpiW() retval=ffffffff ret=01d0a019 ... --- snip --- xlive.5297 API entry = XLiveInitializeEx() Xlive validates certain executables on disk and in memory (process module list) as part of anti-tampering measure (digital signature). The problem is not really visible in trace log and disguised due to the way these large encrypted code sections work, which are part of the DRM protection scheme. The difficulty here is that even errors are propagated through a number of "asm" continuations/thunks which consist of dynamically decrypting executable code. Lots of code with no win32 API usage at all and values being hidden in intermediate memory locations. Furthermore, error paths are sometimes disguised by additional checks/API calls that are also present in "working" case, hence no linear "error out" exit code path. For example the creation of a debugger "zapper" thread which seemed suspicious but in the end turned out to be perfectly fine: --- snip --- ... 002c:Call KERNEL32.CreateThread(00000000,00000000,01e175f8,00000154,00000000,0033e144) ret=02278d2c 002c: *fd* 14 <- 124 002c: new_thread( access=001fffff, attributes=00000000, suspend=1, request_fd=14 ) 002c: new_thread() = 0 { tid=002d, handle=0164 } 002c: resume_thread( handle=0164 ) 002c: resume_thread() = 0 { count=1 } 002d: *fd* 18 <- 139 002c:Ret KERNEL32.CreateThread() retval=00000164 ret=02278d2c 002d: *fd* 20 <- 141 002d: init_thread( unix_pid=19894, unix_tid=19896, debug_level=1, teb=7ffd4000, entry=01e175f8, reply_fd=18, wait_fd=20, cpu=x86 ) 002c:Call KERNEL32.WaitForSingleObject(00000164,ffffffff) ret=0227af5c ... 002d:Starting thread proc 0x1e175f8 (arg=0x154) 002d:Call KERNEL32.SuspendThread(00000154) ret=01e1761e 002d: suspend_thread( handle=0154 ) 002c: *sent signal* signal=10 002d: suspend_thread() = 0 { count=0 } 002d:Ret KERNEL32.SuspendThread() retval=00000000 ret=01e1761e 002d:Call KERNEL32.GetThreadContext(00000154,0440e788) ret=01e1763b 002c: set_suspend_context( context={cpu=x86,eip=f77b742e,esp=0033dca4,ebp=0033dcf8,eflags=00200296,cs=0023,ss=002b,ds=002b,es=002b,fs=0063,gs=006b,eax=00000003,ebx=00000006,ecx=0033dcd8,edx=00000010,esi=0033e0c0,edi=0033e108,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,fp.ctrl=ffff027f,fp.status=ffff0020,fp.tag=ffffffff,fp.err_off=7ce96bde,fp.err_sel=00000023,fp.data_off=7cf7b2b8,fp.data_sel=ffff002b,fp.cr0npx=00000020,fp.reg0=0,fp.reg1=0.660168,fp.reg2=0.961903,fp.reg3=0.85725,fp.reg4=0.5,fp.reg5=0,fp.reg6=0,fp.reg7=-0,extended={...} ) 002c: set_suspend_context() = 0 002d: get_thread_context( handle=0154, flags=00000010, suspend=1 ) 002c: *signal* signal=19 002d: get_thread_context() = 0 { self=0, context={cpu=x86,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000} } 002c: select( flags=2, cookie=7ffdb33c, timeout=0, prev_apc=0000, result={}, data={} ) 002d:Ret KERNEL32.GetThreadContext() retval=00000001 ret=01e1763b 002c: select() = PENDING { timeout=1cf7c3475b620f0 (+0.0000000), call={APC_NONE}, apc_handle=0000 } 002d:Call KERNEL32.ResumeThread(00000154) ret=01e17677 002d: resume_thread( handle=0154 ) 002c: *wakeup* signaled=258 002d: resume_thread() = 0 { count=1 } 002d:Ret KERNEL32.ResumeThread() retval=00000001 ret=01e17677 002d:Call KERNEL32.CloseHandle(00000154) ret=01e1767e 002c: get_suspend_context( ) 002c: get_suspend_context() = 0 { context={cpu=x86,eip=f77b742e,esp=0033dca4,ebp=0033dcf8,eflags=00200296,cs=0023,ss=002b,ds=002b,es=002b,fs=0063,gs=006b,eax=00000003,ebx=00000006,ecx=0033dcd8,edx=00000010,esi=0033e0c0,edi=0033e108,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,fp.ctrl=ffff027f,fp.status=ffff0020,fp.tag=ffffffff,fp.err_off=7ce96bde,fp.err_sel=00000023,fp.data_off=7cf7b2b8,fp.data_sel=ffff002b,fp.cr0npx=00000020,fp.reg0=0,fp.reg1=0.660168,fp.reg2=0.961903,fp.reg3=0.85725,fp.reg4=0.5,fp.reg5=0,fp.reg6=0,fp.reg7=-0,extended=...} } 002d: close_handle( handle=0154 ) 002d: close_handle() = 0 002d:Ret KERNEL32.CloseHandle() retval=00000001 ret=01e1767e 002d: terminate_thread( handle=fffffffe, exit_code=-206558064 ) 002d: terminate_thread() = 0 { self=1, last=0 } ... 002d: *killed* exit_code=-206558064 002c: *wakeup* signaled=0 002c:Ret KERNEL32.WaitForSingleObject() retval=00000000 ret=0227af5c 002c:Call KERNEL32.GetExitCodeThread(00000164,0033e14c) ret=0227af67 002c: get_thread_info( handle=0164, tid_in=0000 ) 002c: get_thread_info() = 0 { pid=002b, tid=002d, teb=7ffd4000, affinity=0000000f, creation_time=1cf7c3475b5f9a4 (-0.0020170), exit_time=1cf7c3475b644b8 (-0.0000950), exit_code=-206558064, priority=0, last=1 } 002c:Ret KERNEL32.GetExitCodeThread() retval=00000001 ret=0227af67 002c:Call KERNEL32.CloseHandle(00000164) ret=01d1747a 002c: close_handle( handle=0164 ) 002c: close_handle() = 0 002c:Ret KERNEL32.CloseHandle() retval=00000001 ret=01d1747a --- snip --- The "helper" thread explained in a nutshell: 1) suspends main thread 2) examines debug control register dr7, sets thread exit code accordingly 3) zeroes dr0-dr7 unconditionally 4) resumes main thread The thread exit code -206558064 is the "good" one (no HW breakpoint usage detected). A short time later one comes across this: --- snip --- 002c:Call advapi32.RegisterEventSourceW(00000000,01c25ebc) ret=01d3fd1d 002c:fixme:advapi:RegisterEventSourceW ((null),L"XLive"): stub 002c:Ret advapi32.RegisterEventSourceW() retval=cafe4242 ret=01d3fd1d 002c:Call advapi32.ReportEventW(cafe4242,00000002,00000000,80000002,00000000,00000004,00000000,0033d090,00000000) ret=01d3fd5d 002c:fixme:advapi:ReportEventW (0xcafe4242,0x0002,0x0000,0x80000002,(nil),0x0004,0x00000000,0x33d090,(nil)): stub 002c:Ret advapi32.ReportEventW() retval=00000001 ret=01d3fd5d 002c:Call advapi32.DeregisterEventSource(cafe4242) ret=01d3fd7d 002c:fixme:advapi:DeregisterEventSource (0xcafe4242) stub 002c:Ret advapi32.DeregisterEventSource() retval=00000001 ret=01d3fd7d --- snip --- Wine doesn't decode/trace the Event API parameters, debugger dumped values: --- snip --- 0033D090 0033DA54 UNICODE "dirt2_game.exe" 0033D094 0033E0EC UNICODE "1, 0, 0, 0" 0033D098 0033DC5C UNICODE "3.1.0099.0 (WGX_XLIVE_V3.01_RTM.091106-1035) C:\windows\system32\xlive.dll" 0033D09C 0013FD90 UNICODE "0x80004005 Games for Windows - LIVE DLL C:\windows\system32\msidcrl40.dll 5.000.737.6" --- snip --- Finally XLive entry point returns with generic 0x80004005 error code: --- snip --- 002c:RET xlive.5297(0033e87c,31005900) retval=80004005 ret=006af424 --- snip --- After some hours of debugging this garbage I found the problem. Certain mapped modules (main executable, xlive dlls) are examined as part of in-memory tampering validation (PE headers/sections populated). Before that, general image information is retrieved from OS loader (PEB/ldr structures) using 'K32GetModuleInformation': mapped image base address, image size, entry point address --- snip --- 002c:Call KERNEL32.K32GetModuleInformation(ffffffff,00400000,0033d61c,0000000c) ret=01d08374 002c: get_process_info( handle=ffffffff ) 002c: get_process_info() = 0 { pid=002b, ppid=0008, affinity=0000000f, peb=7ffdf000, start_time=1cf7c3475214200 (-0.9735880), end_time=0, exit_code=259, priority=2, cpu=x86, debugger_present=0 } 002c: read_process_memory( handle=ffffffff, addr=7ffdf00c ) 002c: *signal* signal=19 002c: read_process_memory() = 0 { data={c0,d2,ce,7b} } 002c: read_process_memory( handle=ffffffff, addr=7bced2cc ) 002c: *signal* signal=19 002c: read_process_memory() = 0 { data={d8,55,11,00} } 002c: read_process_memory( handle=ffffffff, addr=001155d8 ) 002c: *signal* signal=19 002c: read_process_memory() = 0 { data={58,01,11,00,cc,d2,ce,7b,38,e8,11,00,b0,c1,11,00,c8,a0,1c,00,80,4a,13,00,00,00,40,00,00,00,00,00,00,f0,81,01,62,00,64,00,38,56,11,00,1c,00,1e,00,7e,56,11,00,00,00,08,00,ff,ff,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00} } 002c:Ret KERNEL32.K32GetModuleInformation() retval=00000001 ret=01d08374 ... --- snip --- Unfortunately there is a little thing missing that will do the harm later: the ldr module structure for the main executable doesn't have the entry point member set ('ldr.EntryPoint' -> NULL). Little thing can make a big impact. ;-) Before you quick-hack Wine's loader: be careful, there is code that _relies_ on the main exe module entry point member being NULL to have loader notifications work (and other nasty surprises). Anyway, I tested a fix and it made GFWL work. Unfortunately I own very few GFWL games to play with but it made _all_ of them work (with GFWL in-game logins). No native overrides, no XLiveless replacements and/or other Wine hacks in WINEPREFIX. * DiRT 2 (you need 'directx forcedx9="true"' game config file setting to work around DirectX11 insufficiency) * GTA IV Steam (without my fix you would get the infamous "XNetStartup failed - Please re-boot your system and/or re-install the game 10093" message + crash) NOTE: There is a delay of several seconds on startup due to GFWL - this is expected (shortly after 'C:\\windows\\system32\\XLive\\sqmapi.dll' is loaded and harmless 'winhttp' fixme message is shown in terminal). $ wine --version wine-1.7.19-71-g94ccd61 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 31, 2014

[Bug 36617] boost::wregex causes programs to crash - needs wcsxfrm()

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=36617 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|boost::wregex causes |boost::wregex causes |programs to crash |programs to crash - needs | |wcsxfrm() -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 31, 2014

[Bug 36617] boost::wregex causes programs to crash

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=36617 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Component|-unknown |msvcrt Ever confirmed|0 |1 --- Comment #2 from Nikolay Sivov <bunglehead(a)gmail.com> --- --- wine: Call from 0x7b84aa6b to unimplemented function msvcrt.dll.wcsxfrm, aborting --- Confirming. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 31, 2014

[Bug 36617] boost::wregex causes programs to crash

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=36617 --- Comment #1 from Daniel Mensinger <d.m.bugs(a)web.de> --- Created attachment 48669 --> http://bugs.winehq.org/attachment.cgi?id=48669 The wine output -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 31, 2014

[Bug 36617] New: boost::wregex causes programs to crash

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=36617 Bug ID: 36617 Summary: boost::wregex causes programs to crash Product: Wine Version: 1.7.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: d.m.bugs(a)web.de Created attachment 48668 --> http://bugs.winehq.org/attachment.cgi?id=48668 The test program boost::wregex causes (at least my) programs to crash. I made a short test program and attatched it. This problems occurs while the boost::wregex object is created, but only with the wregex version. The normal ones (boost::regex) are working fine. I compiled this program and also boost (v1.55.0 from the AUR) with MinGW on my Arch Linux. I tested the compiled program also an my Windows 7 VM where it worked without any errors or warnings. Exactly the same error occurs when I use the std version of boost::wregex OS: Arch Linux MinGW: x86_64-w64-mingw32-g++ (GCC) 4.9.0 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Sorry for my bad English :) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 31, 2014

[Bug 35118] Guild Wars 2 runs slow

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=35118 --- Comment #5 from orleans <micet2004-winehq(a)yahoo.de> --- Created attachment 48667 --> https://bugs.winehq.org/attachment.cgi?id=48667 Logfile from Guildwars removed many double entries to reduce the filesize from 1.8MB to 32kB > fixme:keyboard:X11DRV_LoadKeyboardLayout L"00000409", 0000: stub! > fixme:keyboard:X11DRV_MapVirtualKeyEx keyboard layout (nil) is not supported and > fixme:d3d:resource_check_usage Unhandled usage flags 0x8. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 31, 2014

[Bug 35118] Guild Wars 2 runs slow

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=35118 orleans <micet2004-winehq(a)yahoo.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|1.7.8 |1.7.19 --- Comment #4 from orleans <micet2004-winehq(a)yahoo.de> --- (In reply to Jarkko K from comment #3) > That's error because ati driver has inbuilt variable which is set too low. > It's not hardware problem it's driver issue. > > orleans do you still have this issue with the game? - Ubuntu 14.04 (I changed the Ticket version to this) - Wine 1.7.19 (Yes PlayOnLinux) The Game Runs a little bit better on 15fps fog is also a solid and in the tested situation it's black. The Logfile I attachet nows was original 1.8MB because of alot of duble entries. > fixme:keyboard:X11DRV_LoadKeyboardLayout L"00000409", 0000: stub! > fixme:keyboard:X11DRV_MapVirtualKeyEx keyboard layout (nil) is not supported and > fixme:d3d:resource_check_usage Unhandled usage flags 0x8. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 31, 2014

[Bug 24513] Background in VirtuaGirl is always black

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=24513 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Austin English <austinenglish(a)gmail.com> --- $ rm -rf ~/.wine $ winetricks -q vb5run vb6run ie7 wmp9 then installed and run. A dancer appears, background is transparent. There's some minor artifacting at the edges, but I haven't seen it on native, could be the app. wine-1.7.19-70-gd6a59f7 I can see the issue with wine-1.3.15 on the same system. Marking fixed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 31, 2014

[Bug 25799] GFWL (Games For Windows Live) Client Crashes at startup

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=25799 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dotnet Status|NEW |RESOLVED URL|http://www.gamesforwindows. |http://download.cnet.com/Ga |com/en-US/download/ |mes-for-Windows-Live/3000-2 | |121_4-10966787.html CC| |focht(a)gmx.net Resolution|--- |FIXED --- Comment #15 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, you have to be careful what GFWL client version you use. Different GFWL versions require different .NET Framework prerequisites hence many problems are just due to incorrect prerequisites. Also don't change the default WinVer of the prefix otherwise you get 'Windows Vista/7+' related .NET bugs. I tested an older GFWL 3.x client with .Net Framework 3.5 installation and known .NET workarounds for WPF (bug 34764) in 32-bit WINEPREFIX and it works as designed. The client starts and shows a dialog window, stating 'Connection error - ... problem with LIVE-Service'. This is expected as old GFWL has been abandoned and replaced by 'Games for Windows Marketplace' which requires a new client. I'm currently testing a fix for many GFWL games in general, dropping the need for XLiveless and other custom hacks/recipes. $ sha1sum gfwlivesetupmin.exe 82c9fecc67bc55f37cebb61b1e483821988b54cd gfwlivesetupmin.exe $ du -sh gfwlivesetupmin.exe 28M gfwlivesetupmin.exe $ wine --version wine-1.7.19-71-g4e9f19f Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 31, 2014