January 2010 - Wine-devel - list.winehq.org

Re: ukrainian-credui
by Paul Vriens 25 Jan '10

25 Jan '10

On 01/24/2010 09:23 PM, гор Хакер wrote: > ukrainian-credui > Hi, If you send a second (or higher) revision of a patch please mark it as such. For example "(Try x)" at the end. This makes it easier to discard older ones. This one supersedes the one that didn't have the pragma for example. A nicer subject would be appreciated as well. "ukrainian-credui" suggests it's a translation but why not say something like "Adding Ukrainian translations to credui" or "Fixed ...". I'm not sure if our automated patch watcher (http://source.winehq.org/patches/) can cope with non-ascii characters in the "From:" field but your patches don't show up over there. Have a look at http://wiki.winehq.org/SubmittingPatches. Your email address for this mail is different from the generated one in the patch attached to that email and the names are again different from the copyright name in the file itself. -- Cheers, Paul.

4 4

Re: [PATCH 1/2] user32/tests/win.c: Fix Win9x detection
by Dmitry Timoshkov 25 Jan '10

25 Jan '10

Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> wrote: > The current code misdetects both Windows XP and Wine as Win9x and skips > some tests due to this. The SetParent tests were not passing on XP, so > this patch also removes the tests that fail on XP SP3. These should be 2 separate patches. And according to http://test.winehq.org/data/e2af560aa3c23a672d8680f91f3e1b8793d5827f/index_… SetParent tests pass under XP just fine. -- Dmitry.

3 6

Re: [PATCH 1/4] [Include]: push/pop pack fixes on 64 bit platforms
by Alexandre Julliard 25 Jan '10

25 Jan '10

Eric Pouech <eric.pouech(a)orange.fr> writes: > diff --git a/include/commctrl.h b/include/commctrl.h > index 27bd745..c841d51 100644 > --- a/include/commctrl.h > +++ b/include/commctrl.h > @@ -2245,7 +2245,9 @@ static const WCHAR WC_PAGESCROLLERW[] = { 'S','y','s','P','a','g','e','r',0 }; > #define PGN_SCROLL (PGN_FIRST-1) > #define PGN_CALCSIZE (PGN_FIRST-2) > > +#ifdef _WIN32 > #include <pshpack1.h> > +#endif That's broken, testing _WIN32 is not useful in Wine. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] wined3d: Add support for EXT_gpu_shader4 provided sampling functions with explicit derivatives.
by Stefan Dösinger 25 Jan '10

25 Jan '10

Am 24.01.2010 um 21:16 schrieb Henri Verbeet: > if(texrect) { > if(lod) { > sample_function->name = projected ? "texture2DRectProjLod" : "texture2DRectLod"; > - } else if(grad) { > - sample_function->name = projected ? "texture2DRectProjGradARB" : "texture2DRectGradARB"; > - } else { > + } > + else if (grad) > + { > + if (gl_info->supported[EXT_GPU_SHADER4]) > + sample_function->name = projected ? "texture2DRectProjGrad" : "texture2DRectGrad"; > + else if (gl_info->supported[ARB_SHADER_TEXTURE_LOD]) > + sample_function->name = projected ? "texture2DRectProjGradARB" : "texture2DRectGradARB"; > + else > + { > + FIXME("Unsupported RECT grad function.\n"); > + sample_function->name = "unsupported2DRectGrad"; > + } > + } > + else > + { > sample_function->name = projected ? "texture2DRectProj" : "texture2DRect"; > } > } else { I think these if constructs in shader_glsl_get_sample_function are becoming ugly with more and more possibilities added. Isn't there a nicer way, like a table that is either searched, or a multi-dimensional array to look up the end result?

2 1

Re: Fix use of uninitialized variable in dlls/advapi32/tests/eventlog.c
by Paul Vriens 25 Jan '10

25 Jan '10

On 01/25/2010 12:21 PM, Vladimir Pankratov wrote: > Hello all. > > Fix use of uninitialized variable in dlls/advapi32/tests/eventlog.c > > changed files: > dlls/advapi32/tests/eventlog.c > > Thanks. > This is the same patch as you've sent a month ago. This doesn't happen on a clean .wine as there we would never reach this test. The fix should be in the implementation, as initializing 'needed' would only hide the problem. What I'm saying is that an app doesn't need to initialize 'needed' before calling ReadEventLogA. -- Cheers, Paul.

1 0

shell32: SHELL_execute() tries to extract program name and arguments from SHELLEXECUTEINFOW.lpFile
by Илья Басин 25 Jan '10

25 Jan '10

At first sight there's a strange behavior in SHELL_execute() (read ShellExecuteEx() ): at tries to extract program path and arguments from SHELLEXECUTEINFOW.lpFile, if it's unquoted. http://source.winehq.org/source/dlls/shell32/shlexec.c?v=wine-1.1.37#L1709 On WinXP at least ShellExecuteExA() doesn't do it/ haven't yet tested with ShellExecuteExW(). This is harmful when you have 2 documents like "C:\aaa.txt" and "C:\aaa.txt bbb.txt" Found an old thread about this, but it seems abandoned. http://www.mail-archive.com/wine-devel(a)winehq.org/msg57246.html

1 0

strsafe.h?
by Dan Kegel 25 Jan '10

25 Jan '10

http://msdn.microsoft.com/en-us/library/bb288454.aspx encourages people to use the functions in strsafe.h. (They're inline by default, and optionally available as a static library.) Neither Wine nor mingw currently ship this header. There are a few copies floating around, though: http://baseutils.googlecode.com/svn/trunk/str_strsafe.h http://github.com/janneke/gub/blob/76e5823756ea1eda37542808a82d784df4a20ee2… And then there's the massively more complete one from the mingw-w64 project: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-heade… Can we just use that one directly? - Dan

1 0

Re: [PATCH 1/2] ws2_32: use ntstatus in overlapped functions (try 3)
by Mike Kaplinskiy 24 Jan '10

24 Jan '10

On Fri, Jan 22, 2010 at 6:46 PM, Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> wrote: > Also some style fixes. Sorry for the fuss over this :) > --- > dlls/ws2_32/socket.c | 45 ++++++++++++++++++++++++++++++++++----------- > 1 files changed, 34 insertions(+), 11 deletions(-) > Don't even look at this patch, didn't mean to send it (yet). Mike.

1 0

Re: winex11.drv: Added missing mouse position clipping. (try 2)
by Lauri Kenttä 24 Jan '10

24 Jan '10

> The SetCursorPos() calls hooks on Wine because Wine has big issue - it doesn't filter pointer move messages that were caused by Wine itself. The first patch (http://source.winehq.org/patches/data/57569) tries to address exactly this. I think XWarpCursor is not a problem, as the event comes asynchronously with some delay. So my patch fixes the easier but worse case, calling hooks directly from SetCursorPos. What's wrong with this, why is it wrong, and do you have a better idea? What else causes Wine to produce extra messages? Also, is there a reason why I shouldn't write a test for this to make the issue better known? >> I'm aware that my version causes hooks to be called with clipped coordinates on mouse move, when they should in that case be called with the unclipped ones. > This particular change will break all games using dinput when mouse pointer goes outside of virtual desktop. (This was the elaboration I was asking for.) I didn't know that, and I don't have any such games. Feel free to reject the patch, I'll rewrite it without this bug and in smaller chunks. (It would be helpful if the first two patches were also either accepted or rejected.) >> returns unclipped coordinates from GetCursorPos > This is what native will do inside hook handler. Add some tests. That's not true. (See below.) >> and even sends incorrect WM_* messages. > Tests please. I've attached a program that outputs coordinates from hookproc and wndproc, both the passed ones and the ones from GetCursorPos. If you try it, you can see that Wine has the following bugs: - incorrect coordinates in some WM:s - incorrect coordinates in some hook calls - incorrect coordinates and missing WM:s after clipping - extra hook calls on SetCursorPos, even if the pos doesn't change - extra WM_MOUSEMOVE after zero-length moves - some other extra hook calls and WM:s due to XWarpPointer The next snippets show the WM bug and how GetCursorPos works inside hook handlers. This first one is from Win2k8 Server. First, the pointer is at (34,34) and clipping is set to (30,30)-(40,40). Then the program calls mouse_event(MOUSEEVENTF_LEFTUP | MOUSEEVENTF_MOVE, 0, 6, 0, 0). 11: hookproc: WM_MOUSEMOVE: (34,40), get = (34,34), injected = 1 11: hookproc: WM_LBUTTONUP: (34,39), get = (34,39), injected = 1 11: wndproc: WM_MOUSEMOVE: (34,39), get = (34,39) 11: wndproc: WM_LBUTTONUP: (34,39), get = (34,39) As you can see, the correct order would be: - call hooks for moving, return old pos from GetCursorPos - clip and store the new position - send the move message using the new position - call hooks and send the button message, both using the clipped position Compare to current Wine output: 11: hookproc: WM_MOUSEMOVE: (34,40), get = (34,34), injected = 1 11: hookproc: WM_LBUTTONUP: (34,40), get = (34,39), injected = 1 11: hookproc: WM_MOUSEMOVE: (34,39), get = (34,39), injected = 0 11: wndproc: WM_MOUSEMOVE: (34,40), get = (34,39) 11: wndproc: WM_LBUTTONUP: (34,40), get = (34,39) 11: wndproc: WM_MOUSEMOVE: (34,39), get = (34,39) Aside of the extra move caused by XWarpPointer, the second hook and both injected messages have incorrect (unclipped) coordinates. > What exactly is wrong with [border scrolling]? Many games (for example, Baldur's Gate) check for mouse coordinates. If the pointer is outside the virtual desktop, Wine gives negative coordinates and the game doesn't scroll left/up, because x != 0 and y != 0. The same thing happens to right/bottom, of course. Correct clipping fixes it. > Who said that Wine should keep the pointer inside virtual desktop? Ok, I'll not do it. But don't you think it's a bit confusing if the pointer moves freely but the program thinks it's clipped to an area? My apologies for bringing up something that is actually none of my business, but I think you should pay more attention to the way you write your comments. First, even small positive comments are considered psychologically very important, but you have given none. Second, most of your negative feedback has only stated that the patches are bad and wrong, often without giving much details or any better ideas. That is, the comments haven't been very constructive. Currently your messages look a bit like "f*** off, noob", which hopefully is not what you had in mind. Anyway, this is certainly not a good way to encourage spending time to Wine development. Some (luckily not me) would take it badly and just rm -rf wine-git and never try again, even if they could be a great help with some guidance. So let's all be nice to each other, and everyone will be happier. -- Lauri Kenttä

4 6

Re: [PATCH 2/8] d3d10: Parse shaders in parse_fx10_local_variable().
by Rico Schüller 24 Jan '10

24 Jan '10

Am 24.01.2010 11:22, schrieb Rico Schüller: > --- > dlls/d3d10/effect.c | 37 +++++++++++++++++++++++++++++++++---- > 1 files changed, 33 insertions(+), 4 deletions(-) > > > > > This patch has a bug in it, it doesn't check the return value. Please don't apply it, I'll send an improved version.

1 0