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

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

by Alexandre Julliard

"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. -- Alexandre Julliard julliard(a)winehq.org

Feb. 15, 2008

Re: [PATCH 1/2] Add IRunnableTask interface (resend)

by Alexandre Julliard

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> writes: > I have no idea why it wasn't applied, so this is a resend with no modifications. It should go in shobjidl.idl. -- Alexandre Julliard julliard(a)winehq.org

Feb. 15, 2008

Re: systray [4/4]: implement systray transparency

by Alexandre Julliard

"Kirill K. Smirnov" <lich(a)math.spbu.ru> writes: > diff --git a/dlls/winex11.drv/winex11.drv.spec b/dlls/winex11.drv/winex11.drv.spec > index 36b83d7..126cbc5 100644 > --- a/dlls/winex11.drv/winex11.drv.spec > +++ b/dlls/winex11.drv/winex11.drv.spec > @@ -130,6 +130,7 @@ # Desktop > > # System tray > @ cdecl wine_make_systray_window(long) X11DRV_make_systray_window > +@ cdecl wine_systray_window_clear(long) X11DRV_systray_window_clear We don't want to export such a specific function. Besides, it should really be setting the window shape. -- Alexandre Julliard julliard(a)winehq.org

Feb. 15, 2008

Re: [PATCH] winex11.drv: get hwnd for injected mouse events

by Alexandre Julliard

"Lei Zhang" <thestig(a)google.com> writes: > --- a/dlls/winex11.drv/mouse.c > +++ b/dlls/winex11.drv/mouse.c > @@ -278,6 +278,7 @@ void X11DRV_send_mouse_input( HWND hwnd, DWORD flags, DWORD x, DWORD y, > { > pt.x = (x * screen_width) >> 16; > pt.y = (y * screen_height) >> 16; > + hwnd = GetAncestor(WindowFromPoint(pt), GA_PARENT); This should not be needed, for injected events the window is determined on the server side. -- Alexandre Julliard julliard(a)winehq.org

Feb. 15, 2008

Re: winedos: Allocate a console when loading dos applications

by Dmitry Timoshkov

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > Fixes bug 9178. > > I was looking hard at it, then I had to laugh, hard, when I found this > simple fix. This patch is not correct, think for instance of all win16 applications. -- Dmitry.

Feb. 15, 2008

Re: Fixing the last failing tests

by Dmitry Timoshkov

"Dan Kegel" <dank(a)kegel.com> wrote: > The test you submitted that checks this, > http://www.winehq.org/pipermail/wine-patches/2005-July/018839.html > must have passed once on Windows, > but it seems to be failing now; see e.g. > http://test.winehq.org/data/200802131000/xp_rs-winxp-sp2/user32:win.txt > which is full of lines like > win.c:3656: Test failed: IsWindowUnicode expected to return FALSE > > Do you have a Windows system where that test passes currently? I've performed a little investigation trying to find out at which point XP has changed its behaviour. It's pretty much hard taking into account how many broken user32:win.c tests we have at test.winehq.org (all the tests marked as 'failed' are useless). It looks like the change/breakage occured somewhere at the end of October 2007 - beginning of November 2007: http://test.winehq.org/data/200710271000/xp_brainless-20071027/user32:win.t… http://test.winehq.org/data/200710271000/xp_mbv-.48/user32:win.txt don't have failing IsWindowUnicode tests, but http://test.winehq.org/data/200711072209/#XP suite already has them: http://test.winehq.org/data/200711072209/xp_200711SCHOEMB/user32:win.txt -- Dmitry.

Feb. 15, 2008

Re: [RFC] winecfg enhancements

by James McKenzie

Reece Dunn wrote: > On 13/02/2008, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: > >> Reece Dunn <msclrhd <at> googlemail.com> writes: >> >> > I am looking at how we can make winecfg more useful. I have already >> > supplied patches to allow importing a ubuntu human theme to work :). >> > So I am now looking at how to build on that. >> >> I think this could probably do with some consideration >> http://bugs.winehq.org/show_bug.cgi?id=6233 , it describes how the >> Applications tab does not belong among the other tabs because it should be >> higher up in the hierarchy of things. >> > > There are several bugs related to winecfg currently. Also, the Ubuntu > devs have some ideas on improvements to winecfg on their wiki, as well > as some ideas for command line access to winecfg, install/uninstall > and other functionality. > Great. One bug == one bugzilla entry. One enhancement == one bugzilla enhancement entry > Ideally, there should be a winecfg meta-bug, like what we have for 1.0 > and have the various enhancements grouped into relevant bugs. This > will allow attachments (like mockups to be added), as well as tracking > patches and ideas. > There is no metabug for Wine 1.0. There is a query that is run that shows bugs that should be closed/corrected before Wine 1.0 is released > I'll start setting this up, and raising the Ubuntu comments as > enhancements, to better track things and get the usability and > scriptability of wine configuration and management up to where they > should be. > > Again, one bug or one enhancement - one bugzilla entry. Some of the bugs/enhancements should be there before Wine 1.0 is released, some others can wait and others still may never be there. > Does anyone know how to set up the meta bug/group to track these? > > No. Metabugz are not desired for additional functionality. Their purpose should be only to track bugs found in a particular release candidate that will stop a product release. It is undesirable to have a metabug for a series of enhancements. James

Feb. 15, 2008

Re: ddraw / wined3d fighting over the resolution!

by Peter Dons Tychsen

On Thu, 2008-02-14 at 09:18 +0100, Stefan Dösinger wrote: > Am Donnerstag, 14. Februar 2008 04:22:16 schrieb Peter Dons Tychsen: > > Why does the SwapChain-destroy function play around with the resolution > > at all. Is that really necessary? I think it should not do it if the > > caller is ddraw at least. > I thought I'm filtering this out in the case of ddraw, but maybe that got > lost. The reason why the swapchain restores the resolution is the different > way ddraw/d3d8 and d3d8/d3d9 set up the screen. > > In ddraw the app calls IDirectDraw7::SetDisplayMode. This sets the mode. Then > it creates a DDSCAPS_PRIMARYSURFACE surface, which creates the swapchain. > > In d3d8/d3d9 the swapchain controls the video mode > > I think the problem is that RestoreDisplayMode is called before the primary > surface is destroyed. The question is why this happens. I can think of the > following reasons: > > -> Refcounting problem, or the app just doesn't release the surfaces. Then > ddraw.dll destroys the objects on DLL_PROCESS_DETACH > > -> The app calls it that way. This needs a test, but I think it is not allowed > to call SetDisplayMode / RestoreDisplayMode while a primary surface is around OK, i have now eaten enough wine-gums to comprehend this.... I think there is a general problem in swapchain->release. The swapchain should only change the resolution back to the original *if* the current resolution is still the same as the swapchain enforced. If someone else has intervened, it should let it be. This fixes the problem at hand, but would also fix other silly problems. Some could for example have called Release() while the "window" is not even visible (tabbed to desktop for example). Please review my patch and let med know if it is submittable. If you hate it, i will eat more wine-gums. :-) /pedro

Feb. 15, 2008

Re: mscms: [GS]etColorSpace() are not supposed to be defined in icm.h.

by Francois Gouget

On Thu, 14 Feb 2008, Detlef Riekenberg wrote: > On Mi, 2008-02-13 at 21:52 +0100, Francois Gouget wrote: > > > diff --git a/include/icm.h b/include/icm.h > > The end of the attached Patch file is broken: > > > &#;& Actually it's ok, this is just extra padding so no part of the patch is missing. Also, I can export the email here and apply it with patch -p1. Still I admit this series of patches is a little weird, I'll change the git-format-patch command for the next round. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

Feb. 14, 2008

Re: gecko valgrind errors show up better now

by Jacek Caban

Dan Kegel wrote: > The new version of valgrind shows better stack > dumps for gecko valgrind errors. For instance, > > ... > > etc., etc. Jacek, if you can give me a debug build of gecko, > I can probably give you even better info. Interested? > I'm definitely interested. I can see from your examples that at most one of them may be a MSHTML problem. The other ones may be Gecko or some other part's problem. I don't have the debug build on my current machine, so I will send it to you as soon as I will have access to them. Thanks, Jacek

Feb. 14, 2008