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

Re: oleaut32: Added insufficient memory check to ITypelib2:GetDocumentation2
by Dan Kegel Aug. 15, 2006

Aug. 15, 2006

2006/8/15, Benjamin Arai <me(a)benjaminarai.com>: > ChangeLog: > - Added insufficient memory check to ITypelib2::GetDocumentation2 > - Returns MSDN specified value STG_E_INSUFFICIENTMEMORY Have you *ever* seen this run out of memory in real life? - Dan

1 0

Re: oleaut32: Added insufficient memory check to ITypelib2:GetDocumentation2
by Frank Richter Aug. 15, 2006

Aug. 15, 2006

On 16.08.2006 04:23, Benjamin Arai wrote: > if(pbstrHelpString) > + { > *pbstrHelpString=SysAllocString(This->DocString); > + if(!*pbstrHelpString) > + return STG_E_INSUFFICIENTMEMORY; > + } > if(pdwHelpStringContext) > *pdwHelpStringContext=This->dwHelpContext; > if(pbstrHelpStringDll) > + { > *pbstrHelpStringDll=SysAllocString(This->HelpStringDll); > + if(!pbstrHelpStringDll) > + return STG_E_INSUFFICIENTMEMORY; > + } Hm, shouldn't pbstrHelpString be freed in case the 2nd allocation fails? -f.r.

1 0

Re: kernel32: add GetNativeSystemInfo (Try 2)
by Dan Kegel Aug. 15, 2006

Aug. 15, 2006

This patch is good, and helps fix MS Photostory 2 LE's installer ( http://bugs.winehq.org/show_bug.cgi?id=5966 ). Robert, you might need to repost, though; there was a wrapped line.

1 0

[meta-bug] I can not contact Jeremy Newman
by Jérôme Bouat Aug. 15, 2006

Aug. 15, 2006

Hello, I can not reach Jeremy Newman. I hope he goes well. A very important bug still exist for years but its bugzilla issue gets no response at all : http://bugs.winehq.org/show_bug.cgi?id=5202 Please, say something (i.e. WONTFIX, INVALID, LATER, ...). I hope someone will respond. Thanks.

4 4

Re: user: Pass all required information with internal message when chaining hooks
by Alexandre Julliard Aug. 15, 2006

Aug. 15, 2006

Vitaliy Margolen <wine-patch(a)kievinfo.com> writes: > This patch deals with two sides of this problem. And actually saves > some time by not calling server one extra time. I don't think that's a good thing, now you risk calling a hook that has been deleted already. You really want to fetch the hook info from the destination thread. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: usp10: Resend - Remove unnecessary casts in test suite
by Alexandre Julliard Aug. 15, 2006

Aug. 15, 2006

Jeff L <lats(a)yless4u.com.au> writes: > Any problems? It doesn't apply. When resending a patch please regenerate it against the current tip. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: usp10: Resend - Add funtionality for ScriptStringAnalyse
by Alexandre Julliard Aug. 15, 2006

Aug. 15, 2006

Jeff L <lats(a)yless4u.com.au> writes: > + cMaxItems = 255; /* Pick an abritary size for buffers */ > + if (!*pssa) /* Clean it out and start again */ > + ScriptStringFree(pssa); I still don't see why you want to free a NULL pointer. > + { > + prtssa(*pssa); > + analysis = * pssa; > + prtssa((SCRIPT_STRING_ANALYSIS *)analysis); Why do you print the same object twice? There seems to be a lot of confusion in your code between pointers and pointers to pointers, I think you need to define better data types to clarify this. -- Alexandre Julliard julliard(a)winehq.org

1 0

RFC: XEmbed Systray Patches
by James Liggett Aug. 15, 2006

Aug. 15, 2006

Hi Everyone, First, I'd like to apologize for sending those tarballs to wine-devel, as I've just been advised on IRC that such a practice discourages reviews. I've attached a text version of the patches in the hopes that it will get some more exposure. Again, sorry for the trouble. :) James

2 1

All right, let's solve these .desktop issues forever
by Scott Ritchie Aug. 14, 2006

Aug. 14, 2006

As of right now, I'd estimate that over half of our users are using Wine from a terminal window to launch their applications, largely because their window manager doesn't put Wine's Start Menu entries into their applications menu. Wine's been making .desktop files for some time, however it seems like they're being put in the wrong place. There's supposedly a proper, standard place to put them (or there should be), and perhaps a hack can be put in at the package-maintainer level, but in any case this is a pretty big usability issue at the moment. I'm pretty confident that someone here knows the answer to how things should be, and I'm also pretty sure it's a fairly simple change to make. Either way, we need to have a discussion about it - what's the next step here? Thanks, Scott Ritchie

7 8

Re: USER: SystemParametersInfo fixes
by Alexandre Julliard Aug. 14, 2006

Aug. 14, 2006

Frank Richter <frank.richter(a)gmail.com> writes: > Subject: [PATCH] USER: Fix SPI_SETICONTITLELOGFONT to check for LOGFONTW size > [...] > Subject: [PATCH] USER: initialize size of nonclients struct in load_nonclient_metrics Please don't attach multiple patches, each patch should be a separate mail. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: WineD3D: add rgb24 colorkey conversion
by Alexandre Julliard Aug. 14, 2006

Aug. 14, 2006

"Roderick Colenbrander" <thunderbird2k(a)gmx.net> writes: > + for (x = 0; x < len; x++) { > + /* Retrieve RGB24 color */ > + DWORD color = *((DWORD*)src); > + /* Store the RGB portion in dest and reserve a byte for alpha */ > + *Dest = color << 8; > + if ((color < surf->SrcBltCKey.dwColorSpaceLowValue) || > + (color > surf->SrcBltCKey.dwColorSpaceHighValue)) > + *Dest |= 0xff; > + src += 3; You should avoid unaligned DWORD accesses, this doesn't work on all platforms. -- Alexandre Julliard julliard(a)winehq.org

1 0

RFC: OpenGL x11drv rewrite (WoW fix)
by Roderick Colenbrander Aug. 14, 2006

Aug. 14, 2006

Hi, Since the WM rewrite we can only use the visual which was created by x11drv at x11drv initialization. In general this is a simple 32bit RGBA visual or when that's not available it is some 16bit visual. The problem is that the opengl code advertises more formats than this single format. The problem which this can cause is that a 'bad' format is set by SetPixelFormat. In the end when we create a context using wglCreateContext this 'bad' pixelformat is used. When some time later glXMakeCurrent is called we will get a BadMatch. (Note that in a few cases we catch the 'BadMatch' before it happens and create a new GLX Context; this is when context is NULL) The proposed patch which I attached to this email rewrites the pixel format code. First I'll give a short introduction and then I will explain my changes. The functions ChoosePixelFormat/GetPixelFormat/SetPixelFormat/DescribePixelFormat all work with a parameter 'iPixelFormat'. This variable is an index into the table of supported pixel formats. At the moment the index is a direct mapping to the FB config table exported by GLX. I have changed ChoosePixelFormat to only return the format of the main visual. Further this function needs to find a 'closest match' to the requested format, before it tried to find an exact match. I changed the function to look for a close match. Further because only 1 format is supported, the max index the function can return is 1. This kills the direct mapping of the index to the index in the GLX FB config table. All the opengl calls in x11drv got changed to only accept our single format. As I mentioned earlier the opengl calls used the specified iPixelFormat as an index in the GLX FB config table. Because the 1:1 mapping of iPixelFormat to this table got lost I have added a function to retrieve the index of the main visual. Further I had to change our wglMakeCurrent call to retrieve the pixel format to use from the main visual instead of getting it from a GetPixelFormat call. This was done because wglMakeCurrent needs an index into the GLX FB Config table and not in our 'win32 opengl format table' (which only contains 1 format). I have tested the patch in several programs. Before Halflife1 didn't work in 16bit because ChoosePixelFormat was too strict, the game works fine now. Further the patch also fixes the BadMatch error Nvidia users received in World Of Warcraft when using the OpenGL renderer. I think the patch is a correct fix for the BadMatch / ChoosePixelFormat issues. The patch isn't 100% complete yet as I haven't updated the WGL extensions for pbuffer and wglChoosePixelFormat to work with the new pixelformats yet (that's why you see a line WoW hack). I will fix that part when you guys think that the patch is correct. Regards, Roderick Colenbrander -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

2 1

Is anyone going to or presenting at Linuxworld?
by Scott Ritchie Aug. 14, 2006

Aug. 14, 2006

Linuxworldexpo is this week. Since no one's mentioned it yet, I'm assuming that we don't have a booth or speech planned :) http://www.linuxworldexpo.com/live/12/events/12SFO06A At any rate, perhaps we should be going to things like this. There's usually a convention like this (OSCON, etc) every couple of months, and it certainly couldn't hurt to have a Wine evangelist there talking about how powerful Wine is getting and why Wine should be considered as a bigger part of the Linux strategy. What do you think? Thanks, Scott Ritchie

2 1

Re: resend add missing glyph code to GetGlyphIndices
by Dmitry Timoshkov Aug. 14, 2006

Aug. 14, 2006

"Jeff L" <lats(a)yless4u.com.au> wrote: > -DWORD WineEngGetGlyphIndices(GdiFont font, LPCWSTR lpstr, INT count, > + * */ Strange indentation at the end of a comment. > +DWORD WineEngGetGlyphIndices(HDC hdc, GdiFont font, LPCWSTR lpstr, INT count, > LPWORD pgi, DWORD flags) > { > INT i; > - > + TEXTMETRICW textm; > for(i = 0; i < count; i++) > + { > pgi[i] = get_glyph_index(font, lpstr[i]); > - > + if (pgi[i] == 0) > + { > + if (flags & GGI_MARK_NONEXISTING_GLYPHS) > + pgi[i] = 0x001f; /* Indicate non existance */ > + else > + { > + GetTextMetricsW(hdc, &textm); > + pgi[i] = textm.tmDefaultChar; > + } > + } > + } > return count; > } I'd suggest to move GetTextMetricsW outside of the loop to not kill the performance. > + WCHAR testtext[] = {'T',0x0000,'s','t',0xffff,0}; > + WORD glyphs[(sizeof(testtext)/2)-1]; > + TEXTMETRIC textm; > + > + memset(&lf, 0, sizeof(lf)); > + strcpy(lf.lfFaceName, "Symbol"); > + lf.lfHeight = 20; > + > + hfont = CreateFontIndirectA(&lf); > + hdc = GetDC(0); > + > + ok(GetTextMetrics(hdc, &textm), "GetTextMetric failed\n"); Please set tab width to 8 instead of 4 and do not mix tabs and spaces. -- Dmitry.

3 3

Re: secur32: Fix heap error.
by Kai Blin Aug. 14, 2006

Aug. 14, 2006

On Monday 14 August 2006 11:57, Kai Blin wrote: > --- > dlls/secur32/dispatcher.c | 1 - > dlls/secur32/ntlm.c | 1 + > 2 files changed, 1 insertions(+), 1 deletions(-) Sorry, this one is obviously a typo. Sending a new one. 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: secur32: Make AcceptSecurityContext behaviour consistent withWindows.
by Dmitry Timoshkov Aug. 14, 2006

Aug. 14, 2006

"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 Aug. 14, 2006

Aug. 14, 2006

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 Aug. 14, 2006

Aug. 14, 2006

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 Aug. 13, 2006

Aug. 13, 2006

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 Aug. 13, 2006

Aug. 13, 2006

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 Aug. 13, 2006

Aug. 13, 2006

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 Aug. 12, 2006

Aug. 12, 2006

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 Aug. 12, 2006

Aug. 12, 2006

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 Aug. 12, 2006

Aug. 12, 2006

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 Aug. 12, 2006

Aug. 12, 2006

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