August 2006 - Wine-devel - list.winehq.org

Re: secur32: Make AcceptSecurityContext behaviour consistent withWindows.
by Dmitry Timoshkov 14 Aug '06

14 Aug '06

"Kai Blin" <kai.blin(a)gmail.com> wrote: > phNewContext->dwUpper = ctxt_attr; > - phNewContext->dwLower = ret; > + phNewContext->dwLower = (DWORD)helper; You need to cast to ULONG_PTR to make the code 64-bit safe. Also please fix (DWORD)helper casts in other places. -- Dmitry.

2 1

Re: secur32: Clean up AcceptSecurityContext (reduce indent and duplication).
by Kai Blin 14 Aug '06

14 Aug '06

On Sunday 13 August 2006 14:44, Kai Blin wrote: > --- > dlls/secur32/ntlm.c | 372 > ++++++++++++++++++++++----------------------------- > 1 files changed, 164 insertions(+), 208 deletions(-) After sending in the fixes for my "Make AcceptSecurityContext behaviour consistent with Windows, try2" patch, this one won't apply anymore. I'll resend it later today. Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

Re: gdi: Implement GetFontUnicodeRanges.
by Huw Davies 14 Aug '06

14 Aug '06

On Sun, Aug 13, 2006 at 08:26:24PM +0200, Hans Leidekker wrote: > > Any word on this patch? > > -Hans > > Changelog > Implement GetFontUnicodeRanges on top of fontconfig and freetype. I wonder whether FcFreeTypeCharSet is what you really want here. It uses a lot of heuristics which almost certainly won't match what Windows does, so we're probably better off writing our own. A test (on say Arial) would be useful here. Also note that even if you do use the Fc* functions you'll need to check that the pFc* ptrs are non-NULL before calling them. Huw.

2 1

[UPDATE 3] RFC: XEmbed System Tray Patches
by James Liggett 13 Aug '06

13 Aug '06

Attached is the third update to the xembed systray patches. For this version I've simplified the if statements for checking if we should map tray icon windows or not (As per Scott Ritchie's advice--Thanks again Scott.) As always, further comments/suggestions appreciated. Thanks, James Liggett

1 0

[UPDATE 2] RFC: XEmbed System Tray Patches
by James Liggett 13 Aug '06

13 Aug '06

Attached is the second update of the XEmbed systray patches. Changes in this version: 1. On the advice of Juan Lang, I only acquire the wine tsx11 lock when actually making X calls, and not while initializing data. 2. Added the ability to detect if we have an XEmbed systray so that we can selectively determine if we need to map tray windows or not. Under the last version, the icons would not be mapped under any circumstances whatsoever. While it would work if we had an XEmbed-compliant tray to dock with, the icon wouldn't show up at all if there wasn't one. Things work both ways now. But, if you look at the patches, you'll notice that the logic in the if statements is a little ugly. Is there a cleaner way to do this? Thanks, James Liggett

2 3

Re: secur32: make GetComputerObjectNameA use GetComputerObjectNameW (revised)
by Chris Robinson 13 Aug '06

13 Aug '06

On Sunday 13 August 2006 06:45, Robert Reif wrote: > This patch also adds a partial implementation of GetComputerObjectNameW. The GetComputerObjectNameA function appears to be broken. When GetComputerObjectNameW fails due to too little memory in the name buffer, it sets the buffer size as specified by MSDN. However, when GetComputerObjectNameA calls GetComputerObjectNameW and receives an error code, this isn't copied into its nSize parameter.

2 1

Re: reasons for not accepting the patch
by Dan Kegel 12 Aug '06

12 Aug '06

2006/8/12, Vijay Kiran Kamuju <infyquest(a)gmail.com>: > [Why wasn't the patch > http://www.winehq.org/pipermail/wine-patches/2006-July/029145.html > accepted?] I looked at this a couple days ago, and sent this to the patches' author to encourage him to repost it: -- snip --- 1. The patch is missing the filename header, and cannot be applied to the sources by running 'patch'. 2. the patch was posted with the following legal notice: "Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited." That tells us "You may not use this patch." You have to post patches without that. 3. the message did not contain any license information (e.g. Author: Renu Rajput (Tata Inc.) Copyright 2006 Tata Inc License: LGPL. Adding that would help. 4. The message essentially repeated much of the bug report in bugzilla. That's not needed. Just refer to the bug report. Any one of the above four might have been enough to cause the patch to be ignored. Fix them all and you've got a good shot. Two more tips: 5. The bug report in bugzilla does not link to your proposed fix. Often after I post a proposed fix, I add a comment to bugzilla saying something like "Patch sent: http://www.winehq.org/pipermail/wine-patches/2006-July/029145.html" Not only does this give another way for people to stumble across and review your patch, it also helps avoid duplication of effort. I had no idea you had sent in a patch for this bug already! 6. Patches that do not get applied need to be resent after a few days. Every time you resend it, you should try to improve it or the test case a bit, and make sure it still applies against current cvs or git. Use the same subject line as before, but append "(resend)" to the end. Patches are like TCP/IP. There is no ACK when a packet is corrupt, you have to resend after correcting a bit error! --- snip --- Hope that helps. - Dan

2 1

Re: winmm: prevent NULL dereference in MCI_Close
by Eric Pouech 12 Aug '06

12 Aug '06

Jan Zerebecki wrote: >If this patch is rejected from inclusion, please tell me why, as >I would have to ask anyway. > >From: Jan Zerebecki <jan.wine(a)zerebecki.de> > > > Jan, do you have a specific program that depends on this case ?

2 1

Missing subtitle in WWN 307
by Francois Gouget 12 Aug '06

12 Aug '06

Hi, It's not a big issue but I have noticed that in WWN 311 the article about 'Microsoft WGA & Wine' does not have a subject: http://www.winehq.org/?issue=311#Microsoft%20WGA%20&%20Wine Currently it reads: +----------------------------------------+---------+ |Microsoft WGA & Wine | Archive | +----------------------------------------+---------+ That is it is missing the 'subtitle' underneath the gray bar. So it should look something like this: +----------------------------------------+---------+ |Microsoft WGA & Wine | Archive | +----------------------------------------+---------+ WINE & Microsoft WGA Is this an XML parsing bug? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

1 0

Wide-string Functions: Double Casting
by Andrew Talbot 12 Aug '06

12 Aug '06

Although I accept that my opinion may not be universally shared :-), I believe that it is better to turn -Wcast-qual on permanently and double-cast the appropriate return values of the relevant wide-string functions (strchrW(), strrchrW(), strpbrkW(), memchrW() and memrchrW()) than to leave it normally turned off: that way, the developers can avoid violations as they go, and give the janitors a break ;-). These functions are ubiquitous and widely understood, and they account for the vast majority of cast-qual warnings. Because, as I understand it, we are aiming for C89 compatibility, and to try to maximise portability, I am proposing to use size_t, rather than uintptr_t (which is a C99 type): it seems like the next-best thing. So I would like to submit a patch that, for example, changes strchrW() to: extern inline WCHAR *strrchrW( const WCHAR *str, WCHAR ch ) { WCHAR *ret = NULL; do { if (*str == ch) ret = (WCHAR *)(size_t)str; } while (*str++); return ret; } What do people think? Should I just send in the patch and see what criticism it engenders? Does anyone have a system on which this would fail or generate other warnings in place of the cast-qual one? Needless to say, I hope to be tackling the cast-qual janitorial task, soon; hence, my sudden interest in this. Thanks, -- Andy.

4 9