wine-devel

wine-devel@winehq.org

9 participants
84397 discussions

Re: Menu crash - was : Re: [PATCH] Version info for comctl32.dll
by gerard patel 18 Mar '01

18 Mar '01

At 11:44 PM 17/03/2001 -0500, you wrote: >Strange but true. I reverted the patch, and alt-b beeps but does not >cause a crash. With the patch in, wine crashes without a beep. > >Now I guess I'll put it back in. It doesn't cripple me if wine crashes >when I fat-finger the GUI. I guess wine-devel doesn't want to see a >trace, and maybe you don't either, but if you do it will save time to >send it. I had left out some cases in my first try :/, but maybe it's better to understand firsst what the app is doing. Could you send me a complete (from start) +relay,+menu trace of your app crashing with current Wine (no copy to wine-devel is best in this case) If you can apply the following patch to enhance trace first : --- menu.c.orig Sun Mar 18 10:18:31 2001 +++ menu.c Sun Mar 18 11:28:29 2001 @@ -1852,6 +1852,7 @@ LPWSTR prevText = IS_STRING_ITEM(item->fType) ? item->text : NULL; debug_print_menuitem("MENU_SetItemData from: ", item, ""); + TRACE("flags=%x str=%p\n", flags, str); if (IS_STRING_ITEM(flags)) { @@ -4511,6 +4512,9 @@ { if (!menu) return FALSE; + debug_print_menuitem("MENU_SetItemInfo_common from: ", menu, ""); + TRACE("mask=%x type=%x text=%p\n", lpmii->fMask, lpmii->fType, lpmii->dwTypeData); + if (lpmii->fMask & MIIM_TYPE ) { /* Get rid of old string. */ if ( IS_STRING_ITEM(menu->fType) && menu->text) { @@ -4589,7 +4603,7 @@ if (lpmii->fMask & MIIM_DATA) menu->dwItemData = lpmii->dwItemData; - debug_print_menuitem("SetMenuItemInfo_common: ", menu, ""); + debug_print_menuitem("SetMenuItemInfo_common to : ", menu, ""); return TRUE; } Thanks. Gerard

2 1

Menu crash - was : Re: [PATCH] Version info for comctl32.dll
by gerard patel 18 Mar '01

18 Mar '01

At 10:26 PM 16/03/2001 -0500, you wrote: > >On a related note, I provoked that crash in menu.c again, this time by >hitting an accelerator key (?) for a button that was not enabled at the >time. First thanks for the bug report. The trace is not difficult to read, the menu item is a text item and the text pointer is NULL. MENU_CalcItemSize is not handling this case. What is strange is this problem appears only with my patch. Maybe your app is really initializing the menu when receiving the WM_INITMENU message, but *only* when there is need to display the menu. I can't see how it could find out about it, though. Anyway, could you try the following patch ? It tries to remove the main case I saw where the app can set a menu item to text type with a null text pointer. It is a legitimate patch by itself, even if it does not fix your problem. Maybe it could have nasty side effects. If it avoids the systematic crash, try to find if the other is really gone for good too. I have found a strangeness in the HEAP_strdup macros - WARNING - this is of interest to anyone dabbling with Wine code. While HEAP_strdupW and HEAP_strdupAtoW appear very similar, the specs are not the same; one returns a null pointer when called with a null pointer, the other allocates 2 bytes of memory and returns a pointer to it. Nice trap :-) Gerard --- menu.c.orig Wed Mar 14 20:19:46 2001 +++ menu.c Sat Mar 17 14:47:30 2001 @@ -4524,11 +4524,15 @@ menu->text = lpmii->dwTypeData; - if (IS_STRING_ITEM(menu->fType) && menu->text) { - if (unicode) - menu->text = HEAP_strdupW(GetProcessHeap(), 0, lpmii->dwTypeData); - else - menu->text = HEAP_strdupAtoW(GetProcessHeap(), 0, (LPSTR)lpmii->dwTypeData); + if (IS_STRING_ITEM(menu->fType)) { + if (menu->text) { + if (unicode) + menu->text = HEAP_strdupW(GetProcessHeap(), 0, lpmii->dwTypeData); + else + menu->text = HEAP_strdupAtoW(GetProcessHeap(), 0, (LPSTR)lpmii->dwTypeData); + } + else + menu->fType |= MF_SEPARATOR; } }

2 2

Re: [PATCH] Version info for comctl32.dll
by gerard patel 18 Mar '01

18 Mar '01

At 10:10 AM 15/03/2001 +0800, you wrote: >I thought that include/wine/wine_common_ver.rc will serve as the quite reasonable >defaults for all built-in Wine dlls. If not, it should be changed for ALL dlls >in ONE place. Getting the common controls to the 4.72 version at least is the *whole* purpose of the patch. There are applications testing the version number of the common controls - tons of them : all the apps written with modern Borland tools. Their behaviour change accordingly because Ms changed things quite a lot with 4.72. Wine does not emulate the old behaviour, so it's needed to return a recent version number to get some apps to work correctly. Unless the version number of winsock.dll, richedit.dll, version.dll, or unrelated dlls like that is always identical to the version number of common controls ? I did not check but that seems unlikely. >1. I believe that version numbers should be equal in both numerical field and >in the string value (0.01 != 4.72 and 1.00 != 4.72). >2. There is no need for excessive \000 at the end of the string value. >3. All well behaving programs do read "VarFileInfo"/"Translation" before >retrieving other version information. LANGUAGE does nothing here. >4. Did you try to use my sample application showing version info? >5. Version resources in kernel, user, gdi for both 16 and 32-bit dlls could serve >as an example of adding version resources into built-in dlls. Well, all right I'll do like it's done in include/wine. I did not search far enough, I used the file in commdlg as an example :-) I found another problem you missed btw, there is a special function to retrieve the dll version directly, it returns hard coded values; I'll add code to retrieve these from the resource. Gerard

3 23

Re: [PATCH] Version info for comctl32.dll
by gerard patel 17 Mar '01

17 Mar '01

At 08:54 PM 15/03/2001 -0500, you wrote: <snip> >for its version info and gets the builtin. The ver trace looks a little >strange to me - maybe it will make sense to you? Do you mean a strangeness that could go away with the following patch : --- info.c.orig Fri Feb 23 21:37:15 2001 +++ info.c Fri Mar 16 10:14:19 2001 @@ -503,8 +503,15 @@ && !VersionInfoIs16( data ) ) { /* convert resource from PE format to NE format */ - ConvertVersionInfo32To16( (VS_VERSION_INFO_STRUCT32 *)data, - (VS_VERSION_INFO_STRUCT16 *)data ); + BYTE *ptemp = HeapAlloc(GetProcessHeap(), 0, datasize); + if (ptemp) + { + ConvertVersionInfo32To16( (VS_VERSION_INFO_STRUCT32 *)data, + (VS_VERSION_INFO_STRUCT16 *)ptemp ); + memcpy(data, ptemp, datasize); + HeapFree(GetProcessHeap(), 0, ptemp); + + } } return TRUE; I don't think this will fix your problem, though. Gerard

2 1

Re: [PATCH] Recalculate menus after WM_INITMENU
by lawson_whitney＠juno.com 17 Mar '01

17 Mar '01

On Mon, 12 Mar 2001, gerard patel wrote: > StatView (www.statview.com) menus don't work at all. > It seems that this app recreates all submenus of the > main menu in the WM_INITMENU handling. > > ChangeLog: > > * controls/menu.c > Recalculate menu sizes if WM_INITMENU has recreated/changed something > > Good day, Gerard! I have noticed a couple of crashes at controls/menu.c 872 since I applied this - when I fatfinger something in the wm (icewm) and keyboard input gets directed to a different window, but the event comes to wine, I think, but I haven't looked into it too closely and I'm not sure I can reproduce it. /* If we get here, then it must be a text item */ if (IS_STRING_ITEM( lpitem->fType )) { SIZE size; GetTextExtentPoint32W(hdc, lpitem->text, strlenW(lpitem->text), &size); and in this case lpitem is NULL and the strlen crashes. Would you be interested to see traces if I can reproduce it (if so which traces)? I think maybe it is a wm bug, but maybe wine should protect itself if it is not too expensive to do so? Lawson ---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: Eliminate excessive retries in GetFileVersionInfo(Size)
by lawson_whitney＠juno.com 16 Mar '01

16 Mar '01

Good day! Maybe it takes a Man from Mars to think that a windose function might ought to sort of do what its name implies, but the more I think about it, wouldn't it be simpler? It is right and proper for the functions of oleaut32.dll to be performed by liboleaut32.so and friends (if the Wine administrator so directs), but if the app asks for the version info for oleaut32.dll, and the named file exists (because the app's installer _put_ that file there, in this case) how about we give it the version info from that bloody file? If the file doesn't exist, we give it a builtin construct, say. IOW, disconnect file version from dll. I don't think it is any business of the app what does its work, so I don't see why it should be able to tell by GetFileVersionInfo whether the working blah.dll is builtin or native. I guess you could make a case for a [VersionOverrides] section in the config, but I am not going to. That way lies madness. I would be willing to take a shot at writing the code if that's what we decide we want, and if no one is in a great hurry for it, but... Regards, Lawson << Sardines of the world unite! << >> You have nothing to lose but your cans. >> ---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: Eliminate excessive retries in GetFileVersionInfo(Size) (fwd)
by lawson_whitney＠juno.com 15 Mar '01

15 Mar '01

Oops, I misdirected this to wine-patches before. Sorry. On Thu, 15 Mar 2001, Dmitry Timoshkov wrote: > Hello. > > This patch helps eliminate excessive retries in GetFileVersionInfo(Size). > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Return from GetFileVersionInfo(Size) if specified file found, > but VS_VERSION_INFO resource not. > Good day! Here we go again. This breaks my app (juno 2.0.11) with builtin ole32/oleaut32. Native ole32/oleaut32 are so full of deadbeef they sort of stink. I guess we don't need to panic yet. I can revert it locally until so I can get and send mail until I see if I (or someone) can make some builtin version resources that will satisfy this app. It installs its own oleaut32.dll and with this patch in it thinks the install is busted. Regards, Lawson It is better to be lucky than good. - J. A. Soucy ---

1 0

Re: winedefault patch
by Andreas Mohr 15 Mar '01

15 Mar '01

On Wed, Mar 14, 2001 at 09:35:17PM +0100, Ove Kaaven wrote: > Wine won't load builtin dlls if a full path to a nonexistent file is > specified, so the default registry should probably not have a full path to > dplayx.dll. Some guy managed to start Settlers 3 after this was fixed... > > Log: > Removed path from dplayx registry entry, so that the builtin dplayx can be > loaded. Alexandre, please add a comment to winedefault.reg reminding people of this problem for future entries. Thanks ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

1 0

Re: [PATCH] deferred trace
by Alexandre Julliard 15 Mar '01

15 Mar '01

"Rob Farnum" <rfarnum(a)mindspring.com> writes: > I am not exactly sure what you mean by this. Do you mean to put the > code that would be in the dll, into the debugger, or to extend the > debugger in such a way that it can load dll's to enhance its > functionality, or something else? I mean that the code that would have been in the dll and loaded into Wine should be in the debugger instead. So for instance, instead of having a magic key (or X message) to switch tracing on, you'd have a debugger command 'set tracing on' that would poke into the Wine address space to do it. Since you can read/write memory, call functions (I think it's broken now but should be easy to fix), etc. from the debugger you can do everything from here and avoid the need to have any debugging code running inside the Wine process. > This would bypass the objection of intercepting a key, like F12, and > using it to generate a window list dump, and replace it with a > mechanism that uses the debugger own builtin functions to do that. Yes, exactly. > I think it is desirable to use as much of the existing debugger > functionality as possible, and to add an "elaborate mechanism in the > debugger" that allows it to be dynamically extended in > functionality. It would certainly be possible to load dlls inside the debugger itself to extend it; though maybe simply loading a batch file containing debugger commands may allow to do a lot of things already without requiring compiling new code. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: [PATCH] Version info for comctl32.dll
by Dmitry Timoshkov 15 Mar '01

15 Mar '01

"gerard patel" <gerard.patel(a)asi.fr> wrote: > ChangeLog: > > * dlls/comctl32/rsrc.rc > Add version info. [...] > LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL > + > +1 VERSIONINFO > +FILEVERSION 4, 72, 0, 0 > +PRODUCTVERSION 4, 72, 0, 0 > +FILEFLAGSMASK VS_FFI_FILEFLAGSMASK > +FILEOS VOS_DOS_WINDOWS16 [...] > + VALUE "FileVersion", "0.01\000" [...] > + VALUE "ProductVersion", "1.00\000" I thought that include/wine/wine_common_ver.rc will serve as the quite reasonable defaults for all built-in Wine dlls. If not, it should be changed for ALL dlls in ONE place. Besides that: 1. I believe that version numbers should be equal in both numerical field and in the string value (0.01 != 4.72 and 1.00 != 4.72). 2. There is no need for excessive \000 at the end of the string value. 3. All well behaving programs do read "VarFileInfo"/"Translation" before retrieving other version information. LANGUAGE does nothing here. 4. Did you try to use my sample application showing version info? 5. Version resources in kernel, user, gdi for both 16 and 32-bit dlls could serve as an example of adding version resources into built-in dlls.

1 0

Jump to page:

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