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

installation problem with yesterday's git
by Susan Cragin 12 Jan '10

12 Jan '10

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 12 Jan '10

12 Jan '10

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 12 Jan '10

12 Jan '10

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 12 Jan '10

12 Jan '10

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 12 Jan '10

12 Jan '10

> + 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 11 Jan '10

11 Jan '10

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 11 Jan '10

11 Jan '10

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 11 Jan '10

11 Jan '10

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 11 Jan '10

11 Jan '10

>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 11 Jan '10

11 Jan '10

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