http://bugs.winehq.org/show_bug.cgi?id=7512
------- Additional Comments From focht@gmx.net 2007-21-02 21:42 ------- Created an attachment (id=5046) --> (http://bugs.winehq.org/attachment.cgi?id=5046&action=view) log showing its not a wine bug (i think)
Hello,
i took the setup from here:
http://download.imgburn.com/SetupImgBurn_2.2.0.0.exe
It does not only have unicode problems ... Sorry if my analysis got too long but it's worth read :)
Ok, Unicode stuff first
################### Part 1 ###################
Attached is a log that shows the problem. In short: the ansi version of edit control window proc is called.
--- relevant log extract --- trace:listbox:LISTBOX_GetText index 1 (0x0001) L"z:\mnt\data1" trace:edit:EditWndProc_common hwnd=0x100a6 msg=c (WM_SETTEXT) wparam=0 lparam=1a33d8 trace:edit:EDIT_WM_SetText L"z" trace:edit:EDIT_EM_ReplaceSel L"z", can_undo 0, send_update 0 trace:edit:EDIT_EM_ReplaceSel inserting stuff (tl 0, strl 1, selstart 0 (L""), text L"") --- relevant log extract ---
unicode=FALSE and text != "" exhibits the seen behaviour:
--- snip --- static void EDIT_WM_SetText(EDITSTATE *es, LPCWSTR text, BOOL unicode) { LPWSTR textW = NULL; if (!unicode && text) { LPCSTR textA = (LPCSTR)text; INT countW = MultiByteToWideChar(CP_ACP, 0, textA, -1, NULL, 0); textW = HeapAlloc(GetProcessHeap(), 0, countW * sizeof(WCHAR)); if (textW) MultiByteToWideChar(CP_ACP, 0, textA, -1, textW, countW); text = textW; }
... --- snip ---
How it comes that ansi window proc is called in a UNICODE created control? Let's dig deeper...
My "custom" trace with unicode flag dump:
--- relevant log extract --- trace:edit:EditWndProcW hwnd=0x100a6 msg=c5 (EM_LIMITTEXT) wparam=0 lparam=0, unicode=true trace:edit:EditWndProc_common hwnd=0x100a6 msg=c5 (EM_LIMITTEXT) wparam=0 lparam=0, unicode=1 trace:edit:EditWndProc_common hwnd=0x100a6 msg=c5 (EM_LIMITTEXT) -- 0x00000000 unicode=1 0009:Ret window proc 0x603ff580 (hwnd=0x100a6,msg=EM_LIMITTEXT,wp=00000000,lp=00000000) retval=00000000 0009:Ret window proc 0x603d94d0 (hwnd=0x100a2,msg=CB_LIMITTEXT,wp=00000000,lp=00000000) retval=00000000 0009:Ret user32.CallWindowProcW() retval=00000000 ret=006b13e1 0009:Ret window proc 0x380135 (hwnd=0x100a2,msg=CB_LIMITTEXT,wp=00000000,lp=00000000) retval=00000000 0009:Ret user32.CallWindowProcA() retval=00000000 ret=0061f37c 0009:Ret window proc 0x38014f (hwnd=0x100a2,msg=CB_LIMITTEXT,wp=00000000,lp=00000000) retval=00000000 0009:Ret user32.CallWindowProcW() retval=00000000 ret=006b11d9 0009:Ret window proc 0x380142 (hwnd=0x100a2,msg=CB_LIMITTEXT,wp=00000000,lp=00000000) retval=00000000 0009:Ret user32.SendMessageA() retval=00000000 ret=005e5751 0009:Call user32.GetWindow(000100a2,00000005) ret=005e5c35 0009:Ret user32.GetWindow() retval=000100a6 ret=005e5c35 0009:Call user32.GetWindowLongA(000100a6,fffffffc) ret=005e5c89 0009:Ret user32.GetWindowLongA() retval=603ff4d0 ret=005e5c89 0009:Call user32.SetWindowLongA(000100a6,fffffffc,0038081d) ret=005e5ca4 trace:win:WIN_SetWindowLong 0x100a6 -4 38081d A trace:win:alloc_winproc allocated 0xffff0059 for 0x38081d/(nil) (90/8192 used) 0009:Ret user32.SetWindowLongA() retval=603ff4d0 ret=005e5ca4 0009:Call user32.SendMessageA(000100a6,000000d3,00000003,00000000) ret=005e5ccc
0009:Call window proc 0x38081d (hwnd=0x100a6,msg=EM_SETMARGINS,wp=00000003,lp=00000000) 0009:Call user32.IsWindowUnicode(000100a6) ret=006a8bc8 0009:Ret user32.IsWindowUnicode() retval=00000000 ret=006a8bc8 0009:Call user32.CallWindowProcA(603ff4d0,000100a6,000000d3,00000003,00000000) ret=005e529f 0009:Call window proc 0x603ff4d0 (hwnd=0x100a6,msg=EM_SETMARGINS,wp=00000003,lp=00000000) trace:edit:EditWndProcA hwnd=0x100a6 msg=d3 (EM_SETMARGINS) wparam=3 lparam=0 unicode=false trace:edit:EditWndProc_common hwnd=0x100a6 msg=d3 (EM_SETMARGINS) wparam=3 lparam=0, unicode=0 --- relevant log extract ---
Did you spot it? Unicode flag changes ... someone switched edit window proc to ansi version on purpose! But thats only half of the story...
--- relevant log extract --- trace:edit:EDIT_SetCaretPos 0 - 0x0 trace:win:RedrawWindow 0x100a6 whole window flags: RDW_INVALIDATE RDW_ERASE trace:edit:EDIT_EM_SetMargins left=0, right=0 trace:edit:EditWndProc_common hwnd=0x100a6 msg=d3 (EM_SETMARGINS) -- 0x00000000 unicode=0 0009:Ret window proc 0x603ff4d0 (hwnd=0x100a6,msg=EM_SETMARGINS,wp=00000003,lp=00000000) retval=00000000 0009:Ret user32.CallWindowProcA() retval=00000000 ret=005e529f 0009:Ret window proc 0x38081d (hwnd=0x100a6,msg=EM_SETMARGINS,wp=00000003,lp=00000000) retval=00000000 0009:Ret user32.SendMessageA() retval=00000000 ret=005e5ccc 0009:Call user32.GetWindowLongA(000100a6,fffffffc) ret=006a883a 0009:Ret user32.GetWindowLongA() retval=0038081d ret=006a883a 0009:Call user32.SetWindowLongW(000100a6,fffffffc,0038081d) ret=006a8843 trace:win:WIN_SetWindowLong 0x100a6 -4 38081d W trace:win:alloc_winproc allocated 0xffff005a for (nil)/0x38081d (91/8192 used) 0009:Ret user32.SetWindowLongW() retval=ffff0059 ret=006a8843 0009:Call user32.SendMessageA(000100a2,0000000e,00000000,00000000) ret=006b1568
trace:msg:WINPROC_CallProcAtoW (hwnd=0x100a2,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) 0009:Call window proc 0x380142 (hwnd=0x100a2,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) 0009:Call user32.CallWindowProcW(0038014f,000100a2,0000000e,00000000,00000000) ret=006b11d9 0009:Call window proc 0x38014f (hwnd=0x100a2,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) 0009:Call user32.CallWindowProcA(00380135,000100a2,0000000e,00000000,00000000) ret=0061f37c 0009:Call window proc 0x380135 (hwnd=0x100a2,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) 0009:Call user32.CallWindowProcW(603d94d0,000100a2,0000000e,00000000,00000000) ret=006b13e1 0009:Call window proc 0x603d94d0 (hwnd=0x100a2,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) trace:combo:ComboWndProc_common [0x100a2]: msg WM_GETTEXTLENGTH wp 00000000 lp 00000000 unicode=1 0009:Call window proc 0x38081d (hwnd=0x100a6,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) 0009:Call user32.IsWindowUnicode(000100a6) ret=006a8bc8 0009:Ret user32.IsWindowUnicode() retval=00000001 ret=006a8bc8 0009:Call user32.IsWindowUnicode(000100a6) ret=006a8a0b 0009:Ret user32.IsWindowUnicode() retval=00000001 ret=006a8a0b 0009:Call user32.CallWindowProcW(603ff4d0,000100a6,0000000e,00000000,00000000) ret=006a8a3f 0009:Call window proc 0x603ff4d0 (hwnd=0x100a6,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) trace:edit:EditWndProcA hwnd=0x100a6 msg=e (WM_GETTEXTLENGTH) wparam=0 lparam=0 unicode=false trace:edit:EditWndProc_common hwnd=0x100a6 msg=e (WM_GETTEXTLENGTH) wparam=0 lparam=0, unicode=0 trace:edit:EditWndProc_common hwnd=0x100a6 msg=e (WM_GETTEXTLENGTH) -- 0x00000000 unicode=0 0009:Ret window proc 0x603ff4d0 (hwnd=0x100a6,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) retval=00000000 0009:Ret user32.CallWindowProcW() retval=00000000 ret=006a8a3f --- relevant log extract ---
The unicode callback is accidentally switched to ansi window proc of edit control. Thats why the ansi version of edit control window proc is called!
I did not look very hard at those (delphi) TNTUnicodeControls the software uses but i found a code piece like this:
-------------------- if ListHandle <> 0 then begin // re-extract FDefListProc as a Unicode proc SetWindowLongA(ListHandle, GWL_WNDPROC, Integer(FDefListProc)); FDefListProc := Pointer(GetWindowLongW(ListHandle, GWL_WNDPROC)); // override with FListInstance as a Unicode proc SetWindowLongW(ListHandle, GWL_WNDPROC, Integer(FListInstance)); end; SetWindowLongW(EditHandle, GWL_WNDPROC, GetWindowLong(EditHandle, GWL_WNDPROC)); --------------------
Last line has a bug .. can you spot it? :)
################### Part 2 ###################
From what i've seen there are other errors too, mostly related to transparent
bitmaps (png's).
Install went fine. Had to unpack the .exe for analysis because it's UPXed.
If you start this thing under winedbg or any other debugger you will notice lot's of 0xC0000005 (first chance). Pass them on but they appear every time.
I tracked the origin of exceptions down to this signature:
; __fastcall Pngimage::TPNGObject::DrawPartialTrans(unsigned int, Types::TRect const &)
Seems some open source png library implemented in delphi:
http://jabberstudio.org/cgi-bin/viewcvs.cgi/exodus/trunk/jopl/png/pngimage.p...
--- snip from source ---
{Draws using partial transparency} procedure TPngObject.DrawPartialTrans(DC: HDC; Rect: TRect); ...
{Structure used to create the bitmap} BitmapInfoHeader: TBitmapInfoHeader = (biSize: sizeof(TBitmapInfoHeader); biWidth: 100; biHeight: 100; biPlanes: 1; biBitCount: 32; biCompression: BI_RGB; biSizeImage: 0; biXPelsPerMeter: 0; biYPelsPerMeter: 0; biClrUsed: 0; biClrImportant: 0);
.... {Prepare to create the bitmap} Fillchar(BitmapInfo, sizeof(BitmapInfo), #0); BitmapInfoHeader.biWidth := Header.Width; BitmapInfoHeader.biHeight := -1 * Header.Height; BitmapInfo.bmiHeader := BitmapInfoHeader;
...
BufferBitmap := CreateDIBSection(BufferDC, BitmapInfo, DIB_RGB_COLORS, BufferBits, 0, 0);
--- snip from source ---
This results in console messages like this:
err:x11drv:X11DRV_CreateBitmap Trying to make bitmap with planes=1, bpp=32
But it gets worse ... Accessing the pixel data results in exceptions thrown all the time.
Run "WINEDEBUG=+seh ...." and see what i mean. Move over an icon or some bitmap -> first chance exception.
These are not "programmed" ones like RaiseError( exception_type, exception_text) but access violations due to incorrect memory access They are handled somewhere but i'm not sure if the default exception handler is located "too high". That might introduce subtle bugs as unwanted/unexpected exceptions lead to skipped code blocks and break normal progam flow.
Would be nice to see this type of error resolved. It's hard to debug with a filter to 0xC0000005's - you might miss the real ones (not caused by png stuff).
Regards