wine-bugs November 2012

wine-bugs@winehq.org

1 participants
8956 discussions

[Bug 22713] New: it returns error
by wine-bugs＠winehq.org 12 Feb '21

12 Feb '21

http://bugs.winehq.org/show_bug.cgi?id=22713 Summary: it returns error Product: Wine Version: unspecified Platform: x86 URL: http://www.tivibu.com.tr/downloads/Tivibu.exe OS/Version: Mac OS X 10.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: cemyildiz(a)estonya.net Created an attachment (id=28000) --> (http://bugs.winehq.org/attachment.cgi?id=28000) log from darwine the software provided by turkish telecom seems that it doesn't have problem while installation, it even downloads and installs the silverlight too. but after executing the program, it returns error. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 19

[Bug 15655] New: Tournament director doesn't start
by wine-bugs＠winehq.org 12 Feb '21

12 Feb '21

http://bugs.winehq.org/show_bug.cgi?id=15655 Summary: Tournament director doesn't start Product: Wine Version: 1.1.6 Platform: PC URL: http://www.thetournamentdirector.net/download.html OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Depends on: 15654 Created an attachment (id=16714) --> (http://bugs.winehq.org/attachment.cgi?id=16714) +relay in git After bug 15654, Tournament Director still won't run: Few generic errors, but seems this may be the culprit: err:ole:CoGetClassObject class {a6b222ab-a5ea-4899-b230-084657eddc7d} not registered err:ole:CoGetClassObject no class object {a6b222ab-a5ea-4899-b230-084657eddc7d} could be created for context 0x1 which is "Browser Thread State" +relay attached -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 15

[Bug 29600] New: IBankWizard.exe doesn't display embed iexplore
by wine-bugs＠winehq.org 12 Feb '21

12 Feb '21

http://bugs.winehq.org/show_bug.cgi?id=29600 Bug #: 29600 Summary: IBankWizard.exe doesn't display embed iexplore Product: Wine Version: 1.3.36 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: fracting(a)gmail.com Classification: Unclassified IBankWizard.exe is the manager program of 95559 online bank (交通银行） 1. Download https://pbank.95559.com.cn/personbank/download/AssistantDelopy/AssistantIns… 2. Install with Wine 3. Start IBankWizard.exe $ cd .wine/drive_c/Program\ Files/BOCOM/IBankWizard2011 $ wine IBankWizard.exe Expect result: Display a window with some content Actual result: Only display a blank frame Workaround by winetricks ie7 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 7

[Bug 31674] New: Wine 1.5.6 breaks Quicken 99 import of .qif files; special text character handling problem
by wine-bugs＠winehq.org 12 Feb '21

12 Feb '21

http://bugs.winehq.org/show_bug.cgi?id=31674 Bug #: 31674 Summary: Wine 1.5.6 breaks Quicken 99 import of .qif files; special text character handling problem Product: Wine Version: 1.5.12 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: drt781(a)yahoo.com Classification: Unclassified Have been using Quicken 99 for years via Wine. Upgraded from OpenSuse 12.1 to OpenSuse 12.2, and with it Wine 1.5.6 broke import function for .qif files. When I try to import a local .qif file (containing transactions) the operation completes "successfully" but resulting table of data is corrupted. Quicken 99 now, newly, incorrectly interprets .qif files. Uses current date for most transactions (instead of historical), and appears to have mangled, shifted, and/or truncated fields. Where 2d field frequently was blank, 3d field shifted into its place in truncated form. None of the fields displayed correctly. Dollar amounts also incorrect; inaccurate and too large by a factor of x100, as if Q 99 failed to see decimals, but the cents still are not rounded (as would be expected if decimal was just dropped) and the amounts are not familar. Only the imported data is corrupted; pre-existing data ok. Looks like a possible problem/change in handling special characters in plain text import files, such as following symbols: ' , and . Possibly also following: * and / The ^ character separated transactions; may have been read ok. Don't think that would explain the entire problem, though. Problem also exists under Wine 1.5.12, not resolved. This will make it much harder to use Q99. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 20

[Bug 29252] New: ICBC Internet Banking Assistant ICBCEBankAssist.exe can't open embed iexplore
by wine-bugs＠winehq.org 12 Feb '21

12 Feb '21

http://bugs.winehq.org/show_bug.cgi?id=29252 Bug #: 29252 Summary: ICBC Internet Banking Assistant ICBCEBankAssist.exe can't open embed iexplore Product: Wine Version: 1.3.34 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: fracting(a)gmail.com Classification: Unclassified Created attachment 37828 --> http://bugs.winehq.org/attachment.cgi?id=37828 Log: start ICBC Assistant wine-1.3.34-39-g95f81d1 1. Download ICBC Internet Banking Assistant installer ( ICBCSetupIntegration.msi ) from https://mybank.icbc.com.cn/icbc/enperbank/index.jsp $ wget http://www.icbc.com.cn/icbc/html/download/EbankToolsSoftware/ICBCSetupInteg… 2. install ICBC Internet Banking Assistant $ msiexec /i ICBCSetupIntegration.msi 3. Start Internet Banking Assistant cd to "Program Files/ICBCEbankTools/ICBCSetupIntegration" $ wine ICBCEBankAssist.exe 4. Click on "One-key Installation for Non-USBKey User" Expect result: open a embed iexplore, user can install ActiveX controls from the Assistant Actual result: nothing happen winetricks wininet doesn't work, winetricks ie7 doesn't work -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 7

[Bug 25579] New: Microsoft Flight Simulator X: cannot activate product
by wine-bugs＠winehq.org 12 Feb '21

12 Feb '21

http://bugs.winehq.org/show_bug.cgi?id=25579 Summary: Microsoft Flight Simulator X: cannot activate product Product: Wine Version: 1.3.9 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Terminal shows some wininet fixme's: fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! so I tried native wininet, no dice. Next was a winhttp error: err:winhttp:netconn_secure_connect couldn't verify server certificate (12057) so 'winetricks winhttp'. Still no luck: austin@aw21 ~/.wine/drive_c/Program Files/Microsoft Games/Microsoft Flight Simulator X $ wine fsx.exe fixme:heap:HeapSetInformation 0x750000 0 0x32f36c 4 fixme:heap:HeapSetInformation 0x110000 0 0x32f368 4 fixme:heap:HeapSetInformation 0x330000 0 0x32f364 4 fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! fixme:ras:RasEnumConnectionsW (0x204b90,0x1e1e454,0x1fd2004),stub! fixme:ras:RasEnumConnectionsW RAS support is not implemented! Configure program to use LAN connection/winsock instead! fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority fixme:wintrust:HTTPSCertificateTrust (0x1ef968) fixme:wintrust:HTTPSFinalProv (0x1ef968) didn't try beyond that. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 9

[Bug 29849] New: oleaut32's OLEPictureImpl_Load fails when Stat() method is missing
by wine-bugs＠winehq.org 12 Feb '21

12 Feb '21

http://bugs.winehq.org/show_bug.cgi?id=29849 Bug #: 29849 Summary: oleaut32's OLEPictureImpl_Load fails when Stat() method is missing Product: Wine Version: 1.4-rc2 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: oleaut32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: michael.blumenkrantz(a)gmail.com Classification: Unclassified Created attachment 38772 --> http://bugs.winehq.org/attachment.cgi?id=38772 test case Without a Stat() method, this function should only read the parts of a file that are needed. Instead, it continues to read and eventually crashes. Find attached a test case which takes an image file as an argument, then crashes. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 23

[Bug 14697] New: wineserver: debug events can block completion of queued user APCs
by wine-bugs＠winehq.org 11 Feb '21

11 Feb '21

http://bugs.winehq.org/show_bug.cgi?id=14697 Summary: wineserver: debug events can block completion of queued user APCs Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, consider the following scenario... A debugger is attached to a debuggee. The debuggee has two threads. The debugger processes debug events and queries virtual memory info of remote process using VirtualQueryEx in its main loop. VirtualQueryEx -> NtQueryVirtualMemory -> enqueues APC_VIRTUAL_QUERY user APC for remote process (debuggee). The calling thread is blocked until the APC is completed. Following is the "good" case: tid=0009 (debugger process, calling thread, main debugger loop) tid=001a (debuggee thread 1) --- snip --- .. 0009: queue_apc( thread=(nil), process=0x54, call={APC_VIRTUAL_QUERY,addr=0x7fff0000} ) 001a: *wakeup* signaled=192 cookie=0x7ffdb7b4 0009: queue_apc() = 0 { handle=0x68, self=0 } 0009: select( flags=4, cookie=0x32d30c, signal=(nil), prev_apc=(nil), timeout=infinite, result={}, handles={0x68} ) 0009: select() = PENDING { apc_handle=(nil), timeout=infinite, call={APC_NONE} } 001a: select( flags=4, cookie=0x7ffdb7b4, signal=(nil), prev_apc=(nil), timeout=1c8f097946d2824 (-0.1787600), result={}, handles={} ) 001a: select() = USER_APC { apc_handle=0x68, timeout=1c8f097946d2824 (-0.1787600), call={APC_VIRTUAL_QUERY,addr=0x7fff0000} } 001a: select( flags=4, cookie=0x7ffdb7b4, signal=(nil), prev_apc=0x68, timeout=1c8f097946d2824 (-0.1792110), result={APC_VIRTUAL_QUERY,status=40000002,base=(nil),alloc_base=(nil),size=0,state=0,prot=0,alloc_prot=0,alloc_type=0}, handles={} ) 0009: *wakeup* signaled=0 cookie=0x32d30c 001a: select() = PENDING { apc_handle=(nil), timeout=1c8f097946d2824 (-0.1792110), call={APC_NONE} } 0009: get_apc_result( handle=0x68 ) 0009: get_apc_result() = 0 { result={APC_VIRTUAL_QUERY,status=40000002,base=(nil),alloc_base=(nil),size=0,state=0,prot=0,alloc_prot=0,alloc_type=0} } --- snip --- Now the interesting one, which ultimately leads to block of calling thread ... tid=0009 (debugger process, calling thread, main debugger loop) tid=001a (debuggee thread 1) tid=001b (debuggee thread 2) --- snip --- 0009: continue_debug_event( pid=0019, tid=001a, status=65538 ) 001a: *wakeup* signaled=258 cookie=0x7ffdb7b4 001b: *wakeup* signaled=258 cookie=0x7ffd77b4 0009: continue_debug_event() = 0 .. 0009: read_process_memory( handle=0x54, addr=0x7ffd8000 ) 001a: *signal* signal=19 0009: read_process_memory() = 0 { data= {} } 0009: read_process_memory( handle=0x54, addr=0x7ffd4000 ) 001a: *signal* signal=19 0009: read_process_memory() = 0 { data={} } 0009: queue_apc( thread=(nil), process=0x54, call={APC_VIRTUAL_QUERY,addr=(nil)} ) 001b: *wakeup* signaled=192 cookie=0x7ed44874 0009: queue_apc() = 0 { handle=0x68, self=0 } 001a: load_dll( handle=(nil), base=0x61090000, size=102400, dbg_offset=0, dbg_size=0, name=0x13e468, filename=L"C:\\windows\\system32\\msacm32.dll" ) 001a: *sent signal* signal=10 001b: *sent signal* signal=10 001a: load_dll() = 0 .. 0009: select( flags=4, cookie=0x32d30c, signal=(nil), prev_apc=(nil), timeout=infinite, result={}, handles={0x68} ) 0009: select() = PENDING { apc_handle=(nil), timeout=infinite, call={APC_NONE} } 001a: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context= {...}) 001a: set_thread_context() = 0 { self=1 } 001b: select( flags=4, cookie=0x7ed44874, signal=(nil), prev_apc=(nil), timeout=infinite, result={}, handles={0x4c} ) 001b: select() = USER_APC { apc_handle=0x68, timeout=infinite, call={APC_VIRTUAL_QUERY,addr=(nil)} } 001a: select( flags=4, cookie=0x7ffdb7b4, signal=(nil), prev_apc=(nil), timeout=0, result={}, handles={} ) 001a: select() = PENDING { apc_handle=(nil), timeout=1c8f09794c8b694 (+0.0000000), call={APC_NONE} } 001b: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context= {...}) 001b: set_thread_context() = 0 { self=1 } 001b: select( flags=4, cookie=0x7ffd77b4, signal=(nil), prev_apc=(nil), timeout=0, result={}, handles={} ) 001b: select() = PENDING { apc_handle=(nil), timeout=1c8f09794c90dc4 (+0.0000000), call={APC_NONE} } ... --- snip --- At this point, tid=0009 (debugger) is blocked forever. When the APC_VIRTUAL_QUERY user APC is queued, remote thread 001b is selected/destined to carry out the APC. After thread 001a and 001b woke up, a dynamic library is loaded from thread 001a which results in LOAD_DLL_DEBUG_EVENT dispatched. This initiates the suspension of all threads in the child process (SIGUSR1 is sent for 001a and 001b). Thread 001a is suspended first, 001b next. The suspension of 001b happens to a time when 001b is about to carry out the APC_VIRTUAL_QUERY. Meanwhile thread 0009 (calling process) is waiting for APC completion result forever because it's blocked by VirtualQueryEx in debugger loop, unable to receive and process any debug event. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 21

[Bug 10249] New: Battlefield2/SafeDisc 4. x and Punkbuster services cause lockup: child processes debugging misconception
by wine-bugs＠winehq.org 11 Feb '21

11 Feb '21

http://bugs.winehq.org/show_bug.cgi?id=10249 Summary: Battlefield2/SafeDisc 4.x and Punkbuster services cause lockup: child processes debugging misconception Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-kernel AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=8876) --> (http://bugs.winehq.org/attachment.cgi?id=8876) WINEDEBUG=-all,+server,+tid,+loaddll,+seh wine ./BF2.exe +fullscreen 0 +szx 800 +szy 600 &>/tmp/debug_pipe Hello, while testing some PunkBuster stuff on popular games, I came across Battlefield 2 which employs SafeDisc 4.x It seems there is a problem with debuggers in chained child processes. Consider following scenario: --- snip process list --- pid threads parent executable (all id:s are in hex) 0000001b 1 00000008 'PnkBstrA.exe' 0000000c 2 00000008 'explorer.exe' 0000000a 2 00000008 '~e5.0001' 00000008 4 00000000 'BF2.exe' --- snip process list --- --- snip thread list --- process tid prio (all id:s are in hex) 0000001b 0000001c 0 0000000c 00000010 0 0000000d 0 0000000a 00000012 0 0000000b 0 00000008 0000001a 1 00000014 15 00000013 0 00000009 0 --- snip thread list --- "BF2.exe" = parent (game) "~e5.0001" = 1st child = SafeDisc 4.x process = "debugger" "PnkBstrA.exe" = 2nd child = PunkBuster Update Service The 1st child acts as debugger for the parent "BF2.exe" and receives all debug events (process, thread creation, dll load/unload...) There are lots of breakpoint events triggered from parent. This is part of SafeDisc 4.x and used for on-the-fly decryption of code sections (child decrypts code of father). When PunkBuster is initialized (loading of pbcl = client, pbag = agent), the following services should get started: PnkBstrA.exe, PnkBstrB.exe and finally the kmode driver PnkBstrK.exe The service process "PnkBstrA.exe" is started from main process "BF2.exe" (which is a debuggee itself). No debug flags (DEBUG_PROCESS | DEBUG_ONLY_THIS_PROCESS) are specified in process creation flags. The debugger (child of parent, receives the process creation event) does not make debugger_attach() to the newly created child process. The child process seems to inherit the state of being a "debuggee": wine server -> new_process -> set_process_debugger( process, parent->debugger ); The parent got its process->debugger from debugger_attach(). This leads to a problem in child process startup code: "dlls/kernel32/process.c:start_process()" checks the PEB->BeingDebugged field and if set, a system breakpoint is encountered before the entry code is called. This breakpoint results in debug event - seen by debugger. Unfortunately this event is _not_ expected by debugger because it didn't expect another debuggee (child) to be created. Ok, long story short solution: If you debug a process by attaching to an already created process, you _must_ treat default debugging flags as if the process has been created with DEBUG_ONLY_THIS_PROCESS, meaning that all childs created by debuggee will NOT automagically become debuggees. Short and (hopefully) acceptable patch snippet: --- snip --- diff --git a/server/debugger.c b/server/debugger.c index a64a17a..c59f3a0 100644 --- a/server/debugger.c +++ b/server/debugger.c @@ -444,6 +444,7 @@ static int debugger_attach( struct process *process, struct thread *debugger ) resume_process( process ); return 0; } + process->create_flags |= DEBUG_ONLY_THIS_PROCESS; return 1; error: --- snip --- And yes, the patch (snippet) works as intended (tm) ;-) Attached for sake of completeness is relevant server trace. Search for "001c:trace:seh:raise_exception code=80000003 flags=0 addr=0x7b870ed8 " to the point where the entry system breakpoint is triggered. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 17

[Bug 20230] New: GetThreadTimes() and the Actual and Pseudo Current Thread Handles
by wine-bugs＠winehq.org 11 Feb '21

11 Feb '21

http://bugs.winehq.org/show_bug.cgi?id=20230 Summary: GetThreadTimes() and the Actual and Pseudo Current Thread Handles Product: Wine Version: 1.1.30 Platform: PC URL: http://rh-software.com OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: ray(a)pobox.co.uk Some time ago I had an issue with SIV being unable to read the thread CPU time usage when using GetThreadTimes(). I tracked down to the following and then did a work-a-round. The "Current Thread" effectively has 2 current thread handles, these are the actual thread handle and the ~0 pseudo handle as returned by GetCurrentThread(). When a call is made to GetThreadTimes() this calls NtQueryInformationThread( ThreadTimes ) which contains the test "if (handle == GetCurrentThread())". As a result of this when GetThreadTimes() is called with the actual thread handle no data is returned. \WINE-1.1.30\dlls\ntdll\thread.c(1011): if (handle == GetCurrentThread()) I suspect the code should be changed to allow both the pseudo and actual thread handles to be used as a minimum, better still would, when possible, be to implement this function for any thread. While searching the source I also noticed: NTSTATUS WINAPI NtSetInformationThread( HANDLE handle, THREADINFOCLASS class, LPCVOID data, ULONG length ) { NTSTATUS status; switch(class) { case ThreadZeroTlsCell: if (handle == GetCurrentThread()) And suspect that code would benefit from a similar fix. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 18

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs November 2012