November 2007 - Wine-Devel - list.winehq.org

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

Nov. 28, 2007

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 Nov. 28, 2007

Nov. 28, 2007

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 Nov. 28, 2007

Nov. 28, 2007

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 Nov. 27, 2007

Nov. 27, 2007

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 Nov. 27, 2007

Nov. 27, 2007

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 Nov. 27, 2007

Nov. 27, 2007

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 Nov. 27, 2007

Nov. 27, 2007

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 Nov. 27, 2007

Nov. 27, 2007

""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 Nov. 27, 2007

Nov. 27, 2007

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

Re: user32: Fix a couple of typos
by Alexandre Julliard Nov. 27, 2007

Nov. 27, 2007

Andrew Talbot <andrew.talbot(a)talbotville.com> writes: > Changelog: > user32: Fix a couple of typos. The patch is clearly correct but it causes test failures, so it looks like more work is needed here: ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so dde.c && touch dde.ok dde.c:250: Test failed: Unhandled msg: 000080c2 dde.c:243: Test failed: client failed with 1 error(s) make[2]: *** [dde.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msvcrt heap: fix _aligned_offset_realloc (move correct block of memory); add a comment to explain why. [1/2]
by Alexandre Julliard Nov. 27, 2007

Nov. 27, 2007

Lionel Debroux <lionel_debroux(a)yahoo.fr> writes: > + Therefore, "size" bytes of actual data have to be moved from the offset > + they were at in the old block (temp + old_padding) to the offset they > + have to be in the new block (temp + new_padding == memblock). > +*/ > if (new_padding != old_padding) > - memmove((char *)memblock + old_padding, (char *)memblock + new_padding, size); > + memmove((char *)memblock, (char *)temp + old_padding, size); You also have to take into account the fact that the size may have changed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Reading Registry Example
by James McKenzie Nov. 27, 2007

Nov. 27, 2007

All: I would like to work on the eventlog.c and would like pointers to an example of reading a registry example under Wine. Thank you. James

2 1

Re: USER32: win16 applications should not see long filenames returned from dialog control (try 4) (RESEND)
by Alexandre Julliard Nov. 27, 2007

Nov. 27, 2007

Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: > Changelog: > * Win16 applications should not see long filenames. Change directory > listbox to return short names when called from the 16-bit wrappers. You are still calling GetShortPathName on potentially uninitialized data. You simply can't do this with a wrapper around the 32-bit DlgDirSelect, you have to duplicate the code. But first it would be worth checking if the listbox shouldn't rather be populated with short path names in the first place. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: David Adam : d3dx8: Implement D3DXQuaternionInverse.
by Robert Shearman Nov. 27, 2007

Nov. 27, 2007

Alexandre Julliard wrote: > /*_________________D3DXQUATERNION________________*/ > > -D3DXQUATERNION* WINAPI D3DXQuaternionMultiply(D3DXQUATERNION * pout, CONST D3DXQUATERNION *pq1, CONST D3DXQUATERNION * pq2) > +D3DXQUATERNION* WINAPI D3DXQuaternionInverse(D3DXQUATERNION *pout, CONST D3DXQUATERNION *pq) > +{ > + D3DXQUATERNION temp; > + FLOAT norm; > + > + norm = D3DXQuaternionLengthSq(pq); > + if ( !norm ) > + { > + pout->x = 0.0f; > + pout->y = 0.0f; > + pout->z = 0.0f; > + pout->w = 0.0f; > + } > + else > + { > + D3DXQuaternionConjugate(&temp, pq); > + pout->x = temp.x / norm; > + pout->y = temp.y / norm; > + pout->z = temp.z / norm; > + pout->w = temp.w / norm; > + } > + return pout; > +} > + > +D3DXQUATERNION* WINAPI D3DXQuaternionMultiply(D3DXQUATERNION *pout, CONST D3DXQUATERNION *pq1, CONST D3DXQUATERNION *pq2) > { > pout->x = pq2->w * pq1->x + pq2->x * pq1->w + pq2->y * pq1->z - pq2->z * pq1->y; > pout->y = pq2->w * pq1->y - pq2->x * pq1->z + pq2->y * pq1->w + pq2->z * pq1->x; This change causes the following warnings for me: math.c: In function ‘D3DXQuaternionInverse’: math.c:695: warning: ‘temp.x’ may be used uninitialised in this function math.c:695: warning: ‘temp.y’ may be used uninitialised in this function math.c:695: warning: ‘temp.z’ may be used uninitialised in this function math.c:695: warning: ‘temp.w’ may be used uninitialised in this function $ gcc --version gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I believe that this is causes by D3DXQuaternionConjugate not writing to temp in one case (pq being NULL) and the compiler not recognising that this case is already covered by the !norm branch above, since D3DXQuaternionLengthSq will return 0.0f if pq is NULL. The attached patch works around the warning. However, there are currently no tests for the case of pq being NULL so I don't know whether it is correct. -- Rob Shearman diff --git a/dlls/d3dx8/math.c b/dlls/d3dx8/math.c index 04072bf..8edd1d3 100644 --- a/dlls/d3dx8/math.c +++ b/dlls/d3dx8/math.c @@ -696,7 +696,7 @@ D3DXQUATERNION* WINAPI D3DXQuaternionInverse(D3DXQUATERNION *pout, CONST D3DXQUA FLOAT norm; norm = D3DXQuaternionLengthSq(pq); - if ( !norm ) + if ( !norm || !pq ) { pout->x = 0.0f; pout->y = 0.0f;

2 1

Re: [dbghelp 1/11] Update some mscvpdb.h definitions and descriptions
by Alexandre Julliard Nov. 27, 2007

Nov. 27, 2007

"Jason Green" <jave27(a)gmail.com> writes: > The Original Author for the following set of patches is Eric van > Beurden from TransGaming, Inc. When submitting patches written by someone else please include a valid From: line in the patch header with his full name and email. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [dbghelp 2/11] Return TRUE in SymInitializeW if process is already initialized and add a number of TRACEs
by Alexandre Julliard Nov. 27, 2007

Nov. 27, 2007

"Jason Green" <jave27(a)gmail.com> writes: > @@ -216,11 +216,17 @@ static BOOL WINAPI process_invade_cb(PCSTR name, ULONG base, ULONG size, PVOID u > char tmp[MAX_PATH]; > HANDLE hProcess = (HANDLE)user; > > - if (!GetModuleFileNameExA(hProcess, (HMODULE)base, > - tmp, sizeof(tmp))) > + > + TRACE("found module %s {base = 0x%08x, size = 0x%08x, user = %p}\n", debugstr_a(name), base, size, user); > + > + if (!GetModuleFileNameExA(hProcess, (HMODULE)base, tmp, sizeof(tmp))){ > + WARN("could not find the full path name of the module. Using the base name of %s instead\n", debugstr_a(name)); > lstrcpynA(tmp, name, sizeof(tmp)); > + } > > + TRACE("loading the module %s {base = 0x%08x}\n", debugstr_a(name), base); > SymLoadModule(hProcess, 0, tmp, name, base, size); > + TRACE("done loading the module\n"); > return TRUE; You are adding way too many traces, most of which are not necessary. Here for instance, SymLoadModule already contains traces, so there's no need to add traces around the call. It's fine to do that sort of thing to help following things when you are trying to understand the code, but afterwards they should be removed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3dx8: Implementation of D3DXAssembleShaderFromFileA
by Dmitry Timoshkov Nov. 27, 2007

Nov. 27, 2007

<luis.busquets(a)ilidium.com> wrote: > else eliminated Did you actually compile it? If you did, did you see a warning you introduced? -- Dmitry.

1 0

modified: dlls/d3dx8/d3dx8_main.c modified: include/d3dx8core.h
by luis.busquets＠ilidium.com Nov. 27, 2007

Nov. 27, 2007

else eliminated. --- dlls/d3dx8/d3dx8_main.c | 18 +++++++++++++----- include/d3dx8core.h | 2 +- 2 files changed, 14 insertions(+), 6 deletions(-)

2 1

Re: ole32: Add tests for WdtpInterfacePointer_* functions.
by Juan Lang Nov. 26, 2007

Nov. 26, 2007

Hi Rob, + ok(*(DWORD *)wireip == 0x44, "wireip + 0x0 should be 0x4c 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); Shouldn't these be "should be 0x44 instead of..."? --Juan

1 0

Re: [PATCH 3/3] advapi32: Add support for using the Mac Keychain services as a backend for the credential functions instead of the registry.
by Juan Lang Nov. 26, 2007

Nov. 26, 2007

Hi Rob, @@ -232,6 +239,198 @@ static DWORD registry_read_credential(HKEY hkey, PCREDENTIALW credential, return ret; } +static DWORD mac_read_credential_from_item(SecKeychainItemRef item, BOOL require_password, + PCREDENTIALW credential, char *buffer, + DWORD *len) You're missing compilation protection here (and elsewhere) on non-Apple systems. --Juan

2 1

1.0 bugs
by Dan Kegel Nov. 26, 2007

Nov. 26, 2007

[putting on tastemaster hat] So far, 82 bugs have been nominated to be fixed for 1.0. I checked a bunch of them, and so far most look reasonable. Some even look easy or have patches, e.g. http://bugs.winehq.org/show_bug.cgi?id=5402 http://bugs.winehq.org/show_bug.cgi?id=5884 http://bugs.winehq.org/show_bug.cgi?id=7544 http://bugs.winehq.org/show_bug.cgi?id=7571 http://bugs.winehq.org/show_bug.cgi?id=9104 http://bugs.winehq.org/show_bug.cgi?id=10147 The list looks meaty enough that it's probably worth folks going through and seeing what they can pick off. Stuff that's silly or too hard - just skip it for now, we'll defer those for later. - Dan

1 1

Re: d3dx8: Implementation of D3DXAssembleShaderFromFileA using D3DXAssembleShaderFromFileW
by Stefan Dösinger Nov. 26, 2007

Nov. 26, 2007

Am Montag, 26. November 2007 11:37:28 schrieb luis.busquets(a)ilidium.com: > --- > dlls/d3dx8/d3dx8_main.c | 22 ++++++++++++++++------ > include/d3dx8core.h | 4 ++-- > 2 files changed, 18 insertions(+), 8 deletions(-) Please watch out with indentions. You are mixing tabs and spaces in D3DXAssembleShaderFromFileA, so the code looks a bit dissorted here.

1 0

Re: Re: urlmon: Wrap heap functions.
by Lionel Debroux Nov. 26, 2007

Nov. 26, 2007

Hi, > 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 second Michael on that. A number of spurious entries previously in his list of potential issues detected by Smatch ( http://people.redhat.com/mstefani/wine/smatch/bugs_all.html ) were due to the wrappers around HeapFree that the script wasn't yet aware of. Currently, the list of functions that allocate memory, in the unfree_wine script, contains 33 entries. The list of functions that free memory contains 34 entries. > I therefore 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. I like that solution. Bye, Lionel. ____________________________________________________________________________________________ Yahoo! Mail innove : interface hyper pratique, messenger intégré, couleurs - http://mail.yahoo.fr

1 0

Re: widl [1/7]: Output working exception handling macros. [take 2]
by Alexandre Julliard Nov. 26, 2007

Nov. 26, 2007

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > This is essentially the same as the last attempt but doesn't add a wine- > internal function to kernel32. It just puts the code directly in the > widl-generated exception handler. An alternative is to handle these access- > based page faults for which we can continue in the signal handler (signal_i386, > etc., in ntdll) so they never actually result in an exception being raised. > I'm not sure if anything depends on the current behavior and didn't want to > mess much more with the exception handling code than I had to. You shouldn't have to do anything of the kind, there's no reason that the generated code has to duplicate the unhandled exception filter. What you have to do is to filter properly and not catch exceptions you are not interested in. For cases where Windows would catch the access violation exception, then the unhandled filter won't be called on Windows either, that's the way it's supposed to work. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3dx8: Implementation of D3DXAssembleShaderFromFileA using D3DXAssembleShaderFromFileW
by Dmitry Timoshkov Nov. 26, 2007

Nov. 26, 2007

<luis.busquets(a)ilidium.com> wrote: > + LPWSTR pSrcFileW = NULL; > + DWORD len; > + HRESULT ret; > + if (pSrcFile) > + { > + 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; > + } > + else return D3DXERR_INVALIDDATA; > } Usually it's much more readable and helps to avoid not necessary indentation to check parameters at the start of the function and return right away with appropriate error code. Besides you are mixing tabs and spaces. > -HRESULT WINAPI D3DXAssembleShaderFromFileW(LPSTR pSrcFile, DWORD Flags, > +HRESULT WINAPI D3DXAssembleShaderFromFileW(LPWSTR pSrcFile, DWORD Flags, You marked pSrcFile parameter 'const' in D3DXAssembleShaderFromFileA declaration but not in D3DXAssembleShaderFromFileW, any reason for that? -- Dmitry.

1 0