July 2001 - Wine-Devel - list.winehq.org

RE: -DSTRICT warning fixes

by Francois Gouget

On Sat, 28 Jul 2001, Patrik Stridvall wrote: [...] > The real reason that we should support compiling Wine with -DSTRICT > is not because handles becomes pointers but because callbacks gets > the correct prototype. > > I case not you haven't realized the obvious, it doesn't matter if > the handles are 32-bit integer or 32-bit pointers as long as > all handles are the same. The code either No, I think you have missed something: when compiling with -DSTRICT on all handles are not the same. For instance you cannot do hDesk=hAccel. That's because with -DSTRICT on you have: typedef struct HDESK__ { int unused; } *HDESK; typedef struct HACCEL__ { int unused; } *HACCEL; Thus HDESK and HACCEL are incompatible pointer types. This brings us more type safety which is the whole point of -DSTRICT. About 64bits Windows I don't know yet how we are going to do that. But you have to check exactly what Windows 64bit does, not just extrapolate from the way Unix 64bit does things. AFAIK the approach used by windows is quite different from that which Unices took. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

July 28, 2001

Re: -DSTRICT warning fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > However for the debugging output I disagree. I orginally thought > as Francois (and you it seems) that handles are pointers and should > be treated as such. But then I realized that when we implement Win32 on > 64-bit platforms we can't have handles as pointers even internally if > we wan't to support x86 emulation and even exposing a 64-bit > handle to Winelib application can only cause trouble since they > might store it is a 32-bit memory location. Sure we will probably be > able to handle 64-bit pointers truncated to 32-bit by storing all > objects in the lower 32-bit part of memory, but fear it might > cause trouble all the same. Handles are pointers in the Windows API, and they should be pointers inside of Wine. On a 64-bit platforms pointers will be 64-bit, and so will handles. If you want to run 32-bit code on such a platform you need a conversion for pointers anyway, so you might as well use the same conversion for handles. Not to mention that some handles are actually pointers (like HMODULE). So no, there is absolutely no reason to force handles to be 32 bits. > Beside doing TRACE("(%p)", handle) on 64-bit platforms will needlessly > display the always the same presumably zero upper 32-bit part > of the handle. That why I decided to should use > TRACE("(0x%08lx)", (DWORD) handle) instead to avoid such issues. Sorry but this is wrong. Handles are pointers and must be printed as pointers. Assuming that handles are always exactly 32-bit is very shortsighted. > The real reason that we should support compiling Wine with -DSTRICT > is not because handles becomes pointers but because callbacks gets > the correct prototype. No, it's because handles become pointers; you cannot do the -DSTRICT typechecking with integers anyway. Callbacks are a very minor issue; the real point is to fix all incorrect handle manipulations, like implicit 16-bit handle conversions or arithmetic on handle values. -- Alexandre Julliard julliard(a)winehq.com

July 28, 2001

RE: -DSTRICT warning fixes

by Patrik Stridvall

> > If we do that can just do > > s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/ > > on the handle types on by one and fix the warnings. > > That's precisely the plan, and it is just the opposite of what you are > doing with your patch (you are turning DECLARE_HANDLE back into > DECLARE_OLD_HANDLE). The reason I did that was that they can't be fixed as long as HANDLE/HGLOBAL is the wrong types. When they become the right types the warnings will automatically disappear and we can do s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/. But there is no reason to have a lot of warnings that can't be fixed otherwise until then. > Yes you get a number of warnings if you turn > -DSTRICT on, most of them should disappear once the conversion is > complete; fixing them before that is a waste of time. Since we can't fix before that why show them at all? People that want to fix for example output messages can do, s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/ in their tree, fix them and submit the patches (without the s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/). > This is the > reason why -DSTRICT is not the default yet. Read bug report #90, > Francois explains everything there. OK. I have read bug report #90 now. > And don't forget the number one rule of the -DSTRICT conversion is: > *no* *typecasts*. If you have to add typecasts something is wrong. No typecasts where the handle is used in conjuction with other handles, certainly not, no argument there. The code some expect all handles to be the of same type. However for the debugging output I disagree. I orginally thought as Francois (and you it seems) that handles are pointers and should be treated as such. But then I realized that when we implement Win32 on 64-bit platforms we can't have handles as pointers even internally if we wan't to support x86 emulation and even exposing a 64-bit handle to Winelib application can only cause trouble since they might store it is a 32-bit memory location. Sure we will probably be able to handle 64-bit pointers truncated to 32-bit by storing all objects in the lower 32-bit part of memory, but fear it might cause trouble all the same. Beside doing TRACE("(%p)", handle) on 64-bit platforms will needlessly display the always the same presumably zero upper 32-bit part of the handle. That why I decided to should use TRACE("(0x%08lx)", (DWORD) handle) instead to avoid such issues. In short, the code should IMHO support both 32-bit pointers as well and 32-bit integers as handles presuming of course that all handles use the same. The real reason that we should support compiling Wine with -DSTRICT is not because handles becomes pointers but because callbacks gets the correct prototype. I case not you haven't realized the obvious, it doesn't matter if the handles are 32-bit integer or 32-bit pointers as long as all handles are the same. The code either 1. Just pass them around as the same type of handles of other types of handles (HANDLE/HGLOBAL). 2. Tries to access the underlying object, in such case a void pointer will not do use any good, we must use a cast either after calls to functions like GlobalLock or alone.

July 28, 2001

Re: -DSTRICT warning fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > Concerning some parts of my warnings patch that was > partly rejected I disagree with the rejection. > The patch in question is in warnings_rejected.diff. > Note the field "u" is a union. But perhaps you know > and rejected it for other reasons? I know it is a union; I thought it was one of these cases that would get fixed by -DSTRICT, but now I see that it is a slightly different problem. I'll apply it. > If you accept all the strict_*.diff patches, perhaps we > should consider adding -DSTRICT as a permanent flag? > It removes the HOOKPROC/TIMERPROC warnings that is not > possible to fix otherwise. > > If we do that can just do > s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/ > on the handle types on by one and fix the warnings. That's precisely the plan, and it is just the opposite of what you are doing with your patch (you are turning DECLARE_HANDLE back into DECLARE_OLD_HANDLE). Yes you get a number of warnings if you turn -DSTRICT on, most of them should disappear once the conversion is complete; fixing them before that is a waste of time. This is the reason why -DSTRICT is not the default yet. Read bug report #90, Francois explains everything there. And don't forget the number one rule of the -DSTRICT conversion is: *no* *typecasts*. If you have to add typecasts something is wrong. -- Alexandre Julliard julliard(a)winehq.com

July 28, 2001

(no subject)

by Ladislav Sladecek

Alexandre Julliard: > I think GetClipBox is correct, the problem is > that the WM_ERASEBKGND > handler should not be using it, but > GetClientRect. You can try this: Hello Alexandre, thank you for your reccomendation. Unfortunately the DefWindowProc improvement does not help, because the default handler newer gets called in my app. The application (Progress _prowin.exe version 7) uses custom dialog boxes (forms) and also custom controls. The controls handle WM_ERASEBKGND themeselves. I have no access to the sources. What I know about GetClipRect, I know from the trace. I agree that your method (GetClientRect in the handler) is much better, but I cannot use it. I also agree that Windows should return the parent area in GetClipBox as Wine does. Unfortunalelly, the Windows do not do that while the _prowin.exe depends on it. I enclose a simple C example which I hacked to demonstrate this. The example displays two red children in a white parent. The value returned by GetClipBox is wsprintf-ed. If you run the binary in the Windows, you will see two properly sized red rectangles on a white background. If you run the same binary in Wine, you will see only one large red child but no white parent background. If either the CS_PARENTDC or WS_CLIPSIBLINGS gets removed from my example, both Windows and Wine give identical results. Regards Ladislav Sladecek

July 28, 2001

Re: -DSTRICT warning fixes

by Francois Gouget

- FIXME("(%x),stub!\n",hrasconn); + FIXME("(0x%08lx): stub\n", (DWORD) hrasconn); [...] I think I would rather use %p to print handles. After all they are pointers, not integers. The annoying aspect of it is that %08p is not very well supported IIRC. Maybe gcc has been fixed though. I forgot to mention it before. But I assume you saw bug #90. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

July 28, 2001

wine on clusters ??

by Francisco Perez

Hi everybody: Has anybody tried to run wine on a High Availabity cluster ?. Especifically we are interested on a Mosix environment where applications don't need be changed. The windows application to be clustered is a Remote IP network back-up system so no grafic intensive or plug modern like ActiveX and so. Any comments are highly apreciated thanks

July 28, 2001

Re: PATCH: wrong clipRect when CS_PARENTDC and WS_CLIPSIBLINGS styles are combined

by Alexandre Julliard

lsla(a)post.cz writes: > Where the Wine's GetClipRect returns the area of the parent, the > Windows version returns only the area of the child. Therefore in > Wine the WM_ERASEBKGND message erases the whole parent including the > other radio buttons. I think GetClipBox is correct, the problem is that the WM_ERASEBKGND handler should not be using it, but GetClientRect. You can try this: Index: windows/defwnd.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/defwnd.c,v retrieving revision 1.57 diff -u -r1.57 defwnd.c --- windows/defwnd.c 2001/06/20 23:16:34 1.57 +++ windows/defwnd.c 2001/07/27 23:47:26 @@ -457,20 +457,15 @@ case WM_ICONERASEBKGND: { RECT rect; + HDC hdc = (HDC)wParam; HBRUSH hbr = GetClassLongW( wndPtr->hwndSelf, GCL_HBRBACKGROUND ); if (!hbr) return 0; - /* Since WM_ERASEBKGND may receive either a window dc or a */ - /* client dc, the area to be erased has to be retrieved from */ - /* the device context. */ - GetClipBox( (HDC)wParam, &rect ); - - /* Always call the Win32 variant of FillRect even on Win16, - * since despite the fact that Win16, as well as Win32, - * supports special background brushes for a window class, - * the Win16 variant of FillRect does not. - */ - FillRect( (HDC) wParam, &rect, hbr ); + /* GetClientRect used to be GetClipBox, but it is not what + * Windows does, and it breaks badly with CS_PARENTDC */ + GetClientRect( wndPtr->hwndSelf, &rect ); + DPtoLP( hdc, (LPPOINT)&rect, 2 ); + FillRect( hdc, &rect, hbr ); return 1; } -- Alexandre Julliard julliard(a)winehq.com

July 28, 2001

Re: Dose wine people hate Solaris?

by Super-User

Now I finally made a wine , :) But I can't get any program to excute so far, mostly It is like bash-2.03# wine --winver win95 sol.exe err:seh:UnhandledExceptionFilter Couldn't start debugger (debugger/winedbg 134639312 24) (2) Read the Wine Developers Guide on how to set up winedbg or another debugger or bash-2.03# wine --winver win98 icq2000b.exe err:win32:do_relocations Standard load address for a Win32 program not available - patched kernel ? err:win32:do_relocations FATAL: Need to relocate F:\export\home\ericw\system\icq2000b.exe, but no relocation records present (stripped during link). Try to run that file directly ! wine: can't exec 'icq2000b.exe': error=21 This wine seems taste not good, :) Francois Gouget wrote: > On Thu, 26 Jul 2001, EriK W wrote: > > > > What does not work? Do you have unicode/libwine_unicode.so or not? > > > Does the following command run or does it say it cannot find > > > libwine_unicode.so? > > > > > I does have the libwine_unicode.so > > but it just don't go to ~unicode directory to search for it, it always > > report " can't find it in /usr/local/lib" I don't know why, I am using bash, > > so I just simply copied libwine_unicode.so over to make it happy. > > I was wondering if it was the shell not exporting the environment > variable or something. Since you're using bash it should be all fine. > So you have to figure out why setting LD_LIBRARY_PATH does not work. > It's supposed to work. I'm 99.9% sure I did use it on Sparc Solaris so I > really don't see why it would not work on Solaris x86. Plus > LD_LIBRARY_PATH is such an important thing that it would be very > surprising if it really did not work and nothing else was broken in your > system. > > Did you try specifying an absolute path like: > LD_LIBRARY_PATH=/export/home/system/wine-20010629/unicode ./tools/winebuild/winebuild > > What does 'echo $LD_LIBRARY_PATH' normally say? Is it empty? > > [...] > > take it out? > > Can I do that by commenting " > > LIBPROGRAMS = \ > > debugger/winedbg" ? > > The following patch should do that nicely: > > --- cut here --- > Index: Makefile.in > =================================================================== > RCS file: /home/wine/wine/debugger/Makefile.in,v > retrieving revision 1.24 > diff -u -r1.24 Makefile.in > --- Makefile.in 2000/12/29 05:38:00 1.24 > +++ Makefile.in 2001/07/27 01:39:15 > @@ -3,7 +3,7 @@ > TOPOBJDIR = .. > SRCDIR = @srcdir@ > VPATH = @srcdir@ > -MODULE = winedbg > +MODULE = #winedbg > > C_SRCS = \ > break.c \ > --- Makefile.orig Thu Jul 26 19:03:36 2001 > +++ Makefile Thu Jul 26 19:00:53 2001 > @@ -3,7 +3,7 @@ > TOPSRCDIR = .. > TOPOBJDIR = .. > SRCDIR = . > -MODULE = winedbg > +MODULE = #winedbg > > C_SRCS = \ > break.c \ > --- cut here --- > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Broadcast message : fin du monde dans cinq minutes, repentez vous !

July 27, 2001

RE: winapi update

by Patrik Stridvall

> make_filter: : can't parse output: 'Make.rules.in is newer > than Make.rules, please rerun ./configure!' Fixed in my tree. > Would it be possible to have the messages pass through as-is when > they are not recognized (with the current directory for context)? [snip] > make_filter: gcc: can't parse output: 'd3ddevice/mesa.c:817: > warning: unused variable `xvis'' I have fixed that for gcc messages (unless --pedantic is specified), however I'm not sure it is good always doing that. I will think about it. > It looks like there's an incompatibility with colorgcc. [snip] > So it must be the controls characters added by colorgcc > that confuse > make_filter. No it wasn't, colorgcc checks whether STDOUT is a TTY or not.

July 27, 2001