April 2008 - Wine-Devel - list.winehq.org

Re: imm: Keep track of context associations between HWND and HIMC

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -93,12 +93,21 @@ typedef struct _tagTRANSMSG { > LPARAM lParam; > } TRANSMSG, *LPTRANSMSG; > > +typedef struct _tagContextAssociation { > + struct list entry; > + > + HWND *hwnds; > + UINT wndCount; > + HIMC context; > +} ContextAssociation; Wouldn't it be a lot easier to store the HIMC in a window property? -- Alexandre Julliard julliard(a)winehq.org

April 1, 2008

Re: Wine Release Plan

by Alexandre Julliard

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > Just noticed that the dates attached to the versions on > http://wiki.winehq.org/WineReleasePlan are not correct. > > 0.9.58 came out on March 21st. > > Does this mean we still stick to May 9th or do we stick to 0.9.61 as being > 1.0.0.rc1? We should stick to May 9th, we'll just have to wait for this date to coincide with a release. If my calculations are right this should be release 0.9.218 on May 9th, 2014. Hopefully we can clear the 1.0 bug list by then. -- Alexandre Julliard julliard(a)winehq.org

April 1, 2008

kernel32: add stub for GetConsoleDisplayMode() et al

by Kirill K. Smirnov

Hi, In the first patch of the series you really implement SetConsoleDisplayMode() instead of GetConsoleDisplayMode(), don't you? And it is dangerous to return success in pure stub functions, especially GetConsoleDisplayMode(). Returning FALSE and setting last error to ERROR_CALL_NOT_IMPLEMENTED will be much better. -- Kirill

April 1, 2008

Re: d3d9: Add some visual tests for Direct3DDevice9_StretchRect()

by Stefan Dösinger

Am Dienstag, 1. April 2008 07:20:44 schrieb Jason Green: Did you take a look at the various capability flags? I think the test as you submitted it is correct for dx9 level cards and drivers, but there are a few capability flags like D3DDEVCAPS2_CANSTRETCHRECTFROMTEXTURE or similar. Also some drivers seem to refuse StretchRecting between offscreenplain surfaces, even if no stretching is used. Do you have any ideas what the scheme behind the allowed/forbidden blits is? So far I can see this: -> Blitting to a rendertarget surface/texture is always OK -> blitting between offscreen surfaces is ok as long as no stretching occurs -> blitting to non-RT surfaces/textures faily, except the above Did you test blitting from/to sysmem surfaces? The msdn says both must be D3DPOOL_DEFAULT as far as I remember

April 1, 2008

Re: Hey all, introducing myself and my GSoC idea...

by Robert Shearman

James Hawkins wrote: > On Mon, Mar 31, 2008 at 8:11 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > >> Personally, I've thought that playing around with the >> native LPC API might be interesting. I'm sure there are other areas >> of the native API that are sparsely documented, and for which some >> test cases might prove useful. >> > > But is the API in question useful for the Wine project as far as > fixing apps? I don't think we should devote SOC resources to a > project that doesn't progress Wine beyond just implementing more APIs. It is useful for getting native rpcrt4 to work, which in turn is useful for getting other COM DLLs to work, and so is potentially useful for bug triage and identifying the source of bugs in builtin COM DLLs. -- Rob Shearman

April 1, 2008

Re: [Bug 3297] UpdateWindow() doesn't call XFlush()

by James Hawkins

On Tue, Apr 1, 2008 at 3:15 AM, <wine-bugs(a)winehq.org> wrote: > http://bugs.winehq.org/show_bug.cgi?id=3297 > > > Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Keywords|patch | > > > > > --- Comment #6 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2008-04-01 03:15:06 --- > The patch is obviously incorrect, so it doesn't count. > There are a lot of bugs with incorrect patches that have the patch keyword. The patch keyword is not to make sure that all bug reports with correct patches attached get those patches submitted and committed. The point of the keyword is to alert developers to a source of information. A user attaches a patch and says, "this makes the app work." Even if the patch is wrong, a developer can see what change makes the app work, and this can potentially help the developer write a correct patch. -- James Hawkins

April 1, 2008

Wine Release Plan

by Paul Vriens

Hi, Just noticed that the dates attached to the versions on http://wiki.winehq.org/WineReleasePlan are not correct. 0.9.58 came out on March 21st. Does this mean we still stick to May 9th or do we stick to 0.9.61 as being 1.0.0.rc1? -- Cheers, Paul.

April 1, 2008

Re: Greek translation patch correction

by James Hawkins

2008/3/31 Dj Apal [GR] <djapal(a)gmail.com>: > Here are the separate patches as requested by James Hawkins > One patch per email. I see that's not on the sending_patches page...man our documentation is in such bad shape (and scattered all over the place). -- James Hawkins

April 1, 2008

Re: user32: Implement GetWindowModuleFileName with tests (try 2)

by Dmitry Timoshkov

"Dmitry Timoshkov" <dmitry(a)codeweavers.com> wrote: >> This won't work across processes. > > Looks like GetWindowModuleFileName is not supposed to work for other > process windows, at least in the following snippet both GetWindowLongPtr > and GetWindowModuleFileName return 0 but don't change the last error value > under XP although FindWindow returns a valid window handle: AF in the bug 10002 pointed out to http://support.microsoft.com/kb/228469 which explains that. -- Dmitry.

April 1, 2008

Re: user32: Implement GetWindowModuleFileName with tests (try 2)

by Dmitry Timoshkov

"Alexandre Julliard" <julliard(a)winehq.org> wrote: > "Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> writes: > >> @@ -3121,9 +3133,21 @@ UINT WINAPI GetWindowModuleFileNameA( HWND hwnd, LPSTR lpszFileName, UINT cchFil >> */ >> UINT WINAPI GetWindowModuleFileNameW( HWND hwnd, LPWSTR lpszFileName, UINT cchFileNameMax) >> { >> - FIXME("GetWindowModuleFileNameW(hwnd %p, lpszFileName %p, cchFileNameMax %u) stub!\n", >> - hwnd, lpszFileName, cchFileNameMax); >> - return 0; >> + HINSTANCE hInst; >> + UINT ret; >> + TRACE("hwnd %p, lpszFileName %p, cchFileNameMax %u\n", hwnd, lpszFileName, cchFileNameMax); >> + >> + hInst = (HINSTANCE)GetWindowLongPtrW(hwnd, GWLP_HINSTANCE); >> + if (!hInst) >> + { >> + if (hwnd == GetDesktopWindow() || !IsWindow(hwnd)) >> + return 0; >> + hInst = GetModuleHandleW(0); >> + } >> + >> + ret = GetModuleFileNameW(hInst, lpszFileName, cchFileNameMax); >> + TRACE("--> %d %s\n", ret, debugstr_wn(lpszFileName, ret)); >> + return ret; > > This won't work across processes. Looks like GetWindowModuleFileName is not supposed to work for other process windows, at least in the following snippet both GetWindowLongPtr and GetWindowModuleFileName return 0 but don't change the last error value under XP although FindWindow returns a valid window handle: hwnd = FindWindow("Shell_TrayWnd", NULL); SetLastError(0xdeadbeef); ret = GetWindowModuleFileNameA(hwnd, buf, sizeof(buf)); printf("hwnd %p, ret %u, buf \"%s\", error %u\n", hwnd, ret, buf, GetLastError()); SetLastError(0xdeadbeef); hinst = (HINSTANCE)GetWindowLongPtr(hwnd, GWLP_HINSTANCE); printf("hwnd %p, hinst %u, error %u\n", hwnd, ret, GetLastError()); GetWindowLong(hwnd, GWL_STYLE) returns a valid style. Both APIs behave the same way for the desktop window. So the above implementation of GetWindowModuleFileName looks correct except a special case for the desktop window (GetWindowLong() should be fixed instead). -- Dmitry.

April 1, 2008