April 2001 - wine-devel

strange msvcrt crash
by Andreas Mohr 16 Apr '01

16 Apr '01

Hi all, (sorry for the long posting, but I think it's needed) wine --debugmsg +relay,+seh mspaint.exe, clicking on File->Send gives: Call kernel32.FindFirstFileA(403c71d0 "G:\\afxe6b2.tmp",405b61dc) ret=5f45b90c tid=08066638 Ret kernel32.FindFirstFileA() retval=403d26ca ret=5f45b90c tid=08066638 Call kernel32.FindClose(403d26ca) ret=5f45b91a tid=08066638 Ret kernel32.FindClose() retval=00000001 ret=5f45b91a tid=08066638 Call kernel32.FileTimeToLocalFileTime(405b61e0,405b61bc) ret=5f40e2ec tid=08066638 Ret kernel32.FileTimeToLocalFileTime() retval=00000001 ret=5f40e2ec tid=08066638 Call kernel32.FileTimeToSystemTime(405b61bc,405b61ac) ret=5f40e302 tid=08066638 Ret kernel32.FileTimeToSystemTime() retval=00000001 ret=5f40e302 tid=08066638 Call msvcrt.mktime(405b614c) ret=5f40e3b3 tid=08066638 Ret msvcrt.mktime() retval=3adae6b2 ret=5f40e3b3 tid=08066638 trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=c0000005 flags=0 Call ntdll.RtlRaiseException(404a4aa8) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a4788) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a4468) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a4148) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a3e28) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a3b08) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a37e8) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a34c8) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a31a8) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a2e88) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a2b68) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a2848) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a2528) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a2208) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a1ee8) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a1bc8) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Segmentation fault Any idea what's going on here ? Somehow the mktime() call seems to be a bit unhealthy. Not to mention the seh mess... Andreas Mohr

2 1

Re: Traces: fs -> tid
by Alexandre Julliard 16 Apr '01

16 Apr '01

Francois Gouget <fgouget(a)free.fr> writes: > Also, this is why I think it's nice to have the tid on each trace. If > not using +relay there is no indication of which thread is issuing the > trace. I'm not opposed to a +tid option to switch on thread information on all traces. But I think +relay should always display the thread info, we will get too many useless traces if it doesn't. -- Alexandre Julliard julliard(a)winehq.com

4 5

InstallShield (resend)
by Daniel Walker 15 Apr '01

15 Apr '01

I've been working on getting the Free Borland installer working. It uses installshield so I think this pertains to all installshield installers .. I've found a problem in propsheet.c , PROPSHEET_CollectPageInfo() . It appears that the property pages that come out of the installer have the PSP_USETITLE flag set. So wine attempts to get the title from the pszTitle field. The problem occurs because the pszTitle field is null. Wine try's to use it as a resource ID then fails. From reading over some MS docs I think windows, in this situation, reverts the PSP_USETITLE flag then uses the title in the template. So far I can get the installer to work, but it doesn't have a title or caption I haven't figured out why. I tryed changind it to "if (dwFlags & PSP_USETITLE && LOWORD(lppsp->pszTitle) != 0)" but it didn't have any effect. I also tryed reverting the PSP_USETITLE flag with no effect. Anyone have any ideas why there isn't a title? The patch below should fix the borland installer and , I assume, other install shield installers. Let me know if this patch doesn't work.. Daniel Walker --- ./dlls/comctl32/propsheet.c Mon Feb 12 10:08:31 2001 +++ ../../wine-20010305/dlls/comctl32/propsheet2.c Sat Apr 14 17:22:59 2001 @@ -296,12 +296,10 @@ if (dwFlags & PSP_USETITLE) { - if ( !HIWORD( lppsp->pszTitle ) ) - { char szTitle[256]; - - if ( !LoadStringA( lppsp->hInstance, (UINT) lppsp->pszTitle, szTitle, 256 ) ) - return FALSE; + + if ( !HIWORD( lppsp->pszTitle ) && LoadStringA( lppsp->hInstance, (UINT) lppsp->pszTitle, szTitle, 256 ) ) + { psInfo->proppage[index].pszText = HEAP_strdupAtoW(GetProcessHeap(), 0, szTitle );

1 0

Strange crash
by Dmitry Timoshkov 15 Apr '01

15 Apr '01

Hello all. Could anybody help to find the source of the following crash? Do this crash look known to somebody? ... Unhandled exception: c000008f in 32-bit code (0x40897fde). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x40897fde (X11DRV_PEN_SelectObject+0x8e [pen.c:69]): fldcw 0xfffffffe(%edx) 69 } Wine-dbg>bt Backtrace: =>0 0x40897fde (X11DRV_PEN_SelectObject+0x8e(dc=0x4038bbbc, hpen=0xffe7, pen=0x40842034) [pen.c:69]) (ebp=41f35aac) 1 0x40895a73 (X11DRV_SelectObject+0xb3(dc=0x4038bbbc, handle=0xffe7) [objects.c:62]) (ebp=41f35ad0) 2 0x4082a789 (SelectObject+0x75(hdc=0x68, handle=0xffe7) [gdiobj.c:867]) (ebp=41f35af0) 3 0x4081fceb (DC_InitDC+0x47(dc=0x4038bbbc) [dc.c:163]) (ebp=41f35b08) 4 0x40820919 (CreateDCA+0x135(driver=0x4083745d, device=0x0, output=0x0, initData=0x0, s=0x0, s=0x0, s=0x4083745d) [dc.c:579]) (ebp=41f35c50) 5 0x40823ddc (CreateDIBitmap+0x144(hdc=0x60, header=0x4038b4ec, init=0x4, bits=0x407bc308, data=0x4038b4ec, coloruse=0x0) [dib.c:850]) (ebp=41f35c80) 6 0x40782069 (CURSORICON_CreateFromResource+0x2dd(hInstance=0x0, hObj=0x0, bits=0x407bc2a0, cbSize=0x2e8, bIcon=0x1, dwVersion=0x30000, width=0x20, height=0x20, loadflags=0x8040) [cursoricon.c:550]) (ebp=41f35d14) 7 0x40782647 (CURSORICON_Load+0x257(hInstance=0x106, name=0x7f00, width=0x20, height=0x20, colors=0x100, fCursor=0x0, loadflags=0x8040) [cursoricon.c:777]) (ebp=41f35d64) 8 0x40784da7 (LoadImageW+0x12f(hinst=0x0, name=0x7f00, type=0x1, desiredx=0x20, desiredy=0x0, loadflags=0x8040) [cursoricon.c:2268]) (ebp=41f35d98) 9 0x40784c4e (LoadImageA+0x7e(hinst=0x0, name=0x7f00, type=0x1, desiredx=0x0, desiredy=0x0, loadflags=0x8040) [cursoricon.c:2208]) (ebp=41f35dcc) 10 0x407840c6 (LoadIconA+0x26(hInstance=0x0, name=0x7f00) [cursoricon.c:1792]) (ebp=41f35df0) ... Commenting lines 36-37 physDev->pen.width = GDI_ROUND((FLOAT)pen->logpen.lopnWidth.x * dc->xformWorld2Vport.eM11 * 0.5); in X11DRV_PEN_SelectObject (graphics/x11drv/pen.c) cures the problem. Why call to floor() leads to crash?

1 0

KC Wine & WWN
by Brian Vincent (C) 15 Apr '01

15 Apr '01

Over the last few days I've talked with Eric Pouech and Zack Brown about taking over the KC Wine and Wine Weekly News updates. It looks like I've got the first issue ready to go. Anyway, here's just some of my thoughts on it, and I'd welcome any and all feedback: - Right now my ISP at home is really messed up. At least in the short term I'll be doing a lot of this at work. Unfortunately that means I'll be mostly using Hypermail archives and some really editing methods. I won't be subscribed to the list, but I'll gladly receive email at the address below. - Unfortunately that also means I don't have CVS access right now. At some point I'd like to get WWN going again, but it might be several weeks. - Also, I always like the CVS commit summary, who used to write that? I'd like to incorporate that into the KC Wine page eventually. - My technical skills are not nearly as good as Eric's. So some of my summaries might be a little off. Hopefully I'll get better over time. - IMHO, these updates are a great PR tool for the project. Screenshots, product reviews, and news stories about Wine are very helpful. I'd encourage all of you to send me any news like this. I'll definitely include it. - Along those same lines, in the future I'll probably setup a screenshots page or something like that. ------------ Brian Vincent Copper Mountain Telecom brianv(a)ski-copper.com

2 1

InstallShield
by Daniel Walker 15 Apr '01

15 Apr '01

I've been working on getting the Free Borland installer working. It uses installshield so I think this pertains to all installshield installers .. I've found a problem in propsheet.c , PROPSHEET_CollectPageInfo() . It appears that the property pages that come out of the installer have the PSP_USETITLE flag set. So wine attempts to get the title from the pszTitle field. The problem occurs because the pszTitle field is null. Wine try's to use it as a resource ID then fails. From reading over some MS docs I think windows, in this situation, reverts the PSP_USETITLE flag then uses the title in the template. So far I can get the installer to work, but it doesn't have a title or caption I haven't figured out why. I tryed changind it to "if (dwFlags & PSP_USETITLE && LOWORD(lppsp->pszTitle) != 0)" but it didn't have any effect. I also tryed reverting the PSP_USETITLE flag with no effect. Anyone have any ideas why there isn't a title? The patch below should fix the borland installer and , I assume, other install shield installers. Let me know if this patch doesn't work.. Daniel Walker --- ./dlls/comctl32/propsheet.c Mon Feb 12 10:08:31 2001 +++ ../../wine-20010305/dlls/comctl32/propsheet2.c Sat Apr 14 17:22:59 2001 @@ -296,12 +296,10 @@ if (dwFlags & PSP_USETITLE) { - if ( !HIWORD( lppsp->pszTitle ) ) - { char szTitle[256]; - - if ( !LoadStringA( lppsp->hInstance, (UINT) lppsp->pszTitle, szTitle, 256 ) ) - return FALSE; + + if ( !HIWORD( lppsp->pszTitle ) && LoadStringA( lppsp->hInstance, (UINT) lppsp->pszTitle, szTitle, 256 ) ) + { psInfo->proppage[index].pszText = HEAP_strdupAtoW( GetProcessHeap(), 0, szTitle );

1 0

Re: debugger startup
by Alexandre Julliard 13 Apr '01

13 Apr '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > apart, from always using argv[0] (and transposing it to a windows > filename when needed), is there another fix ? You can set WINEPRELOAD to make sure we load the right file; so the exec would be something like: WINEPRELOAD=winedbg.so exec wine $* -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: debugger startup
by Alexandre Julliard 13 Apr '01

13 Apr '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > well, this has a major holes: > - since the process creation in Wine knows the created process is not > a PE image, it doesn't set the info on the server side for the newly > created process ; after the exec in the shell script, the info cannot > be retrieved from the parent, hence an error What makes you think that? Of course the info is set for non-PE binaries too, otherwise you could never debug a Winelib app. > perhaps, the best fix would be to merge the init_process/new_process > server calls I don't see how you could possibly do that. new_process is done by the parent, and init_process by the child; they serve very different purposes. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Strange behaviour with GETVDMPOINTER32W
by Alexandre Julliard 12 Apr '01

12 Apr '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Hopefully I get the cutting and pasting right now... > > ... > Call KERNEL.88: LSTRCPY(0x045f781a,0x02ef7044 "%CMDLINE%") ret=02e7:0687 ds=02f7 > Ret KERNEL.88: LSTRCPY() retval=0x045f781a ret=02e7:0687 ds=02f7 > ... > Call KERNEL.516: GETVDMPOINTER32W(0x045f781a,0x0001) ret=02e7:ae4a ds=02f7 > Ret KERNEL.516: GETVDMPOINTER32W() retval=0x404951ba ret=02e7:ae4a ds=02f7 > ... > Call kernel32.lstrcmpA(404951ba "\021\021\021\021\021\021\021\021\021\021\021\021\021\021\0..."...,407e6cbc "%FINDWINDOWCL%") ret=10001464 tid=081df290 Well, either GetVDMPointer returns the wrong pointer, or someone has written to the buffer in the meantime. You need to show us the full trace if you want us to be able to help. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Strange behaviour with GETVDMPOINTER32W
by Alexandre Julliard 12 Apr '01

12 Apr '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > I don't understand this sequence: > > Some strings gets copied to segemented memory > Call KERNEL.88: LSTRCPY(0x046f0018,0x00ef0080 "") ret=02ef:069a ds=02ff > Ret KERNEL.88: LSTRCPY() retval=0x0467781a ret=02ef:0687 ds=02ff lstrcpy is supposed to return its first argument (0x046f0018 in this case). Something is very wrong here... -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: edit control patch
by lawson_whitney＠juno.com 12 Apr '01

12 Apr '01

On Wed, 11 Apr 2001, Dan Engel wrote: > This is my first attempt at submitting a patch--please someone let me know if there are "customs" I need to follow. > Not meaning to beat on you, but - if somebody else patches the same file while you are working on it, it makes garbage of your diff. For a project as big and open as Wine, it is only common sense and common courtesy that we use diff -u. As well as + and - to show what changed, that has also context lines so patch can have some idea if it is FI adding lines where they belong. Besides, Alexandre prefers it. (From <wine>/README, which I think we should all read now and again :-) " If you add something, or fix a bug, please send a patch ('diff -u' format preferred) to julliard(a)winehq.com or to the wine-patches(a)winehq.com mailing list for inclusion in the next release. -- Alexandre Julliard julliard(a)winehq.com " Lawson This message is brought to you by Wine-20010326, junopine-2.0.2, Juno 2.0.11, and pine-4.10 ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: edit control patch
by James Hatheway 12 Apr '01

12 Apr '01

Just one little comment, you should make your diffs using the -u (unified diff) option. (ie. cvs -d $CVSROOT -u controls/edit.c > newdiff.diff) That way your patch has "+"s and "-"s instead of ">"s. It makes it easier to read what is changing in the patch... (For example, you patch will look something like this instead:) + INT BkMode; + BkMode = GetBkMode(dc); + SetBkMode( dc, OPAQUE); + SetBkMode( dc, BkMode); -James -- James Hatheway Work: james(a)macadamian.com ~ http://www.macadamian.com Home: jhatheway(a)home.com ~ http://members.home.net/jhatheway "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer" ----- Original Message ----- From: "Dan Engel" <dengel(a)sourceharvest.com> To: <wine-patches(a)winehq.com> Sent: Wednesday, April 11, 2001 10:24 PM Subject: edit control patch > This is my first attempt at submitting a patch--please someone let me know if there are "customs" I need to follow. > > Problem: Edit boxes are, in some cases, displaying selected text as white-on-white, so that it disappeared. > > Analysis: When text is drawn using the x11drv function X11DRV_ExtTextOut, the function does not paint a background rectangle if the background mode for the device context is transparent. In the case of edit controls, there is no attempt to change the background mode to opaque for selected text. > > Solution: In the case of painting reverse text in the edit control (function EDIT_PaintText) set the backgound mode to opaque, and then restore it before exiting the function. > > The patch is attached (wine.diff). > >

1 0

Strange behaviour with GETVDMPOINTER32W
by Uwe Bonnes 11 Apr '01

11 Apr '01

Hallo, I don't understand this sequence: Some strings gets copied to segemented memory Call KERNEL.88: LSTRCPY(0x046f0018,0x00ef0080 "") ret=02ef:069a ds=02ff Ret KERNEL.88: LSTRCPY() retval=0x0467781a ret=02ef:0687 ds=02ff ... This segmented memory gets mapped to linear memory Call KERNEL.516: GETVDMPOINTER32W(0x0467781a,0x0001) ret=02ef:ae4a ds=02ff Ret KERNEL.516: GETVDMPOINTER32W() retval=0x4043bda2 ret=02ef:ae4a ds=02ff ... Accessing the linear memory returns garbage Call kernel32.lstrcmpA(4043bda2 "\021\021\021\021\021\021... ... ret=10001464 tid=08404b48 I don't see any other accesses to 0x046f:0x0018 or 0x0467781a in between. This happens withthe Encarta 99 setup. Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

Re: debugger startup
by Alexandre Julliard 11 Apr '01

11 Apr '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > either we decide that shell scripts shouldn't be used (easy > solution) or we could do something like : > - if the CreateProcess fails, then wait for a certain amount of > time. If after that time the current process isn't currently > debugged, then report the error. Otherwise assume what did happen is > what has been described above CreateProcess already waits a couple of seconds for the new process to show up, so it's probably enough to simply check for the debugger once CreateProcess returns. An easier fix may be to have the script exec the debugger instead of launching it as a child process; this way the debugger parent pid will be the original Wine process, and everything should work fine. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: VxD information
by Alexandre Julliard 11 Apr '01

11 Apr '01

Maurice van der Pot <griffon26(a)kfk4ever.com> writes: > I'd like to get started on VxD support, but I'm unable to find any useful > documentation on how it's implemented in Wine. I've been looking through > the sources (e.g. vxd.c, wprocs.spec) but I can't find the connection > between a call to int 2F and a call to the functions in vxd.c. The connection is through int 2f ax=0x1684 (in msdos/int2f.c), which does a GetProcAddress on wprocs and returns the vxd entry point to the application. The app then calls the corresponding vxd directly with a normal function call. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: RegSetValueEx problem?
by Alexandre Julliard 11 Apr '01

11 Apr '01

davep <davep(a)cyw.uklinux.net> writes: > I have now been able to build and run WineMine under NT4, and it works > perfectly. On exit each parameter is saved to the registry as 16 bytes including > the training garbage (not visible in Regedit of course) and when restarted the > exact same 16 bytes are reloaded from the registry. > > It does therefore seem that there is something wrong with Wne's implementation. No, it depends if data[sizeof(data)] is null or not; the +1 on the size is done only if the last byte is null, on the assumption that the programmer forgot to count it (i.e. used strlen(data) instead of strlen(data)+1). It's the usual Microsoft approach of hiding bugs instead of fixing them, and it is definitely what NT does (or we wouldn't be doing such a monstrosity). Now what can happen is that the Microsoft compiler lays out the stack in a different way than gcc, and that the variable that is just above the array on the stack doesn't contain 0 in this case. In fact I suspect that if you run your Windows binary of WineMine under Wine it will work fine too. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Traces: fs -> tid
by Alexandre Julliard 11 Apr '01

11 Apr '01

Francois Gouget <fgouget(a)free.fr> writes: > Yes, but it would also be the simplest implementation (overdesign can > be ugly too). And if it's the one off hack that it current looks like it > is, why not. > I propose to just let Alexandre decide which implementation, if any, > he thinks would be worth including in CVS. I think we have now wasted enough bandwidth on this non-issue. The relay traces have always displayed the thread info, and will continue to do so. People who are morally offended by the extra 5 characters needed for the tid can hack their local tree, or learn to use sed/awk/perl. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: edit control patch
by Ian Pilcher 11 Apr '01

11 Apr '01

Dan Engel wrote: > > This is my first attempt at submitting a patch--please someone let me know if there are "customs" I need to follow. > Word-wrap is nice. :-) -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

Re: RegSetValueEx problem?
by Alexandre Julliard 11 Apr '01

11 Apr '01

gerard patel <gerard.patel(a)asi.fr> writes: > I have browsed server/registry.c and it seems that the registry > stores a terminating null for strings; so if you have in the registry > file a string like "0123456789", it get in memory a length of 11. > So I guess that the fix would be to fix the length by -1 somewhere > in the path server->ntdll->advapi No, the current behavior is correct for NT; what you want is a version check to get the Win95 behavior. Something like the patch below should do it (and of course WineMine should be fixed to work on NT too). Index: dlls/advapi32/registry.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/advapi32/registry.c,v retrieving revision 1.24 diff -u -r1.24 registry.c --- dlls/advapi32/registry.c 2001/03/23 19:12:01 1.24 +++ dlls/advapi32/registry.c 2001/04/09 20:49:35 @@ -640,8 +640,12 @@ { UNICODE_STRING nameW; - if (count && is_string(type)) + if (GetVersion() & 0x80000000) /* win95 */ { + if (type == REG_SZ) count = strlenW( (WCHAR *)data ) + sizeof(WCHAR); + } + else if (count && is_string(type)) + { LPCWSTR str = (LPCWSTR)data; /* if user forgot to count terminating null, add it (yes NT does this) */ if (str[count / sizeof(WCHAR) - 1] && !str[count / sizeof(WCHAR)]) @@ -663,7 +667,11 @@ WCHAR *dataW = NULL; NTSTATUS status; - if (count && is_string(type)) + if (GetVersion() & 0x80000000) /* win95 */ + { + if (type == REG_SZ) count = strlen(data) + 1; + } + else if (count && is_string(type)) { /* if user forgot to count terminating null, add it (yes NT does this) */ if (data[count-1] && !data[count]) count++; -- Alexandre Julliard julliard(a)winehq.com

2 1

VxD information
by Maurice van der Pot 11 Apr '01

11 Apr '01

I'd like to get started on VxD support, but I'm unable to find any useful documentation on how it's implemented in Wine. I've been looking through the sources (e.g. vxd.c, wprocs.spec) but I can't find the connection between a call to int 2F and a call to the functions in vxd.c. Regards, Maurice van der Pot.

1 0

Re: Traces: fs -> tid
by Alexandre Julliard 10 Apr '01

10 Apr '01

Francois Gouget <fgouget(a)free.fr> writes: > But maybe we could ask for traces generated with +relay,+tid instead > of just +relay. > Also when you're working on a specific application for which you have > determined that threads don't play a role, then you would have the > option of omitting the +tid to get simpler traces. I disagree, I think the thread information is important even if you are not chasing a thread problem, simply to tell you which calls are part of the same sequence. It's not possible to make sense of any relay trace if the calls made from different threads cannot be distinguished. If the tid really disturbs you, you can always pipe the output into a sed 's/tid=.*//' or something similar. -- Alexandre Julliard julliard(a)winehq.com

3 2

Traces: fs -> tid
by Francois Gouget 10 Apr '01

10 Apr '01

I noticed that fs was replaced by tid in relay (and snoop & co too now). I propose a slightly different version based on the following premises: * when suspecting a threading problem it could be nice to tag each trace with the id of the thread that emits it * when there's no thread issue, then fs and tid are unnecessary and only clutter the traces by making lines longer and harder to read * I find that lines are more readable if the thread id comes first as it's always the same length and doesn't mess up the alignment of the other fields So this patch adds a debug channel called 'tid' which activates printing the tid as the first field of all traces. Actually, it might make sense to merge 'tid' with the 'thread' debug channel. 'Screenshot': 08063178:Call user32.DispatchMessageA(405b6e50) ret=00402135 08063178:trace:relay:WINPROC_CallWndProc (wndproc=0x401c74,hwnd=00000138,msg=WM_SYSCOMMAND,wp=0000f060,lp=00000000) 08063178:Call user32.DefWindowProcA(00000138,00000112,0000f060,00000000) ret=0040206c Comments? Changelog: * dlls/ntdll/ntdll.spec Declare the tid debug channel * dlls/ntdll/debugtools.c, relay32/relay386.c, relay32/snoop.c Output the current thread id as the first field if tid is turned on -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...

2 3

Re: [PATCH] Add Callback for wavemapper -> widOpen
by Alexandre Julliard 09 Apr '01

09 Apr '01

"James Hatheway" <james(a)macadamian.com> writes: > I implemented the callback in a very similar way as the Wave out callback > is implemented. You can see this in the functions wodOpen(), wodOpenHelper(), > and WAVEMAP_DstCallback() , look at the data passed in the wom structure > (in dlls/winmm/wavemap/wavemap.c). I don't see any other way that I will > be able to callback into the app when the WineOSS layer notifies the wavemap > layer. The way it is now (wineoss directly calling the app) > causes my app to crash, and doesn't work that way on waveout. But these other functions are not using the WINE_MLD internal winmm structure, so why do you need it in widOpen()? Couldn't you instead do exactly what wodOpen() does? -- Alexandre Julliard julliard(a)winehq.com

3 5

Re: RegSetValueEx problem?
by gerard patel 08 Apr '01

08 Apr '01

At 10:54 AM 08/04/2001 +0100, you wrote: > >I've found time to do some more digging, but I'm still stumped. <snip> I have browsed server/registry.c and it seems that the registry stores a terminating null for strings; so if you have in the registry file a string like "0123456789", it get in memory a length of 11. So I guess that the fix would be to fix the length by -1 somewhere in the path server->ntdll->advapi I have tried this but I am not sure at all this is correct : --- registry.c.orig Mon Mar 5 20:34:21 2001 +++ registry.c Sun Apr 8 18:11:39 2001 @@ -799,14 +799,17 @@ struct key_value *value; int index; size_t ret = 0; + size_t l; if ((value = find_value( key, name, &index ))) { *type = value->type; - *len = value->len; - if (value->data && offset < value->len) + l = value->len; + if ((value->type == REG_SZ) && l) l--; + *len = l; + if (value->data && offset < l) { - if (maxlen > value->len - offset) maxlen = value->len - offset; + if (maxlen > l - offset) maxlen = l - offset; memcpy( data, (char *)value->data + offset, maxlen ); ret = maxlen; } Gerard

2 1

Wrc question
by gerard patel 08 Apr '01

08 Apr '01

I have looked at wrc code and there is a strange 100K limit on the size of mem allocation : assert(size > 0); assert(size < 102400); res = malloc(size); if(res == NULL) { Baffling code - hardcoded limit hidden in a C file :-/ I removed the assert and wrc was able to handle a 1 megabyte bitmap. Anyone has an idea about the meaning of this limit ? Gerard

2 1

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-devel April 2001