wine-devel

wine-devel@winehq.org

10 participants
84486 discussions

RE: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Patrik Stridvall 10 Aug '01

10 Aug '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So the question is: > > Should we use the FORWARD_WM_* macros to avoid typecasts > > (or rather avoid visable typecast) or should we not? > > If not how should we fix the problems? > > I think it's better to avoid that. Hiding the typecasts in the macros > doesn't really make things cleaner IMO. This is a case where the API > design forces us to use a typecast, so we might as well make it > explicit. True, but be aware of the macros often use a double type cast like (LPARAM)(HWND). I'm not sure this is really helpful, since I guess it will reveal but a few type error if any at all. Also note that the macros also takes care of MAKEWPARAM and MAKELPARAM stuff so it makes the code a little more readable. Anyway, never mind. We could be a little more clever than the macros permit that if we like. See below. > Note that for the specific case of WM_GET/SETTEXT, it would be much > better to use Get/SetWindowText which will do correct type checks. True. They was just an example. They are a few more with similar problems but they are few (less than 10 IIRC). I guess we can worry about them later. > But > for messages that don't have a corresponding function we have to do > the typecast. As the macros work now, yes. But we could extend the "macros" to be a little more clever than that. Take for example one of the more advanced macros #define FORWARD_WM_LBUTTONDOWN(hwnd, fDoubleClick, x, y, keyFlags, fn) \ (void)(fn)((hwnd), (fDoubleClick) ? WM_LBUTTONDBLCLK : WM_LBUTTONDOWN, (WPARAM)(UINT)(keyFlags), MAKELPARAM((x), (y))) We could quite easily write it like: #define _FORWARD_WM_LBUTTONDOWN(hwnd, fDoubleClick, x, y, keyFlags, fn) \ (void)(fn)((hwnd), (fDoubleClick) ? WM_LBUTTONDBLCLK : WM_LBUTTONDOWN, (WPARAM)(UINT)(keyFlags), MAKELPARAM((x), (y))) #if defined(__WINE__) && defined(__GNUC__) extern inline void _WINE_FORWARD_WM_LBUTTONDOWN(HWND hwnd, BOOL fDoubleClick, int x, int y, UINT keyFlags, WNDPROC *fn) { /* return */ _FORWARD_WM_LBUTTONDOWN(hwnd, fDoubleClick, x, y, keyFlags, *fn); } #define FORWARD_WM_LBUTTONDOWN(hwnd, fDoubleClick, x, y, keyFlags, fn) \ _WINE_FORWARD_WM_LBUTTONDOWN((hwnd), (fDoubleClick), (x), (y), (keyFlags), &(fn)) #else #define FORWARD_WM_LBUTTONDOWN(hwnd, fDoubleClick, x, y, keyFlags, fn) \ _FORWARD_WM_LBUTTONDOWN((hwnd), (fDoubleClick), (x), (y), (keyFlags), (fn)) #endif Or something like that. I'm not even sure the __WINE__ is needed. I not sure that any Winelib application could possibly misuse the macros in such a way that the result is not semantically the same (type warnings/errors excluded of course). Note that it is quite easy to write script that automatically does this to avoid subtle bugs especially since the correct (almost) prototype is already before each macro. Like in the case above: /* void Cls_OnLButtonDown(HWND hwnd, BOOL fDoubleClick, int x, int y, UINT keyFlags) */ This will give us all the advantages of the "macros" without any typecasts that could possibly hide a type error. What do you say? Note that we don't have to implement the solution above right now either. Using the macros as they are will not gain us very much (except possible a cleaner looking code), true. However when we implement the type safe "macros" as described above we will immediately find any and all type errors concerning such code. Anway fixing windowsx.h to look like above will not be very difficult either so there is no real reason to wait is it? PS. As hinted above this will also work with most (all?) Winelib applications that happends to use the windowsx.h macros and enable the finding of subtle type errors in such applications.

1 0

Re: RFC: Should we use the macros in windowsx.h to fix -DSTRICT warni ngs?
by Alexandre Julliard 10 Aug '01

10 Aug '01

Patrik Stridvall <ps(a)leissner.se> writes: > So the question is: > Should we use the FORWARD_WM_* macros to avoid typecasts > (or rather avoid visable typecast) or should we not? > If not how should we fix the problems? I think it's better to avoid that. Hiding the typecasts in the macros doesn't really make things cleaner IMO. This is a case where the API design forces us to use a typecast, so we might as well make it explicit. Note that for the specific case of WM_GET/SETTEXT, it would be much better to use Get/SetWindowText which will do correct type checks. But for messages that don't have a corresponding function we have to do the typecast. -- Alexandre Julliard julliard(a)winehq.com

1 0

RFC: Should we use the macros in windowsx.h to fix -DSTRICT warni ngs?
by Patrik Stridvall 10 Aug '01

10 Aug '01

This is not primarily a patch it is a RFC. I have experimented a bit with fixing the strict warnings. I have a few patch that I haven't submitted yet partly because I'm not 100% sure how all warnings should be fixed. Anyway, one large class of warnings is the ones cause by the window messaging functions. Like the one below: SendMessageW(lphc->hWndEdit, WM_SETTEXT, 0, (LPARAM)empty_stringW); This one unlike others this one does cause any warning with -DSTRICT because of the ugly cast, but the principle is the same. The only good way to fix this kind of problems that I can see is to use the FORWARD_WM_* macros in include/windowsx.h to write it like: FORWARD_WM_SETTEXT(lphc->hWndEdit, empty_stringW, SendMessageW); This works fine because the FORWARD_WM_SETTEXT macro look like this: #define FORWARD_WM_SETTEXT(hwnd, lpszText, fn) \ (void)(fn)((hwnd), WM_SETTEXT, 0L, (LPARAM)(LPCTSTR)(lpszText)) Actually I lied this special case will not work fine since FORWARD_WM_SETTEXT uses TCHAR and friends. But that is not so important for the general principle. See below. Anyway, in some meaning the macros only hides the casts, but can casts really be avoided? We must cast to {W,L}PARAM at some time mustn't we? And the macros in windowsx.h is not that bad they cast to the correct type before the cast to {W,L}PARAM. This might help to find some bugs. Perhaps rewriting to macros as inline functions might help to? So the question is: Should we use the FORWARD_WM_* macros to avoid typecasts (or rather avoid visable typecast) or should we not? If not how should we fix the problems? And if we decide to use them, is patches like the one below to include/windowsx.h that fixes the TCHAR and friend problem acceptable or should we solve such problems in another way? PS. Alexandre: Feel free to apply the patch below if you agree. ---8<--- * include/windowsx.h: Include files used internally by Wine can't use the types TCHAR and friends. ---8<--- Index: wine/include/windowsx.h =================================================================== RCS file: /home/wine/wine/include/windowsx.h,v retrieving revision 1.7 diff -u -u -r1.7 windowsx.h --- wine/include/windowsx.h 2001/01/10 22:42:35 1.7 +++ wine/include/windowsx.h 2001/08/10 12:43:18 @@ -714,17 +714,37 @@ #define FORWARD_WM_ENABLE(hwnd, fEnable, fn) \ (void)(fn)((hwnd), WM_ENABLE, (WPARAM)(BOOL)(fEnable), 0L) +/* void Cls_OnSetTextA(HWND hwnd, LPCSTR lpszText) */ +#define HANDLE_WM_SETTEXTA(hwnd, wParam, lParam, fn) \ + ((fn)((hwnd), (LPCSTR)(lParam)), 0L) +#define FORWARD_WM_SETTEXTA(hwnd, lpszText, fn) \ + (void)(fn)((hwnd), WM_SETTEXT, 0L, (LPARAM)(LPCSTR)(lpszText)) + +/* void Cls_OnSetTextW(HWND hwnd, LPCWSTR lpszText) */ +#define HANDLE_WM_SETTEXTW(hwnd, wParam, lParam, fn) \ + ((fn)((hwnd), (LPCWSTR)(lParam)), 0L) +#define FORWARD_WM_SETTEXTW(hwnd, lpszText, fn) \ + (void)(fn)((hwnd), WM_SETTEXT, 0L, (LPARAM)(LPCWSTR)(lpszText)) + /* void Cls_OnSetText(HWND hwnd, LPCTSTR lpszText) */ -#define HANDLE_WM_SETTEXT(hwnd, wParam, lParam, fn) \ - ((fn)((hwnd), (LPCTSTR)(lParam)), 0L) -#define FORWARD_WM_SETTEXT(hwnd, lpszText, fn) \ - (void)(fn)((hwnd), WM_SETTEXT, 0L, (LPARAM)(LPCTSTR)(lpszText)) +#define HANDLE_WM_SETTEXT WINELIB_NAME_AW(HANDLE_WM_SETTEXT) +#define FORWARD_WM_SETTEXT WINELIB_NAME_AW(FORWARD_WM_SETTEXT) + +/* INT Cls_OnGetTextA(HWND hwnd, int cchTextMax, LPSTR lpszText) */ +#define HANDLE_WM_GETTEXTA(hwnd, wParam, lParam, fn) \ + (LRESULT)(DWORD)(int)(fn)((hwnd), (int)(wParam), (LPSTR)(lParam)) +#define FORWARD_WM_GETTEXTA(hwnd, cchTextMax, lpszText, fn) \ + (int)(DWORD)(fn)((hwnd), WM_GETTEXT, (WPARAM)(int)(cchTextMax), (LPARAM)(LPSTR)(lpszText)) + +/* INT Cls_OnGetTextW(HWND hwnd, int cchTextMax, LPWSTR lpszText) */ +#define HANDLE_WM_GETTEXTW(hwnd, wParam, lParam, fn) \ + (LRESULT)(DWORD)(int)(fn)((hwnd), (int)(wParam), (LPWSTR)(lParam)) +#define FORWARD_WM_GETTEXTW(hwnd, cchTextMax, lpszText, fn) \ + (int)(DWORD)(fn)((hwnd), WM_GETTEXT, (WPARAM)(int)(cchTextMax), (LPARAM)(LPWSTR)(lpszText)) /* INT Cls_OnGetText(HWND hwnd, int cchTextMax, LPTSTR lpszText) */ -#define HANDLE_WM_GETTEXT(hwnd, wParam, lParam, fn) \ - (LRESULT)(DWORD)(int)(fn)((hwnd), (int)(wParam), (LPTSTR)(lParam)) -#define FORWARD_WM_GETTEXT(hwnd, cchTextMax, lpszText, fn) \ - (int)(DWORD)(fn)((hwnd), WM_GETTEXT, (WPARAM)(int)(cchTextMax), (LPARAM)(LPTSTR)(lpszText)) +#define HANDLE_WM_GETTEXT WINELIB_NAME_AW(HANDLE_WM_GETTEXT) +#define FORWARD_WM_GETTEXT WINELIB_NAME_AW(FORWARD_WM_GETTEXT) /* INT Cls_OnGetTextLength(HWND hwnd) */ #define HANDLE_WM_GETTEXTLENGTH(hwnd, wParam, lParam, fn) \

1 0

wine+mirc /rename confusiion bug
by mdew 10 Aug '01

10 Aug '01

make a empty file..place it the mirc dir... /rename y:\fake_windows\mirc\text.txt c:\mirc\text2.txt *** /rename: unable to rename 'y:\fake_windows\mirc\text.txt' to 'c:\mirc\text2.txt' $ ls text* -al -rw-r--r-- 1 mdew mdew 6 Aug 10 22:33 text.txt -rw-r--r-- 1 mdew mdew 6 Aug 10 22:36 text2.txt complains about it...yet it actually does it. -- id: 9DF3262C key fingerprint: B556 04DA CFD9 78DD 9215 A970 8196 FB6D 9DF3 262C

1 0

trouble with fonts (old, old problem)
by Mike McCormack 10 Aug '01

10 Aug '01

Hi All, i've got a problem with fonts in Netscape that's been around for a long time, while i've tried several times, unsuccessfully, to fix. When netscape 4.77 first loads, then loads an arbitary page, everything (text, buttons, comboboxes) is rendered incorrectly. If i go to another page, then hit the Back button, the page that was originally rendered incorrectly is now correct. All further renderings are correct for all pages. In my investigations (some time ago), i found that : * font enumeration functions returned different things on the first and second load of the same page. * i could correct the problem by changing the default ansi fixed font to helvetica i suspect that the wine loads extra X11 fonts between the first and second page viewings... but i don't know much about font handling in wine. i'll make some screen shots if anybody is interested. Any ideas? Mike ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Font scaling in PSDRV_EnumDeviceFonts
by Ian Pilcher 10 Aug '01

10 Aug '01

Can anyone point me to the Win32 API that ultimately calls the subject function? I'm trying to understand why it scales fonts to a 200 logical unit (I think) character cell. Is this completely arbitrary? Thanks! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

Re: wineserver.pid
by Alexandre Julliard 09 Aug '01

09 Aug '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > Hi all, > > some guy was running several different versions of wineservers for one > account via wrapper scripts. > And of course he had a hell of a hard time figuring out which wineserver to > kill for which application ;-) Why would you want to do that? Just kill the app and it will die on its own (and save everything too). I don't think encouraging people to kill the wineserver is a good idea. -- Alexandre Julliard julliard(a)winehq.com

1 0

winelib application debugging
by Vitaly Kuznetsov 09 Aug '01

09 Aug '01

Is there currently any way to debug winelib application? I read winedbg doc, but there are only samples for windows executables. -- Vitaly AKA Vitty mailto: vitty(a)dts.ru NetMail:2:5015/133.41

2 1

Today's CVS hangs on startup
by Ian Pilcher 09 Aug '01

09 Aug '01

The good news is that --debugmsg +all actually stops producing anything. Hopefully someone can look at the output below and figure out what's going on. Anyone else seen this? ... 080689c0:trace:dosfs:DOSFS_FindUnixName (/home/pilcher/wine,Eudora\EUDORA.EXE) -> Eudora (EUDORA) 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:heap:HeapFree (403a0000,00000002,403c36c8): returning TRUE 080689c0:trace:dosfs:DOSFS_FindUnixName /home/pilcher/wine/Eudora,EUDORA.EXE 080689c0:trace:heap:HeapAlloc (403a0000,00000002,0000022c): returning 403c36c8 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:dosfs:DOSFS_FindUnixName (/home/pilcher/wine/Eudora,EUDORA.EXE) -> EUDORA.EXE (EUDORA.EXE) 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:heap:HeapFree (403a0000,00000002,403c36c8): returning TRUE 080689c0:trace:dosfs:DOSFS_GetFullName returning /home/pilcher/wine/Eudora/EUDORA.EXE = C:\EUDORA\EUDORA.EXE 080689c0:trace:string:lstrcpynA (0x405f68e8, "C:\\EUDORA\\EUDORA.EXE", 260) 080689c0:trace:string:lstrcpynA (0x405f68ea, "/Eudora/EUDORA.EXE", 258) 080689c0:trace:module:GetModuleFileName16 01cf -> 'C:\Eudora\EUDORA.EXE' 080689c0:trace:heap:HeapAlloc (403a0000,00000002,0000004c): returning 403c3480 080689c0:trace:reg:NtOpenKey (0x80000002,L"Software\\Wine\\Wine\\Config\\AppDefaults",f003f,0x405f6820) 080689c0: open_key( parent=-2147483646, access=000f003f, name=L"Software\\Wine\\Wine\\Config\\AppDefaults" ) Open key ERROR 080689c0: open_key() = OBJECT_NAME_NOT_FOUND { hkey=0 } 080689c0:trace:reg:NtOpenKey <- 0x0000 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"display",(nil),(nil),0x405f68f0,0x405f6818=268) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"display",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"display" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"Managed",(nil),(nil),0x405f68e8,0x405f6814=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"Managed",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"Managed" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"Desktop",(nil),(nil),0x405f68e8,0x405f6810=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"Desktop",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"Desktop" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"DXGrab",(nil),(nil),0x405f68e8,0x405f680c=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"DXGrab",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"DXGrab" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"UseDGA",(nil),(nil),0x405f68e8,0x405f6808=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"UseDGA",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"UseDGA" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"ScreenDepth",(nil),(nil),0x405f68e8,0x405f6804=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"ScreenDepth",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"ScreenDepth" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"Synchronous",(nil),(nil),0x405f68e8,0x405f6800=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"Synchronous",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"Synchronous" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0: close_handle( handle=32 ) 080689c0: close_handle() = 0 { fd=-1 } 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

[Fwd: Re: x11drv port to win32 possible ?]
by Ian Pilcher 09 Aug '01

09 Aug '01

Rudi De Vos wrote: > > The intention is to create a dll that exports the winapi graphic > functions for X11: X11DRV_CreateWindow,X11DRV_InitKeyboard,.. > see x11drv.spec. > Someone can correct me if I'm wrong, but I believe that Wine's built-in graphics drivers -- x11drv, ttydrv, and wineps -- interface with Wine's GDI code in a non-standard way. Alexandre has made some changes in this area recently, but I don't believe they've changed that fundamental fact. So to do what you're proposing, you would first have to modify Wine's GDI code to support one of Microsoft's 32-bit graphics driver interfaces. (Different Microsoft 32-bit OSes have different driver interfaces, BTW.) You could then update x11drv to use this interface. As Patrik pointed out, this is really outside the scope of the Wine project, but I do think that it would be valuable. In addition to the reasons you give above, it would be helpful in improving both the Wine driver code and the Wine GDI code. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel