"Tony Lambregts" tony_lambregts@telusplanet.net wrote:
-LONG WINAPI RegSaveKeyW( HKEY hkey, LPCWSTR file, LPSECURITY_ATTRIBUTES sa ) +LONG WINAPI RegSaveKeyA( HKEY hkey, LPCSTR file, LPSECURITY_ATTRIBUTES sa ) {
- LPSTR fileA = HEAP_strdupWtoA( GetProcessHeap(), 0, file );
- DWORD ret = RegSaveKeyA( hkey, fileA, sa );
- if (fileA) HeapFree( GetProcessHeap(), 0, fileA );
- UNICODE_STRING fileW;
- LONG ret;
- RtlCreateUnicodeStringFromAsciiz( &fileW, file );
- ret = RegSaveKeyW( hkey, fileW.Buffer, sa );
- RtlFreeUnicodeString( &fileW ); return ret;
In the vast majority of cases where an API takes file name, ANSI version of the API is supposed to have a limitation of MAX_PATH characters for the name.
Thus, there is no need to waste CPU cycles by allocating/deallocating memory, but instead having an automatic buffer on the stack will be quite enough. See files/drive.c,GetCurrentDirectoryA for a sample.
All other APIs which get a file name as a parameter should be rewritten that way too. Probably that's the task for yet another janitorial project...
All the said above doesn't mean that your patch can't applied as is, that just means that there is a better way of doing this task.