wine-devel November 2007

wine-devel@winehq.org

117 participants
275 discussions

Re: [PATCH] svchost: Implementation of svchost (revised submission 2)
by Alexandre Julliard 28 Nov '07

28 Nov '07

Roy Shea <roy(a)cs.hmc.edu> writes: > This is another revised and standalone version of the svchost patch. > Changes in this revision include: > > - Only using HEAP_ZERO_MEMORY in calls to HeapReAlloc. Calls to > HeapAlloc explicitly set the NULL terminator when required. The realloc is overkill too, you can just allocate one extra char from the start, and set it to zero unconditionally. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ole32: Fix two comments in ok strings in the WdtpInterfacePointer tests.
by Alexandre Julliard 28 Nov '07

28 Nov '07

Robert Shearman <rob(a)codeweavers.com> writes: > diff --git a/dlls/ole32/tests/usrmarshal.c b/dlls/ole32/tests/usrmarshal.c > index 9959f74..5819ec1 100644 > --- a/dlls/ole32/tests/usrmarshal.c > +++ b/dlls/ole32/tests/usrmarshal.c > @@ -801,9 +801,9 @@ static void test_marshal_WdtpInterfacePointer(void) > wireip = buffer; > if (size >= 28) > { > - ok(*(DWORD *)wireip == 0x44, "wireip + 0x0 should be 0x4c instead of 0x%08x\n", *(DWORD *)wireip); > + ok(*(DWORD *)wireip == 0x44, "wireip + 0x0 should be 0x44 instead of 0x%08x\n", *(DWORD *)wireip); > wireip += sizeof(DWORD); > - ok(*(DWORD *)wireip == 0x44, "wireip + 0x8 should be 0x4c instead of 0x%08x\n", *(DWORD *)wireip); > + ok(*(DWORD *)wireip == 0x44, "wireip + 0x8 should be 0x44 instead of 0x%08x\n", *(DWORD *)wireip); While we are on the subject, why does it say wireip + 0x8 when the pointer is incremented by 4? The rest of the offsets are wrong too, especially the iid comparison. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/8] WineD3D: Inform the texture about filtering changes
by H. Verbeet 28 Nov '07

28 Nov '07

On 27/11/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Don't you need to mark the sampler dirty if it's bound somewhere? Or is it guaranteed it never is at that point?

2 1

Re: [4/8] WineD3D: Do not try to disable unsupported texture units
by H. Verbeet 28 Nov '07

28 Nov '07

On 27/11/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > textures. In this case we build a texture map to read a texture from a > lower texture unit from a higher register combiner. This texture unit > always stays below GL_LIMITS(textures) though. Yes, but you're checking against the sampler, not the texture unit. Shouldn't you be checking against mapped_stage instead?

1 0

Re: [PATCH] svchost: Implementation of svchost (revised submission)
by James Hawkins 27 Nov '07

27 Nov '07

On Nov 27, 2007 3:21 PM, Roy Shea <roy(a)cs.hmc.edu> wrote: > This is a revised and standalone version of svchost patch. Changes in > this revision include: > > - Unicode based with a simple UNICODE to ASCII function used to > convert the lpProcName passed into GetProcAddress > I think you're misunderstanding Wine's policy about not using ansi functions or constant strings. That only applies to external APIs because we don't want to convert from unicode to ansi (lossy). There's nothing wrong with just using: GetProcAddress(library, "ServiceMain"); There aren't many instances where W->A is valid. > - Using HEAP_ZERO_MEMORY flag in calls to HeapAlloc and HeapReAlloc > that are allocating space for a string and the NULL terminator to > set the NULL terminator to zero. > Why HEAP_ZERO_MEMORY when you can just set the last byte to NULL? str[LEN - 1] = '\0'; -- James Hawkins

2 1

Re: d3dx9_xx [patch 2/2] Implementation of the different d3dx9_xx lls
by Maciej Kowalczyk 27 Nov '07

27 Nov '07

Hi! > +@ stdcall D3DXVec2Normalize(ptr ptr) d3dx8.D3DXVec3Normalize Shouldn't it be "d3dx8.D3DXVec2Normalize"? This line is copy-pasted 13 times around the patch. -- Maciej Kowalczyk

1 0

[keyboard] GetAsyncKeyState: request for fixing #5623
by Rafał Miłecki 27 Nov '07

27 Nov '07

Hello, I have two favourite games (Diablo II & Ultima Online) and both of them works great under Wine. Unfortunately this is quite hard to play UO without additional tool called "EasyUO" which doesn't work under Wine. EasyUO generally works fine but it can not detect pressing any key-combination in focued UO window. Possibility of detecting is the main functionality for EUO. This problem is cuased by little bug in support for GetAsyncKeyState function. I am waiting about 8 months now for fixing this bug and I wonder if I can ask sb to look info this bug. Just to make fixing this little faster. Bug is quite well decribed in: http://bugs.winehq.org/show_bug.cgi?id=5623 but if you don't understand this, I can try to explain more detailed. So my request is someone try to fix this bug. Anyone have a free moment for this, please? -- Rafał Miłecki

2 3

Re: urlmon: Callback can be NULL
by Alexandre Julliard 27 Nov '07

27 Nov '07

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Hi, > Changelog: > urlmon: The callback parameter can be null, check pointer before using. This breaks the tests: ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so stream.c && touch stream.ok stream.c:210: Test failed: unexpected call OnDataAvailable stream.c:329: Test failed: IStream_Read failed with error 0x00000001 stream.c:330: Test failed: read data differs from file make: *** [stream.ok] Error 3 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3dx8: Implementation of WINAPI D3DXAssembleShaderFromFileA
by Dmitry Timoshkov 27 Nov '07

27 Nov '07

""Luis C. Busquets Pérez"" <luis.busquets(a)ilidium.com> wrote: > Changed the if clauses to make the implementation more readable. ... > + if ( !pSrcFile ) > + return D3DXERR_INVALIDDATA; > + else > + { > + len = MultiByteToWideChar( CP_ACP, 0, pSrcFile, -1, NULL, 0 ); > + pSrcFileW = HeapAlloc( GetProcessHeap(), 0, len * sizeof(WCHAR) ); > + MultiByteToWideChar( CP_ACP, 0, pSrcFile, -1, pSrcFileW, len ); > + ret=D3DXAssembleShaderFromFileW(pSrcFileW, Flags, ppConstants, ppCompiledShader, ppCompilationErrors); > + HeapFree( GetProcessHeap(), 0, pSrcFileW ); > + return ret; > + } > } This is not more readable than a previous version. There is no need for 'else {}' construct and therefore for additional indentation level at all. -- Dmitry.

4 4

Re: urlmon: Wrap heap functions.
by Michael Stefaniuc 27 Nov '07

27 Nov '07

Hello! (Jacek, this is not directed at you but a general rant). HeapAlloc is an awful API and even its creators wrap it in a couple of DLLs. In Wine HeapAlloc gets wrapped in different places, each using a different name and even a different naming convention. This makes the code harder to understand for people that browse the code (people doing janitorial work) as they have to check every time if the function is yet another wrapper around HeapFree or if the function is doing more than that. And this makes it even harder for static code analyzing tools. I therefor propose to standardize all the internal HeapAlloc wrappers to a common name and form, Something along the lines of: walloc() wzalloc() wrealloc() wzrealloc() wfree() It's short and concise and doesn't conflict with the Win32 API. Comments? bye michael Jacek Caban wrote: > diff --git a/dlls/urlmon/urlmon_main.h b/dlls/urlmon/urlmon_main.h > index 6c2887e..aeb0eb2 100644 > --- a/dlls/urlmon/urlmon_main.h > +++ b/dlls/urlmon/urlmon_main.h > @@ -63,4 +63,24 @@ HRESULT start_binding(LPCWSTR url, IBindCtx *pbc, REFIID riid, void **ppv); > > HRESULT create_binding_protocol(LPCWSTR url, IInternetProtocol **protocol); > > +static inline void *urlmon_alloc(size_t len) > +{ > + return HeapAlloc(GetProcessHeap(), 0, len); > +} > + > +static inline void *urlmon_alloc_zero(size_t len) > +{ > + return HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len); > +} > + > +static inline void *urlmon_realloc(void *mem, size_t len) > +{ > + return HeapReAlloc(GetProcessHeap(), 0, mem, len); > +} > + > +static inline BOOL urlmon_free(void *mem) > +{ > + return HeapFree(GetProcessHeap(), 0, mem); > +} > + > #endif /* __WINE_URLMON_MAIN_H */ -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich

2 2

← Newer
1
2
3
4
5
6
7
8
9
...
28
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel November 2007