wine-devel

wine-devel@winehq.org

84463 discussions

wine: debugtools.c:210: wine_dbg_vprintf: Assertion failed
by Dmitry Timoshkov 20 Mar '01

20 Mar '01

Hello all. I have this very strange situation: Debugging with +relay,+win,+region,+message has revealed: ... Call user32.18: CallNextHookEx(4b483218,00000000,00000001,405a3f40) ret=3d1010fe fs=008f Ret user32.18: CallNextHookEx() retval=00000000 ret=3d1010fe fs=008f trace:message:SPY_EnterMessage (0000565c) {Static} message [0087] WM_GETDLGCODE sent from self wp=00000000 lp=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x40619540,hwnd=0000565c,msg=WM_GETDLGCODE,wp=00000000,lp=00000000) trace:relay:WINPROC_CallWndProc (wndproc=0x40619540,hwnd=0000565c,msg=WM_GETDLGCODE,wp=00000000,lp=00000000) retval=00000100 trace:message:SPY_ExitMessage (0000565c) {Static} message [0087] WM_GETDLGCODE returned 00000100 wine: debugtools.c:210: wine_dbg_vprintf: Assertion `ret < sizeof(info->output) - (info->out_pos - info->output)' failed. err:ntdll:RtlpWaitForCriticalSection Critical section 0x40685190 wait timed out, retrying (60 sec) fs=0287 It seemed to be as libc bug and I have upgraded my stock rh 6.2 from ftp://updates.redhat.com/6.2 to the latest available glibc-2.1.3-22.i386.rpm and glibc-devel-2.1.3-22.i386.rpm. But nothing has changed. Any suggestions?

2 1

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set
by Alexandre Julliard 20 Mar '01

20 Mar '01

Dmitry Timoshkov <dmitry(a)sloboda.ru> writes: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set. I think it would be better to keep the existing support for native dlls, and simply fall back to loading the builtin library if SearchPath fails. It's unlikely we are ever going to support proper LOAD_LIBRARY_AS_DATAFILE for builtin dlls anyway. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set
by Alexandre Julliard 20 Mar '01

20 Mar '01

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > Perhaps version.dll code should use DONT_RESOLVE_DLL_REFERENCES instead of > undesirable LOAD_LIBRARY_AS_DATAFILE? Not necessarily, it may be considered a feature to load version info from the native dll, even though the actual code will run from the builtin. This may help programs believe they got the exact version they wanted (since presumably the app installed the dll in the first place). > Will DONT_RESOLVE_DLL_REFERENCES work with built-in dlls somewhere in the future? Unlikely; the problem is that we cannot prevent constructors from running, and we need to resolve imports before running constructors. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set
by Alexandre Julliard 20 Mar '01

20 Mar '01

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > But here is a problem. This doesn't honor a load order. If load order > of a requested dll explicitly specified as 'builin' but 'native' library > there is somewhere in the path, then we will get unexpected result. > How to cope with it? I think it's reasonable to give the native dll priority when doing LOAD_LIBRARY_AS_DATAFILE. An app using this wants to poke inside the dll binary file and we are much better off giving it the 'real' thing in this case IMO. -- Alexandre Julliard julliard(a)winehq.com

2 1

fixme:win32:DeviceIoControl Unimplemented control 104 for VxD device SECPROV
by Achilleas Mantzios 19 Mar '01

19 Mar '01

Does anyone have a clue??? P.S. You have done serious job :) i wanna say. -- Á÷éëëÝáò ÌÜíôæéïò Application Developer Eurisko A.E. ÐéíäÜñïõ 9 106 71 ÁèÞíá Ôçë: +301 3633362 Öáî: +301 3633074 e-mail: achilleas.mantzios(a)eurisko.gr

1 0

Re: RFC: client side implementation of async I/O
by Mike McCormack 19 Mar '01

19 Mar '01

Hi All, WWW reported that my client side async patch relies on the service thread... sorry for not clearly explaining, but it doesn't. It works by multiplexing the server's wait reponse fd with pending i/o operation fds using poll. When i have time, i'll try to clean it up a bit. Currently i'm working on a kernel patch to help implement other WaitCommEvent flags. i hope Alexandre considers applying the client side async patch in some form. Mike ------------------------------------------ mailto:Mike_McCormack@looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your own free web email at http://www.looksmart.com.au LookSmart Australia

1 0

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

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