- wine-devel - winehq.org

The [Windows] section
by Bill Medland 12 Jul '01

12 Jul '01

Is the [Windows] section of the config still supposed to be in use or should Tweak.Layout be used instead? (I am looking at the [Windows].BorderWidth in particular) Bill

1 1

Re: msvcrt switching from builtin to native
by Alexandre Julliard 11 Jul '01

11 Jul '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > _ismbcdigit is unimplemented. The log looks like wine starts to think with > that call that msvcrt is a native dll. Implementing a semi stub for that > gives the same behaviour at the next unimplemented msvcrt function. This should fix it: Index: loader/pe_image.c =================================================================== RCS file: /opt/cvs-commit/wine/loader/pe_image.c,v retrieving revision 1.94 diff -u -r1.94 pe_image.c --- loader/pe_image.c 2001/05/24 18:43:16 1.94 +++ loader/pe_image.c 2001/07/11 20:50:37 @@ -655,7 +655,7 @@ return NULL; } - if (pe_export) + if (!builtin && pe_export) SNOOP_RegisterDLL( hModule, wm->modname, pe_export->Base, pe_export->NumberOfFunctions ); /* Send DLL load event */ -- Alexandre Julliard julliard(a)winehq.com

1 0

msvcrt switching from builtin to native
by Uwe Bonnes 11 Jul '01

11 Jul '01

Hallo, trying to run msdev.exe with builtin msvcrt, at some point thins strange +snoop,+relay log appears: 08066950:Call msvcrt._strdup(4040b294 "Microsoft Visual C++") ret=5f416652 08066950:Call kernel32.HeapAlloc(40390000,00000000,00000015) ret=4063d846 08066950:Ret kernel32.HeapAlloc() retval=4041c338 ret=4063d846 08066950:Ret msvcrt._strdup() retval=4041c338 ret=5f416652 08066950:Call msvcrt._mbsinc(5f49d450 "%d") ret=5f4160fb 08066950:Ret msvcrt._mbsinc() retval=5f49d451 ret=5f4160fb 08066950:Call msvcrt.atoi(5f49d451 "d") ret=5f41614d 08066950:Ret msvcrt.atoi() retval=00000000 ret=5f41614d 08066950:CALL msvcrt.292: _ismbcdigit(<unknown, check return>) ret=5f416161 ^^^^ 08066950:Call ntdll.RtlRaiseException(406064e0) ret=40631056 08066950:CALL msvcrt.74: __CxxFrameHandler(<unknown, check return>) ret=4006ac97 08066950:Call ntdll.RtlRaiseException(406061d0) ret=40631056 08066950:CALL msvcrt.74: __CxxFrameHandler(<unknown, check return>) ret=4006ac97 _ismbcdigit is unimplemented. The log looks like wine starts to think with that call that msvcrt is a native dll. Implementing a semi stub for that gives the same behaviour at the next unimplemented msvcrt function. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Early crash with msdev.exe
by Uwe Bonnes 11 Jul '01

11 Jul '01

Hallo, trying msdev.exe from Microsoft Visual C in a demonstration at Linuxtag, I was astonished how far wine proceeds. Only when trying to create a template, wine crashed. Trying to debug with snoop, however the crash happens much earlier. I tried to look hard at snoop.c, but couldn't find where this error may originate from. Has anybody some idea? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- 08066950:RET msvcrt.658: malloc() retval = 40b01f20 ret=50043066 tid=08066950 08066950:CALL msvcrt.272: _initterm() ret=50043090 08066950:CALL devshl.1603: @(00000700,00000081,00000000,40605ad4,4060576c) ret=50301f0a 08066950:RET devshl.1603: @() retval = 00000000 ret=50301f0a tid=08066950 08066950:CALL mfc42.6374: @(<unknown, check return>) ret=50301f51 08066950:CALL mfc42.5163: @(<unknown, check return>) ret=5f401aff 08066950:CALL msvcrt.67: _EH_prolog(4101007d,00000081,00000000,40605ad4,40605728,40b06da0,00000000,40605748,41010064,00000081,00000000,40605ad4,40b06da0,40b06da0,40605764,50301f1f, ...) ret=5f401b2b 08066950:RET msvcrt.67: _EH_prolog() retval = 41010096 ret=5f401b2b tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler(<unknown, check return>) ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.203: _except_handler3(<unknown, check return>) ret=4006ac97 08066950:CALL msvcrt.73: _XcptFilter(<unknown, check return>) ret=0040175d fixme:pthread_kill_other_threads_np FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock Could not stat /home/bon/ikda/vol2 (No such file or directory), ignoring drive Y: FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock Could not stat /home/bon/ikda/sys (No such file or directory), ignoring drive Z: WineDbg starting... on pid 80683b0 No debug information in 32bit DLL '<Debugged process>' (0x00400000) Loaded debug information from ELF 'wine' (0x00000000) Breakpoint 1 at 0x4000da00 (_end+0x37fc1284) Loaded debug information from ELF '/spare/bon/wine/dlls/libntdll.so' (0x40026000) Loaded debug information from ELF '/spare/bon/wine/libwine.so' (0x40127000) Loaded debug information from ELF '/spare/bon/wine/libwine_unicode.so' (0x4013d000) Loaded debug information from ELF '/lib/libncurses.so.5' (0x40205000) Loaded debug information from ELF '/lib/libm.so.6' (0x4024f000) No debug information in ELF '/lib/libutil.so.1' (0x4026d000) No debug information in ELF '/lib/libdl.so.2' (0x40270000) Loaded debug information from ELF '/lib/libc.so.6' (0x40273000) Loaded debug information from ELF '/lib/ld-linux.so.2' (0x40000000) Loaded debug information from ELF '/spare/bon/wine/dlls/libkernel32.so' (0x40617000) Loaded debug information from ELF '/spare/bon/wine/dlls/libgdi32.so' (0x406b4000) Loaded debug information from ELF '/spare/bon/wine/dlls/libadvapi32.so' (0x40723000) Loaded debug information from ELF '/spare/bon/wine/dlls/libuser32.so' (0x40762000) Loaded debug information from ELF '/spare/bon/wine/dlls/libshell32.so' (0x40882000) Loaded debug information from ELF '/spare/bon/wine/dlls/libshlwapi.so' (0x408e8000) Loaded debug information from ELF '/spare/bon/wine/dlls/libcomctl32.so' (0x40923000) Loaded debug information from ELF '/spare/bon/wine/dlls/libx11drv.so' (0x40c00000) Loaded debug information from ELF '/spare/bon/wine/libwine_tsx11.so' (0x40741000) No debug information in ELF '/usr/X11R6/lib/libSM.so.6' (0x40019000) No debug information in ELF '/usr/X11R6/lib/libICE.so.6' (0x40c4d000) No debug information in ELF '/usr/X11R6/lib/libXpm.so.4' (0x40c65000) No debug information in ELF '/usr/X11R6/lib/libXxf86dga.so.1' (0x40387000) No debug information in ELF '/usr/X11R6/lib/libXxf86vm.so.1' (0x404e5000) No debug information in ELF '/usr/X11R6/lib/libXv.so.1' (0x404ea000) No debug information in ELF '/usr/X11R6/lib/libXext.so.6' (0x40752000) No debug information in ELF '/usr/X11R6/lib/libX11.so.6' (0x40c74000) No debug information in ELF '/usr/lib/gconv/ISO8859-1.so' (0x4038d000) Loaded debug information from ELF '/spare/bon/wine/dlls/libversion.so' (0x404d3000) Loaded debug information from ELF '/spare/bon/wine/dlls/liblz32.so' (0x40695000) No debug information in 32bit DLL 'NTDLL.DLL' (0x40060000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSVCRT.DLL' (0x78000000) No debug information in 32bit DLL 'ADVAPI32.DLL' (0x40731000) No debug information in 32bit DLL 'GDI32.DLL' (0x406d0000) No debug information in 32bit DLL 'USER32.DLL' (0x40790000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MFC42.DLL' (0x5f400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x7ff20000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLEAUT32.DLL' (0x7fe80000) No debug information in 32bit DLL 'SHLWAPI.DLL' (0x408fd000) No debug information in 32bit DLL 'COMCTL32.DLL' (0x4092f000) No debug information in 32bit DLL 'SHELL32.DLL' (0x4089c000) No debug information in 32bit DLL 'K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVSHL.DLL' (0x50000000) No debug information in 32bit DLL 'X11DRV.DLL' (0x40c11000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MFC42LOC.DLL' (0x7baf0000) No debug information in 32bit DLL 'LZ32.DLL' (0x40698000) No debug information in 32bit DLL 'VERSION.DLL' (0x404d6000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x7fb90000) No debug information in 32bit DLL 'K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVEDIT.PKG' (0x50800000) No debug information in 32bit DLL 'K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG' (0x50300000) 08066950:RET msvcrt.73: _XcptFilter() retval = 00000000 ret=0040175d 08066950:RET msvcrt.203: _except_handler3() retval = 00000001 ret=4006ac97 Unhandled exception: page fault on read access to 0x0000000f in 32-bit code (0x5f401ead). In 32-bit mode. 0x5f401ead (MFC42.DLL.1145+0x10 in C:\WINDOWS\SYSTEM\MFC42.DLL): cmpl $0,0x10(%ebx) Wine-dbg>bt Backtrace: =>0 0x5f401ead (MFC42.DLL.1145+0x10 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=40605684) 1 0x5f401c94 (MFC42.DLL.5163+0x173 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=4060570c) 2 0x4101007d (_end+0x3c3255) (ebp=4060572c) 3 0x41010064 (_end+0x3c323c) (ebp=40605748) 4 0x50301f1f (DEVPRJ.PKG..text+0xf1f in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=40605764) 5 0x5f401a88 (MFC42.DLL.1109+0x74 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=406057c4) 6 0x5f401a10 (MFC42.DLL.1578+0x2a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=406057e0) 7 0x5f4019cf (MFC42.DLL.1579+0x39 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=4060580c) 8 0x40803b87 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=40605830) 9 0x40803c06 (WINPROC_CallWndProc+0x76(proc=0x5f401996, hwnd=0x700, msg=0x81, wParam=0x0, lParam=0x40605ad4) [winproc.c:171] in libuser32.so) (ebp=4060585c) 10 0x408097f8 (CallWindowProcA+0x88(func=0x40d70dbc, hwnd=0x700, msg=0x81, wParam=0x0, lParam=0x40605ad4) [winproc.c:2589] in libuser32.so) (ebp=40605884) 11 0x407ea1a3 (MSG_SendMessage+0x3b3(hwnd=0x700, msg=0x81, wParam=0x0, lParam=0x40605ad4, timeout=0xffffffff, type=0x2, pRes=0x406058ec) [message.c:1733] in libuser32.so) (ebp=406058bc) 12 0x407ea2a2 (SendMessageA+0x32(hwnd=0x700, msg=0x81, wParam=0x0, lParam=0x40605ad4) [message.c:1772] in libuser32.so) (ebp=406058f0) 13 0x40c15014 (X11DRV_CreateWindow+0x184(hwnd=0x700, cs=0x40605ad4, unicode=0x0) [window.c:871] in libx11drv.so) (ebp=40605938) 14 0x407fce51 (WIN_CreateWindowEx+0x6d1(cs=0x40605ad4, classAtom=0xc066, type=0x2) [win.c:865] in libuser32.so) (ebp=406059b0) 15 0x407fd2fb (CreateWindowExA+0x14b(exStyle=0x0, className=0x403fcebc, windowName=0x0, style=0x42000001, x=0x0, y=0x0, width=0x0, height=0x0, parent=0x2b4, menu=0x7310, instance=0x400000, data=0x40605be0) [win.c:1030] in libuser32.so) (ebp=40605b04) 16 0x5f40c211 (MFC42.DLL.2152+0x9a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=40605b74) 17 0x5f40aaa5 (MFC42.DLL.2124+0x46 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=40605bb0) 18 0x4101004b (_end+0x3c3223) (ebp=40605c04) 19 0x50311b41 (DEVPRJ.PKG.InitPackage+0x4b5 in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=40605c2c) 20 0x50310336 (DEVPRJ.PKG.EntryPoint+0xb5e in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=40605c58) 21 0x50311a22 (DEVPRJ.PKG.InitPackage+0x396 in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=40605c84) 22 0x50311760 (DEVPRJ.PKG.InitPackage+0xd4 in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=406060c0) 23 0x50036fa3 (DEVSHL.DLL.3467+0x9a in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVSHL.DLL) (ebp=40606664) 24 0x500344be (DEVSHL.DLL.3219+0x53d in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVSHL.DLL) (ebp=40606e0c) 25 0x41010019 (_end+0x3c31f1) (ebp=40606ecc) 26 0x400dbf23 (start_process+0x1a3 [process.c:391] in libntdll.so) (ebp=40606f30) 27 0x400dfaa1 (SYSDEPS_DoCallOnStack+0x21(func=0x400dbd80, arg=0x0) [sysdeps.c:173] in libntdll.so) (ebp=40606ff0) 28 0x400dfb43 (SYSDEPS_CallOnStack+0x2f in libntdll.so) (ebp=bffff5f0) 29 0x400dfbfa (SYSDEPS_SwitchToThreadStack+0x9a(func=0x400dbd80) [sysdeps.c:236] in libntdll.so) (ebp=bffff62c) 30 0x400dc2be (PROCESS_InitWine+0x1ce(argc=0x4, argv=0xbffff6c4, win16_exe_name=0x804c660, win16_exe_file=0x804c764) [process.c:519] in libntdll.so) (ebp=bffff644) 31 0x0804b20a (Letext [main.c] in wine) (ebp=bffff65c) 32 0x4028fbaf (__libc_start_main+0xcf in libc.so.6) (ebp=bffff698) 33 0x08049021 (_start+0x21 in wine) (ebp=00000000) Wine-dbg>quit WineDbg terminated on pid 80683b0

1 0

Re: PATCH: include mess up
by Francois Gouget 11 Jul '01

11 Jul '01

On Tue, 10 Jul 2001, Marcus Meissner wrote: > Hi, > > There is some bad recursion when including objbase.h in non-WINE programs. > This fixes that problem, by using winbase.h instead of windows.h. Yes but rpc.h is supposed to include 'windows.h', not 'winbase.h'. The correct fix must be elsewhere. What is the recursion that happens and which include statement (in your application) triggers it? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: the choice of a GNU generation

2 1

Re: implement overlapped completion routines
by Alexandre Julliard 10 Jul '01

10 Jul '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > This patch implements overlapped completion routines, and fixes up a > small problem with the overlapped implementation. According to ms > docs, the transfer count should not be stored in the overlapped > structure. Shouldn't you queue an APC instead of calling the completion routine directly? -- Alexandre Julliard julliard(a)winehq.com

1 0

Joysiick under Wine
by David Hagood 10 Jul '01

10 Jul '01

I've seen a couple of messages about getting USB joysticks working under Wine, but do regular (i.e. gameport) sticks work? I've confirmed that my stick is being read by Linux, and that it is reporting events correctly. Now, how do I get Wine to pass them along? I've confirmed: 1) that I have read/write permissions to /dev/js0 2) that Wine tries to read /dev/js0 3) that Wine indeed does read from /dev/js0, but that 4) Wine shortly thereafter closes /dev/js0, never to read it again. Do I need to have the X Window system joystick driver loaded? Or do I need to add something to the system.ini or .wine/config files. This is a Windowless install, under RH6.1, with 2.4.6, and a CVS pull of Wine from a few days ago. I'm trying to get HalfLife running under Wine. I have the GL working, I have sound working, but I am one of those strange fellows that likes to move with a stick, and look with a mouse. Are there any Windows/Wine tools that I can run to try to troubleshoot this?

2 1

Re: some rasapi32 stubs
by Marcus Meissner 10 Jul '01

10 Jul '01

On Tue, Jul 10, 2001 at 10:10:17PM +1000, Mike McCormack wrote: > > ChangeLog: > * dlls/rasapi32/rasapi.c, dlls/rasapi32/rasapi32.spec > Stub some rasapi functions. If you know arguments are strings you can use 'str' instead of 'ptr' in the .spec file, and relay debugging will print strings ;) Also you can use the return value of debugstr_a(a) for string output. Ciao, Marcus

1 0

Re: wv{sn,ns}printf[AW]
by Alexandre Julliard 09 Jul '01

09 Jul '01

Peter Hunnisett <hunnise(a)yahoo.com> writes: > 2) Can wvnsprintf be moved from user32 into shlwapi? This would cause > user32 to have to import shlwapi (because wsprintfA and friends use it > in their implementation) and I don't know if that's legal because user32 > seems to only import gdi32 and kernel32. If not, what's the solution? > Reimplement everything in user32 to not use wvnsprintf and move the > implementation over or just keep the existing situation and rename > wvnsprintf to wvnsprintf and forward the shlwapi calls to user32? user32 cannot import shlwapi, since this would create a circular dependency. Since the functions are needed both in user32 and shlwapi, they have to be implemented in user32 and forwarded from shlwapi to user32 (the alternative is to have two complete wsprintf implementations, which is a bit of a pain). I guess you could also rename the user32 ones, but this is not strictly necessary (and the current name has the advantage of following the C library naming of vsnprintf). -- Alexandre Julliard julliard(a)winehq.com

1 0

wv{sn,ns}printf[AW]
by Peter Hunnisett 09 Jul '01

09 Jul '01

Hi, it appears that we have a bit of a hack in the wine code. Presently we export wvsnprintf[AW] from user32. - These two functions do not appear to be in the real user32.dll and the comments in the code seem to back it up. - Windows does have wvnsprintf[AW] (note the transposed "sn") exported from shlwapi.dll So my questions are: 1) Was the user32 a bit of a hack because those routines just weren't noticed or was it because of something from before shlwapi? 2) Can wvnsprintf be moved from user32 into shlwapi? This would cause user32 to have to import shlwapi (because wsprintfA and friends use it in their implementation) and I don't know if that's legal because user32 seems to only import gdi32 and kernel32. If not, what's the solution? Reimplement everything in user32 to not use wvnsprintf and move the implementation over or just keep the existing situation and rename wvnsprintf to wvnsprintf and forward the shlwapi calls to user32? Thanks, Peter hunnise(a)yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0

Re: Are these the ordinal names?
by Alexandre Julliard 08 Jul '01

08 Jul '01

Peter Hunnisett <hunnise(a)yahoo.com> writes: > Howdy, > I have a couple of questions about the following error messages > > err:win32:fixup_imports No implementation for > SHLWAPI.dll.281(wvnsprintfA) imported from > C:\windows\system\shdocvw.dll, setting to 0xdeadbeef > err:win32:fixup_imports No implementation for > SHLWAPI.dll.282(wvnsprintfW) imported from > C:\windows\system\shdocvw.dll, setting to 0xdeadbeef > err:win32:fixup_imports No implementation for > SHLWAPI.dll.240(StrRetToStrW) imported from > C:\windows\system\shdocvw.dll, setting to 0xdeadbeef > > 1) Do these messages mean that 281 is named wvnsprintfA and so on? If > so, why does the SHLWAPI.240 name not seem to jive with the existing > implementation? If a name is specified, the ordinal is only a hint, so it's OK for it to be different. What this means is that in some version of shlwapi StrRetToStrW is at ordinal 240, but it can be at other ordinals in other versions since it is looked up by name. In our builtin version, ordinal 240 is something else (which is fine), and StrRetToStrW is not implemented at all (which is the cause of your problem). You can either implement it, or use the native shlwapi. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: sharing windows between processes
by Alexandre Julliard 08 Jul '01

08 Jul '01

"Bill Medland" <medbi01(a)accpac.com> writes: > Some time ago I raised the issue of the fact that windows handles cannot be > shared between processes on the same server and was told that it was a > known significant issue. > > Is anyone doing anything about it? Sure, that's the main reason behind all the recent window management and messaging changes. So yes, it is being worked on. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Mouse events
by Alexandre Julliard 08 Jul '01

08 Jul '01

Duane Clark <dclark(a)akamail.com> writes: > I assume some problem led to its removal. I regularly try out Myst (the > 32 bit version) as a test, running locally on a 700MHz Athlon, so this > can't be blamed on a slow ethernet connection or slow machine. When > dragging the slide controls in the "planetarium", they used to follow > the mouse just fine. With this patch, if you grab the control, move the > mouse and release it, the control does not keep up with the mouse but > just moves at a moderately slow pace until it reaches the point where > the mouse was released (a few seconds to travel from one end to the > other). At that point everything returns to normal. The new hardware event handling does not yet attempt to merge mouse motion events, so this is probably the reason for the problem. This should be fixed soon. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: printing docu
by Duane Clark 08 Jul '01

08 Jul '01

Andreas Mohr wrote: > Hi all, > > while trying to configure Wine for printing in order to be able to use > Windows Acrobat Reader instead of Linux acroread which is crashing on certain > PDF files, I remembered that the printing docu is everything but perfect. > > Updated printing docu a bit. > > ... > - <sect3> > <title>Spooling</title> > <para> > Spooling is rather primitive. The [spooler] section of > @@ -82,13 +82,14 @@ > example the following lines > </para> > <screen> > -"LPT1:" = "foo.ps" "LPT2:" = "|lpr" > +"LPT1:" = "foo.ps" > +"LPT2:" = "|lpr" > </screen> > <para> > map <systemitem>LPT1:</systemitem> to file <filename>foo.ps</filename> > and <systemitem>LPT2:</systemitem> to the <command>lpr</command> > - command. If a job is sent to an unlisted port then a file is created > - with that port's name e.g. for <systemitem>LPT3:</systemitem> a file > + command. If a job is sent to an unlisted port, then a file is created > + with that port's name; e.g. for <systemitem>LPT3:</systemitem> a file > called <systemitem>LPT3:</systemitem> would be created. > </para> > <para> While it used to work that way, for me at least, the part about - a job that is sent to an unlisted port will create a file with the port's name - stopped working a few months ago. And I just tested it a few minutes ago and it still does not work (for me). I don't know where the data goes, but it does not appear to be written to a file anywhere. Actually, I think that is probably a good thing. In most cases, the print dialog should have a "Print to file" button. And if there is no way to specify a file name, then the ~/.wine/config entry "FILE:" = "foo.ps" will control where it is written, and in this case it will in fact be correctly written to the indicated file name. Duane

1 0

Half-Life/CS under WINE
by David Bronaugh 08 Jul '01

08 Jul '01

Just as a follow-up to my previous email.. if you want a quick response from me, email me off the list - I'm getting the digest, as I don't want to massively clutter up my inbox. David Bronaugh

1 0

Problems running WINE with Half-Life with CounterStrike
by David Bronaugh 08 Jul '01

08 Jul '01

Hey all, I'm having some interesting issues with Half-Life running under WINE... I'm guessing these are due to it running under WINE (they are strange enough). #1 problem: I can't type normally in the Half-Life console (the keyboard is mapped to a completely nonsensical map). I believe this is because they implemented their own custom key handler. Is there any workaround in software/with config for this? Note that this is only in the game when the game engine is initialized, otherwise the keyboard works great (Kudos to the WINE people that my dvorak-mapped QWERTY keyboard works as it should in dvorak). #2 problem: I can't get to the Half-Life console without going through some convolutions... This in itself is useless to tell you people. How I do get into the game is by the following method: I join a game or whatever, and the "Loading" screen pops up. At this point.. it will sit there for hours (I'm guessing this is a locking issue with pthreads?). What I do that appears to relieve the deadlock is to click the "Done" button that is invisible (but I know where it is, so I click it). Then the game loads normally, and runs decently enough (performance isn't great, but playable... huge kudos to the Wine crew for that). Note that the only button that does this is the "Done" button, the rest do nothing out of the ordinary. Again, this may be due to some peculiarity with Half-Life or with my config.. I'm betting on a peculiarity with Half-Life interacting with some unimplemented feauture or bug in WINE. If anyone has suggestions re these two, send em to me.. I'm more than happy to spend a few hours to help resolve this. David Bronaugh

1 0

Are these the ordinal names?
by Peter Hunnisett 08 Jul '01

08 Jul '01

Howdy, I have a couple of questions about the following error messages err:win32:fixup_imports No implementation for SHLWAPI.dll.281(wvnsprintfA) imported from C:\windows\system\shdocvw.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for SHLWAPI.dll.282(wvnsprintfW) imported from C:\windows\system\shdocvw.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for SHLWAPI.dll.240(StrRetToStrW) imported from C:\windows\system\shdocvw.dll, setting to 0xdeadbeef 1) Do these messages mean that 281 is named wvnsprintfA and so on? If so, why does the SHLWAPI.240 name not seem to jive with the existing implementation? 2) Why would I be getting the error for SHLWAPI.dll.240(StrRetToStrW) given the fact that the shlwapi.spec file contains the following line and there does seem to be an implementation in ordinal.c? 240 stdcall @(long long long long) SHLWAPI_240 Ciao, Peter Hunnisett hunnise(a)yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0

Re: Win16 problems
by Gerard Patel 07 Jul '01

07 Jul '01

At 10:43 PM 03/07/2001 +0200, you wrote: <snip> >winmine fails to draw, whereas freecell runs just fine Yes, I see the problem with winmine; but is it really a 16-bits problem ? What I see is an app creating its main window iconic (minimized), then showing it using ShowWindow. Current Wine code does not take this particular behaviour (completely absurd, granted) in account - When the window is created the 'client' window is not mapped (since it's iconic, nothing surprising here), but in ShowWindow the iconic flag (WS_MINIMIZED) is cleared, and when SetWindowPos is called by ShowWindow, X11DRV_sync_client_window_position cleverly detects that the window is already mapped ;-) and decides that it's not necessary to do anything more. This seems more a Winmine specific problem than otherwise. BTW, I can't see any problem with sol.exe (win3.11 version) This patch : --- window.c.orig Wed Jun 27 03:03:36 2001 +++ window.c Sat Jul 7 23:19:03 2001 @@ -596,7 +596,7 @@ if (was_mapped && !is_client_window_mapped( win )) XUnmapWindow( display, data->client_window ); XConfigureWindow( display, data->client_window, mask, &changes ); - if (!was_mapped && is_client_window_mapped( win )) + if (is_client_window_mapped( win )) XMapWindow( display, data->client_window ); wine_tsx11_unlock(); } works around this particular problem. Gerard

1 0

Windows .lnk file parsing
by J. Henning Schwentner 07 Jul '01

07 Jul '01

Hi Wine developers, I am planning to write a little tool "lnk2desktop" which converts Windows LNK links into KDE/Gnome .desktop links, which you could use then to integrate your Windows start menu into your K menu. When I searched through the wine news archive I found a message about library that parses .lnk files and returns the command to execute, the icon etc. My question is now, does such a library exist and what other ways do exist for finding out such infomations? Regards, Henning Schwentner Lanthan Software KG P.S.: Please CC me, since I am not subscribed to the list.

1 0

sharing windows between processes
by Bill Medland 06 Jul '01

06 Jul '01

Some time ago I raised the issue of the fact that windows handles cannot be shared between processes on the same server and was told that it was a known significant issue. Is anyone doing anything about it? It seems to me that what has to be done is to have wineserver coordinate the allocation of handles. Any comments? Bill

1 0

Confusing SHGetFolderPath
by nog 06 Jul '01

06 Jul '01

Hi, While I was looking through some of the wine dlls' code I found that the function SHGetFolderPath is in the shell32 dll and the shfolder dll. Is this ment to be like this? Because the docs that I read says that the function is meant to be in shfolder. Anyway are the two functions meant to do the same thing? If so then why is the one in shell32 implemented and working and the one on shfolder doesn't eaven appear to give a fixme message? Nog

4 3

Help with nonclient Windows 95 frame
by Bill Medland 06 Jul '01

06 Jul '01

I'd appreciate some advice here before I mess things up for everyone else. In the longer term I am fixing a border issue with the edit control, but before doing so I am fixing up the nonclient frame drawing code (i.e. NC_DoNCPaint95). The code contains quite a bit of calculation based upon the system metrics. The code seems to reflect the Windows documentation. However it should come as no surprise that there are disagreements between that documentation and what I see on my Win95 computer! For example a frame with WS_THICKEDGE but no WS_BORDER nor WS_DLGFRAME nor WS_EX_DLGMODALFRAME on my computer is only 3 pixels wide, not 4 (although one of those pixels is the COLOR_WINDOW associated with the WS_THICKEDGE) Is there a way to adjust the size of the borders on the Win95 to be able to see what affects what? Bill

1 1

Mouse events
by Duane Clark 03 Jul '01

03 Jul '01

Howdy, Just tried the most recent CVS. I found that the patch from 6/25 to windows/x11drv/event.c has led to mildly annoying mouse behavior in certain (admittedly very limited) cases. Here is the change that did it: @@ -292,21 +291,8 @@ case ButtonRelease: EVENT_ButtonRelease( hWnd, (XButtonEvent*)event ); break; case MotionNotify: - /* Wine between two fast machines across the overloaded campus - ethernet gets very boged down in MotionEvents. The following - simply finds the last motion event in the queue and drops - the rest. On a good link events are servered before they build - up so this doesn't take place. On a slow link this may cause - problems if the event order is important. I'm not yet seen - of any problems. Jon 7/6/96. - */ - if ((current_input_type == X11DRV_INPUT_ABSOLUTE) && - (in_transition == FALSE)) - /* Only cumulate events if in absolute mode */ - while (TSXCheckTypedWindowEvent(display,((XAnyEvent *)event)->;window, - MotionNotify, event)); EVENT_MotionNotify( hWnd, (XMotionEvent*)event ); break; I assume some problem led to its removal. I regularly try out Myst (the 32 bit version) as a test, running locally on a 700MHz Athlon, so this can't be blamed on a slow ethernet connection or slow machine. When dragging the slide controls in the "planetarium", they used to follow the mouse just fine. With this patch, if you grab the control, move the mouse and release it, the control does not keep up with the mouse but just moves at a moderately slow pace until it reaches the point where the mouse was released (a few seconds to travel from one end to the other). At that point everything returns to normal. Other similar slide controls, such as the musical slide controls in the space ship, work fine with the patch, however. Perhaps it is possible that the code above was masking some other problem causing the control to move too slowly to follow the mouse? Duane

1 0

Win16 problems
by Ove Kaaven 03 Jul '01

03 Jul '01

Is it just me, or does no Win16 GUI apps work in the current Wine CVS? If Wine is compiled with --enable-opengl, then we get BadMatch errors in X_CreateWindow (some kind of visual mismatch), If I disable the OpenGL visual, then the windows are created and seem to exist, but they're never drawn. Win32 apps work fine, of course. I could probably look into the OpenGL problem if that was the only problem, but why are Win16 windows never drawn anyway? (Unfortunately, I don't have sol.exe here, I tested with MS Word Viewer 16-bit, but DOS apps like Monkey Island gets the same issues in my tree)

2 2

Mixed mode CD's and volume label
by David Hagood 03 Jul '01

03 Jul '01

I was trying to get Half-Life running under Wine last night, and ran into a problem with getting the CD label under Wine. Since the HL CD is a mixed mode data/audio disk (as are most game disks nowadays) Wine complained with a We don't have a way of determining the label of a mixed mode CD - Linux doesn't allow raw access ! However, Xcdroast was easily able to access the data. As an experiment, I disabled this check in misc/cdrom.c, and it worked quite happily. Perhaps this check is out of date. Perhaps it is my system setup: 2.4.6-pre7, Samsung CD-Writer/DVD reader on IDE, ide-scsi module loaded, Wine configured to use the /dev/scd0 link. Now, if I could just work out why the OpenGL is flashing...

2 1

Window painting problem
by Glenn Schrader 03 Jul '01

03 Jul '01

I've been tracking down a window painting problem and I think that I know whats happening but I'd like to get some opinions on the 'right' way to fix it. The symptom is that (in some cases) any change to a window will cause the entire window to be repainted. For instance, using the mouse to select a single character causes the whole window to update rather than just the small region which needs to be highlighted. This doesn't happen on most applications. In fact, the only one where i've seen this effect is RoAClient (a really good MUD client). Even so, its really annoying and makes the window flash so much that the app is effectively useless. The problem appears to be in BeginPaint. There is a test which checks to see if the window has the CS_PARENTDC flag set. If so then then the update region is discarded and the window is painted. This has the side effect of making the whole window repaint every time anything in the window changes. According to the windows docs that i've looked at, the CS_PARENTDC should just make the window paint using its parent's device context. There isn't any mention of also removing the invalid region clipping so i'm pretty sure that what BeginPaint is doing isn't right. In my hacking around, I disabled the branch of the test which removes the clipping region and things appear to work a lot better. The screen updating is definitely smoother. What I'm not sure of is whether this is good enough or whether the CS_PARENTDC case really should be slightly different. Normally the clipping region is offset relative to the window thats being drawn but with CS_PARENTDC should the offset be done relative to the parent window instead? Are there any other subtle things that CS_PARENTDC affects? Any insight would be appreciated... Thanks much, G. Schrader

2 1

Re: Window painting problem
by r.maurizzi＠gvs.it 03 Jul '01

03 Jul '01

Glenn Schrader <gschrad(a)ll.mit.edu> wrote: > The symptom is that (in some cases) any change to a > window will cause the entire window to be repainted. > (...) > This doesn't happen on most applications. > In fact, the only one where i've seen this effect is > RoAClient (a really good MUD client). Even so, its > really annoying and makes the window flash so much > that the app is effectively useless. Just for info, Lotus Notes v 4.6x has the same problem. Ciao, Roberto.

1 0

Re: Win16 problems
by Gerard Patel 03 Jul '01

03 Jul '01

At 02:58 AM 03/07/2001 +0200, you wrote: >Is it just me, or does no Win16 GUI apps work in the current Wine CVS? If >Wine is compiled with --enable-opengl, then we get BadMatch errors in >X_CreateWindow (some kind of visual mismatch), If I disable the OpenGL >visual, then the windows are created and seem to exist, but they're never >drawn. > >Win32 apps work fine, of course. For me Win16 apps have not more problems than Win32 ones. Word viewer 16 bits has one regression with current Cvs vs say one month ago, a focus problem that is occuring only in managed mode. Other than that, it is starting and loading files, either on my old computer with Xfree 3.3 and on my newer one with Xfree 4 (compiled with --enable-opengl) I still run most of my test apps on the old computer, but none of them crashes and the new redrawing problems are less than what you say. IMO Wine behaviour depends more now on the specific X server and window manager. I use Kde on both computers, btw (1.1.1 and 2.1 respectively) Gerard

1 0

Re: dead lock
by Alexandre Julliard 03 Jul '01

03 Jul '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > let's assume fixing it is now on Alexandre's TODO list ;-) Yes, I'll fix it, thanks for the report. You'll have to wait a bit though, as I will be away most of the week. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: setsockopt differences for winsock/winsock2
by Alexandre Julliard 03 Jul '01

03 Jul '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > That was the time that I spotted that the #defines for the IP_* > stuff _differs_ between winsock and winsock2. So I had to split up > the IPPROTO_IP handling. I tried to keep code duplication to a minimum. > > I am not sure whether the forwarders are good style. They are not IMHO. I'd suggest writing a ws1-to-ws2 conversion function instead, and use it (by duplicating its code) both for the 16-bit functions in ws2_32 and for the version 1 functions in wsock32. A little code duplication is better than adding entry points. An even better alternative that would avoid the duplication could be to have the 16-bit functions implemented in wsock32 instead of ws2_32, but this is probably a lot more work. -- Alexandre Julliard julliard(a)winehq.com

1 0

tray icon creation problem
by Adriaan Moors 03 Jul '01

03 Jul '01

hi, earlier, i reported a problem with create_icon_window. It doesn't crash anymore with today's cvs (it says an error occurred when initing the tray icon). The application (winmx) continues to load, but it keeps moving downwards. This only occurs when using enlightenment, with window maker it stays still :-) Maybe it's a bug in enlightenment? regards adriaan moors -- Have you ever noticed that the people who are always trying to tell you, "There's a time for work and a time for play," never find the time for play?

1 0

Request for feature
by David Ronis 02 Jul '01

02 Jul '01

I posted this to comp.emulators.ms-windows.wine, but got no reply. I'd been having problems with a windows application that want's to pass off a URL to a browser (netscape). OK I figured out part of my problem. [In short, I have an windows application that spawn netscape with some command-line url]. As was suggested in this thread, I had to install a windows version of netscape (I only had the linux native version installed). The installation set up the registry and things work (well sort of, netscape complains about not being able to write to the tmp directory e: [which is /tmp]). The problem now is that I seem to be on the slippery slope; i.e., most of the plugins/helper applications are absent, so in order to see various file types I have to download more windows versions of things already on my system. None of this would be necessary if there was some way to get wine to first try a native program; e.g., before trying netscape.exe or whatever was in the registry, try netscape using a standard unix system call; only if this failed would wine look for a windows version. Alternately the order could be reversed (I'd be more than willing to remove the windows versions of netscape). The best solution, would be some sort of override capability be added to the config file, for example, similar to the way native vs windows .dll's are chosen. I'm willing to play around with this, but have no experience with the internals of wine. Can somebody point me to the right point of the source code? It'd probably be trivial (and less likely to mess up wine) to first try to fork off a linux command (e.g., by mapping the end of command to something lowercase and less the .exe or .com suffix) and if that failed resort to the windows command. David P.S., I don't subscribe to this list, so please CC me.

1 0

dead lock
by eric pouech 02 Jul '01

02 Jul '01

an app of mine, using two threads, dead locks as follows: thread 1 0 0x40057b1b (RtlpWaitForCriticalSection+0x147(crit=0x40652d48, crit=0x40652d48) [critsection.c:185] in libntdll.so) (ebp=40a96a74) 1 0x40057bf6 (RtlEnterCriticalSection+0x3e(crit=0x40652d48) [critsection.c:241] in libntdll.so) (ebp=40a96a88) 2 0x400ca883 (_EnterSysLevel+0xf7(lock=0x40652d48) [syslevel.c:80] in libntdll.so) (ebp=40a96ab4) 3 0x40639a5f (GDI_AllocObject+0x2f(size=0x34, magic=0x4f4b, handle=0x40a96afc, handle=0x40a96afc) [gdiobj.c:427] in libgdi32.so) (ebp=40a96ad8) 4 0x4062c668 (CreateBitmap+0x78(width=0x20, height=0x20, planes=0x1, bpp=0x18, bits=0x4039fe1c) [bitmap.c:124] in libgdi32.so) (ebp=40a96b00) 5 0x40770f66 (GetIconInfo+0xca(hIcon=0x24e, iconinfo=0x40a96b50) [cursoricon.c:1816] in libuser32.so) (ebp=40a96b30) 6 0x40805a4a (set_icon_hints+0xe6(display=0x8082898, wndPtr=0x4037fe00, hints=0x8083da0, display=0x8082898, win=0x4037fe00, display=0x8082898, win=0x4037fe00) [window.c:263] in libx11drv.so) (ebp=40a96b8c) 7 0x40805ccb (set_wm_hints+0xf3(display=0x8082898, win=0x4037fe00) [window.c:370] in libx11drv.so) (ebp=40a96bbc) 8 0x4080691e (create_whole_window+0x1aa(display=0x8082898, win=0x4037fe00, win=0x4037fe00) [window.c:699] in libx11drv.so) (ebp=40a96c50) 9 0x40806ead (X11DRV_CreateWindow+0xb5(hwnd=0x4ac, cs=0x40a96e2c, unicode=0x0) [window.c:856] in libx11drv.so) (ebp=40a96c90) 10 0x40797831 (WIN_CreateWindowEx+0x6c9(cs=0x40a96e2c, classAtom=0xc014, type=0x2) [win.c:865] in libuser32.so) (ebp=40a96d08) 11 0x40797cca (CreateWindowExA+0x15a(exStyle=0x0, className=0x404c86ce, windowName=0x4049ef3c, style=0xcf0000, x=0x366, y=0x14, width=0x19a, height=0x16f, parent=0x0, menu=0x0, instance=0x4049d000, data=0x0) [win.c:1030] in libuser32.so) (ebp=40a96e5c) 12 0x4049be85 (SInitInstance+0x169(hInstance=0x4049d000, nCmdShow=0x1) [sinit.c:247] in a.so) (ebp=40a96ecc) 13 0x4049911b (ServerThread+0x4b(p=0x405e6e14) [a.c:19] in a.so) (ebp=40a96f1c) 14 0x400cb1ac (THREAD_Start+0x98 [thread.c:273] in libntdll.so) (ebp=40a96f38) 15 0x400ca44e (SYSDEPS_StartThread+0x36(teb=0x40aa7000) [sysdeps.c:73] in libntdll.so) (ebp=40a96ff4) 16 0x4030531a (NTDLL.DLL.memcpy+0x494aa in libc.so.6) (ebp=00000000) thread 2 0 0x40057b1b (RtlpWaitForCriticalSection+0x147(crit=0x40841d10, crit=0x40841d10) [critsection.c:185] in libntdll.so) (ebp=405e6ac0) 1 0x40057bf6 (RtlEnterCriticalSection+0x3e(crit=0x40841d10) [critsection.c:241] in libntdll.so) (ebp=405e6ad4) 2 0x4080b668 (lock_tsx11+0x1c [x11drv_main.c:109] in libx11drv.so) (ebp=405e6ae4) 3 0x4080f595 (X11DRV_StretchBlt+0x39(dcDst=0x4039f710, xDst=0x0, yDst=0x0, widthDst=0xa0, heightDst=0x80, dcSrc=0x4039f4e8, xSrc=0x0, ySrc=0x0, widthSrc=0x190, heightSrc=0x140, rop=0xcc0020) [bitblt.c:1555] in libx11drv.so) (ebp=405e6b10) 4 0x4061bbf2 (StretchBlt+0x102(hdcDst=0xf4, xDst=0x0, yDst=0x0, widthDst=0xa0, heightDst=0x80, hdcSrc=0xf0, xSrc=0x0, ySrc=0x0, widthSrc=0x190, heightSrc=0x140, rop=0xcc0020) [bitblt.c:120] in libgdi32.so) (ebp=405e6b54) 5 0x40499b84 (CInitializeCoolBitmaps+0x36c [cinit.c:229] in a.so) (ebp=405e6bd4) 6 0x4049a265 (CMainWndProc+0x205(hWnd=0x13c, msg=0x590, wParam=0x0, lParam=0x0) [client.c:131] in a.so) (ebp=405e6d24) 7 0x4079e197 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405e6d48) 8 0x4079e216 (WINPROC_CallWndProc+0x76(proc=0x4049a060, hwnd=0x13c, msg=0x590, wParam=0x0, lParam=0x0) [winproc.c:171] in libuser32.so) (ebp=405e6d74) 9 0x407a3da8 (CallWindowProcA+0x88(func=0x4096054c, hwnd=0x13c, msg=0x590, wParam=0x0, lParam=0x0) [winproc.c:2589] in libuser32.so) (ebp=405e6d9c) 10 0x40785fcc (DispatchMessageA+0xd8(msg=0x405e6e24) [message.c:2359] in libuser32.so) (ebp=405e6de0) 11 0x404991ff (WinMain+0x9b(hInstance=0x4049d000, hPrevInstance=0x0, lpCmdLine=0x40360747, nCmdShow=0x1) [a.c:78] in a.so) (ebp=405e6e40) 12 0x4049e082 (__wine_exe_main+0x82 [a.spec.c:5838] in <Debugged process>) (ebp=405e6ecc) 13 0x400c6d52 (start_process+0x1a6 [process.c:391] in libntdll.so) (ebp=405e6f30) 14 0x400ca559 (SYSDEPS_DoCallOnStack+0x25(func=0x400c6bac, arg=0x0) [sysdeps.c:173] in libntdll.so) (ebp=405e6ff0) 15 0x400ca603 (SYSDEPS_CallOnStack+0x2f in libntdll.so) (ebp=bffff660) 16 0x400ca6ad (SYSDEPS_SwitchToThreadStack+0x95(func=0x400c6bac) [sysdeps.c:236] in libntdll.so) (ebp=bffff69c) 17 0x400c70de (PROCESS_InitWine+0x1ce(argc=0x1, argv=0xbffff734, win16_exe_name=0x804c620, win16_exe_file=0x804c724) [process.c:519] in libntdll.so) (ebp=bffff6b4) 18 0x0804b1ee (Letext [main.c] in wine) (ebp=bffff6cc) 19 0x4027bcbe (NTDLL.DLL.sqrt+0x3262e in libc.so.6) (ebp=bffff708) 20 0x08049021 (_start+0x21 in wine) (ebp=00000000) it (simply) deadlocks because the new window management code (written by Alexandre), (rev 1.5 of dlls/x11drv/window.c, change log entry Create an X window for every window, including children. Fixed non-client rectangle calculations in managed mode. Added support for icon window in managed mode. ) does call GDI functions (here GetIconInfo) while the x11drv critical section is held, which shouldn't be the case let's assume fixing it is now on Alexandre's TODO list ;-) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: convert 16bit comm stuff to use handles
by Ove Kaaven 02 Jul '01

02 Jul '01

On Sat, 30 Jun 2001, Mike McCormack wrote: > this is the first step in cleaning up the 16bit comm code. > This patch is untested, so have a look, and give it a go! > - ptr->s_read = SERVICE_AddObject( FILE_DupUnixHandle( ptr->fd, > - GENERIC_READ | SYNCHRONIZE ), > + ptr->s_read = SERVICE_AddObject( ptr->handle, > comm_notification, > (ULONG_PTR)ptr ); Not good... you *must* duplicate the handle (probably with DuplicateHandle) before passing it to SERVICE_AddObject. The SERVICE_Delete will close the handle passed to AddObject, which is bound to cause problems if it's not a duplicate.

2 1

GDI Memory Leak + err:x11drv:X11DRV_SetDeviceClipping Rgn is 0. Please report this.
by adoniz＠hushmail.com 02 Jul '01

02 Jul '01

I got these errors while trying to do something a little uncommon: I have been running Halflife from my windows partiton just fine. But I wanted to remove the huge files and replace them with symlinks to a cdrom, but since I can't do symlinks on fat32 (is there a wine hack for this?? i think it would be a great idea!!), I figured I copy the basic files of HL to my linux partition, and symlink the huge pak files. So, I have /mnt/halflife and under there I have some symlinks. I went ahead and added these to my ~/.wine/config [Drive H] "Path" = "/mnt" "Type" = "hd" "Filesystem" = "vfat" Now, as root try running halflife with: cd /mnt/halflife ; wine hl.exe or wine h:\\halflie\hl.exe (or with all the command line options for opengl, software, etc) I get these errors and a SegFault from wine: /mnt/halflife# wine h:\\halflife\\hl.exe -- -console -toconsole -soft -w 640 -win err:local:LOCAL_GetBlock not enough space in GDI heap 0237 for 108 bytes err:region:CombineRgn Invalid rgn=0000 err:x11drv:X11DRV_SetDeviceClipping Rgn is 0. Please report this. err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 Segmentation fault whatever:/mnt/halflife# err:ntdll:RtlpWaitForCriticalSection Critical section 0x4065da54 wait timed out, retrying (60 sec) fs=0257 Running notepad.exe from /mnt/ works just fine. So something else is happening here... Email me if you need more info thanks Free, encrypted, secure Web-based email at www.hushmail.com

2 1

Re: Re: rebar trouble with WinZip 8.0
by Mike McCormack 02 Jul '01

02 Jul '01

Hi Guy, Yep, that does it. Thanks, Mike Original message from: "Guy L. Albertelli" <galberte(a)neo.lrun.com> > >Hi Mike, > >See if the attached patch fixes your problem. It seems to do it for me. > >Thanks for finding this. > >Guy > >-----Original Message----- >From: Mike McCormack <mike_mccormack(a)start.com.au> >To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> >Date: Thursday, June 28, 2001 10:46 PM >Subject: rebar trouble with WinZip 8.0 > > >>Hi, >> >>WinZip 8.0 has a toolbar. It used to show all the toolbar buttons, but >>it seems to have a problem now, since only the LHS >>button is shown. Some debug output below. >> >>Mike ------------------------------------------ mailto:Mike_McCormack@looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

opengl32.dll works, but how about opengl.dll
by adoniz＠hushmail.com 01 Jul '01

01 Jul '01

Another (small I think) problem I noticed is that some braindead Windows apps (yes, 32bit, Windows 9x) are linked against opengl.dll as opposed to opengl32.dll !! But this makes wine refuse to run them because it doesn't "recognize" that the application needs the built-in openGL support. So how would one go about fixing this, so that Wine will use the builtin OpenGL support not just for openg32.dll but also for opengl.dll ? thanks in advance ps. please email me as i am not subscribed to the ML Free, encrypted, secure Web-based email at www.hushmail.com

1 0

Re: rebar trouble with WinZip 8.0
by Guy L. Albertelli 01 Jul '01

01 Jul '01

Hi Mike, See if the attached patch fixes your problem. It seems to do it for me. Thanks for finding this. Guy -----Original Message----- From: Mike McCormack <mike_mccormack(a)start.com.au> To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> Date: Thursday, June 28, 2001 10:46 PM Subject: rebar trouble with WinZip 8.0 >Hi, > >WinZip 8.0 has a toolbar. It used to show all the toolbar buttons, but >it seems to have a problem now, since only the LHS >button is shown. Some debug output below. > >Mike > > >mike@linux:~/c > wine Program\ Files/WinZip/WINZIP32.EXE >Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: >x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in >config file >.. >trace:rebar:REBAR_AdjustBands start=0, end=0, max x=550, max y=61 >trace:rebar:REBAR_AdjustBands Phase 1 band 0, (0,0)-(69,61), orig x=0, >xsep=0 >trace:rebar:REBAR_AdjustBands Phase 2 band 0, (0,0)-(69,61), orig x=0, >xsep=0 >err:rebar:REBAR_AdjustBands Serious problem adjusting row 1, start >band 0, end band 0 >trace:rebar:REBAR_AdjustBands start=0, end=0, max x=561, max y=61 >trace:rebar:REBAR_AdjustBands Phase 1 band 0, (0,0)-(69,61), orig x=0, >xsep=0 >trace:rebar:REBAR_AdjustBands Phase 2 band 0, (0,0)-(69,61), orig x=0, >xsep=0 >err:rebar:REBAR_AdjustBands Serious problem adjusting row 1, start >band 0, end band 0 >.. >fixme:shell:SHGetFileInfoA set icon to shell size, stub >fixme:listview:LISTVIEW_SetColumnOrderArray iCount 9 lpiArray >0x405a6a74 >mike@linux:~/c > > > >------------------------------------------ >mailto:Mike_McCormack@looksmart.com.au >ph +82 16 430 0425 > >__________________________________________________________________ >Get your free Australian email account at http://www.Looksmart.com.au > > >

1 0

Re: convert 16bit comm stuff to use handles (fwd)
by lawson_whitney＠juno.com 01 Jul '01

01 Jul '01

OOPS, this was meant for wine-devel, not wine-patches. Sorry! On Sat, 30 Jun 2001, Mike McCormack wrote: > > Hi, > > this is the first step in cleaning up the 16bit comm code. > This patch is untested, so have a look, and give it a go! > > Mike > Good day! Turns out the app will still run with --winver win31 (I swear it worked with --winver nt40 before, I think :-) but with the patch, it can't find the modem with both hands and a flashlight. Seems not to see input. comm trace is attached. Let me know if (which) additional traces would help. Lawson ---blah---

1 0

Re: wine/ ./configure ./configure.in documentation ...
by Uwe Bonnes 29 Jun '01

29 Jun '01

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> ... Alexandre> +0 -0 wine/msdos/ppdev.c ^^^^^ Hallo Alexandre, oops, this is not enough. The patch I submitted was --- /dev/null Tue Feb 20 18:39:20 2001 +++ wine/msdos/ppdev.c Thu Jun 21 14:32:14 2001 @@ -0,0 +1,283 @@ ^^^^ Did I choose wrong arguments to diff? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

rebar trouble with WinZip 8.0
by Mike McCormack 29 Jun '01

29 Jun '01

Hi, WinZip 8.0 has a toolbar. It used to show all the toolbar buttons, but it seems to have a problem now, since only the LHS button is shown. Some debug output below. Mike mike@linux:~/c > wine Program\ Files/WinZip/WINZIP32.EXE Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file .. trace:rebar:REBAR_AdjustBands start=0, end=0, max x=550, max y=61 trace:rebar:REBAR_AdjustBands Phase 1 band 0, (0,0)-(69,61), orig x=0, xsep=0 trace:rebar:REBAR_AdjustBands Phase 2 band 0, (0,0)-(69,61), orig x=0, xsep=0 err:rebar:REBAR_AdjustBands Serious problem adjusting row 1, start band 0, end band 0 trace:rebar:REBAR_AdjustBands start=0, end=0, max x=561, max y=61 trace:rebar:REBAR_AdjustBands Phase 1 band 0, (0,0)-(69,61), orig x=0, xsep=0 trace:rebar:REBAR_AdjustBands Phase 2 band 0, (0,0)-(69,61), orig x=0, xsep=0 err:rebar:REBAR_AdjustBands Serious problem adjusting row 1, start band 0, end band 0 .. fixme:shell:SHGetFileInfoA set icon to shell size, stub fixme:listview:LISTVIEW_SetColumnOrderArray iCount 9 lpiArray 0x405a6a74 mike@linux:~/c ------------------------------------------ mailto:Mike_McCormack@looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: Support Ordinal forwarding in Dll loading
by Alexandre Julliard 29 Jun '01

29 Jun '01

"Guy L. Albertelli" <galberte(a)neo.lrun.com> writes: > In attempting to use Specmaker to create a forwarding DLL to do testing of > the Rebar and ComboBoxEx controls, I ran into a problem where pe_image.c did > not support forwarding an ordinal only reference. This patch allows that > function to work. The ordinal forward is of the form: > dllname.DLLNAME_nnnn. I don't think Windows supports something like this. I would suggest instead to fix specmaker to not generate a forward in this case. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Proper detection of VM86 support
by Alexandre Julliard 28 Jun '01

28 Jun '01

Patrik Stridvall <ps(a)leissner.se> writes: > Proper detection of VM86 support > on FreeBSD, Linux and Solaris added. I don't think that's useful. Even if we someday support vm86 on other platforms, this is one of these cases where a simple platform check (#ifdef linux) is preferable to complex configure magic IMO. This is how we do the LDT check too, because there simply isn't enough similarity between platforms to justify configure tests. -- Alexandre Julliard julliard(a)winehq.com

1 0

[Problem report] Messages cooked too much ?
by Gerard Patel 27 Jun '01

27 Jun '01

This is a problem of intermittents hangings, when moving the mouse or closing a window (not obvious). I finally realized that the traces in the hanging of Eudora 4 looked very similar, but Eudora 4 hangs reliably ;-) I have found this Eudora crash an infinite loop generated by a mouse move message, cooked to generate a WM_NCMOUSEMOVE, then this last message is obtained repeatedly from the server without being ever removed. It does not seem right to peek a cooked message off the server, not find anything useful to do with it, and just ignore it and asking the server again. The following patch removes the problem, and *seems* to cure the intermittent hangings of other apps. Gerard --- message.c.orig Wed Jun 27 22:14:07 2001 +++ message.c Wed Jun 27 22:13:57 2001 @@ -790,7 +790,11 @@ if (qmsg.kind == RAW_HW_MESSAGE || qmsg.kind == COOKED_HW_MESSAGE) { if (!process_hardware_message( &qmsg, hwnd, first, last, flags & PM_REMOVE )) + { + if (qmsg.kind == COOKED_HW_MESSAGE) + if (!(flags & PM_REMOVE)) QUEUE_FindMsg( hwnd, first, last, TRUE, &qmsg ); goto retry; + } } else {

1 0

Re: docu patch
by Alexandre Julliard 26 Jun '01

26 Jun '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > diff -u -r1.9 DEVELOPERS-HINTS > --- DEVELOPERS-HINTS 2001/01/10 23:59:25 1.9 > +++ DEVELOPERS-HINTS 2001/06/26 23:02:00 > @@ -23,6 +23,7 @@ > > GDI: > > + console/ - handling of text consoles > graphics/ - graphics drivers > x11drv/ - X11 display driver > win16drv/ -> see below > @@ -58,7 +59,7 @@ > msnet/ > msvcrt/ - C runtime library > msvideo/ - 16 bit video manager > - ole32/ - 32 bit OLE 2.0 librairies > + ole32/ - 32 bit OLE 2.0 libraries > oleaut32/ - 32 bit OLE 2.0 automation > olecli/ - 16 bit OLE client > oledlg/ - OLE 2.0 user interface support > @@ -86,12 +87,13 @@ > > Miscellaneous: > > - misc/ - shell, registry, winsock, etc. > + misc/ - misc. wine management, registry, etc. > ipc/ - SysV IPC based interprocess communication > - win32/ - misc Win32 functions > ole/ - OLE code > - nls/ - National Language Support > + nls/ - National Language Support > configuration files > + unicode/ - Unicode (character) support > + win32/ - misc Win32 functions > I have nothing against updating the doc, but I don't think adding wrong information is going to help <g>. console/ is not a GDI directory, and there is no top level nls/ directory. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: configure.in patch
by Marcus Meissner 26 Jun '01

26 Jun '01

On Tue, Jun 26, 2001 at 03:34:23PM +0900, Bang Jun-Young wrote: > * configure.in: > Remove a redundant check for flex. It is not redundant! AC_PROG_LEX does more than just look for the 'lex' binary. Please do not apply. Ciao, Marcus > -AC_PROG_LEX > AC_CHECK_PROGS(XLEX,$LEX flex lex,none) > if test "$XLEX" = "none" > then

3 5

change of style in the edit control
by Bill Medland 26 Jun '01

26 Jun '01

Is anyone working on the edit control's handling of WM_STYLE_CHANGED? Does anyone have any useful information? I intend adding handling of WM_STYLE_CHANGING/ED to controls/edit.c for our application (which uses SetWindowLong to modify the style after creation). 1. Does anyone know why the EDITSTATE.style is not fed back to the pWnd->dwStyle after being modified. 2. Does anyone know of any documentation of the interaction within windows when the styles are incompatible? Bill

1 0

Apps DB round 2
by Jeremy Newman 26 Jun '01

26 Jun '01

The new Application DB (http://wine.codeweavers.com/appdb/) is starting to fill up. But, we still need your help before we totally unleash it on the Wine community. We need as much feedback, comments, and flames [:-)] as possible this week. We need volunteers to take responsibility for updating Apps in the DB. If you would like to help, email the appDB team at appdb(a)codeweavers.com. Areas we need help on: - Add Apps and App Versions. - Comments on Apps - Application Owners (the app db has a privilege system where you can be owner of an app.) - Screenshots (lots of 'em) --- _ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://jnewman.codeweavers.com | .` / -_) V V / ' \/ _` | ' \ -= mailto:jnewman@codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

9 12

undefined reference to main in _start
by Gilroy Billard 25 Jun '01

25 Jun '01

Hi, I can't link in any version of the WINE libraries after version 20001202 without getting a linker error: undefined reference to main in function _start. I compile WINE with these options: ./configure --without-x --without-curses --disable-debug --disable-trace. Any ideas??? thanks, Gilroy Billard mailto:gilroy@trakonic.com Software Developer Trakonic Inc. PH: 1-902-450-0922 FX: 1-902-450-0939 1-877-419-3887 http://www.trakonic.com

5 6

Re: Win16 calls by Win32 functions
by Alexandre Julliard 25 Jun '01

25 Jun '01

Patrik Stridvall <ps(a)leissner.se> writes: > Sure Win32 calls to Win16 should be eliminated that is > without question. This is how Windows NT does it and > Alexandre has a policy that Wine should doing like > Windows NT does. I fully agree. > > However I'm not positive that replacing Win16 calls to > Win16 with Win32 calls is always good idea. See below. As a rule it is a good idea, but there are of course exceptions. Basically the rule should be that wherever you can choose between a Win16 or Win32 function to do something, you should pick the Win32 function. But in the cases where the Win16 and Win32 functions have different semantics, then of course you have to use the correct one, even if in some cases it means calling Win16 functions from Win32 (like for the GlobalAlloc stuff). -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Win16 calls by Win32 functions
by Patrik Stridvall 25 Jun '01

25 Jun '01

> "Patrik Stridvall" <ps(a)leissner.se> wrote: > > > Noticing that you (Dimitry) have send in a few patch > > replacing Win16 calls by Win32 ones, I wish to > > point out that winapi_check can detect "illegal" > > calls from Win32 to Win16. > > > > Just do > > winapi_check --cross-call-win32-win16 > > Great! Why didn't you just make a patch and submit it? Well. Because I don't want to blindly do search and replace I haven't got around to do it since it will take some time to analyze each case for correctness. It is on my list of things to do but it has very low priority. But since you seems to be doing it, I might just as well tell you how to easily find many of them. > > Note that some of the fixes in your (Dimitry's) > > patches is not included in the result below > > because they are Win16 functions calling Win16 > > functions. > > > > I do not say this is nessary wrong, but are > > you (Dimitry) really sure this is how it should be? > > Well, as Alexandre already has pointed out, Win16 should be > mostly implemented by using Win32. I agree with him that use > of the 16-bit code should be eliminated as much as possible. > Moreover, until now I just have replaced only obvious places: > 16-bit functions which just thunk up to win32 without any > argument processing. Sure Win32 calls to Win16 should be eliminated that is without question. This is how Windows NT does it and Alexandre has a policy that Wine should doing like Windows NT does. I fully agree. However I'm not positive that replacing Win16 calls to Win16 with Win32 calls is always good idea. See below. > > Sure it probably runs a little faster, but then Win16 > > applications on a modern computer are likely to be > > _very_ fast, so it is really worth risking potential > > compabillity errors because of some probably irrelavant > > speed differences. > > > > Not that functions like DeleteObject are likely to > > have such problems but still... > > I'm not going to blindly replace 16-bit calls by 32-bit. > I look into the code and do think twice before submitting > a patch. Of course you are not, but there might be subtle issues that break the code in the future then the full Win32 semantics is implemented. That requires much more thinking than just casually browsing the code and reading the documentation. Actually just thinking and reading documentation is not enough either Win32 or Win16 might have undocumentation features on Windows not implement by Wine yet. Note that I'm not convinced is a large problem if any at all. I'm just worried and think we need to think this through carefully. So what should we do? Correct me if I'm wrong but because of the DLL separation Win16 to Win16 calls between different DLL:s (or rather different .so files) must not take place. I notice that, for example, user32.spec contains the following lines: ################################################################ # Wine extensions: Win16 functions that are needed by other dlls # @ stdcall CallNextHookEx16(long long long long) CallNextHookEx16 @ stdcall CallWindowProc16(long long long long long) CallWindowProc16 @ stdcall CloseDriver16(long long long) CloseDriver16 @ stdcall CreateDialogIndirectParam16(long ptr long long long) CreateDialogIndirectParam16 @ stdcall DefDriverProc16(long long long long long) DefDriverProc16 @ stdcall DialogBoxIndirectParam16(long long long long long) DialogBoxIndirectParam16 @ stdcall GetDriverModuleHandle16(long) GetDriverModuleHandle16 @ stdcall OpenDriver16(str str long) OpenDriver16 @ stdcall PostAppMessage16(long long long long) PostAppMessage16 @ stdcall SendDriverMessage16(long long long long) SendDriverMessage16 @ stdcall SetWindowsHookEx16(long long long long) SetWindowsHookEx16 @ stdcall UserYield16() UserYield16 and gdi32.spec contains these lines: ################################################################ # Wine extensions: Win16 functions that are needed by other dlls # @ stdcall CreateMetaFile16(str) CreateMetaFile16 @ stdcall CloseMetaFile16(long) CloseMetaFile16 This is what is guess Alexandre wants eliminated not calls like the call in SetDCState16 (Win16 GDI) to DeleteObject16 (Win16 GDI) that you "fixed" in one of your patches. Of course Win32 to Win16 calls should be fixed even within a DLL but that is because of possible different semantics not because of the DLL separation. In short I suggest the following policy 1. No Win32 to Win16 calls: This is because of semantic and speed reasons. 2. No Win16 to Win16 calls between different DLL:s: This is because of the DLL separation. 3. No Win16 to Win32 calls within a DLL (with the exception a function's Win32 counterpart or replacement in the case of obsolete function): This is because of semantic reasons but I'm not sure how hard we must enforce point, because if the the Win32 function generates a non Win16 message or some other non Win16 related stuff I guess we can quite easily can (and perhaps even now does) ignore or filter such things in more fundamental part of the code like in the message dispatching code.

1 0

Win16 calls by Win32 functions
by Patrik Stridvall 25 Jun '01

25 Jun '01

Noticing that you (Dimitry) have send in a few patch replacing Win16 calls by Win32 ones, I wish to point out that winapi_check can detect "illegal" calls from Win32 to Win16. Just do winapi_check --cross-call-win32-win16 Unfortunately there is a bug in the CVS version of winapi_check (fixed in my tree) that makes this option output too many messages. However until it is updated just do "grep 'illegal call'" on the output. The result this is included below. Note that some of the fixes in your (Dimitry's) patches is not included in the result below because they are Win16 functions calling Win16 functions. I do not say this is nessary wrong, but are you (Dimitry) really sure this is how it should be? Sure it probably runs a little faster, but then Win16 applications on a modern computer are likely to be _very_ fast, so it is really worth risking potential compabillity errors because of some probably irrelavant speed differences. Not that functions like DeleteObject are likely to have such problems but still... ---8<--- controls/menu.c: user32: GetSystemMenu: illegal call to GetSubMenu16 (Win32 -> Win16) dlls/kernel/comm.c: kernel32: BuildCommDCBAndTimeoutsA: illegal call to BuildCommDCB16 (Win32 -> Win16) dlls/msvideo/msvideo_main.c: msvfw32: ICClose: illegal call to ICSendMessage16 (Win32 -> Win16) dlls/ole32/compobj.c: ole32: CLSIDFromProgID: illegal call to CLSIDFromProgID16 (Win32 -> Win16) dlls/ole32/compobj.c: ole32 & ole32: CLSIDFromString: illegal call to CLSIDFromString16 (Win32 -> Win16) dlls/ole32/storage.c: ole32: StgIsStorageFile: illegal call to StgIsStorageFile16 (Win32 -> Win16) dlls/shell32/shell.c: shell32: ExtractAssociatedIconA: illegal call to ExtractAssociatedIcon16 (Win32 -> Win16) dlls/winmm/mci.c: mmsystem & winmm: mciExecute: illegal call to mciSendString16 (Win32 -> Win16) dlls/winmm/mci.c: winmm: mciFreeCommandResource: illegal call to mciFreeCommandResource16 (Win32 -> Win16) dlls/winmm/mmsystem.c: winmm: mciGetErrorStringA: illegal call to mciGetErrorString16 (Win32 -> Win16) dlls/winmm/mmsystem.c: winmm: mmsystemGetVersion: illegal call to mmsystemGetVersion16 (Win32 -> Win16) files/profile.c: kernel32: GetPrivateProfileSectionNamesW: illegal call to GetPrivateProfileSectionNames16 (Win32 -> Win16) graphics/escape.c: gdi32: ExtEscape: illegal call to Escape16 (Win32 -> Win16) loader/module.c: kernel32: WIN32_GetProcAddress16: illegal call to GetProcAddress16 (Win32 -> Win16) loader/ne/module.c: kernel & kernel32: FreeLibrary16: illegal call to FreeModule16 (Win32 -> Win16) memory/global.c: kernel & kernel32: GlobalFix16: illegal call to GlobalHandleToSel16 (Win32 -> Win16) memory/global.c: kernel & kernel32: GlobalReAlloc16: illegal call to GlobalHandleToSel16 (Win32 -> Win16) memory/global.c: kernel & kernel32: GlobalWire16: illegal call to WIN16_GlobalLock16 (Win32 -> Win16) memory/global.c: kernel32: K32WOWGlobalLock16: illegal call to WIN16_GlobalLock16 (Win32 -> Win16) objects/clipping.c: gdi32: RectVisible: illegal call to RectVisible16 (Win32 -> Win16) objects/dc.c: gdi32: RestoreDC: illegal call to SetDCState16 (Win32 -> Win16) objects/metafile.c: gdi32: PlayMetaFileRecord: illegal call to PlayMetaFileRecord16 (Win32 -> Win16) objects/palette.c: gdi32: UpdateColors: illegal call to UpdateColors16 (Win32 -> Win16) windows/clipboard.c: user32: RegisterClipboardFormatA: illegal call to RegisterClipboardFormat16 (Win32 -> Win16) windows/cursoricon.c: user32: CreateCursor: illegal call to CreateCursorIconIndirect16 (Win32 -> Win16) windows/cursoricon.c: user32: CreateIcon: illegal call to CreateCursorIconIndirect16 (Win32 -> Win16) windows/cursoricon.c: user32: DestroyCursor: illegal call to CURSORICON_Destroy (Win32 -> Win16) windows/cursoricon.c: user32: DestroyIcon: illegal call to CURSORICON_Destroy (Win32 -> Win16) windows/cursoricon.c: user32: LookupIconIdFromDirectoryEx: illegal call to LookupIconIdFromDirectoryEx16 (Win32 -> Win16) windows/mdi.c: user32: DefFrameProcA: illegal call to DefFrameProc16 (Win32 -> Win16) windows/mdi.c: user32: DefFrameProcW: illegal call to DefFrameProc16 (Win32 -> Win16) windows/mdi.c: user32: DefMDIChildProcA: illegal call to DefMDIChildProc16 (Win32 -> Win16) windows/mdi.c: user32: ScrollChildren: illegal call to CalcChildScroll16 (Win32 -> Win16) windows/painting.c: user32: UserRealizePalette: illegal call to RealizePalette16 (Win32 -> Win16)

2 1

wine core dump
by Heiko Nardmann 25 Jun '01

25 Jun '01

I am not sure whether this mail reached the mailing list already partly. Due to some problem with KMail here is the full mail. Using CVS version from 23.6. I was able to produce a core dump trying to use Word97. Here is the session from gdb. I might provide the core file to anyone interested. snsrv053:nardmann[Word]>gdb /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/wine core GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Core was generated by `/opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-200106'. Program terminated with signal 11, Speicherzugriffsfehler. Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_unicode.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_unicode.so Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libutil.so.1...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libkernel32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libkernel32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libuser32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libuser32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libgdi32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libgdi32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libadvapi32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libadvapi32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libole32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libole32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/librpcrt4.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/librpcrt4.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshell32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshell32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshlwapi.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshlwapi.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libcomctl32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libcomctl32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwinspool.drv.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwinspool.drv.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libx11drv.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libx11drv.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_tsx11.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_tsx11.so Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Loaded symbols for /usr/X11R6/lib/libXpm.so.4 Reading symbols from /usr/X11R6/lib/libXxf86dga.so.1...done. Loaded symbols for /usr/X11R6/lib/libXxf86dga.so.1 Reading symbols from /usr/X11R6/lib/libXxf86vm.so.1...done. Loaded symbols for /usr/X11R6/lib/libXxf86vm.so.1 Reading symbols from /usr/lib/libGL.so.1...done. Loaded symbols for /usr/lib/libGL.so.1 Reading symbols from /usr/lib/libGLU.so.1...done. Loaded symbols for /usr/lib/libGLU.so.1 Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Loaded symbols for /usr/X11R6/lib/libXext.so.6 Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Loaded symbols for /usr/X11R6/lib/libX11.so.6 Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Loaded symbols for /usr/X11R6/lib/libXmu.so.6 Reading symbols from /usr/X11R6/lib/libXi.so.6...done. Loaded symbols for /usr/X11R6/lib/libXi.so.6 Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Loaded symbols for /usr/X11R6/lib/libXt.so.6 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwineps.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwineps.so #0 thread_errno_location () at thread.c:214 214 return &NtCurrentTeb()->thread_errno; (gdb) bt #0 thread_errno_location () at thread.c:214 #1 0x40292a15 in __sigprocmask (how=0, set=0x40114340, oset=0x404a1058) at ../sysdeps/unix/sysv/linux/sigprocmask.c:48 #2 0x400c99c6 in wine_server_call (req=0x404a1158, size=20) at client.c:196 #3 0x4005af51 in send_debug_event (rec=0x404a123c, first_chance=1, context=0x404a12b0) at exception.c:124 #4 0x4005b19f in EXC_RtlRaiseException (rec=0x404a123c, context=0x404a12b0) at exception.c:177 #5 0x40062509 in do_segv (context=0x404a12b0, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #6 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078596916, sc_esi = 1074775150, sc_ebp = 1078596752, sc_esp = 1078596704, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078596704, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #7 <signal handler called> #8 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #9 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #10 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1534, context=0x404a15a8) at exception.c:195 #11 0x40062509 in do_segv (context=0x404a15a8, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #12 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078597676, sc_esi = 1074775150, sc_ebp = 1078597512, sc_esp = 1078597464, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078597464, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #13 <signal handler called> #14 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #15 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #16 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a182c, context=0x404a18a0) at exception.c:195 #17 0x40062509 in do_segv (context=0x404a18a0, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #18 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078598436, sc_esi = 1074775150, sc_ebp = 1078598272, sc_esp = 1078598224, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078598224, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #19 <signal handler called> #20 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #21 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #22 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1b24, context=0x404a1b98) at exception.c:195 #23 0x40062509 in do_segv (context=0x404a1b98, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #24 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078599196, sc_esi = 1074775150, sc_ebp = 1078599032, sc_esp = 1078598984, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078598984, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #25 <signal handler called> #26 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #27 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #28 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1e1c, context=0x404a1e90) at exception.c:195 #29 0x40062509 in do_segv (context=0x404a1e90, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #30 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078599956, sc_esi = 1074775150, sc_ebp = 1078599792, sc_esp = 1078599744, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078599744, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #31 <signal handler called> #32 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #33 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #34 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a2114, context=0x404a2188) at exception.c:195 #35 0x40062509 in do_segv (context=0x404a2188, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #36 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078600924, sc_esi = 1074775150, sc_ebp = 1078600548, sc_esp = 1078600500, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078600500, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #37 <signal handler called> #38 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #39 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #40 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a24dc, context=0x404a2410) at exception.c:195 ---Type <return> to continue, or q <return> to quit--- #41 0x400629c4 in int_handler (__signal=2, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1074113920, sc_esi = 0, sc_ebp = 1078608284, sc_esp = 1078601232, sc_ebx = 1078608268, sc_edx = 810345475, sc_ecx = 17152, sc_eax = 1078601394, sc_trapno = 14, sc_err = 4, sc_eip = 2356908743, sc_cs = 35, __csh = 0, sc_eflags = 646, esp_at_signal = 1078601232, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 1078620009}) at signal_i386.c:893 #42 <signal handler called> #43 0x8c7b92c7 in ?? () #44 0xe in ?? () Cannot access memory at address 0x1 -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de), Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50

1 0

wine core dump
by Heiko Nardmann 25 Jun '01

25 Jun '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Using CVS version from 23.6. I was able to produce a core dump trying to use Word97. Here is the session from gdb. I might provide the core file to anyone interested. snsrv053:nardmann[Word]>gdb /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/wine core GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Core was generated by `/opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-200106'. Program terminated with signal 11, Speicherzugriffsfehler. Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_unicode.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_unicode.so Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libutil.so.1...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libkernel32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libkernel32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libuser32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libuser32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libgdi32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libgdi32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libadvapi32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libadvapi32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libole32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libole32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/librpcrt4.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/librpcrt4.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshell32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshell32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshlwapi.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshlwapi.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libcomctl32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libcomctl32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwinspool.drv.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwinspool.drv.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libx11drv.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libx11drv.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_tsx11.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_tsx11.so Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Loaded symbols for /usr/X11R6/lib/libXpm.so.4 Reading symbols from /usr/X11R6/lib/libXxf86dga.so.1...done. Loaded symbols for /usr/X11R6/lib/libXxf86dga.so.1 Reading symbols from /usr/X11R6/lib/libXxf86vm.so.1...done. Loaded symbols for /usr/X11R6/lib/libXxf86vm.so.1 Reading symbols from /usr/lib/libGL.so.1...done. Loaded symbols for /usr/lib/libGL.so.1 Reading symbols from /usr/lib/libGLU.so.1...done. Loaded symbols for /usr/lib/libGLU.so.1 Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Loaded symbols for /usr/X11R6/lib/libXext.so.6 Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Loaded symbols for /usr/X11R6/lib/libX11.so.6 Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Loaded symbols for /usr/X11R6/lib/libXmu.so.6 Reading symbols from /usr/X11R6/lib/libXi.so.6...done. Loaded symbols for /usr/X11R6/lib/libXi.so.6 Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Loaded symbols for /usr/X11R6/lib/libXt.so.6 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwineps.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwineps.so #0 thread_errno_location () at thread.c:214 214 return &NtCurrentTeb()->thread_errno; (gdb) bt #0 thread_errno_location () at thread.c:214 #1 0x40292a15 in __sigprocmask (how=0, set=0x40114340, oset=0x404a1058) at ../sysdeps/unix/sysv/linux/sigprocmask.c:48 #2 0x400c99c6 in wine_server_call (req=0x404a1158, size=20) at client.c:196 #3 0x4005af51 in send_debug_event (rec=0x404a123c, first_chance=1, context=0x404a12b0) at exception.c:124 #4 0x4005b19f in EXC_RtlRaiseException (rec=0x404a123c, context=0x404a12b0) at exception.c:177 #5 0x40062509 in do_segv (context=0x404a12b0, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #6 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078596916, sc_esi = 1074775150, sc_ebp = 1078596752, sc_esp = 1078596704, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078596704, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #7 <signal handler called> #8 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #9 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #10 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1534, context=0x404a15a8) at exception.c:195 #11 0x40062509 in do_segv (context=0x404a15a8, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #12 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078597676, sc_esi = 1074775150, sc_ebp = 1078597512, sc_esp = 1078597464, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078597464, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #13 <signal handler called> #14 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #15 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #16 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a182c, context=0x404a18a0) at exception.c:195 #17 0x40062509 in do_segv (context=0x404a18a0, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #18 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078598436, sc_esi = 1074775150, sc_ebp = 1078598272, sc_esp = 1078598224, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078598224, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #19 <signal handler called> #20 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #21 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #22 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1b24, context=0x404a1b98) at exception.c:195 #23 0x40062509 in do_segv (context=0x404a1b98, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #24 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078599196, sc_esi = 1074775150, sc_ebp = 1078599032, sc_esp = 1078598984, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078598984, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #25 <signal handler called> #26 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #27 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #28 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1e1c, context=0x404a1e90) at exception.c:195 #29 0x40062509 in do_segv (context=0x404a1e90, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #30 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078599956, sc_esi = 1074775150, sc_ebp = 1078599792, sc_esp = 1078599744, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078599744, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #31 <signal handler called> #32 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7Nu3bpm53PRScYygRAuYLAKDR49a+j/JDCirOmLCC48N1ql1rXgCg10Ah aOiXiUWyz02czaQc4jG1i8k= =W1KY -----END PGP SIGNATURE-----

1 0

Fallout Tactics problems
by Tim Oertel 25 Jun '01

25 Jun '01

Hi all, I sent this to wine-users, but got no response... so I'll assume I've hit a bug or three. I've successfully installed FT, and it sorta runs. Specifically: o It installed without problems. o It runs the intro animations and training walkthroughs, but the anims alternately play audio or video, pausing the other while one plays. o Character creation works, although the keyboard occasionally fails to work... not sure why. o Screen redraw is hosed when scrolling left or up. A ~64 pixel strip gets replicated across the screen... Clicking directly on the map redraws fine. I'm wondering if anyone knows what is going on or can suggest how to start debugging the scrolling problem. (I have plenty of debug experience and can figure things out, but I'm not familiar with wine, so am not sure where to start.) I'm using the latest CVS build as of 2001/06/20. Tim -- ////// toertel(a)rpa.net ///////////// // "Why should I be content to simply // / live in this world, when I, as a // human being, can CREATE it?" //

1 0

A pointer to some undoc functions
by Uwe Bonnes 24 Jun '01

24 Jun '01

Hallo, http://www.geocities.com/SiliconValley/4942/contents.html contains some explications about those undocumented functions in the win32 API mostly used bi explorer, iexplorer and friends. I took a look at the comctl32 MRU functions... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

[Problem report] X11DRV_GetDC
by Gerard Patel 24 Jun '01

24 Jun '01

This problem I see with Eudora (1.5 or 3.06 - I can't see it with Eudora 4 because it crashes before :-)). Using the option dialog box, everytime there is a checkbox or an option button, these buttons appear 2 times when switching from a page to another, one time at the correct place, one time off to the left. I think that the problem comes from the fact that the app paints outside of a WM_PAINT event. What happens is that when switching from a dialog 'page' to another, Eudora creates a hidden dialog with buttons on it, initialize the controls with the correct values from its config file, then reparent all the controls to the main dialog box. The hidden dialog box is a child of the main dialog box (but on this hidden dialog box, the controls are not at the place where they are supposed to be on the real dialog box). To be clearer, we have windows as follow (in the order parent->child) A : main dialog, style visible + clipsiblings B : work dialog, not visible + not clipsiblings C : a checkbox X11DRV_GetDC finds B as top window that is not clipsibling, then Wine use as drawable the parent of B : A. Then the checkbox is displayed somewhere on A. The following patch works around this particular problem, but I doubt that it's the best place to change. And, BTW, there are many other problems in current Cvs with my toy test suite :-/, problems that were not here a month ago, of course. To be fair the new code has removed *some* long standing problems, too. But on the balance it's still very bad. Gerard Index: dlls/x11drv/winpos.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/winpos.c,v retrieving revision 1.10 diff -u -r1.10 winpos.c --- dlls/x11drv/winpos.c 2001/06/22 03:42:27 1.10 +++ dlls/x11drv/winpos.c 2001/06/24 10:50:45 @@ -387,8 +387,11 @@ /* find the top parent in the hierarchy that isn't clipping siblings */ top = NULL; - for (ptr = win->parent; ptr && ptr->parent; ptr = ptr->parent) - if (!(ptr->dwStyle & WS_CLIPSIBLINGS)) top = ptr; + if (IsWindowVisible(win->hwndSelf)) + { + for (ptr = win->parent; ptr && ptr->parent; ptr = ptr->parent) + if (!(ptr->dwStyle & WS_CLIPSIBLINGS)) top = ptr; + } if (!top && !(flags & DCX_CLIPSIBLINGS)) top = win;

1 0

Re: PATCH: MSDOS VGA mode
by Ove Kaaven 23 Jun '01

23 Jun '01

On Sun, 17 Jun 2001, Marcus Meissner wrote: > However, Monkey Island does not appear to get <return> presses. I see > in 60 returning scancode 0x1c (and 0x9c on release), but it never triggers > any reaction :( Yes, the relevant code in msdos/int09.c is stiff #if 0-ed out in the Wine CVS. I think I have some stuff fixing it lying around in my old Wine tree, but it was rejected in its first form, so it might need a rewrite. But the vm86 restructure is probably more important...

2 3

Re: wrc error
by Gaël de Chalendar 23 Jun '01

23 Jun '01

Hi, As I wrote on comp.emulators.ms-windows.wine, I have the same problem (on 2 machines, a third one works well). What caused the problem is the last patch on wrc (I got the previous version of wrc files and it works). A preprocessed version of what do you want ? Bye Gael On Fri, 15 Jun 2001, Bang Jun-Young wrote: > Hi, > > I got the following error when I tried to compile the latest > CVS source: > > gmake[2]: Entering directory `/home/bjy/wine/dlls/user' > LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" ../../tools/wrc/wrc -I. -I. -I../../include -I../../include -o resources/user32.res -r resources/user32.rc > resources/user32_Ca.rc:2:1: Error: syntax error > gmake[2]: *** [resources/user32.res] Error 1 I did a cvs update five minutes ago and it compiled just fine. cvs diff shows no difference in te tools/wrc area either. Can you send me a preprocessed version? -- -- _______________________________________________ Gael de Chalendar LIMSI/CNRS, BP 133, 91 403 Orsay Cedex (France) Tel : 01 69 85 80 04, Fax : 01 69 85 80 88 E-mail : mailto:Gael.de.Chalendar@limsi.fr Web : http://www.limsi.fr/Individu/gael/

3 3

Word97 problems
by Heiko Nardmann 23 Jun '01

23 Jun '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I am still trying to get Word97 up and running. Now I found out that Word tries to LoadLibrary() some MSO7DEU.DLL which seems to be the language DLL. I saw that after failing to find it it tries to find MSO7ENU.DLL. When failing with that, too, some kind of exception is happening according to the log files and the message box described in former mails appears. So I took this DLL from my Windows/Word installation and copied it into the same folder as Word. Now I have the following Word files in one directory: - - winword.exe - - wwintl32.dll - - mso97.dll - - mso7deu.dll No other Windows files are on my Linux machine except on the NT partition which is NOT used during this tests. After starting it again I now get a different message box saying that my registry is corrupt and I should rerun Word setup. I will further analyze the logfiles to see which registry entries are needed ... This analyze has been done with todays CVS ... - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de), Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7NHOhpm53PRScYygRAq7CAJ0YjojtnRdiX5OthOvPEkN4MUY1ugCbB+3e b3QaEHg3OaBl8c0yn0cRKpg= =nMdS -----END PGP SIGNATURE-----

1 1

Problems loading mingw32 binaries (latest CVS)
by Vedran Rodic 23 Jun '01

23 Jun '01

Hello It seems that some recent change (post 20010510) prevents binaries made with mingw32 (at least with my mingw32 linux cross-compiler) to load. The error message is: err:module:map_image Could not map section .text, file probably truncated wine: can't exec 'a.exe': error=21 I've put one such binary and the source at: http://quark.fsb.hr/vedran/wine Debian wine version 0.0.20010510-3 loads the binary fine. Vedran Rodic

1 1

Re: Initializing Dosvm for direct port access
by Alexandre Julliard 23 Jun '01

23 Jun '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > What about checking if Dosvm.GetTimer is initialized and if it isn't > initialized do give back the dummy value? At least the spde doesn't seem to > care... How does the app behave under NT? Or with -winver nt40? -- Alexandre Julliard julliard(a)winehq.com

2 1

Readconsole, was libreadline for winedbg
by Uwe Bonnes 23 Jun '01

23 Jun '01

Hallo, investigating further, I found that winedbg uses ReadConsole to get what the debug-user typed in, however ReadConsole by far doesn't behave as expected, namely to give back the VT100 codes for what the user typed in. At present arrow key presses are never delivered to winedbg and if winedbg runs on the staring console, input is only delivered to winedbg after the user entered "Enter". Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: wine/ dlls/x11drv/winpos.c windows/x11drv/event.c
by Guy L. Albertelli 23 Jun '01

23 Jun '01

With the patch "Don't rely on X to expose windows covered by a sibling, do it manually. (6/21)" installed, it seems that most (possibly all) of the painting problems have been fixed. Great job!! There are two other outstanding problems remaining: 1. With ControlSpy (REBAR.EXE), WinRAR, and IE4 and native controls (commctrl, comctl32): The 01/03/15 cvs, when the mouse moves over the gripper, the cursor changes to linked left & right arrows. When the left button is pressed, the cursor is changed to a small double gripper with left & right arrows. The selected band can then be dragged. At the 01/06/01 cvs, the cursor is not changed either before the left button push or after. However the selected band can still be dragged. With the current cvs (01/06/22), the cursor is changed to the linked left & right arrows, but the area where the change occurs is much smaller. The cursor goes back to the normal arrow after the left button is pressed. The selected band can then be dragged, but is less responsive that the other two cases by about 50%. 2. This is with -managed mode and both examples involve the X-window being minimized (current cvs 6/22): With IE4 and native controls (commctrl, comctl32), when typing in the address box and "enter" is hit, the Xwindow is minimized and the data is processed. With our code, the enter is ignored. With WinRAR and native controls (commctrl, comctl32), selecting the settings dialog and replying OK results in the main window being mimimized. Selecting cancel (or other dialog boxes) do not cause mimimization. Guy

1 0

ChooseFont dialog problems.
by kenon＠go2.pl 23 Jun '01

23 Jun '01

Hello, I'm trying to make choosefont dialog working. (I'm not sending this patch to wine-patches because it is incomplete ,and I rather need some ideas ) First hunk of the patch allows changing font colors in 16-bit apps , and it seems to work properly. Second and third hunk affects both 16 and 32 bit apps ,and my intention is to fix CF_INITTOLOGFONTSTRUCT style handling. It almost works ,but code in dlls/commdlg/fontdlg.c is very cryptic (was it based on original Micro$oft code ? :-) ) . Should it be wrtitten from beginning :-( ? Trying to patch this file resemble hard patchwork :-) or else I spent too little time on trying to understand the file. Maciek --- /home/mkalisz/wine/dlls/commdlg/fontdlg.c Tue Jun 19 05:34:07 2001 +++ dlls/commdlg/fontdlg.c Sat Jun 23 01:27:57 2001 @@ -220,6 +220,7 @@ } lpChFont->lpTemplateName=lpTemplateName; + lpChFont->rgbColors=cf32a.rgbColors; font16 = MapSL(lpChFont->lpLogFont); font16->lfHeight = cf32a.lpLogFont->lfHeight; @@ -782,7 +783,7 @@ j=SendDlgItemMessageA(hDlg, cmb3, CB_GETCOUNT, 0, 0); for (i=0;i<j;i++) { - if (lpxx->lfHeight==(int)SendDlgItemMessageA(hDlg,cmb3, CB_GETITEMDATA,i,0)) + if (lpxx->lfHeight==-(int)SendDlgItemMessageA(hDlg,cmb3, CB_GETITEMDATA,i,0)) SendDlgItemMessageA(hDlg,cmb3,CB_SETCURSEL,i,0); } } @@ -1000,6 +1001,7 @@ return TRUE; } } + break; case chx1: case chx2: case cmb2:

1 0

Re: PATCH: MSDOS VGA mode
by Alexandre Julliard 23 Jun '01

23 Jun '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > I think we managed to get monkey island to start by fixing that keyboard > code. However, because of that annoying wineserver assertion failure, no > DOS apps like this run with my code anymore, so I can't check. Unless you > want to fix the wineserver assertion at server/console.c line 194, so > CONSOLE_make_complex can run in one thread while another winedos thread > keeps waiting for input? Did you try to simply remove the assert? I think the way the select is done now, it should actually work fine, and the assert should no longer be necessary. -- Alexandre Julliard julliard(a)winehq.com

1 0

word wrapping in ListViews
by Bill Medland 22 Jun '01

22 Jun '01

Does anyone know where the word-wrapping occurs in CListView objects? In the MFC code or lower down? One of the issues we face with our app is that on Windows when icons are displayed in a CListView and the label is significantly wider than the icon then I note that the label is written on two lines whereas under Wine it is displayed truncated on a single line. I am trying to figure out where the fault is. Does anyone know? Bill

1 0

server:truncated to 32768
by David Hagood 21 Jun '01

21 Jun '01

With a fresh build of last night's CVS pull, when I attempt to run Delorme's AAA MapNGo V4.0, I get the following error condition: server:truncated to 32768 server:truncated to 32768 At this point the main window of the application is up. However, if I try to do anything non-trivial with the app, it coughs up this error: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 1663 Current serial number in output stream: 1668 and one of the app threads dies. However, the main app window is still up, and four of its threads (plus the wineserver) are still alive. The app stops responding to the system, however. Where do I start on debugging this? What should I trace?

2 1

Initializing Dosvm for direct port access
by Uwe Bonnes 21 Jun '01

21 Jun '01

Hallo Ove, is something like appended patch right to get direct port access working for a win95 program? At least my dongle protected program (spde) doesn't crash any more and recognizes the license. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- hertz:/spare/bon/wine-clean> cvs -d $CVSROOT diff -uw -7 wine/msdos/ioports.c Index: wine/msdos/ioports.c =================================================================== RCS file: /home/wine/wine/msdos/ioports.c,v retrieving revision 1.24 diff -u -w -7 -r1.24 ioports.c --- wine/msdos/ioports.c 2001/05/09 17:31:35 1.24 +++ wine/msdos/ioports.c 2001/06/21 08:23:57 @@ -227,14 +227,15 @@ static void IO_port_init(void) { char temp[1024]; do_direct_port_access = 0; /* Can we do that? */ + DPMI_LoadDosSystem(); if (!iopl(3)) { iopl(0); PROFILE_GetWineIniString( "ports", "read", "*", temp, sizeof(temp) ); do_IO_port_init_read_or_write(temp, IO_READ); PROFILE_GetWineIniString( "ports", "write", "*",

2 2

Press: OsOpinion: Putting a Bad API on a Good OS
by Francois Gouget 20 Jun '01

20 Jun '01

Hi, A nice article with a provocative title. What I like about it is that it addresses the main objection of Linux hardcore users to Wine (at least as seen from Slashdot): will Wine hurt Linux? But judge for yourself :-) http://www.osopinion.com/perl/story/11297.html -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

2 1

Re: Still more clipping issues - but getting better
by r.maurizzi＠gvs.it 20 Jun '01

20 Jun '01

I'm using Lotus Notes 4.6, and with the last updates wirtualy all clipping problems were solved. The problem now is that every time I type a character in the editor, the whole window gets repainted 8-) and sometimes I can't see the cursor or a text selection I make. How can I help? Ciao, Roberto.

1 0

Still more clipping issues - but getting better
by Guy L. Albertelli 20 Jun '01

20 Jun '01

Hi Alexandre, The latest commits (through "Clip parent client area when using the drawable from a higher level parent." julliard@wine2. 01/06/19 20:22:40) have fixed the problem mentioned in the previous email. However certain problems still exist. The attached JPG shows the results with the latest commits and the native control when the second band is deleted (band # 1). Somehow it never erases the band. This did work correctly in 6/1 CVS. Recreation instructions: Select RB_DELETEBAND and change the first zero (second line) to a 1 and send it. The second band with the ComboBoxEx should disappear. There is another issue with IE4 (one of my test programs). When a string is typed into the address line (a ComboBoxEx) and "return" pressed, the entire IE window disappears. IE is still running and by selecting the item in the GNOME taskbar, the IE window reappears correctly. Thanks a lot, Guy Albertelli <<galberte(a)neo.lrun.com>>

1 0

Still clipping issues
by Guy L. Albertelli 19 Jun '01

19 Jun '01

The REBAR ControlSpy (as a simple test application) still displays clipping/drawing issues since 6/1/2001 even with the native control. The enclosed JPG shows some of the problems. The method for recreation is to select the Styles menu and then select the Recreate Control button. At the end of the redraw cycle the distortion is as shown. Note the partial combobox dropdown arrow just below the word "Control_" in the center of the screen. This seems to be due to an unclipped rectangle/too large a client area during the ComboBoxEx creation. In the 6/1 CVS version, you can see the same dropdown arrow but it is within the left hand control window not beyond. Note also the badly drawn text in the two listboxes to the right. If there is anything I can supply to help fix this please let me know. Thanks, Guy Albertelli <<galberte(a)neo.lrun.com>>

1 0

Re: PATCH: wine-config
by Alexandre Julliard 19 Jun '01

19 Jun '01

Malte Starostik <malte(a)kde.org> writes: > For example if the winelib app is only part of a project that for some reason > has its own Makefile management and/or merges its own rules with the ones for > wine. Yes, this refers to activexproxy where we currently have a self-written > configure check, but I could imagine other places where this might be of > interest... Well, of course you don't have to use the complete configure and makefile generated by winemaker, you can just take the subset you need and copy it into your makefiles. But I don't see how a wine-config could help you do that. Also I don't see why you'd necessarily want to use the same flags to compile your winelib app that have been used to compile wine itself; in fact you may not even be using the same compiler. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: wine-config
by Alexandre Julliard 19 Jun '01

19 Jun '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > to help winelib using developers, this program exports flags and directories > to /usr/bin/. > > I am not sure whether exported cflags and libs are ok. > > Hmm, we probably should also tell how to build .so libs. And specs -> .cs. > (Hmm, supply Makefile snippets?) Actually we already have winemaker that can generate a complete configure and makefile, so I'm not sure what purpose a wine-config would serve. -- Alexandre Julliard julliard(a)winehq.com

2 1

problem in create_icon_window in x11drv/window.c ?
by Adriaan Moors 19 Jun '01

19 Jun '01

hi just checked out wine from cvs today (exams are finally over ;-)), and tried to run WinMX (which ran fine, and still runs fine, using the precompiled cvs i have from june 9th), now with today's cvs i get this error: (i think it happens when the window for the tray icon is created...) <snip> trace:x11drv:create_icon_window created 280000d X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 89 Current serial number in output stream: 94 <wine exits> when i comment out the TSXCreateWindow in create_icon_window, the program starts up, but the windows keep moving about... i'm sorry if this is not the right newsgroup to post to, i hope it's not something i've done wrong regards, adriaan moors -- ADDING "JUST KIDDING" DOESN'T MAKE IT OKAY TO INSULT THE PRINCIPAL Bart Simpson on chalkboard in episode 2F09

1 0

RE: Use the libreadline in Winedbg, if available
by Patrik Stridvall 19 Jun '01

19 Jun '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Trying to claim, even though you didn't, that Winelib is > > effected is absurd since it is independent of the debugger. > > Distributing the debugger with WineLib is merly an aggregation > > nothing more. > > In theory any library that the debugger uses will also fall under the > GPL. In _theory_ yes, but hardly in pratices. No sane court would claim that, not even, would I dare say, the one of Judge Kaplan of DeCSS fame. Of course Microsoft (I can't remember the link but search on Slashdot) do claim it in their FUD campaign against the GPL but that doesn't make it true. Whether the GPL:ed is designed to be a "virus" or not is one thing that I will not argue for or against, but copyright law defintely isn't, so I will be quite hard for it to spread in the real world. > And someone shipping Wine binaries may not be aware that parts of > it need to be GPLed, and they will get flamed to death on Slashdot. That is a very convincing argument, yes. :-) > I mostly agree with you that the FSF stance on dynamic linking has no > basis in copyright law, but I'm not interested in providing the test > case. So if you want to use readline you can patch your local copy, > but I won't ship this in the main distribution. I was pretty sure that would be your answer.

1 0

Re: PATCH: Move 16-bit COMM stuff to USER, where it belongs
by Alexandre Julliard 19 Jun '01

19 Jun '01

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > Alexandre, you are right that that code should be revised and duplications > must be remove. But since I'm not an expert in the win32 communications code, > I can't do it without risk to break a working code. This patch was mostly > inspired by the fact, that while USER exports 16-bit comm stuff, that stuff > is not in the USER code. Instead of doing an ugly thing exporting 16-bit comm > functions from KERNEL I decided to move the code around. Please consider the > applying of the patch as it is now. Code duplication can be removed later. No, I'm afraid it won't be fixed if it is moved to a separate file. Also the split is not going to help for dll separation anyway, since the 16-bit routines use the SERVICE_* functions that aren't exported. So if you want clean dll separation the only choice is to rewrite the 16-bit routines. Any volunteer? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Use the libreadline in Winedbg, if available
by Alexandre Julliard 19 Jun '01

19 Jun '01

Patrik Stridvall <ps(a)leissner.se> writes: > Trying to claim, even though you didn't, that Winelib is > effected is absurd since it is independent of the debugger. > Distributing the debugger with WineLib is merly an aggregation > nothing more. In theory any library that the debugger uses will also fall under the GPL. And someone shipping Wine binaries may not be aware that parts of it need to be GPLed, and they will get flamed to death on Slashdot. I mostly agree with you that the FSF stance on dynamic linking has no basis in copyright law, but I'm not interested in providing the test case. So if you want to use readline you can patch your local copy, but I won't ship this in the main distribution. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Use the libreadline in Winedbg, if available
by Patrik Stridvall 19 Jun '01

19 Jun '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > No, it is enough that it is GPL compatible which the Wine > license is. > > But then the code can no longer be distributed under a non GPL > compatible license, while this is allowed by the Wine license. winedbg _binaries_ compiled with --enable-readline quite possibly. As far as the source code to winedbg is concerned maybe but probably not. It might depend on whether --enable-readline or --disable-readline is the default, but that remains to be tested in court, but it is not certain it matters at all. The court might quite reasonably rule that no linking to readline has taken place yet and thus no derived work can have been created and even if they hold that some sort of linking has taken place it might not consider it a derived work. In short linking, especially potential linking, do not always imply a derived work which is all that matters as far as the law is concerned. Also note that I'm not convinced that any court will hold that the GPL is different from the LGPL in any relevant way with the possible exception of in bad faith trying to circumvent the requirements by trying to be "clever". Of course it is a little unclear that you really can do unlawful circumvention of license requirements. This is a like claiming that somebody circumvented trespassing your land by moving around it. Either you trespass or you do not. Either you violate the license or you do not. The analogy is quite good even in other areas: Even if you are on somebodies land you do not nessary trespass either because of copyright like "fair use" requirements in the law of most countries. As a sidenote: In Sweden "fair use" concerning trespass is so extensive that I never heard about _any_ case concerning it. > I think the benefit of using readline in the debugger is much too > small to justify the potential license issues this would cause. Only the debugger (winedbg) links with readline => only the debugger can be effected. Trying to claim, even though you didn't, that Winelib is effected is absurd since it is independent of the debugger. Distributing the debugger with WineLib is merly an aggregation nothing more.

1 0

Re: PATCH: Move 16-bit COMM stuff to USER, where it belongs
by Alexandre Julliard 19 Jun '01

19 Jun '01

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Move 16-bit COMM stuff to USER, where it belongs. While the idea of the patch is correct, I think it would be much better to fix the huge code duplication while everything is in the same file. The 16-bit stuff should be implemented on top of the 32-bit stuff, instead of duplicating most of it. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Use the libreadline in Winedbg, if available
by Alexandre Julliard 19 Jun '01

19 Jun '01

Patrik Stridvall <ps(a)leissner.se> writes: > No, it is enough that it is GPL compatible which the Wine license is. But then the code can no longer be distributed under a non GPL compatible license, while this is allowed by the Wine license. I think the benefit of using readline in the debugger is much too small to justify the potential license issues this would cause. -- Alexandre Julliard julliard(a)winehq.com

1 0

Lost mail
by Alexandre Julliard 18 Jun '01

18 Jun '01

Folks, I have been forced to change ISPs over the week-end, and it seems the old and new ISP couldn't agree on when to do the switch, so any mail sent to me during the week-end probably got forwarded to /dev/null. Also could people who submitted a patch to wine-patches please send me a private copy? I know they are on the mailing list archive, but it makes my life a lot easier to have everything in my mail box. Thanks. -- Alexandre Julliard julliard(a)winehq.com

1 0

set_file_pointer and 64 bit file access
by Bill Medland 18 Jun '01

18 Jun '01

I see we are in the middle of converting set_file_pointer towards 64 bit file systems. Currently the code is confused as to when to change from unsigned to signed int for the low 32 bits. Should it happen in SetFilePointer before sending the request (which means we end up changing the request format) or should it happen within set_file_pointer (after changing the argument back to a signed int; this would also require work in SetFilePointer to get it to set up the request correctly). Any views? Bill

1 0

RE: Use the libreadline in Winedbg, if available
by Ove Kaaven 18 Jun '01

18 Jun '01

On Mon, 18 Jun 2001, Patrik Stridvall wrote: > A minor notice. Readline is GPL:ed (not LGPL:ed) which is not so good. > While it is without doubt legal for us to use and distribute, > it might cause trouble for other people. Not as long as it's optional (that patch even supported ./configure --without-readline, so no trouble, such people would just disable it).

1 0

RE: Use the libreadline in Winedbg, if available
by Patrik Stridvall 18 Jun '01

18 Jun '01

> On Mon, Jun 18, 2001 at 04:10:14PM +0200, Uwe Bonnes wrote: > > Hallo, > > > > at present, wine uses unconditionally a self supplied readline > > function. Appended patch tries to find out if libreadline > is available > > and uses libreadline if available. I configured with and without > > libreadline and successfully compiled winedbg on my system. > > libreadline is a static library on my system and winedbg > grew 90 kByte > > stripped and 110 kByte compiled with -g. > > You are not allowed to link readline aganst non GPL code to > my knowledge. No, it is enough that it is GPL compatible which the Wine license is. Whether we should is another matter though. Just linking it to the debugger is rather harmless IMHO though.

2 1

Re: Use the libreadline in Winedbg, if available
by Marcus Meissner 18 Jun '01

18 Jun '01

On Mon, Jun 18, 2001 at 04:10:14PM +0200, Uwe Bonnes wrote: > Hallo, > > at present, wine uses unconditionally a self supplied readline > function. Appended patch tries to find out if libreadline is available > and uses libreadline if available. I configured with and without > libreadline and successfully compiled winedbg on my system. > libreadline is a static library on my system and winedbg grew 90 kByte > stripped and 110 kByte compiled with -g. You are not allowed to link readline aganst non GPL code to my knowledge. Ciao, Marcus

1 0

Dosvm not initialized for Direct port access
by Uwe Bonnes 18 Jun '01

18 Jun '01

Hallo, some license manager dll (lmgr327a) manages to read IOPORT 0x40 from 32-bit code. This results in an access to Dosvm.GetTimer() in line 297 in ioports.c, and as Dosvm isn't initialized this results in a crash. =>0 0x00000000 (ebp=404e4b38) 1 0x400cd595 (IO_inport+0x205(port=0x40, size=0x1) [ioports.c:297] in libntdll.so) (ebp=404e4b38, null call assumed) 2 0x400a7405 (INSTR_inport+0x25(port=0x40, size=0x1, context=0x404e4c50) [instr.c:328] in libntdll.so) (ebp=404e4b58) 3 0x400a888c (INSTR_EmulateInstruction+0x12cc(context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50) [instr.c:745] in libntdll.so) (ebp=404e4bc4) 4 0x400733c9 (do_segv+0x109(context=0x404e4c50, trap_code=0xd, cr2=0x0, err_code=0x0) [signal_i386.c:671] in libntdll.so) (ebp=404e4c2c) 5 0x4007368d (segv_handler+0x3d(__signal=0xb, __context=0x0) [signal_i386.c:787] in libntdll.so) (ebp=404e4d1c) 6 0x4029fb58 (__restore [sigaction.c] in libc.so.6) (ebp=405f57a0) 7 0x1c0b0004 (LMGR327A.DLL..reloc+0xbfe2004) (ebp=04007242) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

16-bit and 32-bit separation
by Patrik Stridvall 18 Jun '01

18 Jun '01

[Since the subject it up because of Dimitry's "Move 16-bit COMM stuff to USER, where it belongs" patch] My new tool winapi_fixup could without to much effort be extended to facillitate separation of 16-bit and 32-bit stuff by moving the 16-bit parts of a file (example: foo.c) to a new 16-bit only file (example: foo16.c). Of course because of dependecies, includes and such things it can only be partly automatic and it will in most cases require quite a lot editing afterwards, so the questions (primarily to Alexandre but other replies welcome to) are: 1. Will/Should Alexandre accept such patches at all? 2. Is it a useful effort to get the 16-bit stuff out of the way so we don't have to see it in the files when editing the 32-bit stuff? 3. Is it a useful effort to make it possible to have --disable-win16 configure option to compile out as much Win16 stuff as possible in order to save space in the binaries for say embedded stuff. 4. While this certainly it not a high or even medium priority effort, should it have low, very low or extremly low priority? PS. I have other stuff planed so I certainly do not lack things to do. However since the subject is up I might just as well ask.

1 0

SIGSEGV while trying to run Word97
by Heiko Nardmann 17 Jun '01

17 Jun '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am continously getting a dialog "Nicht genügend Arbeitsspeicher oder unzureichender Speicherplatz, um Word auszuführen" (German version). After trying to examine this problem with debugmsg all (without real success) I added an strace call to the whole call. This resulted in a log file which tells me that a SIGSEGV occurrs. Here is a part of the strace log file which contains the SIGSEGV message. After that the appropriate 'debugmsg all' part follows. What can be done to shed more light onto this problem? strace log: write(2, "08069280:trace:win32:_LeaveSysLe"..., 112) = 112 write(2, "08069280:Ret user32.CreateWindo"..., 68) = 68 write(2, "08069280:RET mso97.486: _MsoCre"..., 84) = 84 write(2, "08069280:trace:heap:HeapFree (40"..., 74) = 74 write(2, "08069280:Call kernel32.GetVersio"..., 49) = 49 write(2, "08069280:Ret kernel32.GetVersio"..., 65) = 65 write(2, "08069280:Call kernel32.GetVersio"..., 60) = 60 write(2, "08069280:Ret kernel32.GetVersio"..., 68) = 68 write(2, "08069280:Call kernel32.GlobalMem"..., 65) = 65 time(NULL) = 992531763 time(NULL) = 992531763 open("/proc/meminfo", O_RDONLY) = 11 fstat(11, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4035c000 read(11, " total: used: free:"..., 1024) = 319 read(11, "", 1024) = 0 close(11) = 0 munmap(0x4035c000, 4096) = 0 write(2, "08069280:Ret kernel32.GlobalMem"..., 73) = 73 write(2, "08069280:CALL mso97.394: _MsoFCr"..., 147) = 147 write(2, ") ret=30011010\n", 15) = 15 write(2, "08069280:Call kernel32.VirtualAl"..., 86) = 86 write(2, "08069280:trace:virtual:VirtualAl"..., 68) = 68 mmap2(NULL, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOSYS (Function not implemented) old_mmap(NULL, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40e90000 munmap(0x40ea0000, 65536) = 0 write(2, "View: 40e90000 - 40e9ffff (vallo"..., 35) = 35 write(2, " 40e90000 - 40e9ffff -----\n", 32) = 32 write(2, "08069280:Ret kernel32.VirtualAl"..., 67) = 67 write(2, "08069280:Call kernel32.VirtualAl"..., 86) = 86 write(2, "08069280:trace:virtual:VirtualAl"..., 68) = 68 write(2, "08069280:trace:virtual:VIRTUAL_S"..., 63) = 63 mprotect(0x40e90000, 4096, PROT_READ|PROT_WRITE) = 0 write(2, "View: 40e90000 - 40e9ffff (vallo"..., 35) = 35 write(2, " 40e90000 - 40e90fff c-rW-\n", 32) = 32 write(2, " 40e91000 - 40e9ffff -----\n", 32) = 32 write(2, "08069280:Ret kernel32.VirtualAl"..., 67) = 67 - --- SIGSEGV (Speicherzugriffsfehler) --- write(2, "08069280:RET mso97.394: _MsoFCr"..., 126) = 126 rt_sigprocmask(SIG_BLOCK, [HUP INT ALRM IO], [], 8) = 0 write(5, "F\0\0\0\0\0\34\1<\0336@\1\0\0\0\304\357\17@\0\0\0\0\0\0"..., 64) = 64 read(6, "F\0\0\0\0\0\34\1\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 write(2, "08069280:trace:seh:EXC_CallHandl"..., 87) = 87 write(2, "08069280:trace:seh:EXC_RtlUnwind"..., 55) = 55 write(2, "08069280:trace:seh:EXC_CallHandl"..., 87) = 87 write(2, "08069280:trace:seh:EXC_CallHandl"..., 54) = 54 - --- SIGSEGV (Speicherzugriffsfehler) --- write(2, "08069280:trace:seh:EXC_RtlRaiseE"..., 63) = 63 rt_sigprocmask(SIG_BLOCK, [HUP INT ALRM IO], [], 8) = 0 write(5, "F\0\0\0\0\0\34\1<\0336@\1\0\0\0\304\357\17@\0\0\0\0\0\0"..., 64) = 64 read(6, "F\0\0\0\0\0\34\1\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 wine debug log: 08069280:trace:win32:_LeaveSysLevel (0x40753a74, level 2): thread 0x8069280 (fs 008f, pid 24063) count after 0 08069280:Ret user32.CreateWindowExW() retval=00000138 ret=306cc216 08069280:RET mso97.486: _MsoCreateMonitorWindow@0() retval = 00000000 ret=3000162f 08069280:trace:heap:HeapFree (40360000,00000002,403a4a80): returning TRUE 08069280:Call kernel32.GetVersion() ret=30001984 08069280:Ret kernel32.GetVersion() retval=05650004 ret=30001984 08069280:Call kernel32.GetVersionExA(405c686c) ret=300019b5 08069280:Ret kernel32.GetVersionExA() retval=00000001 ret=300019b5 08069280:Call kernel32.GlobalMemoryStatus(405c6900) ret=300019e2 08069280:Ret kernel32.GlobalMemoryStatus() retval=405c6900 ret=300019e2 08069280:CALL mso97.394: _MsoFCreateIPref@28(<unknown, check return>08069280:trace:heap:HeapAlloc (40360000,00000002,00000040): returning 403a4b98 ) ret=30011010 08069280:Call kernel32.VirtualAlloc(00000000,0000fffc,00002000,00000001) ret=3070b360 08069280:trace:virtual:VirtualAlloc 00000000 0000fffc 2000 00000001 View: 40e90000 - 40e9ffff (valloc) 40e90000 - 40e9ffff ----- 08069280:Ret kernel32.VirtualAlloc() retval=40e90000 ret=3070b360 08069280:Call kernel32.VirtualAlloc(40e90000,00001000,00001000,00000004) ret=3070b38b 08069280:trace:virtual:VirtualAlloc 40e90000 00001000 1000 00000004 08069280:trace:virtual:VIRTUAL_SetProt 40e90000-40e90fff c-rW- View: 40e90000 - 40e9ffff (valloc) 40e90000 - 40e90fff c-rW- 40e91000 - 40e9ffff ----- 08069280:Ret kernel32.VirtualAlloc() retval=40e90000 ret=3070b38b 08069280:RET mso97.394: _MsoFCreateIPref@28(30011020,00000000,08069280:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 08069280: queue_exception_event( first=1, record={context={flags=00000000,eax=00000000,ebx=400fefc4,ecx=4d535744,edx=00000000,esi=00000000,edi=00000007,ebp=405c6790,eip=400c8aca,esp=405c66cc,eflags=00010246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x400c8aca,params={0,4d535744}} ) 08069280: queue_exception_event() = 0 { handle=0 } 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005b520 code=c0000005 flags=0 08069280:trace:seh:EXC_RtlUnwind code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005ad80 code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler handler returned 1 08069280:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 08069280: queue_exception_event( first=1, record={context={flags=00000000,eax=00000000,ebx=400fefc4,ecx=4d535744,edx=00000000,esi=00000000,edi=00000007,ebp=405c6790,eip=400c8baa,esp=405c66cc,eflags=00010246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x400c8baa,params={0,4d535744}} ) 08069280: queue_exception_event() = 0 { handle=0 } 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005b520 code=c0000005 flags=0 08069280:trace:seh:EXC_RtlUnwind code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005ad80 code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler handler returned 1 - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de), Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7KcuPpm53PRScYygRAlfZAJ91r/8CwDzWpu0TU0vB+FRP18w14QCg4sCK GBnoWm0xkKgHgFucJcNrsno= =8hel -----END PGP SIGNATURE-----

5 6

CS_PARENTDC problems
by Malte.Starostik＠t-online.de 17 Jun '01

17 Jun '01

Hi, we had some serious painting problems with dialog from an ActiveX control. All controls were invisible and only showed up sometimes on getting or losing focus. The cause is a custom class "_BitmapClass" that draws a logo and has the CS_PARENTDC class style (and no other class styles FWIW). Its WM_ERASEBKGND handler fills the complete dialog rect with that default Win95-Desktop-Background colour. According to the Win32 docs winelib behaves correctly wrt CS_PARENTDC and clipping. In this case it'd be Macromedia's fault as to how they implemented that window. However, I just found http://msdn.microsoft.com/library/techart/msdn_classy32.htm: <classy> If you use the CS_PARENTDC style for a class, each window in that class uses its parent window's DC. CS_PARENTDC is similar to CS_CLASSDC in that multiple windows share one DC. In CS_PARENTDC, however, the windows that share the DC need not belong to the same class. </classy> This contradicts the API docu at http://msdn.microsoft.com/library/psdk/winui/winclass_3b1v.htm: <api docs> CS_PARENTDC Sets the clipping rectangle of the child window to that of the parent window so that the child can draw on the parent. A window with the CS_PARENTDC style bit receives a regular device context from the system's cache of device contexts. It does not give the child the parent's device context or device context settings. Specifying CS_PARENTDC enhances an application's performance. <api docs> a little later, this is as near as the "classy" text comes to clipping: <classy> Another outcome of the CS_PARENTDC style is that child windows can draw anywhere in their parent's client area as well as drawing in their own client area. The CTL3D library, which creates 3-D effects around edit controls and list boxes, relies on this behavior. An application should not use CS_PARENTDC if it needs to adjust the mapping modes for different child windows. This will negate much of the benefit and could cause problems ensuring that each child window has the correct mapping mode set. </classy> Then I tried on Windows (2000), created a window with a child that has CS_PARENTDC set and * The paint rect of the PAINTSTRUCT as intialized by BeginPaint() equals the window's client rect - as expected. * but - surprise - so does the DC's clip box and trying to largen it to cover some or all areas of the parent fail and of course any drawing on the parent fails. * same for the DC returned by GetDC(hWnd) * only GetDCEx(hWnd, 0, DCX_PARENTCLIP) returns a DC that allows painting on the parent (no difference to a non-CS_PARENTDC window though) So, how is this painting on the parent with that style flag supposed to work? The things above make me think that it isn't possible at all or requires some additional steps. This would at least explain why the dialog described above looks busted in wine. If anyone could confirm my observations I'd come up with a patch. Thanks for any info, -Malte -- Wars don't determine who's right, only who's left.

1 0

Re: PATCH: wine-config
by Andreas Mohr 17 Jun '01

17 Jun '01

On Sun, Jun 17, 2001 at 10:26:34AM +0200, Marcus Meissner wrote: > Hi, > > to help winelib using developers, this program exports flags and directories > to /usr/bin/. > > I am not sure whether exported cflags and libs are ok. > > Hmm, we probably should also tell how to build .so libs. And specs -> .cs. > (Hmm, supply Makefile snippets?) > > Ciao, Marcus > > Changelog: > Added a 'wine-config' for winelib developers. I don't think this is a good idea. That way it'll get confused with wineconf within fractions of a second... I'd much rather use a name like wlib-config or winelib-config instead. -- Andreas Mohr

1 0

wrc error
by Bang Jun-Young 15 Jun '01

15 Jun '01

Hi, I got the following error when I tried to compile the latest CVS source: gmake[2]: Entering directory `/home/bjy/wine/dlls/user' LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" ../../tools/wrc/wrc -I. -I. -I../../include -I../../include -o resources/user32.res -r resources/user32.rc resources/user32_Ca.rc:2:1: Error: syntax error gmake[2]: *** [resources/user32.res] Error 1 After downgrading some files in wrc to earier revisions, Wine was successfully compiled again. I suspect that Francois Gouget's commit made on 2001-06-07 causes this. Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

2 1

Re: Hangs in half-life menus (design problem in new queue code)
by Alexandre Julliard 14 Jun '01

14 Jun '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > The new message queue design doesn't seem to allow this to be fixed... > or does it? Working on it... -- Alexandre Julliard julliard(a)winehq.com

1 0

Hangs in half-life menus (design problem in new queue code)
by Ove Kaaven 14 Jun '01

14 Jun '01

The new message queue code has caused the half-life menus to hang, since it handles timers slightly differently now. Now: - User moves mouse over a menu item - On mouseover, game starts a window timer (55ms) - On each WM_TIMER, game redraws the menu item. This takes longer than 55ms - After drawing, it checks messages. Since the 55ms timer has expired, another WM_TIMER is received, item is redrawn, any user input is ignored. Repeat Before, the hardware input queue was checked before WM_PAINT and WM_TIMER was checked, so the user could move the cursor away from the menu item (which would cancel the timer). With the new code, the hardware input queue (x11drv.MsgWaitFor...) is checked *after* timers, so the menu is now completely stuck. The new message queue design doesn't seem to allow this to be fixed... or does it?

1 0

Re: virtual memory problems with Linux 2.4.5
by Alexandre Julliard 14 Jun '01

14 Jun '01

Alexandre Julliard <julliard(a)winehq.com> writes: > Another related problem is that even without this bug, mmap64 will > always refuse to do an unaligned mmap, even if the kernel might have > accepted it (with kernel 2.2.x for instance). Maybe the best solution > would be to directly call the mmap syscall instead of mmap2 when > mapping executables, this would fix both problems. OK, here we go. Could you please test this, especially people running kernel 2.4? Index: memory/virtual.c =================================================================== RCS file: /opt/cvs-commit/wine/memory/virtual.c,v retrieving revision 1.63 diff -u -r1.63 virtual.c --- memory/virtual.c 2001/06/13 20:13:20 1.63 +++ memory/virtual.c 2001/06/14 02:15:36 @@ -104,7 +104,8 @@ #define VIRTUAL_DEBUG_DUMP_VIEW(view) \ if (!TRACE_ON(virtual)); else VIRTUAL_DumpView(view) -static LPVOID VIRTUAL_mmap( int fd, LPVOID start, DWORD size, DWORD offset, int prot, int flags ); +static LPVOID VIRTUAL_mmap( int fd, LPVOID start, DWORD size, DWORD offset_low, + DWORD offset_high, int prot, int flags ); /* filter for page-fault exceptions */ static WINE_EXCEPTION_FILTER(page_fault) @@ -471,7 +472,7 @@ /* map the header */ - if (VIRTUAL_mmap( fd, ptr, header_size, 0, PROT_READ | PROT_WRITE, + if (VIRTUAL_mmap( fd, ptr, header_size, 0, 0, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_FIXED ) == (char *)-1) goto error; dos = (IMAGE_DOS_HEADER *)ptr; nt = (IMAGE_NT_HEADERS *)(ptr + dos->e_lfanew); @@ -533,7 +534,7 @@ sec->PointerToRawData, pos, sec->SizeOfRawData, size, sec->Characteristics ); if (VIRTUAL_mmap( shared_fd, (char *)ptr + sec->VirtualAddress, size, - pos, PROT_READ|PROT_WRITE|PROT_EXEC, + pos, 0, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED ) == (void *)-1) { ERR_(module)( "Could not map shared section %.8s\n", sec->Name ); @@ -555,7 +556,7 @@ * fall back to read(), so we don't need to check anything here. */ if (VIRTUAL_mmap( fd, (char *)ptr + sec->VirtualAddress, sec->SizeOfRawData, - sec->PointerToRawData, PROT_READ|PROT_WRITE|PROT_EXEC, + sec->PointerToRawData, 0, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE | MAP_FIXED ) == (void *)-1) { ERR_(module)( "Could not map section %.8s, file probably truncated\n", sec->Name ); @@ -650,6 +651,46 @@ } + +/*********************************************************************** + * unaligned_mmap + * + * Linux kernels before 2.4.x can support non page-aligned offsets, as + * long as the offset is aligned to the filesystem block size. This is + * a big performance gain so we want to take advantage of it. + * + * However, when we use 64-bit file support this doesn't work because + * glibc rejects unaligned offsets. Also glibc 2.1.3 mmap64 is broken + * in that it rounds unaligned offsets down to a page boundary. For + * these reasons we do a direct system call here. + */ +static void *unaligned_mmap( void *addr, size_t length, unsigned int prot, + unsigned int flags, int fd, unsigned int offset_low, + unsigned int offset_high ) +{ +#if defined(linux) && defined(__i386__) && defined(__GNUC__) + if (!offset_high && (offset_low & page_mask)) + { + int ret; + __asm__ __volatile__("push %%ebx\n\t" + "movl %2,%%ebx\n\t" + "int $0x80\n\t" + "popl %%ebx" + : "=a" (ret) + : "0" (90), /* SYS_mmap */ + "g" (&addr) ); + if (ret < 0 && ret > -4096) + { + errno = -ret; + ret = -1; + } + return (void *)ret; + } +#endif + return mmap( addr, length, prot, flags, fd, ((off_t)offset_high << 32) | offset_low ); +} + + /*********************************************************************** * VIRTUAL_mmap * @@ -657,15 +698,16 @@ * and falls back to read if mmap of a file fails. */ static LPVOID VIRTUAL_mmap( int fd, LPVOID start, DWORD size, - DWORD offset, int prot, int flags ) + DWORD offset_low, DWORD offset_high, int prot, int flags ) { int pos; LPVOID ret; + off_t offset; if (fd == -1) return wine_anon_mmap( start, size, prot, flags ); - if ((ret = mmap( start, size, prot, flags, fd, offset )) != (LPVOID)-1) - return ret; + if ((ret = unaligned_mmap( start, size, prot, flags, fd, + offset_low, offset_high )) != (LPVOID)-1) return ret; /* mmap() failed; if this is because the file offset is not */ /* page-aligned (EINVAL), or because the underlying filesystem */ @@ -687,6 +729,7 @@ ret = wine_anon_mmap( start, size, PROT_READ | PROT_WRITE, flags ); if (ret == (LPVOID)-1) return ret; /* Now read in the file */ + offset = ((off_t)offset_high << 32) | offset_low; if ((pos = lseek( fd, offset, SEEK_SET )) == -1) { munmap( ret, size ); @@ -1524,8 +1567,8 @@ shared_file, shared_size ); - if (size_high || offset_high) - ERR("Offsets larger than 4Gb not supported\n"); + if (size_high) + ERR("Sizes larger than 4Gb not supported\n"); if ((offset_low >= size_low) || (count > size_low - offset_low)) @@ -1570,7 +1613,7 @@ TRACE("handle=%x size=%x offset=%lx\n", handle, size, offset_low ); - ptr = (UINT)VIRTUAL_mmap( unix_handle, addr, size, offset_low, + ptr = (UINT)VIRTUAL_mmap( unix_handle, addr, size, offset_low, offset_high, VIRTUAL_GetUnixProt( prot ), flags ); if (ptr == (UINT)-1) { /* KB: Q125713, 25-SEP-1995, "Common File Mapping Problems and -- Alexandre Julliard julliard(a)winehq.com

5 5

clipped child
by lawson_whitney＠juno.com 14 Jun '01

14 Jun '01

Good day! A little problem. Unhandled exception: page fault on read access to 0x00000067 in 32-bit code (0x40a25f4e). In 32-bit mode. 0x40a25f4e (clip_children+0x7e [winpos.c:83] in libx11drv.so): testb $0x10,0x67(%esi) 83 if (ptr->dwStyle & WS_VISIBLE) Lawson ---

1 0

RE: wine on Alpha (was: Help needed)
by Patrik Stridvall 14 Jun '01

14 Jun '01

> > Still, you must be aware of a few thing. > > * Wine is not 100% byte order clean. > > Alpha seems to be "correct" endian ;) True. But what I meant was since the size of integer changes from 32 to 64 bits, any code that rely on the exact layout of memory might have problems becuase of this. This is not the same as the problem below where you have pointer truncation issues or because code expects that DWORD x; int y; x = y; will work correcly. But OK. I shold probably explained better what I meant. Anyway all code should be byte order clean regardless and making it so might solve some 32/64 bit byte layout problems as well. When you change to code for Alpha you might as well change it to work with big endian platforms as well. > > * Wine is not 64 bit clean. > > This is a little worse especially since > > Win32 often stores pointers in 32 bit integers > > and this problem really can't be solved in > > a good way, since extending the size of the storage > > is not possible at least not if you want to > > be able to implement a x86 emulator in the > > future. However I guess it will be possible > > to force all memory usage to be in the lower > > 32 bits of memory to be able to cope with > > truncated pointers. > > Digital has(d) a lot of very good emulation technologies - > FX!32 which let to run win32 386 apps on NT Alpha with > almost full speed, em86 which runs 386 Linux apps on Linux > Alpha (http://www.cs.rose-hulman.edu/~donaldlf/em86/index.html), > x86emu which is used in XFree86 and MILO to initialize > graphic card's 386 BIOS. True, but Wine might need something a little more than that and FX!32 doesn't have souce code available AFAIK. Of course that is perhaps not a problem for an internal Digital project. :-) Anyway, that is a later problem. Just making Winelib work might take some effort.

1 0

OT - a free windows screensaver?
by lawson_whitney＠juno.com 14 Jun '01

14 Jun '01

Good day! After I got both my legs broke April 27, my computer and I have been a bit exposed to a small segment of the public, and everybody loves my screensaver. ftp://ftp.ibiblio.org/pub/Linux/utils/console/lockvc-3.9.1.tar.gz Of course, I may have a hard time to get them to install Linux just for a screensaver, so I thought I might see about porting it to windose. A sample or something to plagiarize from would be good, I think. I haven't figured out how to work mingw either, but maybe inspiration will come. Regards, 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

interrupts
by Eugene Toichkin 14 Jun '01

14 Jun '01

Hi! I have to run the add-on card with Windows controlling program on my linux box. That card generates the interrupt and requires some port addresses. Is any way to configure WINE to run that kind of application on Linux host? -- Best regards, Eugene Toichkin ugin(a)itc.mecom.ru

1 0

Re: Re: virtual memory problems with Linux 2.4.5
by Mike McCormack 14 Jun '01

14 Jun '01

Seems ok to me also, after a quick test. Mike Original message from: lawson_whitney(a)juno.com > > > >On 13 Jun 2001, Alexandre Julliard wrote: > >> OK, here we go. Could you please test this, especially people running >> kernel 2.4? >> >> Index: memory/virtual.c > >Looks good to me. First problem app runs OK, and you get this by the >second one. > >gcc version 2.95.3 20010315 (release) >/lib/libc.so.6 -> libc-2.1.3.so* >Linux giftie 2.4.5 #1 Sat Jun 2 11:23:22 EDT 2001 i586 unknown > >Lawson ------------------------------------------ mailto:Mike_McCormack@looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Drawing problems with ControlSpy
by Guy L. Albertelli 14 Jun '01

14 Jun '01

With today's CVS (last patch was "wine/ dlls/gdi/wing.c dlls/kernel/comm.c dlls/ ..."), the following problems exist in the ControSpy (REBAR) test program: Problem #1. Using native version of "commctrl,comctl32", get the following fault: /home/albertel/t1/wine/wine -managed -winver win95 -dll commctrl,comctl32=n G:\Rdhat\test-pgm\controls\rebar.exe Could not stat /mnt/winflp (No such file or directory), ignoring drive A: fixme:pthread_kill_other_threads_np Could not stat /mnt/winflp (No such file or directory), ignoring drive A: WineDbg starting... on pid 8064ef0 ...... Unhandled exception: page fault on read access to 0x00000067 in 32-bit code (0x40894f24). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x40894f24 (clip_children+0x24 [winpos.c:70] in libx11drv.so): testb $0x10,0x67(%esi) 70 if (ptr->dwStyle & WS_VISIBLE) break; Wine-dbg>bt Backtrace: =>0 0x40894f24 (clip_children+0x24(win=0x403732dc, last=0x40373370, hrgn=0xa22, whole_window=0x0) [winpos.c:70] in libx11drv.so) (ebp=40586564) 1 0x4089511e (get_visible_region+0x14e(win=0x40373370, top=0x403732dc, flags=0x1001a, mode=0x1) [winpos.c:144] in libx11drv.so) (ebp=405865a4) 2 0x408952ec (X11DRV_GetDC+0x1a8(hwnd=0x1908, hdc=0x88, hrgn=0x0, flags=0x1001a) [winpos.c:229] in libx11drv.so) (ebp=405865e8) 3 0x406874bc (GetDCEx+0x29c(hwnd=0x1908, hrgnClip=0x0, flags=0x10000) [dce.c:531] in libuser32.so) (ebp=40586620) 4 0x4068755c (GetDC+0x2c(hwnd=0x1908) [dce.c:561] in libuser32.so) (ebp=40586638) 5 0xbfb9a055 (COMCTL32.DLL.InitCommonControlsEx+0x4137 in C:\WINDOWS\SYSTEM\COMCTL32.DLL) (ebp=40586694) 6 0xbfb9a037 (COMCTL32.DLL.InitCommonControlsEx+0x4119 in C:\WINDOWS\SYSTEM\COMCTL32.DLL) (ebp=405867fc) 7 0xbfb94e38 (COMCTL32.DLL.ImageList_GetIconSize+0x558 in C:\WINDOWS\SYSTEM\COMCTL32.DLL) (ebp=40586854) 8 0x406b24a7 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=40586878) 9 0x406b2520 (WINPROC_CallWndProc+0x70(proc=0xbfb94a89, hwnd=0x1908, msg=0x81, wParam=0x0, lParam=0x40586b10) [winproc.c:171] in libuser32.so) (ebp=405868a0) The following patch bypasses the tests: --- wine/dlls/x11drv/winpos.c Wed Jun 13 20:03:34 2001 +++ mywine/dlls/x11drv/winpos.c Wed Jun 13 22:59:18 2001 @@ -65,6 +65,9 @@ HRGN rectRgn; int x, y; + /* if no children then nothing to do */ + if (!win->child) return; + /* first check if we have anything to do */ for (ptr = win->child; ptr != last; ptr = ptr->next) if (ptr->dwStyle & WS_VISIBLE) break; Problem # 2. With above patch and still using native comctl32 get the following: /home/albertel/t1/mywine/wine -managed -winver win95 -dll commctrl,comctl32=n G:\Rdhat\test-pgm\controls\rebar.exe Could not stat /mnt/winflp (No such file or directory), ignoring drive A: err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:x11drv:X11DRV_SetDeviceClipping Rgn is 0. Please report this. ##normal exit from wine## Problem # 3. Still with native comctl32. With more than 1 band in a row, when you drag a band from left to right, the band being uncovered is not fully repainted (suspect InvalidateRect too small). This is especially visible if the band being dragged is a different color. It is also sensitive to the speed of the drag. Attached is a control file to create different color bands in a row. If you need any more information, let me know what. I will be doing more work tomorrow night. Thanks, Guy

1 0

Re: wine/windows/x11drv event.c
by Guy L. Albertelli 14 Jun '01

14 Jun '01

> >Log message: > Force invalidating of siblings children on expose event. > This seems to allow ControlSpy (rebar) to draw its children again, but exposes some other drawing problems. The symptom is that certain areas do not seem to be invalidated correctly. If the window is overlayed with another the everything is redrawn correctly. I will attempt to get documentation later tonight. Thanks, Guy

1 0

RE: Help needed
by Patrik Stridvall 13 Jun '01

13 Jun '01

I'm sorry for not answering earlier. I saw your message but I didn't have time to answer it at the time and then a forgot about it. In truth I wasn't very eager about answering either since I have answered far to many people that just asked questions and then didn't contribute anything because I guess that they felt it was to difficult or to much work. I didn't notice that you were from Digital either, but after reading Kernel Cousin Wine #97 I was made aware of that fact. While it is possible that you are yet another of those people I talked about above, since you are from Digital I will take some time to answer your questions. Note however that I'm not at all unwilling to answer questions. It is just that it has felt like a wasted effort in the past. > We are planning to port wine onto Tru64 Unix. I have some > basic Questions. OK. Sound good. > Can you tell me how to go about it. Yes. But it is better if you ask more specific questions. > How do we start. You try to get it to compile and link. This shouldn't be to difficult. While I never used Tru64 I expect it supports all things Wine will need. > How big > is the task and Well, if you want the emulator (Wine) to work it will be a humongous task, since you will have to emulate x86 instructions on the Alpha among other things. However if you just want the porting tool (Winelib) to work it will be a little easier. Still, you must be aware of a few thing. * Wine is not 100% byte order clean. However there have been some attempts to port it to Sparc which is big endian so don't if I think it is that bad and the remaining problems can be fixed without to much effort. * Wine is not 64 bit clean. This is a little worse especially since Win32 often stores pointers in 32 bit integers and this problem really can't be solved in a good way, since extending the size of the storage is not possible at least not if you want to be able to implement a x86 emulator in the future. However I guess it will be possible to force all memory usage to be in the lower 32 bits of memory to be able to cope with truncated pointers. * Then of course you have Tru64 specific problem. However I don't expect them to be so bad. > how to start about it.. Well as I said. Try to compile and link it. Then try to get some of the simple examples in wine/programs to run.

2 1

Re: virtual memory problems with Linux 2.4.5
by Alexandre Julliard 13 Jun '01

13 Jun '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > your patch produced a yes, BUT when i changed the offset value to > 0x400, and it failed ... see new patch below. That's a bug in glibc 2.1.3. This is from the mmap64 source: [offset is in ecx:edx] testl $0x3ff, %edx jne L(einval) shrdl $12, %ecx, %edx /* mmap2 takes the offset in pages. */ shrl $12, %ecx But of course 0x3ff only tests 10 bits, not 12, so if bits 10 or 11 are set they will be silently dropped. This has been fixed in glibc-2.2. Another related problem is that even without this bug, mmap64 will always refuse to do an unaligned mmap, even if the kernel might have accepted it (with kernel 2.2.x for instance). Maybe the best solution would be to directly call the mmap syscall instead of mmap2 when mapping executables, this would fix both problems. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: virtual memory problems with Linux 2.4.5
by Alexandre Julliard 13 Jun '01

13 Jun '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > i have found a problem with Wine and the Linux 2.4.5 Kernel. > The Kernel no longer return EINVAL when offsets are not page > aligned... it simply does the mapping ignoring the lower bits of the > offset. This small patch fixes that problem. That's a glibc bug IMO. What version are you using? -- Alexandre Julliard julliard(a)winehq.com

3 5

Re: Re: virtual memory problems with Linux 2.4.5
by Mike McCormack 13 Jun '01

13 Jun '01

Hi Marcus, your patch produced a yes, BUT when i changed the offset value to 0x400, and it failed ... see new patch below. something strange is going on ... ;-) Mike >Could you please apply following check to configure.in, then do: > autoconf > rm config.cache > ./configure > >and check whether mmap64 detects as 'no' and check the output of config.log ? > >Ciao, Marcus > >Index: configure.in .. Index: configure.in =================================================================== RCS file: /home/wine/wine/configure.in,v retrieving revision 1.208 diff -u -r1.208 configure.in --- configure.in 2001/06/08 19:34:57 1.208 +++ configure.in 2001/06/13 01:28:16 @@ -538,6 +538,10 @@ ) { exit(1); } + if (-1!=mmap(0,2,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x400)){ + fprintf(stderr,"mapped at non aligned offset?\n"); + exit(2); + } close(fd); fprintf(stderr,"success!\n"); exit(0); ------------------------------------------ mailto:Mike_McCormack@looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

PNG or no PNG
by Igor Furlan 12 Jun '01

12 Jun '01

On Tue, 12 June 2001, Francois Gouget wrote: > Still, quite often I noticed that JPEG is not very good for screenshots: > - screenshots often have large uniform surfaces, e.g. title bar, window > background... JPEG tends to render these with weird dithering-like > patterns. > - it tends to blur fonts. I believe that's because fonts are basically > thin lines, which means high frequency, which is exactly what JPEG's > lossy compression removes. start using PNG format... it is supported by netscape 4.x, mozilla, opera... and yes, big surprise.. it is supported by redmond too Igor

1 0

Re: FYI: ControlSpy has stopped working
by Alexandre Julliard 12 Jun '01

12 Jun '01

520053692817-0001(a)t-online.de (Andreas Mohr) writes: > Well, this simply means there will be no "official" Wine release for some time > to come. > We have two possibilities: > 1. do major changes and debug until it's ready, then commit it > 2. do major changes, commit them and wait for the patches to arrive > > Obviously 2. means there will be *no* new official release before it's fixed > in its entirety (or at least only relatively "trivial" bugs remain). Well, not exactly; the release will be made once I no longer have any bug reports to work on. So if you feel the code is not ready for release, you better send me bug reports... So far the things I'm working on are: - ScrollWindow doesn't always get exposure events - client rect must be empty for zero size window - must create X window before WM_NCCREATE - hardware events priority order is messed up - ControlSpy refresh (?? needs more details) So if you see problems that are not listed here, you have to report them or they won't get fixed before the release. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Make ChooseFontW use ChooseFontA
by Alexandre Julliard 12 Jun '01

12 Jun '01

Ian Pilcher <ian.pilcher(a)home.com> writes: > ChooseFontW was not returning the iPointSize member, and possibly > others. This patch rewrites ChooseFontW to convert all its inputs to > ASCII, call ChooseFontA, and convert the outputs back to Unicode. It would be much better to make ChooseFontA call ChooseFontW instead; converting Unicode to ASCII must be avoided as much as possible. -- Alexandre Julliard julliard(a)winehq.com

2 1

OT: BSD License ?
by Bob 12 Jun '01

12 Jun '01

If Microsoft picked up some of the code in Wine , wouldn't they need to include the copyright , permissions notice, and the authors list? It looks like the license isn't clear as to where the Copyright needs to be displayed? Could anyone clear this up? Daniel Walker

3 4

Missing functionality in mmaux
by Florian Bauer 12 Jun '01

12 Jun '01

Hi, I tried to run Naturally Speaking, a speech recognition software under wine without a real windows installation. It installs just fine, but when I try to run it, it tries to adapt the audio settings. That fails, and I get the following fixme's from wine: fixme:mmaux:MIX_GetLineInfo Unhandled component type (00000007) fixme:mmaux:MIX_GetLineInfo Unhandled component type (00000008) I looked at the sources, and it seems that this is due to missing case clauses in the function MIX_GetLineInfo in mixer.c . Unfortunately, I don't know enough about C programming and the Windows and OSS API's involved to add the missing parts myself. Is it likely that this will be fixed soon? I would love to use NatSpeak under linux, because then I could delete my Windows 98 Partition... Anyway, keep up the good work regards Florian

4 3

Re:Missing functionality in mmaux
by Eric Pouech 12 Jun '01

12 Jun '01

> It installs just fine, but when I try to run it, it tries to adapt the audio > settings. That fails, and I get the following fixme's from wine: > > fixme:mmaux:MIX_GetLineInfo Unhandled component type (00000007) > fixme:mmaux:MIX_GetLineInfo Unhandled component type (00000008) it just misses the wavein component types as a quick fix, you can try to duplicate the case MIXERLINE_COMPONENTTYPE_MIC with MIXERLINE_COMPONENTTYPE_WAVEIN, but I'm not sure it'll fix all your issues, and let the program fully run. I'll have a closer look at it this week-end, if I have some time A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

1 0

Re: Re: virtual memory problems with Linux 2.4.5
by Mike McCormack 12 Jun '01

12 Jun '01

i'm using Suse linux 7.0 with the following files: /usr/lib/libg++-3-libc6.1-2-2.8.1.3.so /lib/libc.so.6 i've upgrade the kernel and various bits and pieces, but not the C libraries. i think there was a discussion about changes to the mmap interface on KT at some time... Mike Original message from: Alexandre Julliard <julliard(a)winehq.com> > >Mike McCormack <mike_mccormack(a)start.com.au> writes: > >> i have found a problem with Wine and the Linux 2.4.5 Kernel. >> The Kernel no longer return EINVAL when offsets are not page >> aligned... it simply does the mapping ignoring the lower bits of the >> offset. This small patch fixes that problem. > >That's a glibc bug IMO. What version are you using? > >-- >Alexandre Julliard >julliard(a)winehq.com >. > ------------------------------------------ mailto:Mike_McCormack@looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: winapi_extract and winapi_fixup
by Alexandre Julliard 12 Jun '01

12 Jun '01

Patrik Stridvall <ps(a)leissner.se> writes: > Here is some new tools that is and will be > more useful in the future. If anybody > wishes to test them they should consider > them prealpha. I'd prefer if you put everything inside the winapi_check directory. Having 4 different directories for such similar tools is a bit overkill IMO. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: FYI: ControlSpy has stopped working
by Guy L. Albertelli 12 Jun '01

12 Jun '01

-----Original Message----- From: Alexandre Julliard <julliard(a)winehq.com> To: andi(a)rhlx01.fht-esslingen.de <andi(a)rhlx01.fht-esslingen.de> Cc: Gerard Patel <gerard.patel(a)nerim.net>; Wine Devel <wine-devel(a)winehq.com> Date: Monday, June 11, 2001 4:52 PM Subject: Re: FYI: ControlSpy has stopped working >- ControlSpy refresh (?? needs more details) > The ControlSpy problem seems to be related to not repainting children windows of the rebar control. The attached traces show (+x11drv,+win,+rebar) for the 6/1 and 6/9 CVS. The 6/9 has submitted patch for zero client rect applied. If you want the full traces, let me know. Thanks, Guy Albertelli

1 0

Problems with GetFileVersionInfo[Size]()
by Malte.Starostik＠t-online.de 12 Jun '01

12 Jun '01

Hi, The Shockwave ActiveX control I'm loading tries to read the VERSIONINFO resource from my winelib app. AFAICS it subsequently crashes because that fails. Anyway, there seems to be a problem: char path[PATH_MAX]; GetModuleFileName(inst, path, sizeof(path)); kdDebug() << "GetModuleFileName: " << path << endl; DWORD dummy; kdDebug() << "GetFileVersionInfoSize: " << GetFileVersionInfoSize(path, &dummy) << endl; kdDebug() << "GetLastError: " << GetLastError() << endl; outputs activexproxy: GetModuleFileName: Y:\src\kde\build\kdenonbeta\activexproxy\proxy\activexproxy activexproxy: GetFileVersionInfoSize: 0 activexproxy: GetLastError: 0 which means it obviously doesn't find the resource. (btw, why is GetLastError() 0 here?) However, this code suceeds (inst is the HINSTANCE passed to WinMain()): HRSRC ver = FindResource(inst, MAKEINTRESOURCE(VS_VERSION_INFO), MAKEINTRESOURCE(VS_FILE_INFO)); kdDebug() << "FindResource: " << ver << endl; int size = SizeofResource(inst, ver); kdDebug() << "SizeofResource:" << size << endl; HGLOBAL mem = LoadResource(inst, ver); void *buf, *block = LockResource(mem); UINT len; VerQueryValue(block, "StringFileInfo\\040904b0\\FileDescription", &buf, &len); kdDebug() << "Description: " << reinterpret_cast<WCHAR *>(buf) << endl; FreeResource(mem); the output is: activexproxy: FindResource: 1078760168 activexproxy: SizeofResource:608 activexproxy: Description: ActiveX-Proxy for Konqueror So basically the code GetFileInfoVersion[Size]() use to load a library fail if the given path is the winelib app (the symlink to wine) itself :( Thanks, -Malte -- Wars don't determine who's right, only who's left.

1 0

New Application Database is ONLINE
by Jeremy Newman 11 Jun '01

11 Jun '01

Hey all! The 'shiny' new Wine Application Database is up and ready for your comments. We will be spending the rest of the day getting the initial category structure and 1st round off applications in. Once we have enough input, and we fell stable enough, I will link the AppDB to Winehq.com and post to wine-users. http://wine.codeweavers.com/appdb/ There is one sample app in so far so you can see what we mean. in: Main > Utilities > Compression > WinZip Use that as a guideline for how this is going to work. Go at it guys! -- _ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://jnewman.codeweavers.com | .` / -_) V V / ' \/ _` | ' \ -= mailto:jnewman@codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

1 0

New Application Database is ONLINE
by Jeremy Newman 11 Jun '01

11 Jun '01

Hey all! The 'shiny' new Wine Application Database is up and ready for your comments. We will be spending the rest of the day getting the initial category structure and 1st round off applications in. Once we have enough input, and we fell stable enough, I will link the AppDB to Winehq.com and post to wine-users. http://wine.codeweavers.com/appdb/ There is one sample app in so far so you can see what we mean. in: Main > Utilities > Compression > WinZip Use that as a guideline for how this is going to work. Go at it guys! -- _ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://jnewman.codeweavers.com | .` / -_) V V / ' \/ _` | ' \ -= mailto:jnewman@codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

1 0

wine binary loader problem - incorrect code at entry point
by Mike McCormack 11 Jun '01

11 Jun '01

Hi, Using the latest CVS, i'm trying to run the Adobe acrobat installer program (ar500enu.exe) and it crashes without doing anything at all. i have traced the problem to bad code at the program's entry point... which presumably means that the wrong piece of the program was mmapped into memory. i have run this program before using wine, (not recently though) and it has worked. Other programs (such as the netscape installer) at least start up and get going before crashing in a similar way. Mike from the debugger: 0x0040c110 (<Debugged process>.EntryPoint in <Debugged process>): decl 0x0(%edi) Using Sang Cho's disassembler i get: //******************** Program Entry Point ******** :0040C110 55 push ebp Disassembly of File: ./c/ar500enu.exe T.DateStamp = 351A66B8: Thu Mar 26 06:31:20 1998 Code Offset = 00000400, Code Size = 00010E00 Data Offset = 00011800, Data Size = 00003200 Number of Objects = 0005 (dec), Imagebase = 00400000h Object01: .text RVA: 00001000 Offset: 00000400 Size: 00010E00 Flags: 60000020 Object02: .rdata RVA: 00012000 Offset: 00011200 Size: 00000600 Flags: 40000040 Object03: .data RVA: 00013000 Offset: 00011800 Size: 00003200 Flags: C0000040 Object04: .idata RVA: 0001A000 Offset: 00014A00 Size: 00001000 Flags: C0000040 Object05: .rsrc RVA: 0001B000 Offset: 00015A00 Size: 0000A400 Flags: 40000040 and from the trace i get: trace:module:PE_LoadImage loading C:\ar500enu.exe trace:module:map_image mapped PE file at 0x400000-0x426000 trace:module:map_image mapping section .text at 0x401000 off 400 size 10e00 flags 60000020 trace:module:map_image mapping section .rdata at 0x412000 off 11200 size 600 flags 40000040 trace:module:map_image mapping section .data at 0x413000 off 11800 size 3200 flags c0000040 trace:module:map_image clearing 0x416200 - 0x417000 trace:module:map_image mapping section .idata at 0x41a000 off 14a00 size 1000 flags c0000040 trace:module:map_image mapping section .rsrc at 0x41b000 off 15a00 size a400 flags 40000040 trace:module:load_library loaded ntdll.dll 0x403512c4 40050000 ------------------------------------------ mailto:Mike_McCormack@looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

[Problem report] X11DRV_ScrollWindowEx
by Gerard Patel 11 Jun '01

11 Jun '01

This function hangs with the following apps (at least) - Notepad Win 3.11 - Notepad NT 4 - Eudora 1.5 In all cases, the problem appears when a text has several pages and I try to scroll toward the beginning of text. The problem disappears if I comment out the calls to X11DRV_StartGraphicsExposure and X11DRV_EndGraphicsExposure. The apps seem to work just as well. The hanging occurs because there is no X event generated in X11DRV_EndGraphicsExposure. I don't quite see why there should be one in this case. Gerard

1 0

FYI: ControlSpy has stopped working
by Guy L. Albertelli 10 Jun '01

10 Jun '01

Using the current CVS (6/9), certain ControlSpy modules (REBAR and COMBOBOXEX) no longer seem to work, even with the native versions of COMCTL32. The internal child windows in the left pane are no longer drawn. Seems to have occured sometime since 6/1. I will look into it tomorrow after some rest. Strange. Guy Albertelli <<galberte(a)neo.lrun.com>>

2 1

Re: FYI: ControlSpy has stopped working
by Gerard Patel 10 Jun '01

10 Jun '01

At 11:56 PM 09/06/2001 -0400, you wrote: >Using the current CVS (6/9), certain ControlSpy modules (REBAR and >COMBOBOXEX) no longer seem to work, even with the native versions of >COMCTL32. The internal child windows in the left pane are no longer drawn. >Seems to have occured sometime since 6/1. I will look into it tomorrow after >some rest. Strange. Strange ??? After this patch : ChangeSet ID: 991691718458116964902729 CVSROOT: /opt/cvs-commit Module name: wine Changes by: julliard@wine2. 01/06/04 17:55:18 (...) Log message: Create an X window for every window, including children. I see a lot of problems in most of my test apps after the implementation of this evil scheme. I have already sent several patches to work around some of these problems, two have been applied, one has been ignored so far, but even with this last Wine's status is beyond the usual breakage level. Gerard

2 1

Help needed
by Renukaprasad, MR 09 Jun '01

09 Jun '01

Hi, We are planning to port wine onto Tru64 Unix. I have some basic Questions. Can you tell me how to go about it. How do we start. How big is the task and how to start about it.. Thanks And Regards, Renuka

1 0

Re: VirtualProtect() fixup
by Alexandre Julliard 08 Jun '01

08 Jun '01

520053692817-0001(a)t-online.de (Andreas Mohr) writes: > (you do know that I disagree on these things, right ? after all Wine emulates > *Windows*, and if Windows does it that way, then we should do it, too, for > heaven's sake, especially if it's not really painful) There is no such thing as "Windows", there are multiple versions that do different things, and we have to choose what we emulate. In this case it's clear that it makes more sense to emulate the NT behavior, since this is what is documented. Of course we could do a winver check, but if we do this for every single difference between Win98 and NT, we'll end up with a mess of spaghetti code with more version checks than actual code. So winver checks must be limited to cases where they are demonstrably necessary for a real-world application. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: VirtualProtect() fixup
by Alexandre Julliard 08 Jun '01

08 Jun '01

520053692817-0001(a)t-online.de (Andreas Mohr) writes: > What isn't the case ? Both fixups ? Or only one of these ? The return value: NT returns a BOOL, 0 or 1. I haven't checked the old protection behavior; but anyway this doesn't belong in VirtualProtect, if we have to ignore the execute permission it must be done consistently throughout the code. > Well, to be exact, no application. > I just found this out by accident. That's what I suspected ;-) > IMHO the probability that some applications exist that are too lazy > to supply their own old_prot variable and that check the return value instead > is rather high, so I think that patch is necessary. We can't start breaking things based only on your suspicion that someone somewhere will have used a feature that isn't documented at all (plus there is a documented way of doing exactly the same thing). If you have an app that needs it sure, otherwise we'll just keep returning a BOOL, as the function is documented to do. > Maybe we should add a winver check, though. No thanks. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wcmd fix
by Francois Gouget 08 Jun '01

08 Jun '01

On Fri, 8 Jun 2001, Andreas Mohr wrote: > Hi all, > > file_size.XXXPart should be file_size.s.XXXPart. > > Thanks to Lasse Melsaeter for spotting this. That's the 'Dummy struct name problem in wcmd' I sent this morning. But actually whether there should an 's.' depends on the compiler (for Winelib applications) so you should test for NONAMELESSSTRUCT as I did in my patch. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

1 0

Re: VirtualProtect() fixup
by Alexandre Julliard 08 Jun '01

08 Jun '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > VirtualProtect had two big problems: > > - undocumented return value > - should return protection flags only instead of whole flag setting This isn't the case under NT. Which application depends on that? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Fwd: Re: WINE fix for HOMM3 [bluefire@zauberwald.net]
by Uwe Bonnes 07 Jun '01

07 Jun '01

>>>>> "BlueFire" == BlueFire <bluefire(a)zauberwald.net> writes: BlueFire> Now with the missing diff..... sorry... On Thu, 07 Jun 2001 BlueFire> 11:37:14 BlueFire wrote: >> This is messed up (totally unreadable) formatting. Anyway, how about >> doing a diff -u of your change, and then submitting that patch (in >> more readable form) either to Debian's BTS, or directly to >> wine-patches(a)winehq.com? BlueFire> Sorry, I'm not familiar with either diff or the debian BlueFire> bts. That's why I tried mailing the stuff to you (and to BlueFire> wine-patches). I did a BlueFire> diff /tmp/dos_fs.c dos_fs.c > dos_fs.c.diff Hallo, find some help at http://www.winehq.com/dev.shtml BlueFire> diff -u is preferred due to it's better readability. Appending the plain file makes it easier for others to read your patch. But don't " cut and paste", as that will ofter reformat and make the patch a pain to apply. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Question about the new window design
by Gerard Patel 07 Jun '01

07 Jun '01

Since the patch of 4 June, all windows are created as X windows. This makes one of my test apps to crash; it's creating a child window in the WM_NCCREATE event handling of a window. When the child window is created, X bombs because the X window parent does not exist yet - Wine is trying to call XCreateWindow with parent = 0. What is the best way of fixing this ? Gerard

1 0

Re: stack limit
by Alexandre Julliard 06 Jun '01

06 Jun '01

Stephen Crowley <stephenc(a)placemark.com> writes: > Works like a charm! Thanks. I'm curious though.. I set the stack size > to 64 megs and the application immediately uses up that much ram. Is > that the default behaviour on windows? What stops it from behaving > like a normal stack and just allocating what's needed from the heap? The ram isn't actually used, it's only reserved from the address space with an anonymous mapping. Only the pages that are really accessed will use physical memory/swap, so it doesn't use any more ram than a normal stack. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: stack limit
by Alexandre Julliard 06 Jun '01

06 Jun '01

Stephen Crowley <stephenc(a)placemark.com> writes: > On Mon, Jun 04, 2001 at 12:02:09PM -0700, Alexandre Julliard wrote: > > There is no way to do this at the moment; but it shouldn't be too hard > > to add support for a 'stack' statement in the application spec file. > > Thanks. Where would I look to change this in the source? I'm using some linear > regression DLLs under linux and we have to deal with some fairly large > matrices. Try this: Index: scheduler/process.c =================================================================== RCS file: /opt/cvs-commit/wine/scheduler/process.c,v retrieving revision 1.154 diff -u -r1.154 process.c --- scheduler/process.c 2001/06/06 20:24:13 1.154 +++ scheduler/process.c 2001/06/06 22:46:20 @@ -319,12 +319,6 @@ LPTHREAD_START_ROUTINE entry; WINE_MODREF *wm; - /* build command line */ - if (!ENV_BuildCommandLine( main_exe_argv )) goto error; - - /* create 32-bit module for main exe */ - if (!(current_process.module = BUILTIN32_LoadExeModule( current_process.module ))) goto error; - /* use original argv[0] as name for the main module */ if (!main_exe_name[0]) { @@ -498,7 +492,6 @@ { if (PE_HEADER(current_process.module)->FileHeader.Characteristics & IMAGE_FILE_DLL) ExitProcess( ERROR_BAD_EXE_FORMAT ); - stack_size = PE_HEADER(current_process.module)->OptionalHeader.SizeOfStackReserve; goto found; } @@ -512,6 +505,13 @@ _EnterWin16Lock(); found: + /* build command line */ + if (!ENV_BuildCommandLine( main_exe_argv )) goto error; + + /* create 32-bit module for main exe */ + if (!(current_process.module = BUILTIN32_LoadExeModule( current_process.module ))) goto error; + stack_size = PE_HEADER(current_process.module)->OptionalHeader.SizeOfStackReserve; + /* allocate main thread stack */ if (!THREAD_InitStack( NtCurrentTeb(), stack_size )) goto error; Index: tools/winebuild/README =================================================================== RCS file: /opt/cvs-commit/wine/tools/winebuild/README,v retrieving revision 1.4 diff -u -r1.4 README --- tools/winebuild/README 2000/12/26 01:22:34 1.4 +++ tools/winebuild/README 2001/06/06 22:46:21 @@ -6,6 +6,7 @@ [file WINFILENAME] [mode dll|cuiexe|guiexe|cuiexe_unicode|guiexe_unicode] [heap SIZE] +[stack SIZE] [init FUNCTION] [import [IMP_FLAGS] DLL] [rsrc RESFILE] @@ -39,6 +40,9 @@ "heap" is the size of the module local heap (only valid for Win16 modules); default is no local heap. + +"stack" is the stack size for Win32 exe modules, in kilobytes; default +size is 1024 (1Mb stack). "file" gives the name of the Windows file that is replaced by the builtin. <name>.DLL is assumed if none is given. (This is important Index: tools/winebuild/build.h =================================================================== RCS file: /opt/cvs-commit/wine/tools/winebuild/build.h,v retrieving revision 1.17 diff -u -r1.17 build.h --- tools/winebuild/build.h 2001/05/22 19:55:51 1.17 +++ tools/winebuild/build.h 2001/06/06 22:46:21 @@ -161,6 +161,7 @@ extern int DLLHeapSize; extern int UsePIC; extern int debugging; +extern int stack_size; extern int nb_debug_channels; extern int nb_lib_paths; Index: tools/winebuild/main.c =================================================================== RCS file: /opt/cvs-commit/wine/tools/winebuild/main.c,v retrieving revision 1.17 diff -u -r1.17 main.c --- tools/winebuild/main.c 2001/05/22 19:55:51 1.17 +++ tools/winebuild/main.c 2001/06/06 22:46:21 @@ -27,6 +27,7 @@ int Limit = 0; int DLLHeapSize = 0; int UsePIC = 0; +int stack_size = 0; int nb_entry_points = 0; int nb_names = 0; int nb_debug_channels = 0; Index: tools/winebuild/parser.c =================================================================== RCS file: /opt/cvs-commit/wine/tools/winebuild/parser.c,v retrieving revision 1.18 diff -u -r1.18 parser.c --- tools/winebuild/parser.c 2001/05/22 19:55:51 1.18 +++ tools/winebuild/parser.c 2001/06/06 22:46:21 @@ -559,6 +559,12 @@ if (!IsNumberString(token)) fatal_error( "Expected number after heap\n" ); DLLHeapSize = atoi(token); } + else if (strcmp(token, "stack") == 0) + { + token = GetToken(0); + if (!IsNumberString(token)) fatal_error( "Expected number after stack\n" ); + stack_size = atoi(token); + } else if (strcmp(token, "init") == 0) { if (SpecType == SPEC_WIN16) Index: tools/winebuild/spec32.c =================================================================== RCS file: /opt/cvs-commit/wine/tools/winebuild/spec32.c,v retrieving revision 1.28 diff -u -r1.28 spec32.c --- tools/winebuild/spec32.c 2001/05/22 19:55:51 1.28 +++ tools/winebuild/spec32.c 2001/06/06 22:46:21 @@ -656,7 +656,10 @@ fprintf( outfile, " %ld,\n", page_size ); /* SizeOfHeaders */ fprintf( outfile, " 0,\n" ); /* CheckSum */ fprintf( outfile, " 0x%04x,\n", subsystem ); /* Subsystem */ - fprintf( outfile, " 0, 0, 0, 0, 0, 0,\n" ); + fprintf( outfile, " 0,\n" ); /* DllCharacteristics */ + fprintf( outfile, " %d, 0,\n", stack_size*1024 ); /* SizeOfStackReserve/Commit */ + fprintf( outfile, " %d, 0,\n", DLLHeapSize*1024 );/* SizeOfHeapReserve/Commit */ + fprintf( outfile, " 0,\n" ); /* LoaderFlags */ fprintf( outfile, " %d,\n", IMAGE_NUMBEROF_DIRECTORY_ENTRIES ); /* NumberOfRvaAndSizes */ fprintf( outfile, " {\n" ); fprintf( outfile, " { %s, %d },\n", /* IMAGE_DIRECTORY_ENTRY_EXPORT */ -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Question about the new window design
by Alexandre Julliard 06 Jun '01

06 Jun '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > This makes one of my test apps to crash; it's creating a child window > in the WM_NCCREATE event handling of a window. When the > child window is created, X bombs because the X window parent > does not exist yet - Wine is trying to call XCreateWindow with > parent = 0. > > What is the best way of fixing this ? The X window should be created before the WM_NCCREATE. I'm planning to fix it, but it needs to correctly handle style changes happening in WM_NCCREATE (otherwise we get the managed tooltips bug), and this needs a bit more work. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: uname(1) on UnixWare (Solaris)
by Alexandre Julliard 06 Jun '01

06 Jun '01

Bang Jun-Young <bjy(a)mogua.org> writes: > I've nearly completed new DLL configuration code in configure.in. > Before making it available, I need to know what uname(1) command > prints out on UnixWare (and Solaris?). Why do you need that? Using uname(1) in a configure script is almost certainly the wrong thing to do. -- Alexandre Julliard julliard(a)winehq.com

4 9

Re: [PATCH] Flag unicode structure for user create window
by Uwe Bonnes 06 Jun '01

06 Jun '01

>>>>> "Gerard" == Gerard Patel <gerard.patel(a)nerim.net> writes: Gerard> In the CreateWindow user driver function, it is not enough to Gerard> test the window procedure to know if the cs structure is unicode Gerard> or not : the window can be subclassed, in the cbt hook, for Gerard> example. Gerard> ChangeLog: Hallo, yesterday I tried to find why the findfile95 dialog only displayed the first character ( "o" versus "open"). Your patch fixed it :-) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

RE: uname(1) on UnixWare (Solaris)
by Patrik Stridvall 06 Jun '01

06 Jun '01

> On Tue, Jun 05, 2001 at 12:18:00AM -0700, Francois Gouget wrote: > > On Tue, 5 Jun 2001, Bang Jun-Young wrote: > > > 1. Configure message is wrong: > > > checking whether we can build a Linux dll... yes > > > I see this even on FreeBSD and NetBSD. :( It's not a > Linux dll, > > > but an FreeBSD/NetBSD dll. > > > > Maybe this message should be changed, yes. But I don't think you > > should put a `uname` there. > > Could you explain me a bit further why we shouldn't do that? As far as the question above is concerned see Francois's reply. I fully agree with him. However regardless of this, uname shouldn't be used (at least not directly). Autoconf provides a standard way to do this (which BTW happends to use uname). It can be used as below. AC_CANONICAL_HOST case $host_os in *cygwin* ) CYGWIN=yes;; * ) CYGWIN=no;; esac It requires two files config.sub and config.guess be distribute along with Wine but that is not really a problem. Perhaps we need to do this anyway. Autoconf 2.50 has discontinued AC_CYGWIN so CYGWIN support seems to require it regardless. Actually the code above is how this is done with Autoconf 2.50. However making CYGWIN an exception is one thing, doing it in other cases is quite another thing. IMHO you will need to provide a _really_ convincing argument that we should make another exception assuming of course we make the first one for CYGWIN which we haven't done yet either.

2 1

RE: uname(1) on UnixWare (Solaris)
by Patrik Stridvall 06 Jun '01

06 Jun '01

> On Tue, Jun 05, 2001 at 11:51:19PM -0700, Francois Gouget wrote: > > Maybe it was not your intention but I was afraid that we > would end up > > with something like: > > "checking whether we can build a `uname` dll..." > > and then a few lines down: > > "checking whether we can build a `uname` dll..." > > > > The problem is then you don't know exactly where the > message comes > > from. > > Sorry but I don't catch what you mean quite well. It's obvious which > message is printed on the screen, isn't it? Yes, but this means that the text no longer describes what it is trying to check. If somebody runs it on a OS called Foo it might trick the him/her into thinking that we know about and have added special handling for OS Foo, which we haven't. > What do you think about replacing "Linux dll" with "GNU style > ELF dll"? Acceptable, but it is not my decision.

1 0

Is this a bug?
by Ian Pilcher 06 Jun '01

06 Jun '01

While poking around in gdi.h, I came upon the following: static inline INT WINE_UNUSED INTERNAL_XWSTODS(DC *dc, INT width) { FLOAT floatWidth; /* Perform operation with floating point */ floatWidth = (FLOAT)width; INTERNAL_XWSTODS_FLOAT(dc, &floatWidth); /* Round to integers */ return GDI_ROUND(floatWidth); } ... and a little later ... static inline INT WINE_UNUSED INTERNAL_YWSTODS(DC *dc, INT height) { FLOAT floatHeight; /* Perform operation with floating point */ floatHeight = (FLOAT)height; INTERNAL_XWSTODS_FLOAT(dc, &floatHeight); /* Round to integers */ return GDI_ROUND(floatHeight); } Shouldn't one of these (probably INTERNAL_YWSTODS) be calling INTERNAL_YWSTODS_FLOAT instead of INTERNAL_XWSTODS_FLOAT? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

2 1

Re: PATCH: set_thread_buffer fixed
by Gerard Patel 05 Jun '01

05 Jun '01

At 10:43 AM 05/06/2001 +0200, you wrote: >> This calls fails because glibc detects that the value at (esp+28) >> is different of 0 - the real system call is never done, with your >> test app and Wine. > >Well, note that the second version is only pushing a 32bit offset, so >mmap64 accesses random stack space! Yes :-/ <snip> >Yes, check the sys/mman.h header, it should have __off64_t as argument >to the mmap ... asm("mmap64") not __off_t. Yes, it is __off_t and that is the problem; but how this header has come to be in this state is part of what I don't understand. It's marked as part of the glibc, but there is nothing like it in the glibc source that I used to compile. The mman.h in my glibc source is much shorter and the declaration of mmap64 seems correct. I guess that the file in my /usr/include/sys/mman.h is a generated file. I don't even want to count the number of 'mman.h' files on my system :-/ >So I think I can use this test program as check for mmap64 brokeness... Btw, the reference on large files http://www.suse.de/~aj/linux_lfs.html says that locking will never be supported on 64 bits files with glibc 2.1.3 so I don't see why it's necessary to support this case. Gerard

1 0

RE: Stanford Checker
by Patrik Stridvall 05 Jun '01

05 Jun '01

> On Tue, 5 Jun 2001 David.Goodenough(a)dga.co.uk wrote: > > but has anyone thought of running these against Wine? > > I'm not sure if it'd do that much good. They're currently working on > checking the XFree86 tree (see the Xpert mailing list archives on > www.XFree86.org if you want), without a lot of big results > yet. From what > I gather, this tool has very limited and context-dependent > intelligence, Perhaps. But see below. > and is not conceptually very different from what a glorified > version of > Patrik's tools/winapi_check script might be, if given enough people > working on it. Not quite. winapi_check is 1. Specifically written for Wine 2. A syntax analyzer 3. Mostly ad hoc. The Stanford checker on the other hand is 1. Generalized for all C/C++ applications 2. A semantic analyzer 3. Formalized with a script language The way I choose when designing winapi_check was the one of the easiest ways and the way they choose is one of the hardest. So just calling it is glorified winapi_check gives the Stanford people too little credit. Anyway the way Stanford choose is really _very_ hard so what I fear is that they had to make some limiting decisions that makes their tool much less useful. That said regardless of how good the Stanford checker really will be I'm pretty there will be a lot of things that will be _much_ easier checked by writting a script for the Stanford checker than by extending winapi_check, because they have fundamentally different design philosofies. However don't underestimate winapi_check either. There is a lot of things that can quite easilt be checked by adding some clever perl pattern, if:s and a little state. Syntax level matching is not that bad just a little more crude. If somebody have something that he want to be automatically checked, please post it on the list and I will see what I can do.

1 0

Stanford Checker
by David.Goodenough＠dga.co.uk 05 Jun '01

05 Jun '01

On the kernel list and in Alan Cox's patches for the kernel there are a lot of references to some logic checking tools being generated by Stanford. I do not know if these are generally available but has anyone thought of running these against Wine?

2 1

RE: Stanford Checker
by Patrik Stridvall 05 Jun '01

05 Jun '01

> Maybe we have to ask them to check our code, rather than the other way > around? I think it far to much to ask. As Eric said, while it is AFAIK highly configurable with specific scripts, for each kind of check it is currently seems to be very much focused on the Linux kernel. I also believe, like Eric, that it is currently very buggy and that even if they have a powerful enough scripting language to be usable for Wine it will probably need some serious debugging to make the scripts we need to actually work in practise not only in theory. No, as I said, I think it is to much to ask. We will have to wait until they release it whenever that will be.

1 0

Re:Stanford Checker
by Eric Pouech 05 Jun '01

05 Jun '01

last time I checked (a month ago), the tool wasn't freely available (nor finished), so nothing can be done for now when the tool is finished (<put here your date estimation>), one could be able to configure the tool for use in Wine (read: write the scripts for the things we want to check, like windows locks...) but, the tool is (as of today) configured for Linux, and check can only be done agains the Linux tree (AFAIU, they check for specific constructs like getting a spin lock, enabling / disabling IRQ... so highly dependent on Linux source...) however, I don't know (yet) the power of the script language they use for configuring, and whether it could be used for Wine... you'll have to wait until the tool is released... (I suspect, the tool is still buggy *AND* still requires lots of processing by hand - you get a 100 warnings from where only a few are real issues). A+ > On the kernel list and in Alan Cox's patches for the kernel there are a lot > of references to some logic checking tools being generated by Stanford. I > do not know if these are generally available but has anyone thought of > running these against Wine? --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

1 0

RE: Stanford Checker
by David.Goodenough＠dga.co.uk 05 Jun '01

05 Jun '01

Maybe we have to ask them to check our code, rather than the other way around? Patrik Stridvall <ps(a)leissner.se> on 05-06-2001 12:31:25 PM To: David Goodenough/DGA/GB cc: wine-devel(a)winehq.com Subject: RE: Stanford Checker [Forgot to include list. Trying again.] > On the kernel list and in Alan Cox's patches for the kernel > there are a lot > of references to some logic checking tools being generated by > Stanford. I > do not know if these are generally available but has anyone thought of > running these against Wine? Yes, I have. However the problem is that it is not publicly available (yet) and I read somewhere (don't remember where) that it is no use trying to get copy even if you promise not to distribute it further. I will probably look into it when it is released. I have no idea when that will be though.

1 0

RE: Stanford Checker
by Patrik Stridvall 05 Jun '01

05 Jun '01

[Forgot to include list. Trying again.] > On the kernel list and in Alan Cox's patches for the kernel > there are a lot > of references to some logic checking tools being generated by > Stanford. I > do not know if these are generally available but has anyone thought of > running these against Wine? Yes, I have. However the problem is that it is not publicly available (yet) and I read somewhere (don't remember where) that it is no use trying to get copy even if you promise not to distribute it further. I will probably look into it when it is released. I have no idea when that will be though.

1 0

CVS compilation problem: XvSelectNotify
by Heiko Nardmann 05 Jun '01

05 Jun '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just compiled CVS wine using ./configure --prefix=/opt/wine-20010605 --enable-dll --with-x and get the following error message starting Word: err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /opt/wine-20010510/lib/libwine_tsx11.so: undefined symbol: XvSelectPortNotify Could not load graphics driver 'x11drv' - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de), Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7HJ2Opm53PRScYygRAkZsAKCXRyt3ncR7sFRNatc7/6Bls3+eywCg9sO5 7oombEYBU9llG4o8Gp7LeyA= =a8Qa -----END PGP SIGNATURE-----

1 0

Re: PATCH: set_thread_buffer fixed
by Gerard Patel 05 Jun '01

05 Jun '01

At 07:20 AM 05/06/2001 +0200, you wrote: >Not really, as Alexandre said. > >Could you please test the attached small test program? It fails (of course). Here is the call with my working computer (glibc2.2, linux 2.4) 0x8048668 <main+72>: call 0x8048464 <write> 0x804866d <main+77>: add $0xc,%esp 0x8048670 <main+80>: push $0x0 0x8048672 <main+82>: push $0x0 0x8048674 <main+84>: push %ebx 0x8048675 <main+85>: push $0x1 0x8048677 <main+87>: push $0x3 0x8048679 <main+89>: push $0x4 0x804867b <main+91>: push $0x0 0x804867d <main+93>: call 0x80484a4 <mmap64>p For the failing one : 0x80486c8 <main+72>: call 0x80484dc <write> 0x80486cd <main+77>: addl $0x20,%esp 0x80486d0 <main+80>: addl $0xfffffff8,%esp 0x80486d3 <main+83>: pushl $0x0 0x80486d5 <main+85>: pushl %ebx 0x80486d6 <main+86>: pushl $0x1 0x80486d8 <main+88>: pushl $0x3 0x80486da <main+90>: pushl $0x4 0x80486dc <main+92>: pushl $0x0 0x80486de <main+94>: call 0x804851c <mmap64> This calls fails because glibc detects that the value at (esp+28) is different of 0 - the real system call is never done, with your test app and Wine. In the glibc 2.1.3 source, this test is not explained; in the 2.2.2 source, there is a comment saying that the offset is 'too large'. I understand that the app is calling mmap64 on an operating system that is not supporting it (it's perfectly correct in this case, the failing box having 2.2.5 kernel), and glibc tests if the call can be mapped to standard mmap. I think that the problem is in the compilation; pushing only 6 dwords on the stack to call mmap64 is wrong. I have not yet figured out why, though (I have never been any good with C header problems) Gerard

2 1

Re: PATCH: set_thread_buffer fixed
by Gerard Patel 05 Jun '01

05 Jun '01

At 08:12 AM 03/06/2001 +0200, you wrote: >> After applying your patch to current cvs, rm config.cache, ./configure, >> make depend && make Wine crashes as before. > >You need to run 'autoheader -l include' if any change to acconfig.h >is submitted. Thanks, it worked. Problem solved IMO. Gerard

1 0

mIRC crash when processing large files.
by rpbrown＠xtra.co.nz 05 Jun '01

05 Jun '01

Details how to replicate the crash. (yes its time consuming, but it shows the crash) Ok, this is what I do to crash mIRC in wine. I install the mp3-script for mIRC. http://welcome.to/autoget load the script according to the readme..and join IRC Undernet, any Undernet server will do. /join #mpthree the person we're looking for is SuperServ (an Op) right mouse on the nick, and grab there mp3 list.. you can try other ppls lists, but SuperServ has a rather big list (8Mb) which at the end of the download the script keeps on loading (processing the txt file) ..and then crashes mIRC. Loading _this_ list itself into mIRC under windows normally, mIRC is locked for a 3-4 minutes (processing the list).. maybe wine gives up too soon, since its not getting a response within X amount of time. Or the list is too big for wine to handle? thats my guesses.. I hope this helps. -mdew

1 0

uname(1) on UnixWare (Solaris)
by Bang Jun-Young 05 Jun '01

05 Jun '01

Hi, I've nearly completed new DLL configuration code in configure.in. Before making it available, I need to know what uname(1) command prints out on UnixWare (and Solaris?). As in NetBSD, it's: $ uname NetBSD I guess it would be $ uname UnixWare on UnixWare. I also wonder if UnixWare and Solaris refer to the same. Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

1 0

Re: FreeType autoconf checks
by Alexandre Julliard 05 Jun '01

05 Jun '01

Ian Pilcher <ian.pilcher(a)home.com> writes: > CPPFLAGS works. Where the heck is that documented? (I can't find it in > the info pages for gcc or cpp.) It's not a gcc option, it's a configure internal variable (from $ac_cpp definition). This is the whole point: it will work independently of the compiler, or at least break the same way during configure and during the compile, which is what we want. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: set_thread_buffer fixed
by lawson_whitney＠juno.com 05 Jun '01

05 Jun '01

On Sun, 3 Jun 2001, Marcus Meissner wrote: > Is this the case where set_thread_buffer fails or not? > Okay, it is not. It crashes in debug_printf or dump_exports (pe_image.c). However, it is so too a glibc-2.1.3 problem. I think. Sort of. The same Wine that crashes with kernel 2.4.4 and 2.4.5 works fine with kernel 2.2.14, and I bet later 2.2.x kernels when (if) I get around to building them. I think I might not be smart enough to debug it in detail. Maybe I should just send www4mail after glibc-2.2 instead. > I don't see a failure message here. > > Also, could you try to run the attached test program and see if it fails? success with either kernel version. Hmmm, do I have 2.0.30 still lying around? 1.3.18? > > Ciao, Marcus > Lawson Constants aren't, and variables won't. ---cut--- ________________________________________________________________ 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: FreeType autoconf checks
by Alexandre Julliard 04 Jun '01

04 Jun '01

Ian Pilcher <ian.pilcher(a)home.com> writes: > One thing to keep in mind, however. The FreeType headers themselves > use relative paths to include one another, so this is an issue that > we're not going to be able to completely eliminate. This is why I > had to mess around with the C_INCLUDE_PATH variable; AC_CHECK_HEADER > tries to preprocess the header file, so it has to be able to find any > subsidiary headers. (Is this what you mean by finding a way to check > that #include <freetype/freetype.h> works?) Yes; we should be using only relative paths in AC_CHECK_HEADER, since this is what we will use in the code. I don't think C_INCLUDE_PATH is portable either. Did you try setting CPPFLAGS instead? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: FreeType autoconf checks
by Ian Pilcher 04 Jun '01

04 Jun '01

Alexandre Julliard wrote: > > Well, I don't like it much, but I haven't had time to look into a > better solution yet. Basically I think it's dangerous to check for the > file name with an absolute path and then include it with a relative > path, since there is no guarantee we'll get the same file. I think we > should really find a way to check that #include <freetype/freetype.h> > works given the right C flags. Also I'm not sure about the portability > of the ${FREETYPEINCL#-I} construct. > I see your point. Now that I think about it, I probably would have been bitten by it if anyone will. I run Red Hat 7.1 which has: /usr/include/freetype/freetype.h (from FreeType 1.x) /usr/include/freetype2/freetype/freetype.h (from FreeType 2.x) I just checked the gcc documentation, and directories specified with '-I' options on the command line are checked first. I have no idea, however, if other compilers behave in a similar manner. Using absolute paths for the FreeType headers would be non-trivial, but probably doable. We would have to use autoconf to define macros that include the complete path name of the headers we want to include; then #include those macros instead of the file names. Somehow, I don't think you're going to want to do that. One thing to keep in mind, however. The FreeType headers themselves use relative paths to include one another, so this is an issue that we're not going to be able to completely eliminate. This is why I had to mess around with the C_INCLUDE_PATH variable; AC_CHECK_HEADER tries to preprocess the header file, so it has to be able to find any subsidiary headers. (Is this what you mean by finding a way to check that #include <freetype/freetype.h> works?) I also had the same thought about the ${FREETYPEINCL#-I} construct. According to http://www.opengroup.org/onlinepubs/7908799/xcu/chap2.html#tag_001_006_002 it seems to be OK. Frankly, I share your distaste for this whole mess. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

Re: fixup bogus SetLastError()
by Alexandre Julliard 04 Jun '01

04 Jun '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > objects/gdiobj.c really has no business dealing with SetLastError(). > SetLastError() is a mechanism to communicate errors to external programs, > so it should definitely not be used for highly internal functions. You didn't include the gdiobj.c patch, but I disagree with it anyway... There can be many good reasons for setting last error in internal functions; for instance setting it inside GDI_GetObjPtr avoids having to set it in every single caller. And in the very rare case where this is not what we want, the caller can always set it to another value. -- Alexandre Julliard julliard(a)winehq.com

3 2

stack limit
by Stephen Crowley 04 Jun '01

04 Jun '01

What is the correct way to increase the default stack size for winelib applications? Also, are there any drawbacks to making the value fairly large? -- Stephen Crowley Software Engineer Placemark Investments 972.404.8100 x28

2 1

Re: stack limit
by Alexandre Julliard 04 Jun '01

04 Jun '01

Stephen Crowley <stephenc(a)placemark.com> writes: > What is the proper way to increase the stack size for winelib > applications? There seems to be a limit of around 2^20 bytes right now. There is no way to do this at the moment; but it shouldn't be too hard to add support for a 'stack' statement in the application spec file. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: fixup bogus SetLastError()
by Alexandre Julliard 04 Jun '01

04 Jun '01

520053692817-0001(a)t-online.de (Andreas Mohr) writes: > Now that's where I disagree ! > The caller can *not* always set it to another value. > If it does and the program intends to read the LastError of a *previously* > executed API that failed, then the LastError will be reset even though > it shouldn't have been ! Then the caller needs to save/restore it across the GDI_GetObjPtr call. That's trivial to do. > In short: the SetLastError behaviour needs to match Windows behaviour very, > very closely. Definitely; but it's not clear to me that not setting last error is anywhere closer to Windows than setting it to INVALID_HANDLE. GDI_GetObjPtr should do what most callers need, and IMO this means setting it. I may be wrong, I haven't checked the error returns of all GDI functions (and of course this is nowhere documented). > This would be SelectObject() in this case, BTW. Which case? Do you have evidence that a SelectObject() with an invalid handle must not set last error? If so then of course it needs fixing. -- Alexandre Julliard julliard(a)winehq.com

2 1

stack limit
by Stephen Crowley 04 Jun '01

04 Jun '01

What is the proper way to increase the stack size for winelib applications? There seems to be a limit of around 2^20 bytes right now. -- Stephen Crowley Software Engineer Placemark Investments 972.404.8100 x28

1 0

tan not exported by msvcrt, ntdll
by Francois Gouget 04 Jun '01

04 Jun '01

I tried compiling Winelib applications without '-lm' (btw, the comment in configure.in is incorrect, it concerns Linux too, not just BeOS). But I had undefined symbol errors for applications that use tan and a couple other math functions. The reason is that both ntdll and msvcrt declare them with '-noimport': * msvcrt.spec: @ forward -noimport tan ntdll.tan * ntdll.spec: @ cdecl -noimport tan(double) tan So a Winelib application that imports msvcrt and ntdll does not get tan and thus must link with libm in the Unix sense. sin, cos and most others were ok though! Changelog: * dlls/msvcrt/msvcrt.spec Remove some '-noimport' for math functions -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

1 0

AnimateWindow() calls SetWindowPos() on a timer???
by Bobby Bingham 04 Jun '01

04 Jun '01

Forgot a detail ... Every time it send the messages it tells it not to move, size, redraw, activate, or change z-order. I could see the reason for these if if didn't tell it not to do anything, but ... ?? Bobby Bingham uhmmmm(a)ameritech.net

1 0

AnimateWindow() calls SetWindowPos() on a timer???
by Bobby Bingham 04 Jun '01

04 Jun '01

I am implementing AnimateWindow(), and I recorded all the messages win98 sent to my window when I called AnimateWindow(). It send a lot of groups of WM_WINDOWPOSCHANGING, WM_NCCALCSIZE, and WM_WINDOWPOSCHANGED. The number of times it sends these seems to correspond to how long I tell it to make the animation, almost as if it were on a timer. It looks like it calls SetWindowPos() on the window a lot, but I don't see why they would do this. Does anyone know?? I can supply my test app once I clean it up a little. Bobby Bingham uhmmmm(a)ameritech.net

1 0

off topic: Windows 98 and binutils
by Brian Craft 03 Jun '01

03 Jun '01

Hey -- Sorry for the OT post, but I suspect someone here will know the answer to this. I'm trying to objdump some Windows 98 device drivers & dlls. Last time I did something like this it was user-mode code from 95 or NT (not sure which), and I just configured binutils for i386-pe. Only this same configuration won't read the Windows 98 files -- it says the file format isn't recognised. I can still read the old Windows binaries with this config. I also tried i386-msdos, for good measure. What's the scoop? 98 has a new format? Is there a binutils target that will do the job? b.c.

2 1

Re: PATCH: set_thread_buffer fixed
by Gerard Patel 03 Jun '01

03 Jun '01

At 07:19 PM 02/06/2001 +0200, you wrote: <snip> >I have now changed config.h to only enable 64bit support for glibc 2.2 >or better. After applying your patch to current cvs, rm config.cache, ./configure, make depend && make Wine crashes as before. Did you leave something to for Alexandre Julliard implicit (he certainly knows about this stuff, I don't) ? I don't understand why _FILE_OFFSET_BITS is still defined in config.h.in. Gerard

3 2

Re: PATCH: set_thread_buffer fixed
by Alexandre Julliard 03 Jun '01

03 Jun '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > Enable 64bit file operations on Linux only for glibc 2.2 or better, > since mmap64 is broken on glibc 2.1. It would be much better to do a configure check. Including features.h from config.h is very ugly IMO (not to mention that mmap64 seems to work fine on my glibc 2.1.3...) -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: PATCH: set_thread_buffer fixed
by Ove Kaaven 03 Jun '01

03 Jun '01

On Sat, 2 Jun 2001, Marcus Meissner wrote: > -/* This is for glibc on Linux, it will turn on 64 bit file support at compile time */ > -#define _FILE_OFFSET_BITS 64 > +#include <features.h> > +/* This is for glibc on Linux, it will turn on 64 bit file support at > + * compile time > + * Since glibc 2.1.x has various degrees of broken mmap64 prototypes, > + * we do not use this on glibc 2.1.x systems. > + */ > +#if (__GLIBC__ >= 2) && (__GLIBC_MINOR__ > 1) > +# define _FILE_OFFSET_BITS 64 > +#endif > + That's probably not going to work. The features.h is the only header that checks whether _FILE_OFFSET_BITS is defined, and it's protected against multiple inclusion, so _FILE_OFFSET_BITS must be defined *before* you include features.h. If you must check version, use autoconf.

1 0

Re: set_thread_buffer (fwd)
by lawson_whitney＠juno.com 02 Jun '01

02 Jun '01

This seems to have bounced once. Hope winehq feels better soon. On Fri, 1 Jun 2001 =?iso-8859-1?Q?G=E9rard_Patel_=3Cgerard.patel=40nerim.net=3E?=(a)tourian.nerim.net wrote: > Just what I have. > > if you verify if you have the same problem as myself, with current cvs > remove the line defining _FILE_OFFSET_BITS. This fixes it for me. > > Gerard > By this I understood to rip #define _FILE_OFFSET_BITS 64 out of config.h (and acconfig.h just to be sure) and rerun make. It recompiles nearly everything, of course, and makes a wine that will run my app again, so I guess it is the same problem. Now, what is the problem? :-/ glibc-2.1.3 - from Mandrake 7.2 - ?? - I am fairly sure I haven't munged any headers myself.. but Mandrake might have. Are <linux/ and <asm/ considered glibc headers? I don't see them in the rpm, but some motorist broke both my legs a while ago and it is too tough to change the CD and see what is in Slackware's glibc-2.1.2. I guess that wouldn't be conclusive anyway. gcc-2.95.2 locally built, with genuine strength-reduce bug. kernel 2.4.4 with devfs? Other? Feels to me like an inconsistancy between headers and library -? Lawson ---cut--- ________________________________________________________________ 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:AnimateWindow() constants?
by Eric Pouech 02 Jun '01

02 Jun '01

> I am about to implement the AnimateWindow() function, but I don't have up to > date windows headers. I did some trial and error on a win98 box and came up > with what I think are the correct values, but could somebody check? all correct A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

1 0

wine-users down?
by Francois Gouget 02 Jun '01

02 Jun '01

Hi, I didn't receive any message on wine-users since May 30th. Is the mailing list down or is it a problem on my end? There's been many messages since then on the newsgroup. Btw, why is the link to the wine-users archive disabled on WineHQ? (http://www.winehq.com/dev.shtml#ml) I found wine-users archives via Google: http://www.winehq.com/hypermail/wine-users/ And I see in the mailing list archives that there's no message since May 30th either. Looks like a mailing list problem to me... Last question (for this email...): Why do the mailing list archives point to the Integrita archives rather than the WineHQ archives? Is there an advantage of one over the other? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

2 1

AnimateWindow() constants?
by Bobby Bingham 02 Jun '01

02 Jun '01

I am about to implement the AnimateWindow() function, but I don't have up to date windows headers. I did some trial and error on a win98 box and came up with what I think are the correct values, but could somebody check? AW_SLIDE 0x00040000 AW_ACTIVATE 0x00020000 AW_BLEND 0x00080000 AW_HIDE 0x00010000 AW_CENTER 0x00000010 AW_HOR_POSITIVE 0x00000001 AW_HOR_NEGATIVE 0x00000002 AW_VER_POSITIVE 0x00000004 AW_VER_NEGATIVE 0x00000008 I'm pretty sure about all of them except AW_BLEND because win98 doesn't implement it. Thanks in advance Bobby Bingham uhmmmm(a)ameritech.net

1 0

Finding (or not) the exact number of args
by Gaël de Chalendar 01 Jun '01

01 Jun '01

Hi, I'm trying to implement stubs for some missing ordinal functions in shlwapi. Reading the NOTES comment in dlls/shlwapi/ordinal.c I don't know if it is a good idea, but it allows explorer.exe (Win 98) to show its desktop and it is what I'm testing (just for fun. I do not hope to be able to use it right now). Anyway, it uses at a moment or another unimplemented ordinal functions. To implement their stubs, I begins with a lot of args, reducing this number until the function is passed. It seems to work but I wonder if I do not add only problems with this strategy. If I left the stack in a corrupted state, maybe the problem will become visible a lot later... I was not able to find in docs, mails archives or google groups any useful tip to find (simply) the right number of args. Particularly, the URL http://www.ece.cmu.edu/afs/ece/usr/dacut/www/src is dead. So, do I continue ? If yes, in this way or differently ? Thanks for your advices. Gael. PS: I will not read my mail until monday 28.

3 4

Re: critical section blocking
by Duane Clark 01 Jun '01

01 Jun '01

Aric Stewart wrote: > > Working with QuickTime5 I found a situation where mouse messages could > lockup wine. This leaving and entering the critical section resolves > that bug. > > -aric > > ------------------------------------------------------------------------ > Index: windows/message.c > =================================================================== > RCS file: /home/wine/wine/windows/message.c,v With this patch, Myst locks up solid as soon as the mouse is moved into the Myst window. Without it, Myst works fine. Duane

3 2

Can MAPI be directed to sendmail from a Windows app on Wine ?
by Steve Ball 01 Jun '01

01 Jun '01

I am running a windows voicemail server under wine and it runs extremely well, but I believe there is no MAPI support in Wine, and the voicemail server complains that there is no MAPI provider. I would not want to install a Windows email client even if I thought I could use MAPI, and would much prefer to use sendmail as the MAPI sender. I don't think it would be difficult to write code that would produce a sendmail mail message from a Wine stub, but I cannot find where the MAPI support goes and I know very little about MAPI under Windows, since I have done very little Windows programming. Has anyone done this before, or could anyone direct me to the hooks in Wine, and preferably some information on how MAPI works in Windows apps. The Wine project is a fantastic achievement, I hope that I can give something back. Steve Ball

1 0

Re: wineps include fix.
by Ian Pilcher 01 Jun '01

01 Jun '01

David Hammerton wrote: > > hi, seems you have done some updating on it.. but now it still doesnt compile, > im not sure if your trying to include something that is defined elsewhere or > you made a typo, but it seems to bawk on: > > gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -g -O2 > -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT > -I/usr/X11R6/include -o truetype.o truetype.c > truetype.c:13: `#include' expects "FILENAME" or <FILENAME> > truetype.c:14: `#include' expects "FILENAME" or <FILENAME> > I give up. You're getting the error because FreeType's macros are not being defined by your include files. This is supposed to be the way to work around the fact that the FreeType guys rename their include files with every minor release. freetype/freetype.h should either define the macros or include another file that does so. If you can figure out why that isn't happening, let me know. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

5 9

Re: WINE server messages
by Alexandre Julliard 01 Jun '01

01 Jun '01

David Howells <dhowells(a)redhat.com> writes: > Actually, I see that you do maintain a view list in the client as well as the > module list and section lists in the server. What I was thinking of was just > consolidating the three into a single view list and a single section list in > the server. > > In effect, Wine'd still have the module list, it's just that there'd be > non-modules in the list too. I still don't see why you want that. The fact that the section list is in the client or in the server is orthogonal to the fact that we maintain a list of modules. If you have a list of mapped views in the server you can simplify the module list a bit by making each module point to the view instead of the backing file, but you still need a module list to send debugger events and do toolhelp snapshots. You could of course hide the module list inside the section list by adding some magic flags to the section descriptor, but all it changes is that you then need to walk the whole section list to retrieve the modules; I don't really see the point. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: set_thread_buffer
by Marcus Meissner 31 May '01

31 May '01

On Thu, May 31, 2001 at 01:12:14PM -0400, =?iso-8859-1?Q?G=E9rard_Patel_=3Cgerard.patel=40nerim.net=3E?=(a)tourian.nerim.net wrote: > At 01:24 30/05/2001 +0200, you wrote: > (yet another self followup) > > >Since the commits of last night, every app I have tried only says : > > > >wine client error:0x80675a8: set_thread_buffer failed with status c000000d Hmm, can you do 'nm file/file.o|grep stat64' and see if we are including stat64 there? > >with apps that usually work fine. > I have still the problem; I have downloaded a fresh tree from winehq > to make sure it was not a random event. > > I don't have much time to debug until next weekend, but I have done > a bit of searching : this does not happen on my newest computer, a > Mandrake 8 with glibc 2.2. It happens with my other box, a Suse 6.1 > with a manually upgraded glibc 2.1.3 (I use it without this problem since > months) > > The problem occurs in the mmap call in the server subroutine, the parameters > being > size=8192, fd=8,offset=0. > > Has anyone compiled cvs since 3 days with glibc 2.1.3 ? I have build RPMs for OpenLinux eDesktop 2.4, which is kernel 2.2.14 and glibc 2.1.3, and sol.exe still works. You can try them from http://www.lst.de/~mm/wine.html if you want to. Ciao, Marcus

2 1

Re: set_errno patch
by Alexandre Julliard 31 May '01

31 May '01

Francois Gouget <fgouget(a)free.fr> writes: > MSVCRT__set_errno should be able to set errno to 0. It's called at > least once explicitly with 0 in dir.c, but many other times it is > called with a GetLastError() that may return 0. I don't think it is ever correct to set errno to 0. Code that does that should be fixed to provide a valid error code instead. -- Alexandre Julliard julliard(a)winehq.com

1 0

FreeType autoconf checks - please test
by Ian Pilcher 31 May '01

31 May '01

This works on my system (Red Hat 7.1 with FreeType 2.0.1). Please try it on other variants and let me know if it works. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ======================================================================== diff -urN ../wine-20010529cvs/configure.in ./configure.in --- ../wine-20010529cvs/configure.in Thu May 31 09:16:57 2001 +++ ./configure.in Thu May 31 09:19:41 2001 @@ -402,8 +402,21 @@ wine_cv_msg_freetype=yes else AC_DEFINE(HAVE_FREETYPE) - FREETYPELIBS=`$ft_devel --libs` - FREETYPEINCL=`$ft_devel --cflags` + FREETYPELIBS=`$ft_devel --libs` + FREETYPEINCL=`$ft_devel --cflags` + ft_incl_dir=${FREETYPEINCL#-I} + old_c_include_path="$C_INCLUDE_PATH" + C_INCLUDE_PATH="$ft_incl_dir:$C_INCLUDE_PATH" + export C_INCLUDE_PATH + ft_incl_dir=$ft_incl_dir/freetype + AC_CHECK_HEADER($ft_incl_dir/freetype.h,AC_DEFINE(HAVE_FREETYPE_H)) + AC_CHECK_HEADER($ft_incl_dir/ftglyph.h,AC_DEFINE(HAVE_FTGLYPH_H)) + AC_CHECK_HEADER($ft_incl_dir/tttables.h,AC_DEFINE(HAVE_TTTABLES_H)) + AC_CHECK_HEADER($ft_incl_dir/ftnames.h,AC_DEFINE(HAVE_FTNAMES_H)) + AC_CHECK_HEADER($ft_incl_dir/ftsnames.h,AC_DEFINE(HAVE_FTSNAMES_H)) + AC_CHECK_HEADER($ft_incl_dir/ttnameid.h,AC_DEFINE(HAVE_TTNAMEID_H)) + C_INCLUDE_PATH="$old_c_include_path" + export C_INCLUDE_PATH wine_cv_msg_freetype=no fi fi diff -urN ../wine-20010529cvs/dlls/wineps/truetype.c ./dlls/wineps/truetype.c --- ../wine-20010529cvs/dlls/wineps/truetype.c Thu May 31 09:17:26 2001 +++ ./dlls/wineps/truetype.c Thu May 31 09:17:56 2001 @@ -9,11 +9,30 @@ #ifdef HAVE_FREETYPE +/* + * These stupid #ifdefs should work for FreeType 2.0.1 and 2.0.2. Beyond that + * is anybody's guess. + */ + +#ifdef HAVE_FREETYPE_H #include <freetype/freetype.h> -#include FT_NAMES_H -#include FT_TRUETYPE_NAMES_H -#include FT_TRUETYPE_TABLES_H -#include FT_GLYPH_H +#endif +#ifdef HAVE_FTGLYPH_H +#include <freetype/ftglyph.h> +#endif +#ifdef HAVE_TTTABLES_H +#include <freetype/tttables.h> +#endif +#ifdef HAVE_FTNAMES_H +#include <freetype/ftnames.h> +#endif +#ifdef HAVE_FTSNAMES_H +#include <freetype/ftsnames.h> +#endif +#ifdef HAVE_TTNAMEID_H +#include <freetype/ttnameid.h> +#endif + #include <sys/types.h> #include <dirent.h> #include <string.h> diff -urN ../wine-20010529cvs/include/acconfig.h ./include/acconfig.h --- ../wine-20010529cvs/include/acconfig.h Tue May 29 18:16:35 2001 +++ ./include/acconfig.h Thu May 31 09:17:56 2001 @@ -129,3 +129,11 @@ /* Define if FreeType 2 is installed */ #undef HAVE_FREETYPE + +/* Define if various FreeType headers are present */ +#undef HAVE_FREETYPE_H +#undef HAVE_FTGLYPH_H +#undef HAVE_TTTABLES_H +#undef HAVE_FTNAMES_H +#undef HAVE_FTSNAMES_H +#undef HAVE_TTNAMEID_H

2 1

[Fwd: autoconf help needed [was wineps include fix.]]
by Ian Pilcher 31 May '01

31 May '01

Ian Pilcher wrote: > > Marcus Meissner wrote: > > > > Add here: > > > > CFLAGS="$CFLAGS -I$ft_incl_dir" > > > > Works great. Thanks! > I spoke too soon. It's finding /usr/include/freetype/freetype.h (from FreeType 1.x). The test is not paying any attention to the CFLAGS variable. So how does one get the autoconf tests to look in a non-standard directory for header files? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

Re: WINE server messages
by Alexandre Julliard 31 May '01

31 May '01

David Howells <dhowells(a)redhat.com> writes: > I'm having a little trouble deciding exactly how to emulate the "module > registration" functionality in my kernel module. It occurs to me that this > might be easier to accomplish with a change to the current wine server message > set. My idea is: > > * Have the server only deal with NT Section objects and views of Sections. > > * Have no separate module table attached to a process. > > * Implement NtQuerySectionInformation/NtSetSectionInformation calls (or > whatever they're called) as wineserver messages. > > * Add an extra Wine-specific information class for the purpose of recording > the extra module information. > > * The wineserver process structure can then be changed so that rather than > keeping a separate list of process_dlls, they can just keep a list of > section views, some of which will be images/modules. Maintaining a section list in the server is certainly something we could do, but I don't really see why you want to get rid of the modules list. What would you gain by doing that?> -- Alexandre Julliard julliard(a)winehq.com

2 1

PathGetCharType/PathGetCharTypeA
by Dax Kelson 31 May '01

31 May '01

I'm having a failure with a windows app. The application starts, and it asks me to name my project and pick a directory to store it in. When I do so, I get errors such as: fixme:shell:PathGetCharTypeA d fixme:shell:PathGetCharTypeA f fixme:shell:PathGetCharTypeA d fixme:shell:PathGetCharTypeA t And apps reports "such such character isn't valid", and doesn't continue (each time I try again, it generates another fixme message). According to MSDN: http://msdn.microsoft.com/library/psdk/shellcc/shell/SHLWAPI/Path/PathGetCh… PathGetCharType/PathGetCharTypeA part of shlwapi.h returns one or more of the following values that define the type of character: GCT_INVALID The character is not valid in a path. GCT_LFNCHAR The character is valid in a long file name. GCT_SEPARATOR The character is a path separator. GCT_SHORTCHAR The character is valid in a short (8.3) file name. GCT_WILD The character is a wildcard character. This is the current Wine code: /************************************************************************* * PathGetCharTypeA [SHLWAPI.@] */ UINT WINAPI PathGetCharTypeA(UCHAR ch) { FIXME("%c\n", ch); return 0; } I'm a perl guy, but I'm learning C. Maybe I'm naive, but fleshing out the Wine version of this function shouldn't be too hard it seems. You'd have to go track down the rules. Can some point me in the right direction on fixing this up? Can someone give me a quick hack to make my application work? Many thanks, Dax

2 3

autoconf help needed [was wineps include fix.]
by Ian Pilcher 31 May '01

31 May '01

Alexandre Julliard wrote: > > Basically do a > > AC_CHECK_HEADERS(freetype/freetype.h freetype/foo.h freetype/bar.h) > Unfortunately it's not that simple, because the FreeType include files won't always be in /usr/include/freetype. On Red Hat 7.1, for example, they're in /usr/include/freetype2/freetype, to distinguish them from the FreeType 1.x headers. The required compiler flag to include the proper directories is in the FREETYPEINCL variable. For example, on my Red Hat system it is set to '-I/usr/include/freetype2'. I tried the following: ft_incl_dir=${FREETYPEINCL#-I} AC_CHECK_HEADER("$ft_incl_dir/freetype/freetype.h",AC_DEFINE(HAVE_FREETYPE_H)) When I run autoconf, autoheader, and configure, I get the following: checking for FT_Init_FreeType in -lfreetype... yes checking for freetype-config... freetype-config checking for /usr/include/freetype2/freetype/freetype.h... no So the AC_CHECK_HEADER macro isn't finding the file, even though it is right there. Anyone have any idea why? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

2 1

Re: wineps include fix.
by Alexandre Julliard 31 May '01

31 May '01

Ian Pilcher <ian.pilcher(a)home.com> writes: > Did you read somewhere that they're getting rid of freetype.h? > > I've looked at 2.0.1 and 2.0.2: > > * In 2.0.1, the header macros are defined in > freetype/config/ftbuild.h, which is included in freetype/freetype.h. > > * In 2.0.2, the header macros are defined in ft2build.h, which is > included in freetype/freetype.h. > > So as long as they keep freetype/freetype.h around, we can include that > and get the macro definitions. The page at http://freetype.sourceforge.net/freetype2/docs/tutorial/step1.html says that you have to include ft2build.h and use macros to include freetype.h, and that other inclusion schemes will get broken in 2.1. I have no idea if this page is up-to-date or if the recommendations have changed again. > We still have to test which macros are defined and only include the ones > that exist, but it does save the work of adding extra autoconf checks. Except with the autoconf checks we control what macros are being defined, we don't have to guess which file to include to get the proper macros. Frankly this idea of defining macros to specify include file names is hopelessly brain-damaged, and the less we have to do with that the happier I will be. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: PATCH: Version 2, GetX11WindowId
by Alexandre Julliard 30 May '01

30 May '01

Nikolas Zimmermann <wildfox(a)kde.org> writes: > ah > i mean, this feature would _only_ be used in kdenonbeta/activexproxy > and it would be great to have this in CVS until you've done this rewrite-task. > > Do you think that's a good, short-term, solution for me? For you certainly. But it doesn't have to be in CVS for you to use it, does it? These kinds of quick hacks have a way of staying around much too long, especially when external packages depend on them, and the best way to avoid that is to not put them in CVS the first place. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wineps include fix.
by Alexandre Julliard 30 May '01

30 May '01

Ian Pilcher <ian.pilcher(a)home.com> writes: > I *believe* that <freetype/freetype.h> should always include the header > that defines the macros. If not, it's going to be a nightmare checking > for 2.0.1, 2.0.2, 2.0.3, etc. -- let alone every intermediate snapshot > that a rawhide/cooker distribution might use. It seems the rule is now to use ft2build.h instead of freetype.h. And this will certainly change in the next release again... so yes, it will be a nightmare if we actually try to use the silly macros. But if we simply bypass them and do autoconf checks like we do for every other package, I think it should work, and be harder to break (though I'm sure the freetype guys will manage to do it ;-) Basically do a AC_CHECK_HEADERS(freetype/freetype.h freetype/foo.h freetype/bar.h) and then #ifdef HAVE_FREETYPE_FREETYPE_H #include <freetype/freetype.h> #endif #ifdef HAVE_FREETYPE_FOO_H #include <freetype/foo.h> #endif etc. Then when they change all the header names again in the next release we can simply add the new names to the list. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wineps include fix.
by Alexandre Julliard 30 May '01

30 May '01

Ian Pilcher <ian.pilcher(a)home.com> writes: > FT_SFNT_NAMES_H doesn't appear anywhere in the 2.0.1 headers. It > appears to be impossible to be source code compatible between 2.0.1 and > 2.0.2. How about doing autoconf checks for all the possible header names variations, and including the ones we find? This would be a lot more robust than trying to find the header that defines the macros that define the headers that define what we need... -- Alexandre Julliard julliard(a)winehq.com

3 2

Problems with large file support.
by Ludovic LANGE 30 May '01

30 May '01

Hello, A few days ago (15 or 16) the support for large files / 64bits was added to Wine ( files/files.c, server/file.c, win32/file.c). Since that modification, my Wine installation isn't functional any more, and wine throws an exception while setting up the SystemHeap. The exception occurs in heap.c, function HEAP_InitSubHeap, just at the instruction : "subheap->heap = heap;" while the subheap pointer is valid. It seems as if the protection of this memory areay was set to read-only, and that the mprotect() call did not succeed in setting it to read/write. I don't know where the real problem is, but since I found no record of such problem in the lists archive, it may be a configuration problem of mine. However, having not found the solution, I'd like some advices. I also think it could be a problem with my glibc not functionning with 64bits functions. My system is a Linux 2.4.4 / RedHat 7.0 / redhat's glibc 2.2-12 Here is a working trace, before the support for 64bits functions was added : ============================================================================== 0806cb00:trace:virtual:CreateFileMappingA (ffffffff,(nil),08000004,0000000000110000,"__SystemHeap") 0806cb00: create_mapping( size_high=0, size_low=1114112, protect=67, inherit=0,file_handle=0, name=L"__SystemHeap" ) 0806cb00: create_mapping() = 0 { handle=32 } 0806cb00: get_mapping_info( handle=32 ) 0806cb00: get_mapping_info() = 0 { size_high=0, size_low=1114112, protect=67, header_size=0, base=(nil), shared_file=0, shared_size=0 } 0806cb00: get_handle_fd( handle=32, access=00000000 ) 0806cb00: *fd* 32 -> 9 0806cb00: get_handle_fd() = 0 { fd=-1 } 0806cb00: set_handle_info( handle=32, flags=0, mask=0, fd=6 ) 0806cb00: set_handle_info() = 0 { old_flags=0, cur_fd=6 } 0806cb00:trace:virtual:MapViewOfFileEx handle=20 size=110000 offset=0 0806cb00: dup_handle( src_process=-1, src_handle=32, dst_process=-1, access=00000000, inherit=0, options=2 ) 0806cb00: dup_handle() = 0 { handle=36, fd=-1 } View: 65430000 - 6553ffff 36 65430000 - 6553ffff c-rW- 0806cb00:trace:virtual:VirtualAlloc 65430000 00110000 1000 00000040 0806cb00:trace:virtual:VIRTUAL_SetProt 65430000-6553ffff c-rWx View: 65430000 - 6553ffff 36 65430000 - 6553ffff c-rWx 0806cb00: create_semaphore( initial=00000000, max=00000001, inherit=0, name=L"") ============================================================================== Here is the stack trace with support for 64 bits functions (more debug traces of mine.) ============================================================================== 0806cb40:trace:virtual:CreateFileMappingA (ffffffff,(nil),08000004,0000000000110000,"__SystemHeap") 0806cb40: create_mapping( size_high=0, size_low=1114112, protect=67, inherit=0, file_handle=0, name=L"__SystemHeap" ) 0806cb40: create_mapping() = 0 { handle=32 } 0806cb40:trace:heap:HEAP_CreateSystemHeap LLA 0806cb40: get_mapping_info( handle=32 ) 0806cb40: get_mapping_info() = 0 { size_high=0, size_low=1114112, protect=67, header_size=0, base=(nil), shared_file=0, shared_size=0 } 0806cb40: get_handle_fd( handle=32, access=00000000 ) 0806cb40: *fd* 32 -> 9 0806cb40: get_handle_fd() = 0 { fd=-1 } 0806cb40: set_handle_info( handle=32, flags=0, mask=0, fd=6 ) 0806cb40: set_handle_info() = 0 { old_flags=0, cur_fd=6 } 0806cb40:trace:virtual:MapViewOfFileEx handle=20 size=110000 offset=0 0806cb40: dup_handle( src_process=-1, src_handle=32, dst_process=-1, access=00000000, inherit=0, options=2 ) 0806cb40: dup_handle() = 0 { handle=36, fd=-1 } View: 65430000 - 6553ffff 36 65430000 - 6553ffff c-rW- 0806cb40:trace:heap:HEAP_CreateSystemHeap LLA - after MapViewOfFileEx : 1077 0806cb40:trace:heap:HEAP_CreateSystemHeap LLA - line 1081 0806cb40:trace:heap:HEAP_InitSubHeap LLA address = 65430000 - line 478 0806cb40:trace:heap:HEAP_InitSubHeap LLA - line 482 0806cb40:trace:virtual:VirtualAlloc 65430000 00110000 1000 00000040 0806cb40:trace:virtual:VIRTUAL_SetProt 65430000-6553ffff c-rWx View: 65430000 - 6553ffff 36 65430000 - 6553ffff c-rWx 0806cb40:trace:virtual:VirtualAlloc LLA 65430000 00110000 1000 00000040 VIRTUAL_SetProt : base= 65430000 0806cb40:trace:heap:HEAP_InitSubHeap LLA - line 491 0806cb40:trace:heap:HEAP_InitSubHeap LLA subheap = 65430000 - line 518 0806cb40:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 0806cb40: queue_exception_event( first=1, record={context={flags=00000000,eax=00000047,ebx=4012c0ec,ecx=65430000,edx=65430000,esi=40128e05,edi=00110000,ebp=00000000,eip=400bb7eb,esp=40626dd0,eflags=00010212,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x400bb7eb,params={1,65430010} ) 0806cb40: queue_exception_event() = 0 { handle=0 } ============================================================================== Any clues are welcome. Best regards, Ludovic LANGE

1 0

Re: PATCH: Version 2, GetX11WindowId
by Alexandre Julliard 30 May '01

30 May '01

Nikolas Zimmermann <wildfox(a)kde.org> writes: > Hi there, > > andrewl (#winehq) advised me to remove > the winuser.h dependencies > > here is the new patch > > Any comments? The main problem is that this requires linking the application to x11drv, which is not a good idea. x11drv is an internal driver that should only be loaded by user/gdi. There needs to be a way to do that without loading x11drv, for instance by using window properties. This is somewhere on my todo list for the new window management code that I'm currently working on. -- Alexandre Julliard julliard(a)winehq.com

2 1

PATCH: Version 2, GetX11WindowId
by Nikolas Zimmermann 30 May '01

30 May '01

Hi there, andrewl (#winehq) advised me to remove the winuser.h dependencies here is the new patch Any comments? Bye Bye Niko -- Nikolas Zimmermann wildfox(a)kde.org

1 0

some unimplemented COM stuff
by Malte.Starostik＠t-online.de 30 May '01

30 May '01

Hello, I have started implementing a small winelib-program that shall eventually add ActiveX support to the Konqueror web browser. For testing I'm using the Shockwave Flash OCX and experienced some problems due to unimplemented functions and features in winelib. First thing is typelib registration, which doesn't work yet as the debug output tells. Okay, did that manually. Then, for setting the control's properties, I tried the easy way via IDispatch::Invoke(), which calls ITypeInfo::Invoke() and that's only a stub :( I worked around this via evil assembler hacks to call the interface's members as given by the vtable offsets in the FUNCDESC using stdcall convention - unfortunately g++ doesn't support specifying a calling convention for method pointers like HRESULT (IDispatch::*setProp)(BSTR). After getting this to work, I hit the next problem: unimplemented urlmon.RegisterBindStatusCallback and when I use a native urlmon.dll it tries to call shlwapi.154, with native shlwapi it still doesn't work somehow, but that's a different story. Anyway, what I'd basically need to get this to work properly is - typelib registration - IDispatch::Invoke() - RegisterBindStatusCallback() and probably asyncronous bind contexts - probably a "real" URL Moniker, not just CreateURLMoniker() using a File Moniker What I'd like to know is if anyone is already working on any of these and if so what's the status and how I could help getting these implemented. if no one started yet, I'd still like to give it a try. Thanks, -Malte PS: the attached patch fixes urlmon.h not being C++-safe. -- Wars don't determine who's right, only who's left.

5 9

WINE server messages
by David Howells 30 May '01

30 May '01

Hello Alexandre, I'm having a little trouble deciding exactly how to emulate the "module registration" functionality in my kernel module. It occurs to me that this might be easier to accomplish with a change to the current wine server message set. My idea is: * Have the server only deal with NT Section objects and views of Sections. * Have no separate module table attached to a process. * Implement NtQuerySectionInformation/NtSetSectionInformation calls (or whatever they're called) as wineserver messages. * Add an extra Wine-specific information class for the purpose of recording the extra module information. * The wineserver process structure can then be changed so that rather than keeping a separate list of process_dlls, they can just keep a list of section views, some of which will be images/modules. David

1 0

set_thread_buffer
by gerard patel 29 May '01

29 May '01

Since the commits of last night, every app I have tried only says : wine client error:0x80675a8: set_thread_buffer failed with status c000000d with apps that usually work fine. Gerard

1 0

PATCH: GetX11WindowId()
by Nikolas Zimmermann 29 May '01

29 May '01

Hi there, this is my first wine patch. it allows the coder to get the X11 Window Id of a HWND. People ask me why this belongs into x11drv and why i need it. ActiveX support for Konqueror, Malte Starostik (who will post some oleaut and urlmon patches soon) and me are working on this. I need to embed the created window, therefore i need this window id. Thank you in advance Bye Bye Niko -- Nikolas Zimmermann wildfox(a)kde.org

1 0

Re: Small fixes in controls/menu.c
by gerard patel 28 May '01

28 May '01

At 10:46 PM 25/05/2001 +0200, you wrote: >I downloaded ftp://ftp.supermemo.com/ftp/sm8zip.exe and managed to >reproduce the bug. (WINE version 20010510) >The way: >1) Using mouse chose File>SuperMemo >2) When app changes its mode click at capition of window >"Contents: E:\SM8\SYSTEMS\SUPERMEMO" >And now main menu is inaccesible (using mouse) >When you force wine to repaint all windows (eg. switch to linux console >and back to X-Window ) you can see menu is drawn up 10-20 pixels than >it should. All right, I still can't see this bad redrawing , but I can see the menu not accessible behaviour now. I'll try to understand something in this problem this week. Btw, this app does not work at all for me in managed mode, it hangs after displaying the splash screen. (but sm7.exe - version 7.5 and sm99.exe - version 9 both load). I think it's an unrelated problem though since it happens with my oldest wine version (20000801) and it's not fixed by your patch. Gerard

2 1

a tool: simple C++ interface definition -> ICOM_ macro converter.
by TAKESHIMA Hidenori 28 May '01

28 May '01

This program may help creating ICOM_ macro. (but this code doesn't have portability, so some modification may be required.) for example, if give the following codes to stdin, we gets ICOM_ macros for IPersist. class IUnknown { public: HRESULT QueryInterface( REFIID riid, LPVOID *ppvObj) ; ULONG AddRef() ; ULONG Release() ; }; export interface IPersist : public IUnknown { virtual HRESULT STDMETHODCALLTYPE GetClassID( CLSID *pClassID ); };

1 0

Wrc patch
by kenon＠go2.pl 28 May '01

28 May '01

Hi, This patch is an answer for "Call for volunteers". I hope it fixes : "wrc fails on preprocessed files" #115: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=115 Maciek Changelog * tools/wrc/ppy.y Maciek Kaliszewski <kenon(a)go2.pl> Added better GCC-style #line directive handling. --

1 0

Enabling backing store
by David Hagood 27 May '01

27 May '01

Has any thought been given to enabling backing store on Wine's windows? As it stands now, when you obscure a Wine window, it forces the Windows app to redraw the screen. Many times this is not needed. Perhaps a configuration option to allow certain apps to have backing store on would be useful. I know that up until a few months ago, it was possible to go into wnd.c and change the default from NotUseful to WhenMapped and things seemed to work well. However, the structure of the X driver has changed, and a simple patch is no longer possible.

1 0

Re: X Error with latest Wine and Notes
by Ian Pilcher 27 May '01

27 May '01

David.Goodenough(a)dga.co.uk wrote: > > I have noticed that with the latest Wine (May drop) I have started to get X > Errors. This typically happens as a dialog is being dismissed. > > The latest of these errors read:-- > > X Error of failed request: BadWindow (invalid Window parameter) > Major opcode of failed request: 12 (X_ConfigureWindow) > Resource if in failed request: 0x1c24350 > Serial number of failed request: 9920 > Current serial number in output stream: 9922 > > I get the feeling, although I can not prove it, that this may be timing > related, as it tends to happen when I am a bit quick completing the dialog. > The other odd thing that happens when this occurs is that a second copy of > the window, not the detail face of the window, just the window and its > frame controls, is drawn slightly down and right of the original window, > then it blows and Notes hangs. > > I had not noticed this behaviour before switching to the May drop. There > are no other console messages that are out of the ordinary set that I have > been reporting for a while. > > Is this a known problem? David - I have also seen this problem, but I have no idea what causes it. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

Q: anybody using Exceed on NT4 as X server for wine?
by Heiko Nardmann 26 May '01

26 May '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there anybody out there who uses Exceed on NT4 as the X server to display wine applications (like winemine from examples) which have been started on Linux? If yes are did you try 20010510 snapshot (or CVS) to run your applications? If yes could you provide me with your configuration files? I am still not able to start winemine since snapshot 20010418 (20010326 works fine). - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de), Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7DgpMpm53PRScYygRAn6cAKDaQl3Tm4l/sIe9cQoRbdwo7vf7bwCg8gm5 38OwXBWHUxJVc1ZV91iywRY= =CjPM -----END PGP SIGNATURE-----

2 1

Re: AFM files no longer required
by Alexandre Julliard 25 May '01

25 May '01

Ian Pilcher <ian.pilcher(a)home.com> writes: > Here's a thought. How about creating a data subdirectory for the Post- > Script driver (i.e. dlls/wineps/data). The data could then be put in > separate files in that directory without confusing things. (The data > isn't interdependent from a build point of view, just from a main- > tenance point of view.) > > I don't know the Makefile magic necessary to do this, but if someone > could step forward with that piece, I suspect it would address both of > our concerns. > > What do you think? That's certainly a viable solution yes. If you send me a patch implementing the separate files I'll do the Makefile magic. -- Alexandre Julliard julliard(a)winehq.com

1 0

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