- Wine-Devel - list.winehq.org

Re: Remove unnecessary #pragma code_page(xxxx) statements from winefile .rc files
by Martin Fuchs Aug. 23, 2005

Aug. 23, 2005

> This is because 'LANGUAGE LANG_xxxx' statements don't actually change > code page specified by a previous '#pragma code_page(xxxx)', therefore > russian resources get translated to unicode using wrong code page. > I don't know whether it's an rc bug or a feature. We either need > to remove '#pragma code_page' statements altogether, or add them > to all included .rc files. I took the 1st approach. > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Remove unnecessary #pragma code_page(xxxx) statements from > winefile .rc files, they confuse the resource compiler. Please be carefull to remove the code page pragmas. IMHO this is not the correct way. When there is no other code page given, the resource compiler uses the current code page of the operating system. And I don't think, all of those language specific resource scripts will compile correct on all possible OS code pages. The reliable way would be to include the correct code page at the begin of all resource scripts. Please take in mind: Wine is compiled on many different environments: LANG_C, de_DE.ISO-8859-1, en_EN.UTF-8, swedish, or whatever... Removing the code page pragmas would require to test the correctness of the compilation results of all different languages on all possible platforms. Regards, Martin

2 1

Safedisc1 CD checks work, it tries to start the game but fails to do so
by Ivan Leo Puoti Aug. 23, 2005

Aug. 23, 2005

Hello list, here's a little update Safedisc1 now successfully passes all anti debugger check, and recognises the CD correctly. It then attempts to start the game, but this doesn't work yet because of the nested exception on signal stack bug. Hopefully we aren't too far from getting it to run. Ivan.

4 3

Re: [winedbg] Don't ever pass a NONCONTINUABLE exception
by Alexandre Julliard Aug. 22, 2005

Aug. 22, 2005

Glenn Wurster <gwurster(a)scs.carleton.ca> writes: > Changelog: > Don't pass on non-continuable exceptions. Why do you want to do that? -- Alexandre Julliard julliard(a)winehq.org

3 6

Re: Throwing in an idea (probably it was discussed before though)
by Jacek Caban Aug. 22, 2005

Aug. 22, 2005

John Smith wrote: >> You can also set it yourselves in in your app. As configuration >> is in registry, every app can modify it. > > > I like this idea, thanks. There are still 2 issues with such a soultion: > a) most likely, it won't work until 2nd start of the application (we > will modify it on the first run, and it most likely won't be applied > until the second run); If you have an installer, you may configure Wine during installation. If not - just detect Wine at the beginning of the app and, if you have to configure Wine, do so and restart the app. It's a bit (very) hackish but it should work and it's not visible for user. > b) current WINE guides are discouraging us from detecting WINE - and > messing up with Windows Registry, especially HKEY_LOCAL_MACHINE, on > all the millions of non-WINE machines is not a thing I would really > like to do (the last thing we want is to be caught by some antivirus, > which monitors activity it considers suspicious and changing > HKEY_LOCAL_MACHINE can easily qualify). > You don't have to touch HKEY_LOCAL_MACHINE, Wine's configuration is in HKEY_CURRENT_USER. And you may use modified WGA (and millions of other) way to detect Wine:-) Note: I still think fixing Wine is better way to go. Jacek

1 0

UpdateWindow doesn't call XFlush
by Michael Kaufmann Aug. 22, 2005

Aug. 22, 2005

Hi all, I've noticed that after an application calls UpdateWindow, the window contents doesn't get updated until the application requests the next event (GetMessage/PeekMessage). That's because UpdateWindow doesn't flush the X output queue (XFlush). I think the best approach would be that UpdateWindow calls GdiFlush, but this function is currently not implemented. The problem is that GdiFlush doesn't get a DC handle, it must figure out itself which DCs it has to flush. Can anyone implement GdiFlush or propose another mechanism on how to call XFlush in UpdateWindow? Regards Michael

1 0

X11: Problems with ConfigureNotify events that are received/processed too late
by Michael Kaufmann Aug. 22, 2005

Aug. 22, 2005

Hi all, I'm trying to get the dialog boxes of Word 95 working. They often appear with the minimal window size (about 70x50 pixels), so they're unusable. With KDE's window manager (KWin) this happens very often. With Enlightenment and GNOME's window manager (Metacity), it only happens from time to time. I've looked for the reason, and I think it's very closely related to WINE bug 1265 which Duane Clark has tried to fix here: http://www.winehq.com/hypermail/wine-patches/2003/02/0095.html That's what's going on (CVS version of WINE, managed window mode): 1. Word creates a dialog with an initial position of (0,0) and size 0x0 (using CreateWindowEx) 2. Word calls SetWindowPos to set the correct dialog position and size 3. Word calls SetWindowPos to show the dialog (SWP_SHOWWINDOW) 4. The dialog gets the focus, the main window is being deactivated 5. In the WM_NCACTIVATE procedure of the main window, Word calls GetQueueStatus. WINE will process X events. 6. WINE receives a ConfigureEvent for the initial dialog position and size (0x0) and saves this to data->whole_rect in X11DRV_sync_window_position (7. If you're lucky, WINE also receives a ConfigureEvent for the correct dialog position) 8. Wine shows the dialog and maps it. It calls X11DRV_set_wm_hints, which calls set_size_hints. This procedure uses data->whole_rect as the dialog's rectangle. But this stored rectangle is completely wrong because WINE has not yet received all ConfigureEvents. 9. The window manager has to resize the dialog to the wrong size. The best solution would be to process all X events before setting the window position in SetWindowPos, but I don't know if that's possible. I've tried another approach: WINE should not set the window size hints when mapping a window (step 8.). I've attached a patch, but it's not 100% correct, because the style of a window (e.g. the WS_THICKFRAME style) may be changed by an application using SetWindowLong and SetWindowPos (with the SWP_FRAMECHANGED flag). WINE doesn't look for the SWP_FRAMECHANGED flag and updates the X11 window every time if it's visible or gets visible. So if an application calls SetWindowPos with the SWP_SHOWWINDOW flag, WINE needs to set the size hints because the window has been hidden and its style may have been changed. What would be the correct fix for this problem? Any ideas? Thanks, Michael Index: window.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/window.c,v retrieving revision 1.115 diff -u -r1.115 window.c --- window.c 27 Jul 2005 15:22:58 -0000 1.115 +++ window.c 15 Aug 2005 21:32:54 -0000 @@ -353,9 +353,9 @@ /*********************************************************************** * X11DRV_set_wm_hints * - * Set the window manager hints for a newly-created window + * Set the window manager hints for a window */ -void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data ) +void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data, BOOL update_size_hints ) { Window group_leader; XClassHint *class_hints; @@ -400,7 +400,7 @@ } /* size hints */ - set_size_hints( display, data, style ); + if (update_size_hints) set_size_hints( display, data, style ); /* systray properties (KDE only for now) */ if (ex_style & WS_EX_TRAYWINDOW) @@ -692,7 +692,7 @@ xim = x11drv_thread_data()->xim; if (xim) data->xic = X11DRV_CreateIC( xim, display, data->whole_window ); - X11DRV_set_wm_hints( display, data ); + X11DRV_set_wm_hints( display, data, TRUE ); SetPropA( data->hwnd, whole_window_prop, (HANDLE)data->whole_window ); return data->whole_window; Index: winpos.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/winpos.c,v retrieving revision 1.136 diff -u -r1.136 winpos.c --- winpos.c 15 Aug 2005 09:33:39 -0000 1.136 +++ winpos.c 15 Aug 2005 21:32:56 -0000 @@ -489,7 +489,7 @@ { TRACE( "mapping win %p\n", hwnd ); X11DRV_sync_window_style( display, data ); - X11DRV_set_wm_hints( display, data ); + X11DRV_set_wm_hints( display, data, FALSE ); wine_tsx11_lock(); XMapWindow( display, data->whole_window ); wine_tsx11_unlock(); @@ -650,7 +650,7 @@ { TRACE( "mapping win %p\n", hwnd ); X11DRV_sync_window_style( display, data ); - X11DRV_set_wm_hints( display, data ); + X11DRV_set_wm_hints( display, data, FALSE ); wine_tsx11_lock(); XMapWindow( display, data->whole_window ); wine_tsx11_unlock(); Index: x11drv.h =================================================================== RCS file: /home/wine/wine/dlls/x11drv/x11drv.h,v retrieving revision 1.76 diff -u -r1.76 x11drv.h --- x11drv.h 29 Jun 2005 19:28:06 -0000 1.76 +++ x11drv.h 15 Aug 2005 21:32:58 -0000 @@ -686,7 +686,7 @@ const RECT *new_whole_rect ); extern BOOL X11DRV_set_window_pos( HWND hwnd, HWND insert_after, const RECT *rectWindow, const RECT *rectClient, UINT swp_flags, const RECT *validRects ); -extern void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data ); +extern void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data, BOOL update_size_hints ); extern void X11DRV_handle_desktop_resize(unsigned int width, unsigned int height); extern void X11DRV_Settings_AddDepthModes(void);

1 1

(no subject)
by John Smith Aug. 22, 2005

Aug. 22, 2005

>You can also set it yourselves in in your app. As configuration >is in registry, every app can modify it. I like this idea, thanks. There are still 2 issues with such a soultion: a) most likely, it won't work until 2nd start of the application (we will modify it on the first run, and it most likely won't be applied until the second run); b) current WINE guides are discouraging us from detecting WINE - and messing up with Windows Registry, especially HKEY_LOCAL_MACHINE, on all the millions of non-WINE machines is not a thing I would really like to do (the last thing we want is to be caught by some antivirus, which monitors activity it considers suspicious and changing HKEY_LOCAL_MACHINE can easily qualify). _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

1 0

Re: X11DRV: more gcc 4.0 warning fixes
by Alexandre Julliard Aug. 22, 2005

Aug. 22, 2005

Mike McCormack <mike(a)codeweavers.com> writes: > Index: dlls/x11drv/event.c > =================================================================== > RCS file: /home/mike/src/wine-cvs/wine/dlls/x11drv/event.c,v > retrieving revision 1.58 > diff -u -p -r1.58 event.c > --- dlls/x11drv/event.c 16 Aug 2005 16:02:45 -0000 1.58 > +++ dlls/x11drv/event.c 17 Aug 2005 01:09:41 -0000 > @@ -698,7 +698,7 @@ static void EVENT_DropFromOffiX( HWND hW > > if( !aux_long && p_data) /* don't bother if > 64K */ > { > - signed char *p = (signed char*) p_data; > + char *p = (char*) p_data; > char *p_drop; > > aux_long = 0; The code is storing -1 in there so it has to be a signed char (though that algorithm is really a nasty hack that should be fixed properly). > --- dlls/x11drv/text.c 23 Dec 2004 20:31:56 -0000 1.15 > +++ dlls/x11drv/text.c 16 Aug 2005 01:53:53 -0000 > @@ -390,7 +390,7 @@ X11DRV_ExtTextOut( X11DRV_PDEVICE *physD > wine_tsx11_lock(); > if (lfUnderline) > { > - long linePos, lineWidth; > + unsigned long linePos, lineWidth; > > if (!XGetFontProperty( font, XA_UNDERLINE_POSITION, &linePos )) > linePos = descent - 1; > @@ -405,7 +405,7 @@ X11DRV_ExtTextOut( X11DRV_PDEVICE *physD > } > if (lfStrikeOut) > { > - long lineAscent, lineDescent; > + unsigned long lineAscent, lineDescent; > if (!XGetFontProperty( font, XA_STRIKEOUT_ASCENT, &lineAscent )) > lineAscent = ascent / 2; > if (!XGetFontProperty( font, XA_STRIKEOUT_DESCENT, &lineDescent )) I think these should remain signed too, especially since lineDescent is set to -lineAscent. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: MSXML: add some node tests
by Alexandre Julliard Aug. 22, 2005

Aug. 22, 2005

Mike McCormack <mike(a)codeweavers.com> writes: > diff -u -p -r1.1 domdoc.c > --- dlls/msxml3/tests/domdoc.c 12 Aug 2005 11:25:05 -0000 1.1 > +++ dlls/msxml3/tests/domdoc.c 20 Aug 2005 07:38:47 -0000 > @@ -27,59 +27,65 @@ > #include "xmldom.h" > #include <stdio.h> > > +#ifndef STANDALONE > #include "wine/test.h" > +#else > +#define ok(cond,str) do{ if(!(cond)) fprintf(stderr,"line %d: %s",__LINE__,str); }while (0) > +#endif Please don't add that sort of thing again, simply copy wine/test.h over to Windows and build with -DSTANDALONE. -- Alexandre Julliard julliard(a)winehq.org

1 0

DDRAW: don't leak visuals
by Saulius Krasuckas Aug. 21, 2005

Aug. 21, 2005

I was walking through a Lionel code (written in 2003) and stumbled at the call to XGetVisualInfo(). The list of visuals it returns is never released. Hence, three lines were added. This is my first X-perience. Does this look OK, folks? Index: dlls/ddraw/device_opengl.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/device_opengl.c,v retrieving revision 1.7 diff -p -u -r1.7 device_opengl.c --- dlls/ddraw/device_opengl.c 11 Aug 2005 10:57:47 -0000 1.7 +++ dlls/ddraw/device_opengl.c 21 Aug 2005 19:58:09 -0000 @@ -4344,12 +4344,14 @@ d3ddevice_init_at_startup(void *gl_handl gl_context = glXCreateContext(display, vis, NULL, GL_TRUE); if (gl_context == NULL) { + XFree(vis); LEAVE_GL(); WARN("Error creating default context for capabilities initialization - D3D support disabled !\n"); return FALSE; } if (glXMakeCurrent(display, drawable, gl_context) == False) { glXDestroyContext(display, gl_context); + XFree(vis); LEAVE_GL(); WARN("Error setting default context as current for capabilities initialization - D3D support disabled !\n"); return FALSE; @@ -4435,6 +4437,7 @@ d3ddevice_init_at_startup(void *gl_handl /* And frees this now-useless context */ glXMakeCurrent(display, None, NULL); glXDestroyContext(display, gl_context); + XFree(vis); LEAVE_GL(); return TRUE;

1 1