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

Re: ddraw: Fix missing D3D misc caps
by Stefan Dösinger 03 May '10

03 May '10

Am 02.05.2010 um 22:07 schrieb Ričardas Barkauskas: > Fixes missing D3D misc caps needed by Independence War 2: Edge Of Chaos (bug 7012) The patch seems ok

1 0

Re: [ddraw] Fix discrepancy in alpha mask for WINED3DFMT_B2G3R3A8_UNORM.
by Stefan Dösinger 03 May '10

03 May '10

Am 02.05.2010 um 08:26 schrieb Vincent Pelletier: > > PixelFormat_DD2WineD3D returns WINED3DFMT_B2G3R3A8_UNORM when alpha mask > is 0xFF00, which is consistent with constant name (A8). The patch looks ok to me.

1 0

Re: [PATCH] Fix Unicode escape string occurring when calling GetClipboardData(CF_TEXT).
by Dmitry Timoshkov 03 May '10

03 May '10

Sin-ta Hsiea <ibmibmibm.tw(a)gmail.com> wrote: > Here's a patch that fetch UTF8 string, and convert to local codepage. > + count = WideCharToMultiByte(CP_OEMCP, 0, lpwstr, -1, NULL, 0, NULL, NULL); > + hText = GlobalAlloc(GMEM_MOVEABLE | GMEM_DDESHARE, count); > + > + if (hText) > + { > + CHAR *text = GlobalLock(hText); > + WideCharToMultiByte(CP_OEMCP, 0, lpwstr, -1, text, -1, NULL, NULL); > + GlobalUnlock(hText); > + } CP_OEMCP is not a local codepage. -- Dmitry.

1 0

Re: [Wine] Potential bug in RtlRegisterWait()
by Joakim Tjernlund 03 May '10

03 May '10

Charles Davis <cdavis(a)mymail.mines.edu> wrote on 2010/05/03 01:18:25: > > On 5/2/10 3:02 PM, Joakim Tjernlund wrote: > > > > Noticed that RtlRegisterWait() will approve a zero timeout value(Milliseconds == 0) > > > > This makes ies4linux spin the CPU 100% when visiting a > > https page. The below crude patch fixes it: > > > > --- dlls/ntdll/threadpool.c.org 2010-05-02 22:37:08.000000000 +0200 > > +++ dlls/ntdll/threadpool.c 2010-05-02 22:46:45.000000000 +0200 > > @@ -427,6 +427,9 @@ > > > > TRACE( "(%p, %p, %p, %p, %d, 0x%x)\n", NewWaitObject, Object, Callback, > Context, Milliseconds, Flags ); > > > > + if (!Milliseconds) > > + return RPC_NT_INVALID_TIMEOUT; > > + > > wait_work_item = RtlAllocateHeap( GetProcessHeap(), 0, sizeof(*wait_work_item) ); > > if (!wait_work_item) > > return STATUS_NO_MEMORY; > > > > On a related note, whitout this patch wineserver also goes into an endless > > loop, doing brk() calls over and over until memory is exausted. Seems > > like a bug that too. > This looks like something you should post to wine-devel. Right, posting there but with a new patch. I think the orginal fix was wrong. Here is a new one: >From 2f5e169e286265bb82b17f76023c463bc2a96703 Mon Sep 17 00:00:00 2001 From: Joakim Tjernlund <Joakim.Tjernlund(a)transmode.se> Date: Mon, 3 May 2010 09:03:09 +0200 Subject: [PATCH] RegisterWaitForSingleObjectX(), fix tmo == 0 Timeout == 0 is special, from the manual: The time-out interval, in milliseconds. The function returns if the interval elapses, even if the object's state is nonsignaled. If dwMilliseconds is zero, the function tests the object's state and returns immediately. If dwMilliseconds is INFINITE, the function's time-out interval never elapses. 1) Only call Callback iff signaled 2) Implies WT_EXECUTEONLYONCE. 3) Callback should be called before returning. This is a crude fix not impl. 3) but is enough to get ies4linux around the 100% CPU problem. Not sure tmo == 0 implies returning a NULL ptr for phNewWaitObject too. --- dlls/ntdll/threadpool.c | 14 ++++++++++---- 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/dlls/ntdll/threadpool.c b/dlls/ntdll/threadpool.c index 44afb01..159baee 100644 --- a/dlls/ntdll/threadpool.c +++ b/dlls/ntdll/threadpool.c @@ -373,11 +373,17 @@ static DWORD CALLBACK wait_thread_proc(LPVOID Arg) wait_work_item->Context ); TimerOrWaitFired = TRUE; } - wait_work_item->CallbackInProgress = TRUE; - wait_work_item->Callback( wait_work_item->Context, TimerOrWaitFired ); - wait_work_item->CallbackInProgress = FALSE; + /* Milliseconds == 0 is special, only call Callback iff + signaled and treat as WT_EXECUTEONLYONCE */ + if (wait_work_item->Milliseconds || !TimerOrWaitFired) + { + wait_work_item->CallbackInProgress = TRUE; + wait_work_item->Callback( wait_work_item->Context, TimerOrWaitFired ); + wait_work_item->CallbackInProgress = FALSE; + } - if (wait_work_item->Flags & WT_EXECUTEONLYONCE) + if (!wait_work_item->Milliseconds || + wait_work_item->Flags & WT_EXECUTEONLYONCE) break; } else -- 1.6.4.4

1 0

Re: localspl/tests: Improve the tests in test_XcvDataPort_AddPort by properly checking return values and avoiding a duplicat
by testbot＠testbot.winehq.org 02 May '10

02 May '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=1881 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: Minor dlls/localspl/tests/localmon.c simplificiation
by Nikolay Sivov 02 May '10

02 May '10

On 4/23/2010 16:50, Gerald Pfeifer wrote: > In addition to just building this patch as is, I also gave it a spin > changing the if (0) to if (1) to ensure this still builds (it should, > of course, and it does, but...) > > Gerald > > ChangeLog: > Remove variable res which is not really used from test_XcvClosePort. > We should better test for return value than remove it.

2 3

Re: quartz: Properly return E_POINTER when ppFilters is null
by Nikolay Sivov 02 May '10

02 May '10

On 5/3/2010 02:17, Jerome Leclanche wrote: > Fixes bug 22563. Also fix broken indent right below. > > J. Leclanche > Please, add a test for this, it looks trivial to test.

1 0

Re: Minor dlls/comctl32/tests/listview.c simplification
by Nikolay Sivov 02 May '10

02 May '10

On 4/21/2010 21:32, Gerald Pfeifer wrote: > ChangeLog: > Remove variable hwndheader which is not really used from test_items. > > diff --git a/dlls/comctl32/tests/listview.c b/dlls/comctl32/tests/listview.c > index 2c5ef70..06f2ddd 100644 > --- a/dlls/comctl32/tests/listview.c > +++ b/dlls/comctl32/tests/listview.c > @@ -1182,7 +1182,7 @@ static void test_items(void) > > static void test_columns(void) > { > - HWND hwnd, hwndheader; > + HWND hwnd; > LVCOLUMN column; > DWORD rc; > INT order[2]; > @@ -1207,7 +1207,6 @@ static void test_columns(void) > > /* LVM_GETCOLUMNORDERARRAY */ > hwnd = create_listview_control(LVS_REPORT); > - hwndheader = subclass_header(hwnd); > > memset(&column, 0, sizeof(column)); > column.mask = LVCF_WIDTH; > Hi, Gerald. You can't do this, subclassing is important thing here. And you will see it if you run a test (that you should do before sending patch actually).

2 1

Re: Francois Gouget : winedbg: Fix compilation with gcc 2. 95 and non-GNU compilers.
by Eric Pouech 02 May '10

02 May '10

Alexandre Julliard a écrit : > Module: wine > Branch: master > Commit: 51dfd9adb11885daec878737f18f89fb05c1516c > URL: http://source.winehq.org/git/wine.git/?a=commit;h=51dfd9adb11885daec878737f… > > Author: Francois Gouget <fgouget(a)free.fr> > Date: Sat Mar 27 16:55:27 2010 +0100 > > winedbg: Fix compilation with gcc 2.95 and non-GNU compilers. > François, what was the exact issue here ? I guess that the ; at the end of the attribute definition for GNUCC compiler was missing for the non gnu C compilers ? your fix is wrong as dbg_printf doesn't take a va_list as argument (you'd want dbg_vprintf which doesn't exist) does the attached patch work in your configuration ? A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams) diff --git a/programs/winedbg/db_disasm64.c b/programs/winedbg/db_disasm64.c index 98f7ef2..88fa0dd 100644 --- a/programs/winedbg/db_disasm64.c +++ b/programs/winedbg/db_disasm64.c @@ -32,24 +32,13 @@ #include <stdio.h> #include "debugger.h" -#ifndef __GNUC__ -#define __attribute__(X) +#ifdef __GNUC__ +static int (*db_printf)(const char* format, ...) __attribute__((format (printf,1,2))); +#else +static int (*db_printf)(const char* format, ...); #endif -static int db_debug = 0; -static int db_printf(const char* format, ...) __attribute__((format (printf,1,2))); -int db_printf(const char* format, ...) -{ - va_list valist; - int len = 0; - if (db_debug) - { - va_start(valist, format); - len = dbg_printf(format, valist); - va_end(valist); - } - return len; -} +static int no_printf(const char* format, ...) {return 0;} typedef DWORD_PTR db_addr_t; typedef BOOL boolean_t; @@ -93,7 +82,7 @@ static ULONG64 db_get_value(db_addr_t addr, int size, int is_signed) static void db_printsym(db_addr_t addr, unsigned unused) { - if (db_debug) + if (db_printf != no_printf) { ADDRESS64 a; @@ -1656,6 +1645,6 @@ db_disasm(db_addr_t loc, boolean_t altfmt) void be_x86_64_disasm_one_insn(ADDRESS64 *addr, int display) { - db_debug = display; + db_printf = display ? dbg_printf : no_printf; addr->Offset = db_disasm(addr->Offset, TRUE); }

2 3

Fullscreen Borderlands at Desktop Resolution
by Erich Hoover 02 May '10

02 May '10

I've been playing the game Borderlands at less than my desktop resolution due to a strange bug and finally decided to try and track it down. The issue is that whenever the resolution of Borderlands is set to the same resolution as the desktop then the game window does not appear in the upper left hand corner and the size of the window is about 1/2 of the display size for both the width and the height. After some exploration, this appears to be two separate issues with the Wine's X11 driver. 1) sync_window_position() will not move an iconified managed window, so the window is never repositioned to the upper left corner. 2) set_size_hints() checks to see if a window is the size of the display (or larger) and does not resize the window if that is the case. Another interesting point is that these issues only occur when using compiz, when using metacity the following warnings are displayed: --- Window manager warning: Window 0x4200005 (Borderland) sets an MWM hint indicating it isn't resizable, but sets min size 1 x 1 and max size 2147483647 x 2147483647; this doesn't make much sense. Window manager warning: Treating resize request of legacy application 0x4200005 (Borderland) as a fullscreen request --- I've attached a patch that overcomes these issues, but I'm suspicious that there are unintended consequences. I would appreciate it if someone could take a look. Erich Hoover ehoover(a)mines.edu

1 0