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

Re: d3dx9: Implement D3DXCheckVersion [PATCH 1/9]
by Alexandre Julliard 26 Feb '08

26 Feb '08

tony.wasserka(a)freenet.de writes: > D3DXCheckVersion doesn't check for one specific D3DX version, but > for all that are compatible with our Wine code (i.e. d3dx9_24 to d3dx9_36) > The reasons for that were explained in these mails by me: > http://www.winehq.org/pipermail/wine-devel/2008-February/062290.html > and http://www.winehq.org/pipermail/wine-devel/2008-February/062292.html This is wrong, you should have a separate version check for each dll that checks the exact version of that dll. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msvcrt: Implemented wcscpy_s (try 2)
by Alistair Leslie-Hughes 26 Feb '08

26 Feb '08

Hi, Is there any thing wrong with this patch? Best Regards Alistair Leslie-Hughes "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote in message news:fpljui$nsa$1(a)ger.gmane.org... > Hi, > Correct msvcrt.spec file > > Changelog: > msvcrt: Implemented wcscpy_s > -------------------------------------------------------------------------------- > From 6860771cc3fc06b3da63f7c674daf71861593ef3 Mon Sep 17 00:00:00 2001 > From: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > Date: Fri, 22 Feb 2008 13:48:01 +1100 > Subject: [PATCH] Implemented wcscpy_s > > --- > dlls/msvcrt/msvcrt.spec | 1 + > dlls/msvcrt/tests/string.c | 45 > ++++++++++++++++++++++++++++++++++++++++++++ > dlls/msvcrt/wcs.c | 45 > ++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 91 insertions(+), 0 deletions(-) > > diff --git a/dlls/msvcrt/msvcrt.spec b/dlls/msvcrt/msvcrt.spec > index d6cffcb..7b821e6 100644 > --- a/dlls/msvcrt/msvcrt.spec > +++ b/dlls/msvcrt/msvcrt.spec > @@ -761,6 +761,7 @@ > @ cdecl wcscmp(wstr wstr) ntdll.wcscmp > @ cdecl wcscoll(wstr wstr) MSVCRT_wcscoll > @ cdecl wcscpy(ptr wstr) ntdll.wcscpy > +@ cdecl wcscpy_s(ptr long wstr) MSVCRT_wcscpy_s > @ cdecl wcscspn(wstr wstr) ntdll.wcscspn > @ cdecl wcsftime(ptr long wstr ptr) MSVCRT_wcsftime > @ cdecl wcslen(wstr) ntdll.wcslen > diff --git a/dlls/msvcrt/tests/string.c b/dlls/msvcrt/tests/string.c > index c6dcd34..b09d204 100644 > --- a/dlls/msvcrt/tests/string.c > +++ b/dlls/msvcrt/tests/string.c > @@ -50,6 +50,7 @@ static int* (*pmemcmp)(void *, const void *, size_t n); > static int (*pstrcpy_s)(char *dst, size_t len, const char *src); > static int (*pstrcat_s)(char *dst, size_t len, const char *src); > static int (*p_mbsnbcpy_s)(unsigned char * dst, size_t size, const > unsigned char * src, size_t count); > +static int (*p_wcscpy_s)(wchar_t *wcDest, size_t size, const wchar_t > *wcSrc); > > #define SETNOFAIL(x,y) x = (void*)GetProcAddress(hMsvcrt,y) > #define SET(x,y) SETNOFAIL(x,y); ok(x != NULL, "Export '%s' not found\n", > y) > @@ -562,6 +563,47 @@ static void test__mbsnbcpy_s(void) > dest[0], dest[1], dest[2], dest[3], dest[4], dest[5], dest[6], > dest[7]); > } > > +static void test_wcscpy_s(void) > +{ > + static const WCHAR szLongText[] = { > 'T','h','i','s','A','L','o','n','g','s','t','r','i','n','g',0 }; > + static WCHAR szDest[18]; > + static WCHAR szDestShort[8]; > + int ret; > + > + if(!p_wcscpy_s) > + { > + skip("wcscpy_s not found\n"); > + return; > + } > + > + /* Test NULL Dest */ > + ret = p_wcscpy_s(NULL, 16, szLongText); > + ok(ret == EINVAL, "p_wcscpy_s expect EINVAL got %d\n", ret); > + > + /* Test NULL Source */ > + szDest[0] = 'A'; > + ret = p_wcscpy_s(szDest, 16, NULL); > + ok(ret == EINVAL, "expected EINVAL got %d\n", ret); > + ok(szDest[0] == 0, "szDest[0] not 0\n"); > + > + /* Test invalid size */ > + szDest[0] = 'A'; > + ret = p_wcscpy_s(szDest, 0, szLongText); > + ok(ret == EINVAL, "expected ERANGE got %d\n", ret); > + ok(szDest[0] == 0, "szDest[0] not 0\n"); > + > + /* Copy same buffer size */ > + ret = p_wcscpy_s(szDest, 18, szLongText); > + ok(ret == 0, "expected 0 got %d\n", ret); > + ok(lstrcmpW(szDest, szLongText) == 0, "szDest != szLongText\n"); > + > + /* Copy smaller buffer size */ > + szDest[0] = 'A'; > + ret = p_wcscpy_s(szDestShort, 8, szLongText); > + ok(ret == ERANGE, "expected EINVAL got %d\n", ret); > + ok(szDestShort[0] == 0, "szDest[0] not 0\n"); > +} > + > START_TEST(string) > { > char mem[100]; > @@ -577,6 +619,7 @@ START_TEST(string) > SET(pstrcpy_s,"strcpy_s"); > SET(pstrcat_s,"strcat_s"); > SET(p_mbsnbcpy_s,"_mbsnbcpy_s"); > + SET(p_wcscpy_s,"wcscpy_s"); > > /* MSVCRT memcpy behaves like memmove for overlapping moves, > MFC42 CString::Insert seems to rely on that behaviour */ > @@ -599,4 +642,6 @@ START_TEST(string) > test_strcpy_s(); > test_strcat_s(); > test__mbsnbcpy_s(); > + > + test_wcscpy_s(); > } > diff --git a/dlls/msvcrt/wcs.c b/dlls/msvcrt/wcs.c > index 92dd644..66b8907 100644 > --- a/dlls/msvcrt/wcs.c > +++ b/dlls/msvcrt/wcs.c > @@ -27,6 +27,8 @@ > #include "wine/unicode.h" > #include "wine/debug.h" > > +#include <msvcrt/errno.h> > + > WINE_DEFAULT_DEBUG_CHANNEL(msvcrt); > > > @@ -971,3 +973,46 @@ INT CDECL MSVCRT_iswxdigit( MSVCRT_wchar_t wc ) > { > return isxdigitW( wc ); > } > + > +/********************************************************************* > + * wcscpy_s (MSVCRT.@) > + */ > +INT CDECL MSVCRT_wcscpy_s( MSVCRT_wchar_t* wcDest, size_t numElement, > const MSVCRT_wchar_t *wcSrc) > +{ > + int size = 0; > + > + if(!wcDest) > + return EINVAL; > + > + if(!wcSrc) > + { > + wcDest[0] = 0; > + return EINVAL; > + } > + > + if(numElement <= 0) > + { > + wcDest[0] = 0; > + > + if(numElement < 0) > + return ERANGE; > + else > + return EINVAL; > + } > + > + size = strlenW(wcSrc) + 1; > + > + if(size > numElement) > + { > + wcDest[0] = 0; > + return ERANGE; > + } > + > + if(size > numElement) > + size = numElement; > + > + memcpy( wcDest, wcSrc, size*sizeof(WCHAR) ); > + > + return 0; > +} > + > -- > 1.5.4.1 > > -------------------------------------------------------------------------------- > >

2 1

Re: [6/6] msxml3: Tests for put_data
by Alistair Leslie-Hughes 26 Feb '08

26 Feb '08

"Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote in message news:fpu31c$upv$4(a)ger.gmane.org... > +#if 0 > +/* For some Reason, IXMLDOMComment_put_data cannot be found even though > it can > + be exists in msxml2.h. > + */ > + /* put data Tests */ > + hr = IXMLDOMComment_put_data(pComment, _bstr_("This &is a > ; test <>\\")); > + ok(hr == S_OK, "ret %08x\n", hr ); > + > +#endif Hi, Im a little confused, IXMLDOMComment_put_data wasnt compiling on my machine, and yet Alexandre changed to include this code and now it compiles correctly? I event tried a >make clean; ./configure; make depend;make which didnt work either. Can anybody explain what was fixed? Best Regards Alistair Leslie-Hughes

2 1

Re: wininet: Fix retrieving the raw headers
by Alexandre Julliard 26 Feb '08

26 Feb '08

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> writes: > @@ -3059,12 +3060,14 @@ static INT HTTP_GetResponseHeaders(LPWININETHTTPREQW lpwhr) > * We should first receive 'HTTP/1.x nnn OK' where nnn is the status code. > */ > memset(buffer, 0, MAX_REPLY_LEN); > + memset(buffertoken, 0, MAX_REPLY_LEN); > if (!NETCON_getNextLine(&lpwhr->netConnection, bufferA, &buflen)) > goto lend; > MultiByteToWideChar( CP_ACP, 0, bufferA, buflen, buffer, MAX_REPLY_LEN ); > + MultiByteToWideChar( CP_ACP, 0, bufferA, buflen, buffertoken, MAX_REPLY_LEN ); That's ugly, it shouldn't be necessary to have two copies of the whole data just to parse some status codes. -- Alexandre Julliard julliard(a)winehq.org

1 0

Valgrind results. Update for glibc-2.6.
by Dan Kegel 25 Feb '08

25 Feb '08

Today's valgrind results online at http://kegel.com/wine/valgrind/logs-2008-02-25-summary.txt http://kegel.com/wine/valgrind/logs-2008-02-25/ Nothing too special (thanks for the cleanup, James), but this is the first set of results after updating my test machine from feisty to gutsy, and I had to apply http://kegel.com/wine/valgrind/futimesat.patch to my copy of valgrind svn to handle the new glibc properly. Already reported to Valgrind; see http://sourceforge.net/mailarchive/forum.php?thread_name=a71bd89a0802240546…

3 3

Re: Add a slight delay before testing the ddraw and d3d9 visual tests
by Dmitry Timoshkov 25 Feb '08

25 Feb '08

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > This makes the tests pass on my pc. Perhaps there is something less hacky way like GdiFlush() which is more appropriate for this. -- Dmitry.

2 3

Re: d3dx9_xx
by Francois Gouget 25 Feb '08

25 Feb '08

On Fri, 22 Feb 2008, "Luis C. Busquets Pérez" wrote: > The number of functions reported in > http://www.winehq.org/site/winapi_stats > for the following dlls is > > d3dx9_24 308 [...] That's because d3dx9_36 has some forwards to functions that have not been declared in d3dx8, not even as a stub. It's allowed of course but winapi does not like it and thus ignores those. Here's the list: d3dx9_36.spec: forward is broken: D3DXFresnelTerm => d3dx8.D3DXFresnelTerm d3dx9_36.spec: forward is broken: D3DXGetImageInfoFromFileA => d3dx8.D3DXGetImageInfoFromFileA d3dx9_36.spec: forward is broken: D3DXGetImageInfoFromFileInMemory => d3dx8.D3DXGetImageInfoFromFileInMemory d3dx9_36.spec: forward is broken: D3DXGetImageInfoFromFileW => d3dx8.D3DXGetImageInfoFromFileW d3dx9_36.spec: forward is broken: D3DXGetImageInfoFromResourceA => d3dx8.D3DXGetImageInfoFromResourceA d3dx9_36.spec: forward is broken: D3DXGetImageInfoFromResourceW => d3dx8.D3DXGetImageInfoFromResourceW d3dx9_36.spec: forward is broken: D3DXIntersectSubset => d3dx8.D3DXIntersectSubset d3dx9_36.spec: forward is broken: D3DXIntersectTri => d3dx8.D3DXIntersectTri d3dx9_36.spec: forward is broken: D3DXQuaternionSquadSetup => d3dx8.D3DXQuaternionSquadSetup d3dx9_36.spec: forward is broken: D3DXSplitMesh => d3dx8.D3DXSplitMesh d3dx9_36.spec: forward is broken: D3DXTessellateNPatches => d3dx8.D3DXTessellateNPatches -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

1 0

How should we treat users on bugzilla?
by Dan Kegel 25 Feb '08

25 Feb '08

I've been seeing a lot of bugs closed as INVALID when a poor user didn't file the bug perfectly. IMHO this leads to Wine having a user-hostile reputation. Case in point: http://bugs.winehq.org/show_bug.cgi?id=11625 What can we do to reduce this kind of behavior? Maybe we should have a "three warnings" sort of policy. If somebody continues to be rude to users after being asked twice not to, we should consider taking away their Bugzilla privileges for a while. Sure, that would hurt our productivity, but it might be better to do that than to alienate our users. What do other people think? - Dan

13 28

Re: WGL: wglDeleteContext should fail on garbage handles [attempt2]
by Alexandre Julliard 25 Feb '08

25 Feb '08

"Roderick Colenbrander" <thunderbird2k(a)gmx.net> writes: > Subject: [PATCH] wglDeleteContext should fail on a garbage hglrc. When > we receive garbage ctx->hdc is invalid which leads to a > crash. Retrieve a default DC and use it to pass hglrc to the display > driver. Luckily the opengl code maintains a list of valid opengl > contexts, so it can detect whether the hglrc is valid or not. :) If we are going to go in this direction, then the context should be made opaque in gdi32, and all calls should use the default DC. The alternative is to make the context a proper GDI handle, and have GDI check it for validity first. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winex11drv: Distinguish left and right keys for shift, ctrl and alt.
by Alexandre Julliard 25 Feb '08

25 Feb '08

Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > --- a/dlls/winex11.drv/keyboard.c > +++ b/dlls/winex11.drv/keyboard.c > @@ -1022,9 +1022,9 @@ static const WORD nonchar_key_vkey[256] = > 0, 0, 0, 0, 0, 0, 0, 0, /* FFD0 */ > 0, 0, 0, 0, 0, 0, 0, 0, /* FFD8 */ > /* modifier keys */ > - 0, VK_SHIFT, VK_SHIFT, VK_CONTROL, /* FFE0 */ > - VK_CONTROL, VK_CAPITAL, 0, VK_MENU, > - VK_MENU, VK_MENU, VK_MENU, 0, 0, 0, 0, 0, /* FFE8 */ > + 0, VK_LSHIFT, VK_RSHIFT, VK_LCONTROL, /* FFE0 */ > + VK_RCONTROL, VK_CAPITAL, 0, VK_MENU, > + VK_MENU, VK_LMENU, VK_RMENU, 0, 0, 0, 0, 0, /* FFE8 */ > 0, 0, 0, 0, 0, 0, 0, 0, /* FFF0 */ > 0, 0, 0, 0, 0, 0, 0, VK_DELETE /* FFF8 */ This is going to change the vkeys everywhere, I don't think that's correct. Things like WM_KEYDOWN have to report VK_SHIFT, not VK_LSHIFT etc. -- Alexandre Julliard julliard(a)winehq.org

2 2