July 2008 - Wine-devel - list.winehq.org

Re: comctl32: initial support for drawing themed push buttons.
by Reece Dunn 16 Jul '08

16 Jul '08

2008/7/15 Reece Dunn <msclrhd(a)googlemail.com>: > This adds basic support for drawing themed push buttons. Please ignore this patch, as it breaks the drawing of some dialogs (e.g. Cepstral SwiftTalker options). - Reece

1 0

Re: Patch for Bug 14072
by Vitaliy Margolen 16 Jul '08

16 Jul '08

Chris Ahrendt wrote: > I have been chasing down a bug which causes a unhandled exception in > wine for various d3d applications and have found where the problem occurs. > > The problem occurs in provider.c in dll/dxdiagn > > here is the dif for the patch : > > --- provider.c 2008-07-15 11:56:57.000000000 -0400 > +++ provider_orig.c 2008-07-11 11:55:55.000000000 -0400 > @@ -665,11 +665,7 @@ static HRESULT DXDiag_InitDXDiagDirectSh > } > IPropertyBag_Release(pPropFilterBag); pPropFilterBag = NULL; > } > - if (pEnum != NULL) > - { > - IEnumMoniker_Release(pEnum); > - pEnum = NULL; > - } > + IEnumMoniker_Release(pEnum); pEnum = NULL; > } > class_enum_failed: > SysFreeString(wszCatName); > > What's occuring is that pEnum is NULL and when the release function is > called it throws an exception. This fix checks to make sure its not > NULL before calling the release. > > If you need the exception please look at bug 14072 > > Chris > Thanks for the patch however there are number of things that are wrong with it: 1. You need to generate patch from the top of the source tree. 2. provider_orig.c goes first not second 3. The patch is not correct - it's hiding an error. The pEnum should not be NULL. If it is - something else is really wrong. 4. The crash in your bug has nothing to do with what you are fixing. Unless you attached the wrong trace. Vitaliy.

1 0

Re: Patches for "RegGetValue" and "SetDIBits"
by James Hawkins 16 Jul '08

16 Jul '08

On Tue, Jul 15, 2008 at 10:56 PM, Mathias Kosch <info(a)mkosch.de> wrote: > Dear Sirs and Madams, > > while configuration "The Bat!" for wine I had to fix some issues with > Wine (version 1.1.1). I am now sending you the patches, because I was > told so in Bugzilla. I hope, they can be applied to the next version > of Wine so I don't need to recompile myself. > > The first problem relates to the functions "RegGetValueW" and > "RegGetValueA" in "advapi32". > In case dwFlags contains the Bits (RRF_RT_REG_EXPAND_SZ | > RRF_RT_REG_SZ) and not the bit RRF_NOEXPAND the function will return > ERROR_INVALID_PARAMETER. This is wrong behaviour, because expansion > will transform a result of type RRF_RT_REG_EXPAND_SZ into > RRF_RT_REG_SZ which satisfies the request. > This will especially make the use of the flag "RRF_RT_ANY" impossible. > The patch can be found in the attached file "registry.c.patch". > > The second problems relates to the function "X11DRV_SetDIBits" in > "winex11.drv". It causes "The Bat!" to display white squares instead > of colored icons. > The mistake is inside the recently added optimization code for the > case "where the input bits are in exactly the same format as the > internal representation". > The assignment >> dbits = (LPBYTE)bits + (dstwidthb * (lines-1)); > obviously needs to be changed to: >> dbits = (LPBYTE)dbits + (dstwidthb * (lines-1)); > The patch can be found in the attached file "dib.c.patch". > Only one patch per mail. Please read about sending patches to Wine at [1]. Also, you forgot to send a test case as was mentioned in the bug report. [1] http://www.winehq.org/site/sending_patches -- James Hawkins

1 0

Re: secur32: First small test for a Kerberos SSP. (try 2)
by Kai Blin 15 Jul '08

15 Jul '08

On Tuesday 15 July 2008 14:23:29 Kai Blin wrote: > + > + ret = pAcquireCredentialsHandleA(NULL, sec_pkg_name, > SECPKG_CRED_INBOUND, + NULL, NULL, NULL, NULL, &cred, &ttl); > + pFreeCredentialsHandle(&cred); > + Of course I missed the ok() check, and of course it's failing. Seems like the patch won't be that small after all. Disregard for now, I'll resend if I have a full patch that works on windows for both server and client side. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

3 2

Re: secur32: First small test for a Kerberos SSP.
by Kai Blin 15 Jul '08

15 Jul '08

On Tuesday 15 July 2008 12:52:49 Kai Blin wrote: Please disregard this one. It's a bit too small, and I've got a small addition that really doesn't make too much sense by itself, but fits into this patch better than it fits into the next patch. I'll resend in a moment. Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

Compile error in wine-1.1.1
by George Dunlap 15 Jul '08

15 Jul '08

Downloaded wine-1.1.1.tar.bz2, and after unzipping, running configure (which included adding some -dev libraries to make it happy) and 'make depend', it ran for several minutes before stopping here: --snip-- make[2]: Leaving directory `/home/dunlapg/src/wine-1.1.1/dlls/mswsock' make[2]: Entering directory `/home/dunlapg/src/wine-1.1.1/dlls/msxml3' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o attribute.o attribute.c In file included from attribute.c:32: msxml_private.h:94: error: expected ')' before 'xmldoc' make[2]: *** [attribute.o] Error 1 make[2]: Leaving directory `/home/dunlapg/src/wine-1.1.1/dlls/msxml3' make[1]: *** [msxml3] Error 2 make[1]: Leaving directory `/home/dunlapg/src/wine-1.1.1/dlls' make: *** [dlls] Error 2 --snip-- I looked at msxml_private.h:94, and it looks perfectly harmless; some previous function prototypes in the same header file use xmlDocPtr in the argument list as well, and don't cause an error. I'm using an Ubuntu 8.04 install. gcc reports version "gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)". Any ideas? -George

4 3

Re: dlls/ws2_32/tests/sock.c: Wait on thread handles before closing sockets
by Andrey Turkin 15 Jul '08

15 Jul '08

Diff doesn't look in line with the description (I can't see any waits in the diff :) 2008/7/15 Jon Griffiths <jon_p_griffiths(a)yahoo.com>: > Hi, > > In the socket tests, avoid a race by waiting for the read threads to finish > before closing the sockets (found during TransmitFile testing). > > Cheers > Jon > > > > > > >

1 0

Re: advpack: Sign-compare warnings fix (Resend)
by Michael Stefaniuc 15 Jul '08

15 Jul '08

Andrew Talbot wrote: > Is there anything wrong with this patch, please? If I might venture a guess it's probably because of the casts. Casts are evil if not really needed and using casts to get rid of the sign comparison warnings is debatable at best. > --- > Changelog: > advpack: Sign-compare warnings fix. > > diff --git a/dlls/advpack/files.c b/dlls/advpack/files.c > index 5e9ce30..43c07ea 100644 > --- a/dlls/advpack/files.c > +++ b/dlls/advpack/files.c > @@ -709,7 +709,7 @@ HRESULT WINAPI ExtractFilesA(LPCSTR CabName, LPCSTR ExpandDir, DWORD Flags, > if (FileList) > { > szConvertedList = convert_file_list(FileList, &dwFileCount); > - if (!szConvertedList || dwFileCount == -1) > + if (!szConvertedList || (LONG)dwFileCount == -1) This one could be replaced by a comparison with either "-1u" or "~0". > { > res = E_FAIL; > goto done; > diff --git a/dlls/advpack/install.c b/dlls/advpack/install.c > index c5a5df0..05a7232 100644 > --- a/dlls/advpack/install.c > +++ b/dlls/advpack/install.c > @@ -41,7 +41,7 @@ WINE_DEFAULT_DEBUG_CHANNEL(advpack); > #define SPAPI_MASK 0xFFFFL > #define HRESULT_FROM_SPAPI(x) ((x & SPAPI_MASK) | SPAPI_PREFIX) > > -#define ADV_HRESULT(x) ((x & SPAPI_ERROR) ? HRESULT_FROM_SPAPI(x) : HRESULT_FROM_WIN32(x)) > +#define ADV_HRESULT(x) ((x & SPAPI_ERROR) ? HRESULT_FROM_SPAPI(x) : (DWORD)HRESULT_FROM_WIN32(x)) > > #define ADV_SUCCESS 0 > #define ADV_FAILURE 1 > > bye michael

3 4

RE: [1/8] [d3d8] validate pool type in CreateVolumeTexture
by Stefan Dösinger 15 Jul '08

15 Jul '08

> + if ((DWORD)(Pool) >= 4) { > + ERR("(%p) Called with invalid pool type\n", This); > + return D3DERR_INVALIDCALL; > + } You could use if(Pool != D3DPOOL_DEFAULT && Pool != MANAGED ...) instead of comparing to the arbitary value "4". The compiler should figure that out and generate a >= 4 for better efficiency, but even if not it doesn't hurt because Create* isn't performance critical.

1 0

RE: [5/8] [wined3d] correctly set lockable boolean in IWineD3DDeviceImpl_CreateVolume
by Stefan Dösinger 15 Jul '08

15 Jul '08

> + if (Usage & WINED3DUSAGE_DYNAMIC) > + object->lockable = ((WINED3DPOOL_DEFAULT == Pool) || (WINED3DPOOL_SYSTEMMEM > == Pool)) ? TRUE : FALSE; The pool check here is somewhat redundant because a DYNAMIC texture of a non-default / non-systemmem pool will not reach that code due to the check added in patches 3 and 4. However, since one is in wined3d and the other check in d3d8/9 it somewhat makes sense to have it; I think we should discuss if we want the pool checks in wined3d or ddraw/d3d8/d3d9/d3d10. I'll take a look at the docs tomorrow. > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Tobias Jakobi > Sent: Monday, July 14, 2008 7:32 AM > To: wine-patches(a)winehq.org > Subject: [5/8] [wined3d] correctly set lockable boolean in > IWineD3DDeviceImpl_CreateVolume > > Hi there, > > this patchset fixes conformance of volumes/volumetextures creation > (plus > locking) in d3d8 and d3d9. Currently creating volumes/volumetextures > always succeeds regardless of the usage and pool type specified. > > A testcase for both d3d8 and d3d9 is included in the last two patches. > The test was verified on Vista and XP systems. > > Further fixes to volume/volumetexture locking are planned (the > behaviour is still not quite correct) and some of the fixes in this > patchset could be moved over to wined3d. That's also something that can > be done when the hardest work is over. > > Cheers, > Tobias Jakobi > > (PART 5/8) > >

1 0