wine-devel February 2008

wine-devel@winehq.org

141 participants
325 discussions

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@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@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 26 Feb '08

26 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 26 Feb '08

26 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

d3dx9_xx
by "Luis C. Busquets Pérez" 25 Feb '08

25 Feb '08

The number of functions reported in http://www.winehq.org/site/winapi_stats for the following dlls is d3dx9_24 308 d3dx9_25 311 d3dx9_26 315 d3dx9_27 315 d3dx9_28 320 d3dx9_29 320 d3dx9_30 320 d3dx9_31 317 d3dx9_32 322 d3dx9_33 322 d3dx9_34 322 d3dx9_35 322 d3dx9_36 325 Nevertheless, the correct number is d3dx9_24 320 d3dx9_25 323 d3dx9_26 327 d3dx9_27 327 d3dx9_28 332 d3dx9_29 332 d3dx9_30 332 d3dx9_31 329 d3dx9_32 334 d3dx9_33 334 d3dx9_34 334 d3dx9_35 334 d3dx9_36 336

2 1

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

← Newer
1
...
4
5
6
7
8
9
10
...
33
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel February 2008