March 2008 - Wine-devel - list.winehq.org

Re: user32: Fix enumeration and add tests for EnumWindowStations and EnumDesktops, try X
by Alexandre Julliard 11 Mar '08

11 Mar '08

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> writes: > +static BOOL CALLBACK windowstationcallbackA(LPSTR winsta, LPARAM lp) > +{ > + trace("windowstationcallbackA called with argument %s\n", winsta); > + return lp; > +} > + > +static BOOL CALLBACK openwindowstationcallbackA(LPSTR winsta, LPARAM lp) > +{ Please use underscores to separate words in function names, theselongstringswithoutspacesarepainfultoread. -- Alexandre Julliard julliard(a)winehq.org

1 0

DestroyWindow behavior differences between Win9x and Win2k/xp
by Justin Chevrier 11 Mar '08

11 Mar '08

Hey guys, I'm looking into a crash of Master Of Orion II on exit (both in Wine and Windows XP). The problem appears to be that the program is attempting to do a DestroyWindow on a different thread. This is not allowed by our code and that behavior is backed up by MSDN documentation. This behavior was allowed on Windows 9x however. I have confirmed that removing the thread check allows the app to exit cleanly, but of course that is not an acceptable fix. As this is a full screen app the game's window stays on top in a partially drawn state and exiting requires doing an alt-tab to the console. Opinions on the correct course of action to resolve this? Thanks Justin Chevrier

4 5

Future Wine Weekly Newsletters
by Zachary Goldberg 11 Mar '08

11 Mar '08

Wine, I normally would like to have WWNs ready by Sunday night to be posted on Monday but as you can tell i'm going to slip by a day or two again this week. A proposal was mentioned to me to make WWNs perhaps bi-weekly, either coordinating with the week of releases or the off week. This would have a couple immediate pros and cons that I can see: pros *More articles and posts for me to sift through, pick out the more important and relevent articles. Slightly higher overall W(B)WN quality. *It'd be much easier for me to be on time with them. cons *Fewer wwns *Perhaps slightly bigger wwns, i don't know what general consensus is on preffered newsletter length Thoughts? Either way i'de like to have 343 ready and submitted sometime tomorrow evening. --Zach

3 2

Re: make LoadStringW pass tests (fixed merge conflict)
by James Hawkins 10 Mar '08

10 Mar '08

On Wed, Mar 5, 2008 at 11:58 AM, Christopher <raccoonone(a)procyongames.com> wrote: > resubmitting my patch to resolve a merge conflict with the latest GIT > > Christopher Berner > > From 47a770102acf010834899489416e92fd4f79ffd1 Mon Sep 17 00:00:00 2001 > From: Christopher Berner <raccoonone(a)procyongames.com> > Date: Wed, 5 Mar 2008 09:28:26 -0800 > Subject: [PATCH] make LoadStringW pass conformance tests > > --- > dlls/crypt32/oid.c | 3 ++- > dlls/hhctrl.ocx/help.c | 4 ++-- > dlls/mpr/wnet.c | 3 ++- > dlls/user32/resource.c | 14 +++++++++++++- > dlls/user32/tests/resource.c | 29 +++++++++++------------------ > 5 files changed, 30 insertions(+), 23 deletions(-) > > diff --git a/dlls/crypt32/oid.c b/dlls/crypt32/oid.c > index 5d17997..edd9732 100644 > --- a/dlls/crypt32/oid.c > +++ b/dlls/crypt32/oid.c > @@ -1402,8 +1402,9 @@ static void init_oid_info(HINSTANCE hinst) > } > else > { > + LPWSTR junkpointer; /* third argument cannot be NULL, to receive length of resource from LoadStringW */ > int len = LoadStringW(hinst, (UINT_PTR)oidInfoConstructors[i].pwszName, > - NULL, 0); > + (LPWSTR)&junkpointer, 0); > Why don't you just name the new parameter the same name as the function parameter ('buffer' or some variation)? junkpointer is a terrible variable name. -- James Hawkins

3 3

re: DestroyWindow behavior differences between Win9x and Win2k/xp
by Dan Kegel 10 Mar '08

10 Mar '08

Maybe writing a test showing that the cross-thread behavior is required on win9x would be a good next step?

1 0

Fwd: Re: RegOverridePredefKey stub - Take 2
by Jens Nestler 10 Mar '08

10 Mar '08

Hello, six weeks ago I've sent this patch for a basic implementation of the RegOverridePredefKey function. Unfortunately the patch was not considered till now. Can everybody help me ? Jens

2 2

re: Processes and ioctl's
by Dan Kegel 10 Mar '08

10 Mar '08

Maarten wrote: > I am hitting a snag with moving ioctl handling into mount manager. It might be good to review for the group why you're moving ioctl handling. Context is always helpful.

1 0

Re: ddraw: Implement ForceRefreshRate registry entry for overriding DirectX refresh rate
by Denver Gingerich 10 Mar '08

10 Mar '08

On Mon, Mar 10, 2008 at 12:44 PM, Denver Gingerich <denver(a)ossguy.com> wrote: > The DirectX refresh rate override feature that this patch implements is described in main.c below. > > In order for the override to take effect only on SetDisplayMode and not on RestoreDisplayMode it was necessary to move the functionality of SetDisplayMode into a helper function (IDirectDrawImpl_SetDisplayModeNoOverride) and let IDirectDrawImpl_SetDisplayMode and IDirectDrawImpl_RestoreDisplayMode call the helper function. > > Denver Gingerich > > > diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c > index 4cac55d..0f7eeaf 100644 > --- a/dlls/ddraw/ddraw.c > +++ b/dlls/ddraw/ddraw.c > @@ -3,6 +3,7 @@ > * Copyright 1998-2000 Lionel Ulmer > * Copyright 2000-2001 TransGaming Technologies Inc. > * Copyright 2006 Stefan Dösinger > + * Copyright 2008 Denver Gingerich > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -60,6 +61,9 @@ static const DDDEVICEIDENTIFIER2 deviceidentifier = > 0 > }; > > +/* in main.c; stores value of ForceRefreshRate */ > +extern DWORD force_refresh_rate; > + > /***************************************************************************** > * IUnknown Methods > *****************************************************************************/ > @@ -534,34 +538,24 @@ IDirectDrawImpl_SetCooperativeLevel(IDirectDraw7 *iface, > } > > /***************************************************************************** > - * IDirectDraw7::SetDisplayMode > * > - * Sets the display screen resolution, color depth and refresh frequency > - * when in fullscreen mode (in theory). > - * Possible return values listed in the SDK suggest that this method fails > - * when not in fullscreen mode, but this is wrong. Windows 2000 happily sets > - * the display mode in DDSCL_NORMAL mode without an hwnd specified. > - * It seems to be valid to pass 0 for With and Height, this has to be tested > - * It could mean that the current video mode should be left as-is. (But why > - * call it then?) > + * Helper function for SetDisplayMode and RestoreDisplayMode > * > - * Params: > - * Height, Width: Screen dimension > - * BPP: Color depth in Bits per pixel > - * Refreshrate: Screen refresh rate > - * Flags: Other stuff > - * > - * Returns > - * DD_OK on success > + * Implements DirectDraw's SetDisplayMode, but ignores the value of > + * ForceRefreshRate, since it is already handled by > + * IDirectDrawImpl_SetDisplayMode. RestoreDisplayMode can use this function > + * without worrying that ForceRefreshRate will override the refresh rate. For > + * argument and return value documentation, see > + * IDirectDrawImpl_SetDisplayMode. > * > *****************************************************************************/ > -static HRESULT WINAPI > -IDirectDrawImpl_SetDisplayMode(IDirectDraw7 *iface, > - DWORD Width, > - DWORD Height, > - DWORD BPP, > - DWORD RefreshRate, > - DWORD Flags) > +static HRESULT > +IDirectDrawImpl_SetDisplayModeNoOverride(IDirectDraw7 *iface, > + DWORD Width, > + DWORD Height, > + DWORD BPP, > + DWORD RefreshRate, > + DWORD Flags) > { > ICOM_THIS_FROM(IDirectDrawImpl, IDirectDraw7, iface); > WINED3DDISPLAYMODE Mode; > @@ -616,6 +610,46 @@ IDirectDrawImpl_SetDisplayMode(IDirectDraw7 *iface, > } > > /***************************************************************************** > + * IDirectDraw7::SetDisplayMode > + * > + * Sets the display screen resolution, color depth and refresh frequency > + * when in fullscreen mode (in theory). > + * Possible return values listed in the SDK suggest that this method fails > + * when not in fullscreen mode, but this is wrong. Windows 2000 happily sets > + * the display mode in DDSCL_NORMAL mode without an hwnd specified. > + * It seems to be valid to pass 0 for With and Height, this has to be tested > + * It could mean that the current video mode should be left as-is. (But why > + * call it then?) > + * > + * Params: > + * Height, Width: Screen dimension > + * BPP: Color depth in Bits per pixel > + * Refreshrate: Screen refresh rate > + * Flags: Other stuff > + * > + * Returns > + * DD_OK on success > + * > + *****************************************************************************/ > +static HRESULT WINAPI > +IDirectDrawImpl_SetDisplayMode(IDirectDraw7 *iface, > + DWORD Width, > + DWORD Height, > + DWORD BPP, > + DWORD RefreshRate, > + DWORD Flags) > +{ > + if (force_refresh_rate != 0) > + { > + TRACE("ForceRefreshRate overriding passed-in refresh rate (%d Hz) to %d Hz\n", RefreshRate, force_refresh_rate); > + RefreshRate = force_refresh_rate; > + } > + > + return IDirectDrawImpl_SetDisplayModeNoOverride(iface, Width, Height, BPP, > + RefreshRate, Flags); > +} > + > +/***************************************************************************** > * IDirectDraw7::RestoreDisplayMode > * > * Restores the display mode to what it was at creation time. Basically. > @@ -642,12 +676,12 @@ IDirectDrawImpl_RestoreDisplayMode(IDirectDraw7 *iface) > ICOM_THIS_FROM(IDirectDrawImpl, IDirectDraw7, iface); > TRACE("(%p)\n", This); > > - return IDirectDraw7_SetDisplayMode(ICOM_INTERFACE(This, IDirectDraw7), > - This->orig_width, > - This->orig_height, > - This->orig_bpp, > - 0, > - 0); > + return IDirectDrawImpl_SetDisplayModeNoOverride(ICOM_INTERFACE(This, IDirectDraw7), > + This->orig_width, > + This->orig_height, > + This->orig_bpp, > + 0, > + 0); > } > > /***************************************************************************** > diff --git a/dlls/ddraw/main.c b/dlls/ddraw/main.c > index 4e77d4f..a33cb34 100644 > --- a/dlls/ddraw/main.c > +++ b/dlls/ddraw/main.c > @@ -4,6 +4,7 @@ > * Copyright 1998 Lionel Ulmer > * Copyright 2000-2001 TransGaming Technologies Inc. > * Copyright 2006 Stefan Dösinger > + * Copyright 2008 Denver Gingerich > * > * This file contains the (internal) driver registration functions, > * driver enumeration APIs and DirectDraw creation functions. > @@ -68,6 +69,9 @@ static CRITICAL_SECTION_DEBUG ddraw_cs_debug = > }; > CRITICAL_SECTION ddraw_cs = { &ddraw_cs_debug, -1, 0, 0, 0, 0 }; > > +/* value of ForceRefreshRate */ > +DWORD force_refresh_rate = 0; > + > /*********************************************************************** > * > * Helper function for DirectDrawCreate and friends > @@ -886,6 +890,38 @@ DllMain(HINSTANCE hInstDLL, > } > } > > + /* On Windows one can force the refresh rate that DirectDraw uses by > + * setting an override value in dxdiag. This is documented in KB315614 > + * (main article), KB230002, and KB217348. By comparing registry dumps > + * before and after setting the override, we see that the override value > + * is stored in HKLM\Software\Microsoft\DirectDraw\ForceRefreshRate as a > + * DWORD that represents the refresh rate to force. We use this > + * registry entry to modify the behavior of SetDisplayMode so that Wine > + * users can override the refresh rate in a Windows-compatible way. > + * > + * dxdiag will not accept a refresh rate lower than 40 or higher than > + * 120 so this value should be within that range. It is, of course, > + * possible for a user to set the registry entry value directly so that > + * assumption might not hold. > + * > + * There is no current mechanism for setting this value through the Wine > + * GUI. It would be most appropriate to set this value through a dxdiag > + * clone, but it may be sufficient to use winecfg. > + * > + * TODO: Create a mechanism for setting this value through the Wine GUI. > + */ > + if ( !RegOpenKeyA( HKEY_LOCAL_MACHINE, "Software\\Microsoft\\DirectDraw", &hkey ) ) > + { > + DWORD type, data; > + size = sizeof(data); > + if (!RegQueryValueExA( hkey, "ForceRefreshRate", NULL, &type, (LPBYTE)&data, &size ) && type == REG_DWORD) > + { > + TRACE("ForceRefreshRate set; overriding refresh rate to %d Hz\n", data); > + force_refresh_rate = data; > + } > + RegCloseKey( hkey ); > + } > + > DisableThreadLibraryCalls(hInstDLL); > } > else if (Reason == DLL_PROCESS_DETACH) This patch differs from my previous patch [1] in the following ways: a) DDRAW_SetDisplayMode renamed to IDirectDrawImpl_SetDisplayModeNoOverride b) sentence in main.c description changed from "To ensure compatibility with Windows, we use this registry entry to modify the behavior of SetDisplayMode." to "We use this registry entry to modify the behavior of SetDisplayMode so that Wine users can override the refresh rate in a Windows-compatible way." Hopefully these changes are sufficient for the patch to be accepted. Please let me know if there are further concerns with it. Thanks. Denver 1. http://www.winehq.org/pipermail/wine-patches/2008-March/051213.html

1 0

Fixed function pipeline replacement infrastructure follow up
by Stefan Dösinger 10 Mar '08

10 Mar '08

Hi, As a follow up to the mail from last Sunday I now have a concrete implementation suggestion for an infrastructure for a fixed function pipeline replacement: What it mainly does is that it makes the state table a property of the shader backend, as well as the shader caps to keep GetDeviceCaps simpler. It also adds rudimentary functions for comparing the fixed function fragment processing settings. As an example implementation, the patchset is constructed around a fragment pipeline implementation using GL_ATI_fragment_shader. What is missing is dealing with vertex states, Henri has some code for that already. The data structure and comparison of pipeline states needs optimization. The already existing pipeline replacement using GL_NV_register_combiners and GL_NV_texture_shader should be moved into a separate shader backend. And obviously an implementation of vertex and fragment pipeline using ARB shaders and GLSL(that could be done as a gsoc project maybe) The GL_ATI_fragment_shader code is constructed bottom-up, so if the patches are applied as-is, it will lead to a temporary regression on ATI cards. Inverting this would be a major pain, so when sending it in I'll keep the extension disabled in patch 1, and enable it in a final last patch. The GL_NV_* stuff will work a bit different than atifs, arb and glsl, since we can configure all texture stages individually, so a stored program and state comparison is not needed. Instead we can keep the set_tex_op as it is, but the if(GL_SUPPORTED(...)) checks and related nastiness can be factored out. Maybe we can also get rid of setting up the texunit map every draw in some cases.

1 1

Re: shell32: Support getting the shell folder path for users other than the current user and the default user (take 3)
by Alexandre Julliard 10 Mar '08

10 Mar '08

"Ge van Geldorp" <ge(a)thinstall.com> writes: > Changelog: > Juan Lang <juan.lang(a)gmail.com> > Ge van Geldorp <ge(a)thinstall.com> > Support getting the shell folder path for users other than the current > user and the default user > Fixes bug 10905 You are leaking memory now. -- Alexandre Julliard julliard(a)winehq.org

1 0