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

Re: msxml - Fix Memory Leak

by Vitaliy Margolen

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > Fixed memory leak > > > Regards > Alistair Leslie-Hughes > > > begin 666 xmlelem.diff Please attach patches as a plain text. This patch is not an attachment and is unreadable. Vitaliy.

Nov. 2, 2007

Re: shell32: Use SHStrDupW in IShellFolder2::GetDetailsOf to allocate returned string

by Vitaliy Margolen

Thomas Weidenmueller wrote: > Use SHStrDupW in IShellFolder2::GetDetailsOf to allocate the returned > string. pOleStr in the STRRET structure has to be allocated using > CoTaskMemAlloc(). SHStrDupW uses CoTaskMemAlloc() whereas StrDupW uses > LocalAlloc(). > > - Thomas > ------------------------------------------------------------------------ > > Index: recyclebin.c > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/recyclebin.c,v > retrieving revision 1.5 > diff -u -r1.5 recyclebin.c > --- recyclebin.c 11 Jun 2007 13:47:57 -0000 1.5 > +++ recyclebin.c 1 Nov 2007 21:58:30 -0000 Please diff it from the top of the source tree. The above should say dlls/shell32/recyclebin.c Vitaliy.

Nov. 2, 2007

Re: [PATCH 02/18] inetcomm: Add a framework for connecting to a server and sending/receiving data asynchronously with callbacks being called in the context of the original thread, using window messages.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > +#include "winsock2.h" > +#include "winuser.h" > + > +#undef GetProp > +#undef SendMessage > +#undef SetProp > + > +#include "objbase.h" > +#include "imnxport.h" You forgot to submit the new imnxport.idl. -- Alexandre Julliard julliard(a)winehq.org

Nov. 2, 2007

Re: Fix type of loop variable in alloc_device().

by Vitaliy Margolen

Gerald Pfeifer wrote: > We iterate between 0 and and the value of an usigned variable, so we > should adjust the loop variable accordingly (not the list to silence > GCC). > - int i; > + unsigned i; If there is nothing wrong about it, then why do you change it? If even gcc does not complain about it. Vitaliy.

Nov. 2, 2007

Re: [PATCH 04/18] inetcomm: Add self-registration code.

by Paul Vriens

Robert Shearman wrote: > --- +static LONG recursive_delete_key(HKEY key); +static LONG recursive_delete_keyA(HKEY base, char const *name); +static LONG recursive_delete_keyW(HKEY base, WCHAR const *name); We just got rid of all the self build recursive delete ones. Can you use RegDeleteTree[AW] (or is there a specific reason not to)? -- Cheers, Paul.

Nov. 2, 2007

Re: [Bug 10266] Numpad keyboard handling is strange, Del keyproducestwo events

by Dmitry Timoshkov

"Peter Åstrand" <astrand(a)cendio.se> wrote: > > Current behaviour emulates what ToUnicodeEx does under Windows. And some > > apps depend on it. > > We shouldn't forget that the Wine keyboard implementation is a total mess. > The code is full of special cases, makes wrong assumptions about the > platform (such as relying on X11 keycodes, bug 1181), contains race > conditions (bug 4923) and is, in general, very ugly. There are a lot of > special cases. Some looks at the virtual key, others are a keysym, others > at keycodes etc etc. The code is a mess. The patches are always welcome, especially if they add a test case for each fix. > It's a good idea to try to have > ToUnicodeEx work mainly as it does on Windows, but we are miles away from > reaching this goal. What goal are you talking about? Since I'm very closely track all locale and keyboard input related problems current code works very well, including international keyboard input. The only feature that is missing is support for loadable keyboard layouts. > At this point, just "make the stuff work as we want it > with most applications" is a more realistic goal. And the stuff really works. > When it comes to my actual patch, I'm not sure it actually changes the > ToUnicodeEx behaviour. As far as I know, ToUnicodeEx returns zero > characters for VK_LEFT etc, regardless of the shift state. > > What my patch is mainly change which vkey is generated, which should be > safe. If you have a test case that doesn't pass without your patch and passes with then your patch is acceptable, otherwise it's not. > Btw, I've asked a dozen of people what they think. Most are advanced > users, using different kinds of platforms. The result is pretty > interesting. None knew the effect of Shift+Numlock, and only 25% were > finding the behaviour of Shift (without NumLock) logic. Even more > interesting is that 5 users actually preferred a model which doesn't exist > on neither Linux nor Windows: The case where NumLock+shift is the same as > just NumLock. Most users said that they were never using Shift with numpad > keys at all. > > Another interesting fact is that none expected or preferred the current > Wine behaviour. It this case it doesn't really matter what users expect or prefer, behaviour of ToUnicodeEx is predefined by what Windows does. -- Dmitry.

Nov. 2, 2007

Re: [PATCH 1/7] advapi32: Implement CredWriteW.

by Detlef Riekenberg

On Di, 2007-10-30 at 12:36 +0000, Robert Shearman wrote: > +static DWORD open_cred_mgr_key(HKEY *hkey, BOOL open_for_write) > +{ > + return RegCreateKeyExW(HKEY_CURRENT_USER, > wszCredentialManagerKey, 0, > + NULL, REG_OPTION_NON_VOLATILE, > + KEY_READ | KEY_WRITE, NULL, hkey, NULL); > +} > + What's the reason of the Parameter "BOOL open_for_write" ? open_cred_mgr_key is called with (..., TRUE) and (..., FALSE), but you always use "KEY_READ | KEY_WRITE". On the other hand, gcc does not warn about that unused Parameter. My first Idea was the optimizer in gcc, but removing "-O2" does not give us a warning. With "-pedantic", we lost (but still no warning for "open_for_write"). -- By by ... Detlef

Nov. 2, 2007

Re: alsa->pulseaudio->alsa directsound hang

by Jan Zerebecki

I didn't test pulseaudio nor looked at your .asoundrc , but there are some non-obvious pitfalls when configuring such stuff in .asoundrc . But the fault may also be that the pulseaudio alsa plugin doesn't fully behave like normal alsa does. Wine is pretty sensitive to such things (even to e.g. non-default dmix settings), but most other alsa applications are not. I made tests with the alsa plugin from jack and wine and mplayer also had problems with that. And, yes, their alsa plugin should be the recommended way to use wine (and other applications) with pulseaudio or jack. I imagine it would be good for those projects to have their alsa plugin working properly. On Fri, Nov 02, 2007 at 12:20:15AM -0700, Al Tobey wrote: > I'm just trying it out as it seems to be the recommended way of mixing > native alsa apps through pulseaudio. It works fine for all the other > alsa apps I tried. Does mplayer work that way without problems? It's the only other application I know of where I experienced similar problems. Jan

Nov. 2, 2007

Re: [Bug 10266] Numpad keyboard handling is strange, Del keyproduces two events

by Peter Åstrand

On Thu, 1 Nov 2007, Dmitry Timoshkov wrote: > > 1) "Not consistent" > > > > It might be interesting to compare with CapsLock. Shift can cancel > > CapsLock, but also substitute it. This is true on both Windows and Linux. > > Additionally, on Linux, NumLock works the same, ie Shift works in both > > directions. On Windows, however, Shift can only cancel NumLock, not > > substitute it. Regardless of whether users actually finds this useful or > > not, I think it's hard to argue for that this is "logical" or > > "consistent". > > Current behaviour emulates what ToUnicodeEx does under Windows. And some > apps depend on it. We shouldn't forget that the Wine keyboard implementation is a total mess. The code is full of special cases, makes wrong assumptions about the platform (such as relying on X11 keycodes, bug 1181), contains race conditions (bug 4923) and is, in general, very ugly. There are a lot of special cases. Some looks at the virtual key, others are a keysym, others at keycodes etc etc. The code is a mess. It's a good idea to try to have ToUnicodeEx work mainly as it does on Windows, but we are miles away from reaching this goal. At this point, just "make the stuff work as we want it with most applications" is a more realistic goal. When it comes to my actual patch, I'm not sure it actually changes the ToUnicodeEx behaviour. As far as I know, ToUnicodeEx returns zero characters for VK_LEFT etc, regardless of the shift state. What my patch is mainly change which vkey is generated, which should be safe. > > Can it be that you have a Windows background and are therefore used to the > > Windows behaviour? > > When NumLock is off arrow kys on numpad should behave like normal arrow > keys IMO. Perhaps you have an idea how to use keypad with NumLock turned > off to move cursor, and to select text when needed with Shift just like > arrow keys do? With the X11/QT model, this is not possible. You need to turn NumLock on to select text. This problem isn't just about "taste", it's a real compatibility problem. A typical way of generating a numpad dot in X11 is to press Shift+NumpadDel. This will typically generate the keysym XK_KP_Decimal. Or, in other layouts (such as Swedish), you will get XK_KP_Separator. In other words, the KeyPress event from the X server contains semantic information: "The user wants a keypad separator symbol". Translating this to "Mark the character to the left" is just plain wrong! One actual case when this is a problem is with VNC. When the VNC servers recieves a XK_KP_Separator keyboard event, it typically generates an event which contains the same XK_KP_Separator keysym. With most layouts, this means using Shift, since typical xmodmaps looks like: keycode XYZ = KP_Delete KP_Separator Again, it's vital that Wine translates this into a separator symbol, or there will be no way of generating such a symbol via VNC. Btw, I've asked a dozen of people what they think. Most are advanced users, using different kinds of platforms. The result is pretty interesting. None knew the effect of Shift+Numlock, and only 25% were finding the behaviour of Shift (without NumLock) logic. Even more interesting is that 5 users actually preferred a model which doesn't exist on neither Linux nor Windows: The case where NumLock+shift is the same as just NumLock. Most users said that they were never using Shift with numpad keys at all. Another interesting fact is that none expected or preferred the current Wine behaviour. I've updated my HOWTO with some new information, still available as http://www.cendio.com/~astrand/keyboards/numpad.txt. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00 ThinLinc User Group 2007 Höstkonferens --- 15-16 november, Linköping. Program och anmälan: http://www.thinlincusergroup.se/aktiviteter

Nov. 2, 2007

Re: setupapi: Add stub for SetupInstallServicesFromInfSectionW

by Alexandre Julliard

Frank Richter <frank.richter(a)gmail.com> writes: > Unless you ignore the A/W suffix. One could argue that this is more > intuitive as you could locate an entry in the list by searching for the > undecorated name and then look for the one with the appropriate suffix, > which is at most one line away. If you sort strictly alphabetically, A/W > variants may be a couple of lines away (e.g. FooA/FooExA/FooExW/FooW) > which could make finding the right variant slightly counterintuitive. It may be counterintuitive, but it is sorted alphabetically on Windows so we want to do it the same way. -- Alexandre Julliard julliard(a)winehq.org

Nov. 2, 2007