wine-devel

wine-devel@winehq.org

84463 discussions

Re: Another pack4 issue (fwd)
by Francois Gouget 27 Nov '01

27 Nov '01

On Thu, 22 Nov 2001, Dmitry Timoshkov wrote: > "Francois Gouget" <fgouget(a)free.fr> wrote: > > > After the recent patch sent by Dmitry Timoshkov I checked for other > > similar issues. AFAICS, at this time there is only one place where a > > pack4 is really necessary. > > Well, I don't know why you are so sure. My testing revealed the following > differences in structure sizes between Wine and Windows: Well, I had just performed a search on 'pshpck4.h' and checked that against Wine's headers to see whether there would be a difference. Your method seems much more thorough. I am a bit surprised that we have so many differences. We should see tons of crashes... (maybe that's good news) [...] > What is really fun, that usage of FILETIME instead of LARGE_INTEGER leads > to differences in size of structures. That's very strange. It would be good to understand why because this should not happen. diff -u cvs/hq/wine/dlls/advapi32/registry.c wine/dlls/advapi32/registry.c --- cvs/hq/wine/dlls/advapi32/registry.c Mon Jul 23 22:19:41 2001 +++ wine/dlls/advapi32/registry.c Thu Nov 22 17:52:05 2001 @@ -287,7 +287,7 @@ DWORD len = info->NameLength / sizeof(WCHAR); DWORD cls_len = info->ClassLength / sizeof(WCHAR); - if (ft) *ft = info->LastWriteTime; + if (ft) *ft = *(FILETIME *)&info->LastWriteTime; This cast should not be necessary. Both sides are FILETIMEs. --- cvs/hq/wine/dlls/ntdll/reg.c Thu Nov 8 16:15:30 2001 +++ wine/dlls/ntdll/reg.c Thu Nov 22 17:45:36 2001 @@ -161,9 +161,9 @@ WCHAR *class_ptr = (WCHAR *)((char *)name_ptr + name_size); int class_size = server_data_size(req) - sizeof(WCHAR) - name_size; int fixed_size; - FILETIME modif; + LARGE_INTEGER modif; - RtlSecondsSince1970ToTime( req->modif, &modif ); + RtlSecondsSince1970ToTime( req->modif, (FILETIME *)&modif ); Here I don't understant why you changed modif to a LARGE_INTEGER since RtlSecondsSince1970ToTime takes a FILETIME* switch(info_class) { diff -u cvs/hq/wine/include/commctrl.h wine/include/commctrl.h --- cvs/hq/wine/include/commctrl.h Wed Aug 8 17:37:12 2001 +++ wine/include/commctrl.h Thu Nov 22 16:50:13 2001 @@ -744,6 +744,8 @@ LPARAM lParam; INT iImage; INT iOrder; + UINT type; + LPVOID pvFilter; } HDITEMA, *LPHDITEMA; I don't see these two fields on Windows. Same thing for the W version. That's with the VC 6 headers. @@ -2959,9 +2958,11 @@ typedef struct { DWORD cb; - BYTE DeviceName[32]; - BYTE DeviceString[128]; + CHAR DeviceName[32]; + CHAR DeviceString[128]; DWORD StateFlags; + CHAR DeviceID[128]; + CHAR DeviceKey[128]; } DISPLAY_DEVICEA,*PDISPLAY_DEVICEA,*LPDISPLAY_DEVICEA; Hmm, no. It is 'BYTE' on Windows. And I don't see the two extra fields either. diff -u cvs/hq/wine/include/winnt.h wine/include/winnt.h --- cvs/hq/wine/include/winnt.h Mon Aug 13 00:51:56 2001 +++ wine/include/winnt.h Thu Nov 22 18:00:57 2001 @@ -396,8 +396,6 @@ typedef a *P##a, *LP##a #endif /*STRICT*/ - -#include "pshpack1.h" /* Defines */ /* Argument 1 passed to the DllEntryProc. */ @@ -576,6 +574,8 @@ DWORD Cr0NpxState; } FLOATING_SAVE_AREA, *PFLOATING_SAVE_AREA; +#define MAXIMUM_SUPPORTED_EXTENSION 512 + typedef struct _CONTEXT86 { DWORD ContextFlags; @@ -612,6 +612,8 @@ DWORD EFlags; DWORD Esp; DWORD SegSs; + + BYTE ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION]; } CONTEXT86; I don't have this field in CONTEXT86, but it is there in CONTEXT. It seems that it's our definition of CONTEXT which is wrong: typedef CONTEXT86 CONTEXT; @@ -2923,11 +2923,15 @@ WORD Reserved; } IMAGE_BOUND_FORWARDER_REF, *PIMAGE_BOUND_FORWARDER_REF; +#include "pshpack2.h" + typedef struct _IMAGE_BASE_RELOCATION { DWORD VirtualAddress; DWORD SizeOfBlock; +#ifdef __WINE__ WORD TypeOffset[1]; +#endif } IMAGE_BASE_RELOCATION,*PIMAGE_BASE_RELOCATION; Do we handle this correctly in the code? I.e. is there APIs where the application gives us a pointer to a struct without the field and we write to it? I wonder how this is supposed to work. +#include "pshpack4.h" typedef struct _LUID_AND_ATTRIBUTES { LUID Luid; DWORD Attributes; } LUID_AND_ATTRIBUTES; +#include "poppack.h" Is this really necessary? LUID is 8 bytes so the DWORD should be aligned just fine with or without the pack4... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

3 4

SetActiveWindow problem
by bperkins＠netspace.org 27 Nov '01

27 Nov '01

Sorry, I'm new to wine hacking, so bear with me. I was playing around a bit the other day trying to see if the tahni deskmate worked at all. I tried to run the installer (tahnisetup.exe available at tahni.com). It would run, and then crash with a stack overflow. I've attached the sequence in a backtrace that was repeated many times at the bottom. It's wine-20011108, BTW. Since I don't have the source to tahnisetup it made things a bit tricky to decipher. My guess was(is) that the program is trying to the window as active, which sends a message to the program. It sees that it's not active, so it again tries to set it as be active, which eventually causes a stack overflow. My awful hack was to just put a sanity counter in SetActiveWindow and return true after being called a certain number of times. This seems to work, as in it causes to program to get farther (it gets stuck on something else). Presumably one could check if it was being called recursively. I realize that this isn't really useful info, but I was curious to see if I was right about this, or if anyone had an insight. Am I right or did I just get lucky with the hack? 25246 0x0040266f (tahnisetup.exe..text+0x166f in E:\tahnisetup.exe) (ebp=437e6444) 25247 0x407c3a67 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=437e6468) 25248 0x407c3af2 (WINPROC_CallWndProc+0x82(proc=0x4025b8, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:173] in libuser32.so) (ebp=437e6498) 25249 0x407c95ca (CallWindowProcA+0x4a(func=0x4025b8, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2623] in libuser32.so) (ebp=437e64cc) 25250 0x4097b54c (FILEDLG_CallWindowProc+0x54(lfs=0x40400dbc, wMsg=0x6, wParam=0x0, lParam=0x10026) [filedlg.c:294] in libcomdlg32.so) (ebp=437e64f4) 25251 0x4097d944 (FileOpenDlgProc+0x78(hWnd=0x1002f, wMsg=0x6, wParam=0x0, lParam=0x10026) [filedlg.c:1440] in libcomdlg32.so) (ebp=437e651c) 25252 0x407c3a67 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=437e6540) 25253 0x407c3af2 (WINPROC_CallWndProc+0x82(proc=0x4097d8cc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:173] in libuser32.so) (ebp=437e6570) 25254 0x407c91f4 (WINPROC_CallProc32WTo32A+0x80(func=0x4097d8cc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2435] in libuser32.so) (ebp=437e6598) 25255 0x407c972b (CallWindowProcW+0xab(func=0x430c0984, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2675] in libuser32.so) (ebp=437e65cc) 25256 0x4079f744 (DefDlgProcW+0x48(hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [defdlg.c:389] in libuser32.so) (ebp=437e65f8) 25257 0x407c3a67 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=437e661c) 25258 0x407c3af2 (WINPROC_CallWndProc+0x82(proc=0x4079f6fc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:173] in libuser32.so) (ebp=437e664c) 25259 0x407c9152 (WINPROC_CallProc32ATo32W+0x7e(func=0x4079f6fc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2412] in libuser32.so) (ebp=437e6674) 25260 0x407c9647 (CallWindowProcA+0xc7(func=0x430c0259, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2643] in libuser32.so) (ebp=437e66a8) 25261 0x4076957e (call_window_proc+0xf2(hwnd=0x1002f, msg=0x6, wparam=0x0, lparam=0x10026, unicode=0x0) [message.c:1146] in libuser32.so) (ebp=437e6704) 25262 0x4076a1af (SendMessageTimeoutA+0xdf(hwnd=0x1002f, msg=0x6, wparam=0x0, lparam=0x10026, flags=0x0, timeout=0xffffffff, res_ptr=0x437e6788) [message.c:1577] in libuser32.so) (ebp=437e6764) 25263 0x4076a317 (SendMessageA+0x37(hwnd=0x1002f, msg=0x6, wparam=0x0, lparam=0x10026) [message.c:1622] in libuser32.so) (ebp=437e6798) 25264 0x407c2e92 (WINPOS_SetActiveWindow+0x196(hWnd=0x10026, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1282] in libuser32.so) (ebp=437e67f0) 25265 0x407c229a (SetForegroundWindow+0x7a(hwnd=0x10026) [winpos.c:781] in libuser32.so) (ebp=437e680c) -- "Only CmdrTaco can save us now" -- The Register Brian Perkins bperkins(a)netspace.org

1 0

winedbg error
by Dave Hawkes 26 Nov '01

26 Nov '01

Hi all, I keep getting an assertion in winedbg, before I try and find out the cause does anyone know the possible reason for this? winedbg: types.c:573: DEBUG_CopyFieldList: Assertion 'dt->type == dt2->type && ((dt->type == DT_STRUCT) || (dt->type == DT_ENUM))' failed. It looks like its an issue with parsing the debug info, but the windows application debugs just fine with MS Developer Studio 6. Thanks, Dave Hawkes

3 10

ITypeInfo_fnGetContainingTypeLib
by lawson_whitney＠juno.com 25 Nov '01

25 Nov '01

Good day! Anyone like to take a swat at this? I don't normally shy from a page fault, but frankly, ICOM confuses me. Anyway, maybe Ove can spot it in a second. If I have to do it it may take weeks. Backtrace attached. Wineconsole seems to be working nicely, as long as the resolution is good and high. I wanted to include a typelib trace, but that crashes at an earlier spot. I haven't really looked at that one yet; I can send it along if anyone is interested. At least Wine is starting to get its teeth into InstallSh**** and its confounded IKernel.exe. Regards Lawson ---oof---

3 5

Re: Crashing menus, event handling broken?
by Alexandre Julliard 25 Nov '01

25 Nov '01

Jukka Heinonen <jhei(a)iki.fi> writes: > The reason for this is that raw hardware messages get processed > before menu event loop starts. Raw event processing turns raw events > into cooked events and because menu event loop has not started yet, > game window is not capturing events and thus clicks on menu bar > are turned into nonclient messages. These cooked messages are > put back into message queue. Raw messages are not supposed to get processed while there is a cooked message in the queue. Is the app filtering messages in GetMessage? Could you please do a +server trace showing the problem? -- Alexandre Julliard julliard(a)winehq.com

3 3

Re: ttydrv fix (adds missing ShowWindow function)
by lawson_whitney＠juno.com 25 Nov '01

25 Nov '01

On Thu, 22 Nov 2001, Eric Laforest wrote: > tydrv/ttydrv.spec > =================================================================== > RCS file: /cvsroot/winex/wine/dlls/ttydrv/ttydrv.spec,v > retrieving revision 1.1.1.8 > diff -r1.1.1.8 ttydrv.spec > 71a72 > > @ cdecl ShowWindow(long long) TTYDRV_ShowWindow > Index: dlls/ttydrv/wnd.c > =================================================================== > RCS file: /cvsroot/winex/wine/dlls/ttydrv/wnd.c,v > retrieving revision 1.1.1.10 > diff -r1.1.1.10 wnd.c > 648a649,809 > > I think it is worth reading <wine>/README all the way to the end, where you will see: 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 Is it asking too much to use diff -u? Would you like to get patches from all over the world against who knows which version of wine in random formats? I think -u is the only format suitable for an open-source project. Regards, Lawson ---oof---

1 1

Re: wineconsole compile error
by Gerard Patel 24 Nov '01

24 Nov '01

At 06:59 PM 24/11/2001 +0100, you wrote: >make[1]: Entre dans le répertoire `/home/wine/programs/wineconsole' >gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -DSTRICT -DUNICODE -D_REENTRANT -I/usr/X11R6/include -o >dialog.o dialog.c >dialog.c: In function `WCUSER_GetProperties': >dialog.c:492: structure has no member named `u' <snip> Yes, me too. Does the patch posted on Wine-patches by Chris Green not fix it for you ? Gerard

3 2

Re: mmsystem should be loaded at startup
by eric pouech 24 Nov '01

24 Nov '01

Joshua Thielen wrote: > > Note: I'm not sure if I should have called ExitProcess if mmsystem.dll > can't be loaded not needed, if it couldn't be loaded, then no need to free it > and if I needed to call FreeLibrary. I just took the > LoadLibrary("user32") as an example. well, error reporting for 16 bit DLL is a bit different (see below) > + if(!(mmsystem = LoadLibrary16("mmsystem.dll"))) the correct test should be > + if((mmsystem = LoadLibrary16("mmsystem.dll")) < 32) (the other values (< 32) are the error codes) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

mmsystem should be loaded at startup
by Joshua Thielen 24 Nov '01

24 Nov '01

Hello everybody, Finale expects mmsystem to be present without having to call LoadLibrary on it. It does a GetModuleHandle on mmsystem.dll to find out if the mm extensions are available. I checked out windows 95, and it has mmsystem and winmm loaded when no apps are runing besides the desktop / explorer. This patch links wine with winmm andmakes winmm load mmsystem on init. Finale gets by this ok now. I don't know if this the correct approach, though. Could someone (Eric or Alexandre?) please take a look at it before I send it to wine-patches? TIA, Josh Thielen Index: wine/miscemu/wine.spec =================================================================== RCS file: /home/wine/wine/miscemu/wine.spec,v retrieving revision 1.3 diff -u -r1.3 wine.spec --- wine/miscemu/wine.spec 2000/12/15 03:38:11 1.3 +++ wine/miscemu/wine.spec 2001/11/23 19:11:47 @@ -4,3 +4,4 @@ init wine_initial_task import ntdll.dll +import winmm.dll Index: wine/dlls/winmm/mmsystem.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/mmsystem.c,v retrieving revision 1.46 diff -u -r1.46 mmsystem.c --- wine/dlls/winmm/mmsystem.c 2001/11/13 21:58:32 1.46 +++ wine/dlls/winmm/mmsystem.c 2001/11/23 19:11:59 @@ -114,6 +114,7 @@ */ BOOL WINAPI WINMM_LibMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID fImpLoad) { + HINSTANCE16 mmsys16; TRACE("0x%x 0x%lx %p\n", hInstDLL, fdwReason, fImpLoad); switch (fdwReason) { @@ -124,9 +125,15 @@ MULTIMEDIA_DeleteIData(); return FALSE; } + mmsys16 = LoadLibrary16("mmsystem.dll"); + if (!mmsys16) { + ERR("Could not load sibling mmsystem.dll\n"); + return FALSE; + } break; case DLL_PROCESS_DETACH: MULTIMEDIA_DeleteIData(); + if(mmsys16) FreeLibrary16(mmsys16); break; case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: @@ -2549,7 +2556,7 @@ TRACE("(%d, %p, %d);\n", uDeviceID, lpCaps, uSize); if ((wmld = MMDRV_Get(uDeviceID, MMDRV_MIDIIN, TRUE)) == NULL) - return MMSYSERR_INVALHANDLE; + return MMSYSERR_BADDEVICEID; return MMDRV_Message(wmld, MIDM_GETDEVCAPS, (DWORD)lpCaps, uSize, TRUE); }

3 3

Re: mmsystem should be loaded at startup
by Alexandre Julliard 24 Nov '01

24 Nov '01

Joshua Thielen <thielen(a)netprince.net> writes: > Finale expects mmsystem to be present without having to call LoadLibrary > on it. It does a GetModuleHandle on mmsystem.dll to find out if the mm > extensions are available. I checked out windows 95, and it has mmsystem > and winmm loaded when no apps are runing besides the desktop / > explorer. This patch links wine with winmm andmakes winmm load mmsystem > on init. Finale gets by this ok now. I don't know if this the correct > approach, though. Could someone (Eric or Alexandre?) please take a look > at it before I send it to wine-patches? It would be better to do the LoadLibrary16("mmsystem") in wine_initial_task, this way it only impacts 16-bit applications. -- Alexandre Julliard julliard(a)winehq.com

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