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

Re: gdi32: Use the LOGFONT charset field on OEM font creation
by Ilya Shpigor Jan. 13, 2010

Jan. 13, 2010

Hi, Is this patch incorrect or more tests are needed? Dmitry said that there are needed additional tests, but you wouldn't like to commit these. Please explain my mistakes. -- Best regards, Ilya Shpigor.

1 0

Re: wineoss.drv: Ignore volume settings on primary buffer
by Michael Stefaniuc Jan. 13, 2010

Jan. 13, 2010

Maarten, Maarten Lankhorst wrote: > dsound shouldn't be able to mess with the system-wide volume if this is a deliberate design decision then the FIXME("stub") is wrong. It needs to be replaced by a TRACE (or WARN if you insist) with a message like: "Explicitly ignoring wodSetVolume request; dsound shouldn't mess with the system-wide volume". > Fixes bug 15710 and makes the bsd's happier > --- > --- a/dlls/wineoss.drv/dsrender.c > +++ b/dlls/wineoss.drv/dsrender.c > @@ -533,14 +533,7 @@ static HRESULT WINAPI IDsDriverBufferImpl_SetVolumePan(PIDSDRIVERBUFFER iface, P > { > DWORD vol; > IDsDriverBufferImpl *This = (IDsDriverBufferImpl *)iface; > - TRACE("(%p,%p)\n",This,pVolPan); > - > - vol = pVolPan->dwTotalLeftAmpFactor | (pVolPan->dwTotalRightAmpFactor << 16); > - > - if (wodSetVolume(This->drv->wDevID, vol) != MMSYSERR_NOERROR) { > - WARN("wodSetVolume failed\n"); > - return DSERR_INVALIDPARAM; > - } > + FIXME("(%p,%p) stub\n",This,pVolPan); > > return DS_OK; > } thanks bye michael

1 0

Re: [rsaenh/tests] Don't check result twice (Coccinelle)
by Michael Stefaniuc Jan. 13, 2010

Jan. 13, 2010

Hi Paul, Paul Vriens wrote: > We already check and return FALSE a few lines up. > > Found with the help of Coccinelle and the CocciCheck scripts. > > Changelog > Don't check result twice (Coccinelle) > --- a/dlls/rsaenh/tests/rsaenh.c +++ b/dlls/rsaenh/tests/rsaenh.c @@ -275,7 +275,6 @@ static BOOL derive_key(ALG_ID aiAlgid, HCRYPTKEY *phKey, DWORD len) return FALSE; } ok(result, "%08x\n", GetLastError()); - if (!result) return FALSE; result = CryptHashData(hHash, pbData, sizeof(pbData), 0); ok(result, "%08x\n", GetLastError()); if (!result) return FALSE; that is not the same "result"; it gets a new value after the first "return FALSE". bye michael

3 5

Re: [PATCH 3/4] msxml3/xmldoc: IPersistStreamInit::InitNew() seems to do nothing for IXMLDocument
by Alistair Leslie-Hughes Jan. 12, 2010

Jan. 12, 2010

On 13/01/2010 1:41 AM, Nikolay Sivov wrote: > IPersistStreamInit::InitNew() seems to do nothing for IXMLDocument > > > + hr = IPersistStreamInit_IsDirty(psi); > + todo_wine ok(hr == S_FALSE, "Expected S_OK, got %08x\n", hr); The message doesn't match the condition. Best Regards Alistair Leslie-Hughes

2 1

Re: installation problem with yesterday's git - NEVERMIND
by Susan Cragin Jan. 12, 2010

Jan. 12, 2010

Somehow, the 4th time was a charm. Must be me? -----Original Message----- >I'm having an installation problem with yesterday's git. >err:msi:ITERATE_Actions Execution halted, action L"InstallSpeechAPI" returned 1627 >err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1627 > >Bug? >Regression test? >anyone want to see my whole terminal output?

1 0

installation problem with yesterday's git
by Susan Cragin Jan. 12, 2010

Jan. 12, 2010

I'm having an installation problem with yesterday's git. err:msi:ITERATE_Actions Execution halted, action L"InstallSpeechAPI" returned 1627 err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1627 Bug? Regression test? anyone want to see my whole terminal output?

1 0

Re: Nikolay Sivov : advapi32: Free descriptor if it isn' t returned from GetSecurityInfo().
by Rob Shearman Jan. 12, 2010

Jan. 12, 2010

2010/1/11 Alexandre Julliard <julliard(a)winehq.org>: > Module: wine > Branch: master > Commit: dbd76575ef8353484afa0b0d2da95760c26f34fe > URL: http://source.winehq.org/git/wine.git/?a=commit;h=dbd76575ef8353484afa0b0d2… > > Author: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Fri Jan 8 21:05:21 2010 +0300 > > advapi32: Free descriptor if it isn't returned from GetSecurityInfo(). > > --- > > dlls/advapi32/security.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/advapi32/security.c b/dlls/advapi32/security.c > index 629a74a..babe468 100644 > --- a/dlls/advapi32/security.c > +++ b/dlls/advapi32/security.c > @@ -3118,6 +3118,8 @@ DWORD WINAPI GetSecurityInfo( > } > if (ppSecurityDescriptor) > *ppSecurityDescriptor = sd; > + else > + LocalFree(sd); > > return ERROR_SUCCESS; > } This is not correct as per the discussion on wine-devel, so it needs to be reverted. It causes these new Valgrind warnings: http://kegel.com/wine/valgrind/logs/2010-01-11-14.17/diff-advapi32_security… -- Rob Shearman

2 1

Re: d3drm: Merge Direct3DRMCreate with its implementation.
by Christian Costa Jan. 12, 2010

Jan. 12, 2010

What the hell is the purpose of this patch ? d3drm.c is for the IDirect3DRMx objects implementations and there will be a file for each other object. Direct3DRMCreate is just an entry point and BTW many wine DirectX dlls are implemented this way because some objects can be also created using the class factory. And why are you removing the d3drm_private.h file at all ? More generally, is it really necessary to do some clean-up while I'm doing some work on this dll ? Christian Dmitry Timoshkov a écrit : > --- > dlls/d3drm/d3drm.c | 11 ++++++----- > dlls/d3drm/d3drm_main.c | 16 ---------------- > dlls/d3drm/d3drm_private.h | 31 ------------------------------- > 3 files changed, 6 insertions(+), 52 deletions(-) > delete mode 100644 dlls/d3drm/d3drm_private.h > > diff --git a/dlls/d3drm/d3drm.c b/dlls/d3drm/d3drm.c > index a0d7d3f..ae80d46 100644 > --- a/dlls/d3drm/d3drm.c > +++ b/dlls/d3drm/d3drm.c > @@ -27,20 +27,21 @@ > > #include "winbase.h" > #include "wingdi.h" > - > -#include "d3drm_private.h" > #include "d3drm.h" > > WINE_DEFAULT_DEBUG_CHANNEL(d3drm); > > typedef struct { > - IDirect3DRM lpVtbl; > + const IDirect3DRMVtbl *lpVtbl; > LONG ref; > } IDirect3DRMImpl; > > static const struct IDirect3DRMVtbl Direct3DRM_Vtbl; > > -HRESULT Direct3DRM_create(LPDIRECT3DRM* ppDirect3DRM) > +/*********************************************************************** > + * (D3DRM.@) > + */ > +HRESULT WINAPI Direct3DRMCreate(LPDIRECT3DRM* ppDirect3DRM) > { > IDirect3DRMImpl* object; > > @@ -53,7 +54,7 @@ HRESULT Direct3DRM_create(LPDIRECT3DRM* ppDirect3DRM) > return E_OUTOFMEMORY; > } > > - object->lpVtbl.lpVtbl = &Direct3DRM_Vtbl; > + object->lpVtbl = &Direct3DRM_Vtbl; > object->ref = 1; > > *ppDirect3DRM = (IDirect3DRM*)object; > diff --git a/dlls/d3drm/d3drm_main.c b/dlls/d3drm/d3drm_main.c > index 38a6a6c..d38159d 100644 > --- a/dlls/d3drm/d3drm_main.c > +++ b/dlls/d3drm/d3drm_main.c > @@ -20,12 +20,6 @@ > #include <stdarg.h> > #include "windef.h" > #include "winbase.h" > -#include "wingdi.h" > -#include "d3drm.h" > -#include "d3drm_private.h" > -#include "wine/debug.h" > - > -WINE_DEFAULT_DEBUG_CHANNEL(d3drm); > > /*********************************************************************** > * DllMain (D3DRM.@) > @@ -42,13 +36,3 @@ BOOL WINAPI DllMain( HINSTANCE inst, DWORD reason, LPVOID reserved ) > } > return TRUE; > } > - > -/*********************************************************************** > - * (D3DRM.@) > - */ > -HRESULT WINAPI Direct3DRMCreate(LPDIRECT3DRM* ppDirect3DRM) > -{ > - TRACE("(%p)\n", ppDirect3DRM); > - > - return Direct3DRM_create(ppDirect3DRM); > -} > diff --git a/dlls/d3drm/d3drm_private.h b/dlls/d3drm/d3drm_private.h > deleted file mode 100644 > index 091b076..0000000 > --- a/dlls/d3drm/d3drm_private.h > +++ /dev/null > @@ -1,31 +0,0 @@ > -/* > - * Direct3DRM private interfaces (D3DRM.DLL) > - * > - * Copyright 2010 Christian Costa > - * > - * This file contains the (internal) driver registration functions, > - * driver enumeration APIs and DirectDraw creation functions. > - * > - * This library is free software; you can redistribute it and/or > - * modify it under the terms of the GNU Lesser General Public > - * License as published by the Free Software Foundation; either > - * version 2.1 of the License, or (at your option) any later version. > - * > - * This library is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > - * Lesser General Public License for more details. > - * > - * You should have received a copy of the GNU Lesser General Public > - * License along with this library; if not, write to the Free Software > - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > - */ > - > -#ifndef __D3DRM_PRIVATE_INCLUDED__ > -#define __D3DRM_PRIVATE_INCLUDED__ > - > -#include "d3drm.h" > - > -HRESULT Direct3DRM_create(LPDIRECT3DRM* ppDirect3DRM); > - > -#endif /* __D3DRM_PRIVATE_INCLUDED__ */ >

2 4

Re: d3d8: Fix a ptrdiff_t warning on 64-bit.
by Alexandre Julliard Jan. 12, 2010

Jan. 12, 2010

Nicolas Le Cam <niko.lecam(a)gmail.com> writes: > @@ -175,7 +175,7 @@ static DWORD d3d8_allocate_handle(struct d3d8_handle_table *t, void *object, enu > entry = t->free_entries; > if (entry->type != D3D8_HANDLE_FREE) > { > - ERR("Handle %u(%p) is in the free list, but has type %#x.\n", (entry - t->entries), entry, entry->type); > + ERR("Handle %tu(%p) is in the free list, but has type %#x.\n", (entry - t->entries), entry, entry->type); Please don't use that kind of printf formats, they are not portable. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] wined3d: Do not try to use not available texture stages in set_tex_op_nvr
by Stefan Dösinger Jan. 12, 2010

Jan. 12, 2010

> + if (stage > (gl_info->limits.texture_stages-1)) > + { > + ERR("Texture stage %d invalid (only %d availables)\n", stage, gl_info->limits.texture_stages); > + return; > + } In which situations does this occur? I guess its on some older nvidia GPU. I don't like the ERR here. If this occurs because an app ignores the d3d limits, then this should be a WARN. If this code is called because some other wined3d code doesn't honor the limits this should be fixed elsewhere. If this code is called correctly, and catching the limit violation in the state setter is the correct thing to do this should be a TRACE(e.g. the state handler is called because device creation dirtifies all states).

3 10

Re: dbghelp: merge dwarf code from ntdll/signal_x86_64.c
by Eric Pouech Jan. 11, 2010

Jan. 11, 2010

André Hentschel a écrit : > thanks Eric Pouech for the reviews > --- > dlls/dbghelp/dwarf.c | 229 +++++++++++++++++++++++++++++++++++++++++--------- > dlls/dbghelp/dwarf.h | 15 ++++ > 2 files changed, 204 insertions(+), 40 deletions(-) > > diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c > index 48e6351..d7f4f50 100644 > --- a/dlls/dbghelp/dwarf.c > +++ b/dlls/dbghelp/dwarf.c > @@ -241,6 +241,13 @@ static DWORD64 dwarf2_get_u8(const unsigned char* ptr) > return *(const UINT64*)ptr; > } > > +static DWORD64 dwarf2_parse_u8(dwarf2_traverse_context_t* ctx) > +{ > + unsigned long uvalue = dwarf2_get_u8(ctx->data); > + ctx->data += 8; > + return uvalue; > +} > + > static unsigned long dwarf2_get_leb128_as_unsigned(const unsigned char* ptr, const unsigned char** end) > { > unsigned long ret = 0; > @@ -344,6 +351,58 @@ static unsigned long dwarf2_parse_addr(dwarf2_traverse_context_t* ctx) > return ret; > } > > +static ULONG_PTR dwarf2_get_ptr( const unsigned char **p, unsigned char encoding, unsigned word_size) > +{ > + ULONG_PTR base; > + > + if (encoding == DW_EH_PE_omit) return 0; > + > + switch (encoding & 0xf0) > + { > + case DW_EH_PE_abs: > + base = 0; > + break; > + case DW_EH_PE_pcrel: > + base = (ULONG_PTR)*p; > I'm afraid I've got some further comments this is wrong, as it implies that the underlying ELF section (relative to p) is mapped at same address between the process dbghelp is working on (it has been mapped by the ELF loader) and where dbghelp has mapped some ELF sections (likely in another process) a proper fix will require some extra work I've started doing it So either so you do it properly, or you drop the EH frame support out of this patch A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 2

Re: MSVCRT: Handle \r at buffer boundary
by Alexandre Julliard Jan. 11, 2010

Jan. 11, 2010

Uwe Bonnes <bon(a)hertz.ikp.physik.tu-darmstadt.de> writes: > @@ -1767,6 +1771,12 @@ static int read_i(int fd, void *buf, unsigned int count) > if (MSVCRT_fdesc[fd].wxflag & WX_TEXT) > { > DWORD i, j; > + if (bufstart[num_read-1] == '\r') > + { > + if(pushback) > + MSVCRT__lseeki64(fd, -1, SEEK_CUR); You can't use lseek for this, the file may not be seekable. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: user32: Do not allow a change of capture if the currently capture window is a menu unless explicitly specified (try2)
by Alexandre Julliard Jan. 11, 2010

Jan. 11, 2010

Peter Dons Tychsen <donpedro(a)tdcadsl.dk> writes: > @@ -85,6 +85,17 @@ BOOL set_capture_window( HWND hwnd, UINT gui_flags, HWND *prev_ret ) > HWND previous = 0; > UINT flags = 0; > BOOL ret; > + GUITHREADINFO info; > + if(!GetGUIThreadInfo(GetCurrentThreadId(), &info)) > + { > + return FALSE; > + } > + > + /* if in menu mode, reject all requests to change focus, except if the menu bit is set */ > + if((info.flags & GUI_INMENUMODE) && !(gui_flags & GUI_INMENUMODE)) > + { > + return FALSE; > + } This should be handled on the server side. -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: msvcrt: Add support for sprintf_s
by Jason Edmeades Jan. 11, 2010

Jan. 11, 2010

>This doesn't seem correct to me You are right, its incomplete, but it also was based on the logic already in MSVCRT_vswprintf_s, which is just as incomplete! I'll happily just raise a bug report if the patch is insufficient, but in general all the _s special processing is missing from the printf* family, and the patch implements enough to get the basic functionality working. I probably should have put a fixme comment in like MSVCRT_vswprintf_s though but would that be enough? Jason

1 0

Re: msvcrt: Add support for sprintf_s
by Chris Robinson Jan. 11, 2010

Jan. 11, 2010

This doesn't seem correct to me. According to MSDN, sprintf_s checks for valid formatting chars (in addition to the buffer and format arguments) and invokes an invalid parameter handler if something bad turns up. It then returns -1 with errno set to EINVAL if execution is allowed to continue. Additionally, if the buffer is too small to hold the resulting string, it is made an empty string and invokes the invalid parameter handler. It also guarantees the output buffer is null terminated. http://msdn.microsoft.com/en-us/library/ce3zzk1k(VS.80).aspx

2 1

Re: Implement OleCreatePropertyFrame
by Piotr Caban Jan. 11, 2010

Jan. 11, 2010

Hi, In prop_sheet_proc you wrote: case PSN_APPLY: FIXME("(%p, %s, %s)\n", hwnd, "WM_NOTIFY", "PSN_APPLY"); IPropertyPage_Apply(opf->propPage); return TRUE; If I understand it correctly applying changes is fully implemented. Why there's a FIXME? Probably you wanted to use TRACE here. default: FIXME("(%p, %d, %ld, %p)\n", hwnd, msg, wparam, (void *)lparam); There's lots of messages that your're not going to handle (e.g. WM_SETCURSOR) so this FIXME will be very loud. In pixels_to_dialog_units function: You're using some hardcoded values here. Probably something like this would be better, but I'm not sure if it's correct: static void pixels_to_dialog_units(short *x_pixels, short *y_pixels) { int basey; float basex; HFONT font = GetStockObject(DEFAULT_GUI_FONT); HDC hdc = GetDC(NULL); TEXTMETRICW tm; SIZE size; font = SelectObject(hdc, font); GetTextMetricsW(hdc, &tm); GetTextExtentPoint32A(hdc, "ABCDEFGHIJKLMNOPQRSTUVWXYZ" "abcdefghijklmnopqrstuvwxyz", 52, &size); SelectObject(hdc, font); basex = ((float)size.cx/26+1)/2; basey = tm.tmHeight; *x_pixels = (float)(*x_pixels)*4/basex; *y_pixels = MulDiv(*y_pixels, 8, basey); } Of course the basex and basey values should be computed once. In OleCreatePropertyFrameIndirect it's probably good to add a FIXME, that dispidInitialProperty value is ignored. Please try to use the same formatting in whole file (e.g. you sometimes use white chars before brackets). Cheers, Piotr

1 0

Re: advpack: Use GetModuleHandle instead of LoadLibrary.
by Paul Vriens Jan. 11, 2010

Jan. 11, 2010

On 01/05/2010 02:46 AM, James Hawkins wrote: > --- > dlls/advpack/tests/advpack.c | 7 +------ > 1 files changed, 1 insertions(+), 6 deletions(-) > Hi James, Don't think this works: advpack: 0 tests executed (0 marked as todo, 0 failures), 0 skipped. -- Cheers, Paul.

2 2

Re: [2/4] avifil32/tests: Initial-test-data-and-simple-test-for-avifil32-depends
by James McKenzie Jan. 10, 2010

Jan. 10, 2010

Julius Schwartzenberg wrote: > These are resents of last week which are cleaned up more and with > Detlef's patch on which they depend in front. > > While looking at avifile, I noticed some strange behaviour. Because > some fixes may seem strange, I felt a test suite was really necessary > to show that this is really what's happening on Windows. All the tests > pass on both Windows 98 and Windows XP. > > C++ type comments are not allowed. Please mark second and subsequent submissions with [Try #] in the message header. It keeps us from guessing which submission is the latest. There is no requirement to submit subsequent parts of a patchset if there are no changes to them if changes in prior sections do not affect the code in them. James McKenzie

2 1

Re: avifil32: Overwrite dwRate in the audiostream with the nBlockAlign from the wave header
by Paul Vriens Jan. 10, 2010

Jan. 10, 2010

On 01/10/2010 03:18 AM, Julius Schwartzenberg wrote: > I was stupid last week and sent patches in a serie that didn't actually > depend on each other. I'm resending them properly now. All fixes are > actually independent from each other. > > I started looking into some problems avifil32 had because Civilization > II would crash if it tried to play it's intro movie. > I created a small program to print information about the different > headers in AVI files and to play back the audio stream. Also with this > program, many AVI files failed to play (while they worked on Windows > with it). The fixes I introduce also allow my testing program to play > back everything correctly. > > These patches solve this problem and several other problems. > Hi Julius, Do any of these patches fix any of the tests? If so you should also change the tests by removing one or more todo_wine()'s. This could become tricky though if your tests patches are not committed before these ones. -- Cheers, Paul.

3 2

Re: ntdll/tests: Fix a test failure on NT4
by Paul Vriens Jan. 10, 2010

Jan. 10, 2010

On 01/10/2010 05:44 PM, André Hentschel wrote: > --- > dlls/ntdll/tests/om.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/ntdll/tests/om.c b/dlls/ntdll/tests/om.c > index 1bab21d..e351813 100644 > --- a/dlls/ntdll/tests/om.c > +++ b/dlls/ntdll/tests/om.c > @@ -677,7 +677,8 @@ static void test_query_object(void) > ok( status == STATUS_SUCCESS, "NtQueryObject failed %x\n", status ); > ok( len> sizeof(UNICODE_STRING), "unexpected len %u\n", len ); > str = (UNICODE_STRING *)buffer; > - ok( sizeof(UNICODE_STRING) + str->Length + sizeof(WCHAR) == len, "unexpected len %u\n", len ); > + ok( sizeof(UNICODE_STRING) + str->Length == len /* WinNT */ || > + sizeof(UNICODE_STRING) + str->Length + sizeof(WCHAR) == len, "unexpected len %u\n", len ); > trace( "got %s len %u\n", wine_dbgstr_w(str->Buffer), len ); > pNtClose( handle ); > } Looks a bit like: http://source.winehq.org/patches/data/57319 Except that I used broken() for NT4 which IMHO makes more sense as this is the only platform with this issue. -- Cheers, Paul.

2 2

Re: Resent of [1/4] and [2/4] from avifil32/test serie
by Paul Vriens Jan. 10, 2010

Jan. 10, 2010

On 01/10/2010 05:35 PM, Julius Schwartzenberg wrote: > First of all, my apologies for all the junk. I didn't fully understand > how the mail moderation exactly worked and made some wrong guesses. > > I'm going to use git send-email now as Henri suggested me, to resent two > patches from the serie as replies to this e-mail. Both with included > suggestions from Paul & Henri wine-devel. > > [1/4]: This is Detlef's patch from June 2008 with just the import > changed from "vfw32" to "avifil32" to work around bug 14085. > > http://www.winehq.org/pipermail/wine-patches/2008-June/056310.html > > > [2/4]: These are resents of last week which are cleaned up more and with > Detlef's patch on which they depend in front. > > While looking at avifile, I noticed some strange behaviour. Because some > fixes may seem strange, I felt a test suite was really necessary to show > that this is really what's happening on Windows. All the tests pass on > both Windows 98 and Windows XP. Remember that we have that great winetestbot (https://winetestbot.geldorp.nl/index.pl) which I encourage people to use as it covers NT4 up to W2K8R2 if needed. -- Cheers, Paul.

1 0

Re: Sorry!! Please drop the previous mails ^^^
by Henri Verbeet Jan. 10, 2010

Jan. 10, 2010

2010/1/10 Julius Schwartzenberg <j.schwartzenberg(a)student.utwente.nl>: > My apologies to who'll read this. I found out a bit late my mailclient > sucked and used the wrong 'from' address. I've resent all my patches with > the proper address now, so all other mails from me may be dropped. > I'm not sure what was wrong with it? Afaik the address in the "From: " line in the patch is leading, unless it's obviously invalid. Note that just using "git send-email" avoids a lot of the common issues with patch submission.

2 1

Re: d3drm: The input quaternions are not changed when calling D3DRMQuaternionSlerp
by Henri Verbeet Jan. 10, 2010

Jan. 10, 2010

2010/1/10 David Adam <david.adam.cnrs(a)gmail.com>: > + > +/* Test to show that the input quaternions are not changed */ > + expect_quat(q1,q1final); > + expect_quat(q2,q2final); > + You have some trailing spaces here.

1 0

Re: [1/4] avifil32/tests: Add initial tests
by Henri Verbeet Jan. 10, 2010

Jan. 10, 2010

2010/1/10 Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com>: > This is Detlef's patch from June 2008 with just the import changed from > "vfw32" to "avifil32" to work around bug 14085. > > http://www.winehq.org/pipermail/wine-patches/2008-June/056310.html > You should add a proper "From: " line to the patch when submitting patches for other people. If you use "git format-patch" it will do this automatically, provided you gave correct author information to "git commit".

1 0

Re: [PATCH] shell32: handle bad menu handle (Coverity)
by Nikolay Sivov Jan. 10, 2010

Jan. 10, 2010

On 1/9/2010 16:59, Marcus Meissner wrote: > Hi, > > handle "invalid menu" return -1. Now with test. > > Ciao, Marcus > --- > dlls/shell32/shlmenu.c | 5 +++-- > dlls/shell32/tests/shlfileop.c | 13 +++++++++++++ > 2 files changed, 16 insertions(+), 2 deletions(-) > > > { > diff --git a/dlls/shell32/tests/shlfileop.c b/dlls/shell32/tests/shlfileop.c > index 0a5cdca..4d74b93 100644 > --- a/dlls/shell32/tests/shlfileop.c > +++ b/dlls/shell32/tests/shlfileop.c > Wrong file to place test in I think. > @@ -2224,6 +2224,17 @@ static void test_unicode(void) > ok(!file_existsW(UNICODE_PATH), "The directory should have been removed\n"); > } > > +extern HRESULT WINAPI Shell_MergeMenus (HMENU hmDst, HMENU hmSrc, UINT uInsert, UINT uIDAdjust, UINT uIDAdjustMax, ULONG uFlags); > + > This should got to shlobj.h. > +static void > +test_shlmenu(void) { > + HRESULT hres; > + hres = Shell_MergeMenus (0, 0, 0x42, 0x4242, 0x424242, 0); > + ok (hres == 0x4242, "expected 0x4242 but got %x\n", hres); > + hres = Shell_MergeMenus ((HMENU)42, 0, 0x42, 0x4242, 0x424242, 0); > + ok (hres == 0x4242, "expected 0x4242 but got %x\n", hres); > +} > + > Use a valid empty menu handle here as first parameter. Also I'd like to use more sane const values. > START_TEST(shlfileop) > { > InitFunctionPointers(); > @@ -2263,4 +2274,6 @@ START_TEST(shlfileop) > clean_after_shfo_tests(); > > test_unicode(); > + > + test_shlmenu(); > } > Function is available starting XP SP2 per msdn, so dynamic load should be used.

3 4