February 2002 - Wine-Devel - list.winehq.org

Re: Question about ToolbarWindowProc

by Guy L. Albertelli

----- Original Message ----- From: "Guy L. Albertelli" <galberte(a)neo.lrun.com> To: "Jeremy Shaw" <jeremy(a)lindows.com>; "Wine Devel" <wine-devel(a)winehq.com> Sent: Wednesday, February 27, 2002 9:20 PM Subject: Re: Question about ToolbarWindowProc [snip] > case 0x0463: > { > LPDWORD hoho = (LPDWORD)lParam; > ERR("[0463] lParam 0x%08lx -> 0x%08lx 0x%08lx\n", > lParam, *hoho, *(hoho+1)); > /* guess - level 1 */ > if (!*(hoho+1)) { > *(hoho+1) = *hoho; /* set second word to first */ > } > return 0; /* really should be 1 */ > } > After more thought (this is still supposition), I think that lParam is a LPSIZE. Also that the code (at least partially) could be: case 0x0463: { LPSIZE hoho = (LPDWORD)lParam; ERR("[0463] lParam 0x%08lx -> 0x%08lx 0x%08lx\n", lParam, hoho->cx, hoho->cy); /* guess - level 2 */ if (!hoho->cy) { hoho->cy = infoPtr->rcBound.bottom - infoPtr->rcBound.top; } return 1; } Note that there has to be some difference between [0463] and TB_GETMAXSIZE. Also I have seen some of the values being -1 or other small values. Making the changes to spy.c and seeing what the natvie control does will be the key. Guy

Feb. 28, 2002

Re: chsize(HANDLE, long)

by Alexandre Julliard

"jonathan" <jonathan(a)corvu.com.au> writes: > I tried wine-patchesPlEaSeReMoVeme(a)winehq.com but was rejected. Here is a > implementation of chsize(). You cannot use a kernel internal function from msvcrt. chsize should be implemented on top of the exported SetEndOfFile function. (and the PlEaSeReMoVeMe is supposed to be removed before mailing ;-) -- Alexandre Julliard julliard(a)winehq.com

Feb. 28, 2002

Status of clippy

by Michael Cardenas

What's the status of clippy? I picked up today's cvs and when clippy comes up, it still hangs office applications. Has there been any progress on this?

Feb. 28, 2002

chsize(HANDLE, long)

by jonathan

Hi Alexandre, I tried wine-patchesPlEaSeReMoVeme(a)winehq.com but was rejected. Here is a implementation of chsize(). Cheers Jonathan

Feb. 28, 2002

Re: Question about ToolbarWindowProc

by Guy L. Albertelli

----- Original Message ----- From: "Jeremy Shaw" <jeremy(a)lindows.com> To: "Wine Devel" <wine-devel(a)winehq.com> Sent: Wednesday, February 27, 2002 7:30 PM Subject: Re: Question about ToolbarWindowProc > Now, If I use the WindomsME comctl32.dll BUT modify SendMessageA to block the > Favorites menu from receiving message 0x463, then the Favorites menu reverts to > only being 8 pixel tall. Jeremy, I do believe I have been totally wrong about toolbar message [0463]. 0806f388:trace:message:SPY_EnterMessage (00010044) L"Menu" message [043a] TB_GETBUTTONSIZE sent from self wp=00000000 lp=00000000 0806f388:trace:message:SPY_ExitMessage (00010044) L"Menu" message [043a] TB_GETBUTTONSIZE returned 001500a5 0806f388:trace:message:SPY_EnterMessage (00010044) L"Menu" message [0463] WM_USER+0063 sent from self wp=00000001 lp=405243ac 0806f388:trace:message:SPY_ExitMessage (00010044) L"Menu" message [0463] WM_USER+0063 returned 00000000 0806f388:trace:message:SPY_EnterMessage (00010046) L"{ToolbarWindow}" message [043a] TB_GETBUTTONSIZE sent from self wp=00000000 lp=00000000 0806f388:trace:message:SPY_ExitMessage (00010046) L"{ToolbarWindow}" message [043a] TB_GETBUTTONSIZE returned 00150173 0806f388:trace:message:SPY_EnterMessage (00010046) L"{ToolbarWindow}" message [0463] WM_USER+0063 sent from self wp=00000001 lp=405243ac 0806f388:trace:message:SPY_ExitMessage (00010046) L"{ToolbarWindow}" message [0463] WM_USER+0063 returned 00000000 ... 0806f388:Call user32.AdjustWindowRectEx(4052463c,86400000,00000000,00000088) ret=7113f8d6 0806f388:trace:win:InflateRect r (-3,-3)-(374,4) 0806f388:Ret user32.AdjustWindowRectEx() retval=00000001 ret=7113f8d6 The above trace is from work I've been doing on IE5.5. It shows the entries just before the first known point of failure. If I fudge AdjustWindowRectEx and force the rectangle to be deeper (larger y value), it displays the Favorites "menu" window. Note that the app code touches, with both TB_GETBUTTONSIZE and [0463], both toolbars that are part of the rebar just before the call. Based on your note, I added some code (bottom) to toolbar.c to display the data pointed to by the lParam of the [0463] message. I chose 2 dwords after looking at memory with the debugger. The third and fourth dwords are the stack pointer and return address, so the max size of the data must be 2 dwords. The trace below shows the values displayed. Then I guessed that the code in native probably sets the second word. AND THAT STARTED TO WORK!!!! No, not correctly, but it is definitely bigger. err:toolbar:ToolbarWindowProc [0463] lParam 0x40523c70 -> 0x000000a5 0x00000000 err:toolbar:ToolbarWindowProc [0463] lParam 0x40523c68 -> 0x00000173 0x00000000 case 0x0463: { LPDWORD hoho = (LPDWORD)lParam; ERR("[0463] lParam 0x%08lx -> 0x%08lx 0x%08lx\n", lParam, *hoho, *(hoho+1)); /* guess - level 1 */ if (!*(hoho+1)) { *(hoho+1) = *hoho; /* set second word to first */ } return 0; /* really should be 1 */ } BTW, The interior windowproc is the "real" toolbar windowproc. You can check the windowproc addresses by running the ControlSpy samples with "+relay,+message" and noting which addresses are used for which window classes. I really think we are closer. If we add another case to windows/spy.c to trap the [0463] message and dump the two dwords at the lParam on entry and exit, I think we can understand what this thing really does. Guy

Feb. 28, 2002

SystemParamtersInfoA Unknown Action: 4104

by David.Goodenough＠DGA.co.uk

I have just tried to fire up MindManager under Wine. It installed cleanly (as far as I can tell) and successfully created an icon on my KDE desktop.. When I try to run it however, it first complains about a fixme in CreateAcceleratorTableA, which I think I understand, and then hits another fixme in SystemParamertersInfoA from which it asked for action 4104. Looking at SystemParametersInfoA this seems odd as the action value is much too large. Does anyone have any idea what this might mean? Neither 04 nor 41 make much sense either. The app then hangs, and neither the mouse nor the keyboard seem to be able to get from the first little window into the main application. Perhaps the 04 did make sense, as it talks about the mouse. I am running the version from Debian testing. David

Feb. 28, 2002

Re: Question about ToolbarWindowProc

by Jeremy Shaw

Hello, Let me ask a different question on the same subject. I am going to start with a bit of background first. Under internet explorer, the favorites menu is not really a 'menu' but a toolbar that is laid out top to bottom instead of left to right. (that is somewhat of a simplification, there are actually two toolbar windows, a SysPager window, and a few others involved). Under wine, when the Favorites menu is displayed it has the correct width but is only 8 pixels tall. If I use the native comctl32.dll from Windows ME, the menu works correctly. Now, If I use the WindomsME comctl32.dll BUT modify SendMessageA to block the Favorites menu from receiving message 0x463, then the Favorites menu reverts to only being 8 pixel tall. Here are some brief traces using the wine builtin and WinME comctl32.dll (this is WITHOUT the patch to block msg 0x463) ** Builtin ** 0806b4a8:CALL SHLWAPI.136: @(00010040,00000463,00000001,405c2fb4) ret=7102dc2e 0806b4a8:Call user32.SendMessageA(00010040,00000463,00000001,405c2fb4) ret=70bd2540 0806b4a8:Call window proc 0x40fe2d74 (hwnd=00010040,msg=WM_USER+0063,wp=00000001,lp=405c2fb4) 0806b4a8:Call user32.GetWindowLongA(00010040,00000000) ret=40fe2dcb 0806b4a8:Ret user32.GetWindowLongA() retval=428c2544 ret=40fe2dcb err:toolbar:ToolbarWindowProc unknown msg 0463 wp=00000001 lp=405c2fb4 0806b4a8:Call user32.DefWindowProcA(00010040,00000463,00000001,405c2fb4) ret=40fe3c81 0806b4a8:Ret user32.DefWindowProcA() retval=00000000 ret=40fe3c81 0806b4a8:Ret window proc 0x40fe2d74 (hwnd=00010040,msg=WM_USER+0063,wp=00000001,lp=405c2fb4) retval=00000000 0806b4a8:Ret user32.SendMessageA() retval=00000000 ret=70bd2540 0806b4a8:RET SHLWAPI.136: @() retval = 00000000 ret=7102dc2e ** Native (comctl32.dll from WinMe) ** 0806b4d8:CALL SHLWAPI.136: @(0001003d,00000463,00000001,405c29e0) ret=7102dc2e 0806b4d8:Call user32.SendMessageA(0001003d,00000463,00000001,405c29e0) ret=70bd2540 0806b4d8:Call window proc 0x77b562ef (hwnd=0001003d,msg=WM_USER+0063,wp=00000001,lp=405c29e0) 0806b4d8:Call user32.GetPropW(0001003d,0000c050) ret=77b56337 0806b4d8:Ret user32.GetPropW() retval=4044e410 ret=77b56337 0806b4d8:CALL COMCTL32.413: @(0001003d,00000463,00000001,405c29e0) ret=7103f54b 0806b4d8:Call user32.IsWindow(0001003d) ret=77b564ca 0806b4d8:Ret user32.IsWindow() retval=00000001 ret=77b564ca 0806b4d8:Call user32.GetPropW(0001003d,0000c050) ret=77b564eb 0806b4d8:Ret user32.GetPropW() retval=4044e410 ret=77b564eb 0806b4d8:Call kernel32.GetCurrentThreadId() ret=77b564f7 0806b4d8:Ret kernel32.GetCurrentThreadId() retval=0806b4d8 ret=77b564f7 0806b4d8:Call user32.CallWindowProcW(77b5655c,0001003d,00000463,00000001,405c29e0) ret=77b56535 0806b4d8:Call window proc 0x77b5655c (hwnd=0001003d,msg=WM_USER+0063,wp=00000001,lp=405c29e0) 0806b4d8:Call user32.GetWindowLongA(0001003d,00000000) ret=77b56571 0806b4d8:Ret user32.GetWindowLongA() retval=4044e688 ret=77b56571 0806b4d8:Ret window proc 0x77b5655c (hwnd=0001003d,msg=WM_USER+0063,wp=00000001,lp=405c29e0) retval=00000001 0806b4d8:Ret user32.CallWindowProcW() retval=00000001 ret=77b56535 0806b4d8:RET COMCTL32.413: @() retval = 00000001 ret=7103f54b 0806b4d8:Call user32.IsWindow(0001003d) ret=77b56396 0806b4d8:Ret user32.IsWindow() retval=00000001 ret=77b56396 0806b4d8:Ret window proc 0x77b562ef (hwnd=0001003d,msg=WM_USER+0063,wp=00000001,lp=405c29e0) retval=00000001 0806b4d8:Ret user32.SendMessageA() retval=00000001 ret=70bd2540 0806b4d8:RET SHLWAPI.136: @() retval = 00000001 ret=7102dc2e As mentioned later in this thread, it appears that there is some sort of subclassing going on here. Currently I have only been working on trying to figure out what happens when you call window proc 0x77b5655c and pass it msg WM_USER + 0063. Obviously, its not doing a whole lot since the only function it calls is "GetWindowLongA". GetWindowLongA is presumably returning a pointer to a structure similar to TOOLBAR_INFO. My best guess is that the function is calcaluting the height of the favorites menu (by adding together the heights of all the buttons in the toolbar) and copying the height to another field in the TOOLBAR_INFO-like structure. So, my question is, where do I go from here? Since message 0x463 is undocumented, I do not know how to proceed except by disassembling the windows version of comctl32.dll. And, as part of that, it would be very beneficial to know what the structure returned by GetWindowLongA looks like. Thanks for your help! Jeremy Shaw.

Feb. 28, 2002

(no subject)

by Mike McCormack

Hi Mehmet, I created the problematic change in question. Without the change, when StgOpenStorage is called with an existing zero length file as the filename, it fails because it suceeded in opening the file but expects it to have valid content... Unfortunately, the change was merged incorrectly from the big CW patch. (the Fad structure is not initiaized) Could you try this patch instead please? Mike > Microsoft Visual Studio 6 is crashing when opening an existing projet, > with current CVS version of Wine (Wine20020122 was OK). > > Comparing both, I have found the change that triggers the crash. > It is function StgOpenStorage in OLE32/storage32.c, line 5595 : > > hr = StorageImpl_Construct( > newStorage, > hFile, > pwcsName, > NULL, > grfMode, > TRUE, > - FALSE); > + !(Fad.nFileSizeHigh || Fad.nFileSizeLow) /* FALSE */ ); > TRACE shows that Fad.nFileSizeHigh = Fad.nFileSizeLow = 0; > > As you can see in TRACE the crash occurs in StorageImpl_WriteBigBloc. > I suppose Wine is trying to write to a readonly opened file ? > (because file is opened with GENERIC_READ) > > I hope this will help finding a fix. ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

Feb. 28, 2002

(no subject)

by David.Goodenough＠DGA.co.uk

Feb. 28, 2002

Re: Status of clippy

by Michael Cardenas

I know you can use runonce and remove clippy from the registry, but I'm wondering if anyone has gotten any closer to actually making it work. ----- Original Message ----- From: "Hetz Ben Hamo" <hetz(a)kde.org> To: "Michael Cardenas" <michaelc(a)lindows.com>; <wine-devel(a)winehq.com> Sent: Wednesday, February 27, 2002 10:54 AM Subject: Re: Status of clippy > Here's a hint... > > Hack the registry ;) > > Hetz > > On Thursday 28 February 2002 04:30, Michael Cardenas wrote: > > What's the status of clippy? > > > > I picked up today's cvs and when clippy comes up, it still hangs office > > applications. Has there been any progress on this? > > >

Feb. 27, 2002