Re: [PATCH] advapi32: add RegSetKeyValue{A,W}
On 1/13/2013 09:27, danielfsan...@att.net wrote:
Adds RegSetKeyValue{A,W} to advapi32.dll
Refactors RegSetValue{A,W} to call RegSetKeyValue{A,W}
Fixes bug #32711
---
dlls/advapi32/advapi32.spec |4 +-
dlls/advapi32/registry.c| 81 +--
2 files changed, 64 insertions(+), 21 deletions(-)
diff --git a/dlls/advapi32/advapi32.spec b/dlls/advapi32/advapi32.spec
index 21357fa..336518b 100644
--- a/dlls/advapi32/advapi32.spec
+++ b/dlls/advapi32/advapi32.spec
@@ -645,8 +645,8 @@
# @ stub RegSaveKeyExW
@ stdcall RegSaveKeyW(long ptr ptr)
@ stdcall RegSetKeySecurity(long long ptr)
-# @ stub RegSetKeyValueA
-# @ stub RegSetKeyValueW
+@ stdcall RegSetKeyValueA(long str str long ptr long)
+@ stdcall RegSetKeyValueW(long str str long ptr long)
This should use wstr.
+LSTATUS WINAPI RegSetValueW( HKEY hkey, LPCWSTR name, DWORD type, LPCWSTR
data, DWORD count )
+{
+ return RegSetKeyValueW(hkey, name, NULL, type, data, count);
+}
Don't use tabs please.
And as I said in bug comment this needs tests.
Re: comctl32/listview: fix icon spacing calculation
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=23897 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: comctl32/listview: fix icon spacing calculation
On 1/14/2013 00:00, Daniel Jelinski wrote:
-static DWORD LISTVIEW_SetIconSpacing(LISTVIEW_INFO *infoPtr, INT cx, INT cy)
+static DWORD LISTVIEW_SetIconSpacing(LISTVIEW_INFO *infoPtr, WORD cx, WORD cy)
I don't really like it as WORD, what it really is a int value with
special meaning reserved for -1.
For 64bits and lParam == -1 you'll still get two -1 values.
+/* LPARAM = -1 - restore default processing */
+ret = SendMessage(hwnd, LVM_SETICONSPACING, 0, MAKELPARAM(-1,-1));
+todo_wine
+expect(100, LOWORD(ret));
+expect(0x, HIWORD(ret));
+
+/* NOTE: -1 is not the same as MAKELPARAM(-1,-1) in 64bit listview */
+if(sizeof(LPARAM) == 8)
+{
+ret = SendMessage(hwnd, LVM_SETICONSPACING, 0, -1);
+todo_wine {
+expect(0x, LOWORD(ret));
+expect(0x, HIWORD(ret));
+}
+}
That means you should just use lParam == -1. Also this message is
supposed to use MAKELONG apparently, not sure if it makes a difference.
Re: Reload a DLL and _getptd returns zero
On Fri, Jan 11, 2013 at 11:24:55AM -0800, Michael Ost wrote: Hi list, Does anyone know why _getptd() calls would return zero on a DLL that has been reloaded? Does something happen to the TLS used by _getptd? At Muse Research we have been struggling with a deep bug for years where there is a crash _sometimes_ if you load a DLL a second time. Finally (with a big tip of the hat to Julien Pommier at PianoTeq!) we have a test case that demonstrates a (if not _the_) crash. The sequence is: 1. [main] start a thread 2. [main] load a library 3. [thread] call std::cout from the library 4. [main] free the library 5. [main] reload the library 6. [thread] call std::cout from the library - crash! It looks like the crash happens because the MSVCRT function _getptd() is returning zero in step 6. This is dereferenced and crashes. In windows, there is no crash. The library in question is using static vc runtime linkage, so _getptd() is linked in and I don't know exactly what it is doing. But Wine's MSVCRT implementation of _getptd() gets its data from TlsGetValue. And I can see that just before the crash there is a TlsGetValue call that returns zero. Looking at TlsGetValue(), there must be something wrong with the values in TlsSlots. Maybe they persist for DLLs in Windows in a way they don't for Wine...? Or maybe Wine doesn't reinitialize them the same way when the DLL is reloaded? Any hints, thoughts? clues? Thanks! Is this statically linked msvcrt from Wine or Windows? And why free/reload a statically linked library? Ciao, Marcus
Re: Reload a DLL and _getptd returns zero
On 1/13/13 1:17 PM, Marcus Meissner wrote: On Fri, Jan 11, 2013 at 11:24:55AM -0800, Michael Ost wrote: Hi list, Does anyone know why _getptd() calls would return zero on a DLL that has been reloaded? Does something happen to the TLS used by _getptd? At Muse Research we have been struggling with a deep bug for years where there is a crash _sometimes_ if you load a DLL a second time. Finally (with a big tip of the hat to Julien Pommier at PianoTeq!) we have a test case that demonstrates a (if not _the_) crash. The sequence is: 1. [main] start a thread 2. [main] load a library 3. [thread] call std::cout from the library 4. [main] free the library 5. [main] reload the library 6. [thread] call std::cout from the library - crash! It looks like the crash happens because the MSVCRT function _getptd() is returning zero in step 6. This is dereferenced and crashes. In windows, there is no crash. The library in question is using static vc runtime linkage, so _getptd() is linked in and I don't know exactly what it is doing. But Wine's MSVCRT implementation of _getptd() gets its data from TlsGetValue. And I can see that just before the crash there is a TlsGetValue call that returns zero. Looking at TlsGetValue(), there must be something wrong with the values in TlsSlots. Maybe they persist for DLLs in Windows in a way they don't for Wine...? Or maybe Wine doesn't reinitialize them the same way when the DLL is reloaded? Any hints, thoughts? clues? Thanks! Is this statically linked msvcrt from Wine or Windows? It's statically linked in Windows. And why free/reload a statically linked library? We load and unload the DLL that has MSCVRT statically linked into it. Our program is a plugin player, that loads (and unloads) VST sound plugins for musicians to perform with. -- mo
Re: Reload a DLL and _getptd returns zero
On 1/14/2013 01:59, Michael Ost wrote: On 1/13/13 1:17 PM, Marcus Meissner wrote: On Fri, Jan 11, 2013 at 11:24:55AM -0800, Michael Ost wrote: Hi list, Does anyone know why _getptd() calls would return zero on a DLL that has been reloaded? Does something happen to the TLS used by _getptd? At Muse Research we have been struggling with a deep bug for years where there is a crash _sometimes_ if you load a DLL a second time. Finally (with a big tip of the hat to Julien Pommier at PianoTeq!) we have a test case that demonstrates a (if not _the_) crash. The sequence is: 1. [main] start a thread 2. [main] load a library 3. [thread] call std::cout from the library 4. [main] free the library 5. [main] reload the library 6. [thread] call std::cout from the library - crash! It looks like the crash happens because the MSVCRT function _getptd() is returning zero in step 6. This is dereferenced and crashes. In windows, there is no crash. The library in question is using static vc runtime linkage, so _getptd() is linked in and I don't know exactly what it is doing. But Wine's MSVCRT implementation of _getptd() gets its data from TlsGetValue. And I can see that just before the crash there is a TlsGetValue call that returns zero. Looking at TlsGetValue(), there must be something wrong with the values in TlsSlots. Maybe they persist for DLLs in Windows in a way they don't for Wine...? Or maybe Wine doesn't reinitialize them the same way when the DLL is reloaded? Any hints, thoughts? clues? Thanks! Is this statically linked msvcrt from Wine or Windows? It's statically linked in Windows. And why free/reload a statically linked library? We load and unload the DLL that has MSCVRT statically linked into it. Our program is a plugin player, that loads (and unloads) VST sound plugins for musicians to perform with. Not sure if it's related but wine's msvcrt doesn't like to be unloaded, so LdrAddRefDll() is used to prevent that. If I remember correctly there was a problem with messed up standard handles or something like that. -- mo
Re: windowscodecs: Implement CreateBitmapFromHICON. Take 2.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=23899 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: windowscodecs: Implement CreateBitmapFromHICON. Take 2.
Looks good to me.
