Re: Some thoughts about next GSoC
On Thursday 22 November 2007 11:38:19 Kai Blin wrote: Comments? Thanks for the comments so far. I'll just go and flesh out the wiki page some more during next week, then we can talk about the individual steps if people think they need discussion. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: d3dx8: Implementation of WINAPI D3DXAssembleShaderFromFileA
[EMAIL PROTECTED] wrote:
I say that it is more readable because I understood you wanted the return
code as soon as possible, but, anyway, what would you propose as code for
this function?
Would the following work for you?
Just go for
if ( !pSrcFile )
return D3DXERR_INVALIDDATA;
LPWSTR pSrcFileW = NULL;
DWORD len;
HRESULT ret;
...
Like Dimitry said the else is not needed at all.
bye
michael
+
+ if ( !pSrcFile )
+ return D3DXERR_INVALIDDATA;
+ else
+ {
+ LPWSTR pSrcFileW = NULL;
+ DWORD len;
+ HRESULT ret;
+ 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.
--
Michael Stefaniuc Tel.: +49-711-96437-199
Sr. Network EngineerFax.: +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
modified: dlls/d3dx8/d3dx8_main.c modified: include/d3dx8core.h
else eliminated.
---
dlls/d3dx8/d3dx8_main.c | 18 +-
include/d3dx8core.h |2 +-
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/dlls/d3dx8/d3dx8_main.c b/dlls/d3dx8/d3dx8_main.c
index 9221221..81a1eca 100644
--- a/dlls/d3dx8/d3dx8_main.c
+++ b/dlls/d3dx8/d3dx8_main.c
@@ -29,11 +29,10 @@
#include wingdi.h
#include winuser.h
#include wine/debug.h
-
+#include wine/unicode.h
#include d3dx8core.h
#include d3dx8core_private.h
-
WINE_DEFAULT_DEBUG_CHANNEL(d3d);
HRESULT WINAPI D3DXCreateBuffer(DWORD NumBytes, LPD3DXBUFFER* ppBuffer) {
@@ -79,11 +78,20 @@ HRESULT WINAPI D3DXAssembleShaderFromFileA(LPSTR pSrcFile, DWORD Flags,
LPD3DXBUFFER* ppConstants,
LPD3DXBUFFER* ppCompiledShader,
LPD3DXBUFFER* ppCompilationErrors) {
- FIXME((void): stub\n);
- return D3D_OK;
+ if ( !pSrcFile )
+ return D3DXERR_INVALIDDATA;
+ LPWSTR pSrcFileW = NULL;
+ DWORD len;
+ HRESULT ret;
+ 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;
}
-HRESULT WINAPI D3DXAssembleShaderFromFileW(LPSTR pSrcFile, DWORD Flags,
+HRESULT WINAPI D3DXAssembleShaderFromFileW(LPWSTR pSrcFile, DWORD Flags,
LPD3DXBUFFER* ppConstants,
LPD3DXBUFFER* ppCompiledShader,
LPD3DXBUFFER* ppCompilationErrors) {
diff --git a/include/d3dx8core.h b/include/d3dx8core.h
index 1398067..051deb7 100644
--- a/include/d3dx8core.h
+++ b/include/d3dx8core.h
@@ -120,7 +120,7 @@ HRESULT WINAPI D3DXAssembleShaderFromFileA(LPSTR pSrcFile, DWORD Flags,
LPD3DXBUFFER* ppConstants,
LPD3DXBUFFER* ppCompiledShader,
LPD3DXBUFFER* ppCompilationErrors);
-HRESULT WINAPI D3DXAssembleShaderFromFileW(LPSTR pSrcFile, DWORD Flags,
+HRESULT WINAPI D3DXAssembleShaderFromFileW(LPWSTR pSrcFile, DWORD Flags,
LPD3DXBUFFER* ppConstants,
LPD3DXBUFFER* ppCompiledShader,
LPD3DXBUFFER* ppCompilationErrors);
Re: TransGaming's dpnet (DirectPlay 8)
On Wednesday 21 November 2007 05:42:18 Gavriel State wrote: Enclosed here is a patch to today's WineHQ git tree with our dpnet implementation in the hopes that someone finds it useful. Beyond ensuring that it compiles and links, it has not been tested at all with WineHQ. That's funny, it doesn't even apply for me against today's git, and the last changes to dlls/dpnet are months old. Would you be so kind and supply the plain source code of dlls/dpnet/address.c ? I've pulled the patch apart and the other changes apply or are trivial to fix manually. Once the code compiles for me, I'll push it to a public git repo. I think the next step would be adding some tests. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: modified: dlls/d3dx8/d3dx8_main.c modified: include/d3dx8core.h
Am Dienstag, 27. November 2007 10:24:55 schrieb [EMAIL PROTECTED]: else eliminated. --- dlls/d3dx8/d3dx8_main.c | 18 +- include/d3dx8core.h |2 +- 2 files changed, 14 insertions(+), 6 deletions(-) Wrong mailing list? signature.asc Description: This is a digitally signed message part.
Reading Registry Example
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
Re: d3dx8: Implementation of D3DXAssembleShaderFromFileA
[EMAIL PROTECTED] wrote: else eliminated Did you actually compile it? If you did, did you see a warning you introduced? -- Dmitry.
Re: [dbghelp 2/11] Return TRUE in SymInitializeW if process is already initialized and add a number of TRACEs
Jason Green [EMAIL PROTECTED] writes:
@@ -216,11 +216,17 @@ static BOOL WINAPI process_invade_cb(PCSTR name, ULONG
base, ULONG size, PVOID u
chartmp[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
[EMAIL PROTECTED]
Re: [dbghelp 1/11] Update some mscvpdb.h definitions and descriptions
Jason Green [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: David Adam : d3dx8: Implement D3DXQuaternionInverse.
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;
Re: USER32: win16 applications should not see long filenames returned from dialog control (try 4) (RESEND)
Alex Villacís Lasso [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: Reading Registry Example
On Tuesday 27 November 2007 04:28:07 James McKenzie wrote: 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 You can access the registry using the same functions that you would use on Windows. Our wordpad and notepad clones read/write to the registry; look in the 'programs' folder of the Wine source. Alexander N. Sørnes
Re: msvcrt heap: fix _aligned_offset_realloc (move correct block of memory); add a comment to explain why. [1/2]
Lionel Debroux [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: urlmon: Wrap heap functions.
Michael Stefaniuc [EMAIL PROTECTED] writes: 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. Standardizing them is OK, but the names aren't very good, especially walloc looks too much like malloc. It's suggest something like heap_alloc, heap_alloc_zero, etc. -- Alexandre Julliard [EMAIL PROTECTED]
Re: user32: Fix a couple of typos
Andrew Talbot [EMAIL PROTECTED] 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: 80c2 dde.c:243: Test failed: client failed with 1 error(s) make[2]: *** [dde.ok] Error 1 -- Alexandre Julliard [EMAIL PROTECTED]
Re: urlmon: Wrap heap functions.
Alexandre Julliard wrote: Michael Stefaniuc [EMAIL PROTECTED] writes: 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. Standardizing them is OK, but the names aren't very good, especially walloc looks too much like malloc. It's suggest something like heap_alloc, heap_alloc_zero, etc. Yeah, i went for the convention used by the Linux kernel replacing 'k' with 'w'. But I don't mind how they are named as long as it is consistent. I'll do a janitorial task page for this and start sending patches. bye michael -- 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
Re: d3dx8: Implementation of WINAPI D3DXAssembleShaderFromFileA
On 27.11.2007 09:28, Michael Stefaniuc wrote: Just go for if ( !pSrcFile ) return D3DXERR_INVALIDDATA; LPWSTR pSrcFileW = NULL; DWORD len; HRESULT ret; ... That's C++, not C, isn't it? -f.r.
Re: d3dx8: Implementation of WINAPI D3DXAssembleShaderFromFileA
Frank Richter wrote: On 27.11.2007 09:28, Michael Stefaniuc wrote: Just go for if ( !pSrcFile ) return D3DXERR_INVALIDDATA; LPWSTR pSrcFileW = NULL; DWORD len; HRESULT ret; ... That's C++, not C, isn't it? No it is C as C99 allows to have the variable definitions in the middle of the code. But Wine itself doesn't allow that and i have missed that. bye michael -- 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
Re: urlmon: Callback can be NULL
Alistair Leslie-Hughes [EMAIL PROTECTED] 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 0x0001 stream.c:330: Test failed: read data differs from file make: *** [stream.ok] Error 3 -- Alexandre Julliard [EMAIL PROTECTED]
Re: David Adam : d3dx8: Implement D3DXQuaternionInverse.
Robert Shearman [EMAIL PROTECTED] a écrit :
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
I have just tried with a native d3dx8 dll. Giving a null pointer to pq
leads to a crash. So, the application must take care to not send such
a pointer.
So, I think that to avoid the warning that you see, we could just
initialize the variable temp before the if condition.
David
Re: [keyboard] GetAsyncKeyState: request for fixing #5623
2007/11/26, Stefan Dösinger [EMAIL PROTECTED]: Am Montag, 26. November 2007 12:17:07 schrieb Rafał Miłecki: 2007/11/7, Rafał Miłecki [EMAIL PROTECTED]: 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? Really, not a chance for fixing this? I know you are busy, have own life, efc. but... maybe? Anyone, please? The usual way for that is either to offer payment to someone to fix it, or fix it yourself. Offering bug bounties was tried in the past, but I don't know how well they worked. The issue is that usually affordable bounties are not comparable to usual salaries and the issues involved with handling the bounty and reading into the code. $100 for a bug bounty is quite a lot already, but at codeweavers we have some estimation that fixing a minor bug costs about $1000 to $1500 to fix(http://www.codeweavers.com/services/engagements/) . Sure, in a lot of cases the easiest way is to pay and get it done. Unfortunately not every person is able to offer hundreds of $ (as I am not). So the most efficient way to get a bug fixed is to read into the code yourself. I tried. I found function implementing GetAsyncKeyState but that's all I was able to do. Improveing this implementation was much over my little skills. The bottom line is that while a free software project may be freely downloadable, but it is not a place where one can expect service for free. I understand that and hope there wasn't anything wrong in my request. I tried be kind and ask for help, not demand it. -- Rafał Miłecki
Re: [PATCH] svchost: Implementation of svchost (revised submission)
On Nov 27, 2007 3:21 PM, Roy Shea [EMAIL PROTECTED] 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
Re: [PATCH] svchost: Implementation of svchost (revised submission)
On Tue, Nov 27, 2007 at 03:37:50PM -0600, James Hawkins wrote:
On Nov 27, 2007 3:21 PM, Roy Shea [EMAIL PROTECTED] 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.
The name of the procedure passed into GetProcAddress is not always the
constant string ServiceMain. In these cases I'm getting the
procedure name from RegQueryValueEx. RegQueryValueEx requires a
little bit of error checking to ensure proper NULL termination of a
REG_SZ. I'd already wrapped this into the helper function GetRegValue
and thought a simple conversion from UnicodeToAscii would be cleaner
than writing a second ANSI version of GetRegValue.
I guess that inlining a native ANSI query doesn't look too bad:
/* Look for alternate to default ServiceMain entry point */
ret = RegQueryValueExA(service_hkey, service_main, NULL, NULL, NULL, size);
if (ret != ERROR_SUCCESS)
{
dll_service_main = NULL;
}
else
{
dll_service_main = HeapAlloc(GetProcessHeap(), 0, size);
ret = RegQueryValueExA(service_hkey, service_main, NULL, NULL,
(LPBYTE)dll_service_main, size);
if (ret != ERROR_SUCCESS)
{
HeapFree(GetProcessHeap(), 0, dll_service_main);
RegCloseKey(service_hkey);
goto cleanup;
}
if (dll_service_main[size-1] != '\0')
{
WINE_TRACE(NULL terminating registry entry: %s\n, service_main);
tmp_value = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
dll_service_main, size+1);
if (!tmp_value)
{
HeapFree(GetProcessHeap(), 0, dll_service_main);
RegCloseKey(service_hkey);
goto cleanup;
}
dll_service_main = tmp_value;
}
}
RegCloseKey(service_hkey);
/* Load the DLL and obtain a pointer to ServiceMain entry point */
library = LoadLibraryW(dll_name_long);
if (!library)
{
WINE_ERR(failed to load library %s, err=%u\n,
wine_dbgstr_w(dll_name_long), GetLastError());
goto cleanup;
}
if (dll_service_main)
{
service_main_func =
(LPSERVICE_MAIN_FUNCTIONW) GetProcAddress(library, dll_service_main);
}
else
{
service_main_func =
(LPSERVICE_MAIN_FUNCTIONW) GetProcAddress(library, service_main);
}
if (!service_main_func)
{
WINE_ERR(cannot locate ServiceMain procedure in DLL for %s\n,
wine_dbgstr_w(service_name));
FreeLibrary(library);
goto cleanup;
}
I'll switch svchost over to a direct ANSI query when looking up the
DLL's service main function.
- 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';
I was saving a line of code at the cost of performance. My bad. Thanks for
catching this. And thank you for your continued help with this patch.
Peace,
-Roy
Re: d3dx9_xx [patch 2/2] Implementation of the different d3dx9_xx lls
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
