- wine-devel - winehq.org

Re: (try 2) gdi32: if a font substitution is given then only match tothat substitution not to the original family name.
by Dmitry Timoshkov 11 Oct '08

11 Oct '08

"Aric Stewart" <aric(a)codeweavers.com> wrote: > diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c > index 145be9b..c427694 100644 > --- a/dlls/gdi32/freetype.c > +++ b/dlls/gdi32/freetype.c > @@ -3408,8 +3408,8 @@ GdiFont *WineEngCreateFontInstance(DC *dc, HFONT hfont) > */ > LIST_FOR_EACH(family_elem_ptr, &font_list) { > family = LIST_ENTRY(family_elem_ptr, Family, entry); > - if (!strcmpiW(family->FamilyName, FaceName) || > - (psub && !strcmpiW(family->FamilyName, psub->to.name))) > + if (( psub && !strcmpiW(family->FamilyName, psub->to.name)) || > + (!psub && !strcmpiW(family->FamilyName, FaceName))) > { > LIST_FOR_EACH(face_elem_ptr, &family->faces) { > face = LIST_ENTRY(face_elem_ptr, Face, entry); After loking at this change once more I think it's not correct. It will lead to failures to find a font if there is a substitution but a face specified by substitution doesn't exist. I'd suggest to test what Windows does in that case, and if Windows allows to substitute existing faces at all. Do you have a test cases which passes with your patch but doesn't without it? -- Dmitry.

2 2

Help testing a test on Win9x/NT4
by Juan Lang 11 Oct '08

11 Oct '08

Hi folks, could someone who has Win9x or NT4 and is capable of building the tests try the attached patch and email me the results if it fails? Also please tell me the Windows version if it's failing. Thanks, --Juan

2 1

Re: mshtml: avoid dereferencing a potental NULL (Coverity 633)
by Jacek Caban 10 Oct '08

10 Oct '08

Austin English wrote: > ret++; > - if(bound_pos && dompos_cmp(&tmp, bound_pos)) { > + if(bounded && bound_pos && dompos_cmp(&tmp, bound_pos)) { > *bounded = TRUE; It's a false error. bounded is never NULL if bound_pos is not NULL. Jacek

1 0

Re: [try3] advapi32: Implement CredReadDomainCredentials stub and tests
by James Hawkins 10 Oct '08

10 Oct '08

On Fri, Oct 10, 2008 at 2:52 PM, Andrey Turkin <andrey.turkin(a)gmail.com> wrote: > [few comments added as per James' suggestion] > > Implement CredReadDomainCredentialsA and CredReadDomainCredentialsW > stubs and few tests for them. Required for MSN Messenger 7.0 > --- > dlls/advapi32/advapi32.spec | 4 +- > dlls/advapi32/cred.c | 163 +++++++++++++++++++++++++++++++++++++++++++ > dlls/advapi32/tests/cred.c | 52 ++++++++++++++ > include/wincred.h | 39 ++++++++++ > 4 files changed, 256 insertions(+), 2 deletions(-) > + /* these two tests would crash on both native and Wine. Implementations + * does not check for NULL output pointers and try to zero them out early + ok(!pCredReadDomainCredentialsA(&info, 0, NULL, &creds) && + GetLastError() == ERROR_INVALID_PARAMETER, "!"); + ok(!pCredReadDomainCredentialsA(&info, 0, &count, NULL) && + GetLastError() == ERROR_INVALID_PARAMETER, "!"); */ + Please use if(0) instead of commenting them out. + if (pCredReadDomainCredentialsA) test_CredReadDomainCredentialsA(); This should be tested for in test_CredReadDomainCredentialsA, and a win_skip issued if the function is not available. -- James Hawkins

1 0

Do the menu tests work on any Windows version?
by Juan Lang 10 Oct '08

10 Oct '08

Looking over the results on test.winehq.org, the user32 menu tests are the worst in terms of failure count (though I suppose crashing tests are worse): they fail over 1000 times on NT4, over 600 times on Win9x, and over 300 times on Vista. The only operating systems on which they seem to succeed are Windows 2000 and XP, and they never succeeded for me on Windows XP, so I'm not sure the succeeding results are even representative. Basically, they're the worst offender in terms of reliable results. Is there anyone who knows anything about them that can take a look at the test failures? --Juan P.S. The crypt32 encode tests are the next-worst offender. I'm working on 'em.

3 2

Re: rpcrt4: Use pseudo-random numbers to generate UUIDs rather than using the (old, deprecated) MAC-address-and-time generation algorithm (try 2)
by Rob Shearman 10 Oct '08

10 Oct '08

Hi Juan, 2008/10/9 Juan Lang <juan.lang(a)gmail.com>: > + RtlGenRandom(Uuid, sizeof(*Uuid)); > + /* Clear the version bits and set the version (4) */ > + Uuid->Data3 &= 0x0fff; > + Uuid->Data3 |= (4 << 12); The RFC recommends the following: o Set the two most significant bits (bits 6 and 7) of the clock_seq_hi_and_reserved to zero and one, respectively. However, I don't see that done in your patch. Also, I don't know what compatibility effect changing the algorithm will have on applications. Have you checked which algorithm recent versions of Windows use and what bits are set? -- Rob Shearman

2 1

Adding timestamps to log output
by Michael Karcher 10 Oct '08

10 Oct '08

Hello developers, In http://www.winehq.org/pipermail/wine-patches/2008-June/056508.html Peter Urbanec sent a patch I like, that adds timing information to the log. It has been critized for having the wrong indentation style. As I would like to give that patch a second chance, I reindented the code to match the surrounding code. The question I have: How to give credit? The standard "based on a patch from" clause seems to weak to me, as it is aside from whitespace changes exactly that patch. But as I did these whitespace changes, it also seems wrong to just put Peter Urbanec into the From line. He did never submit in that form. I would be happy about any advice. The indentation-fixed patch is included, although the first two lines are munged to prevent the patch to get away with the "forged" attribution. Regards, Michael Karcher Based-on-From 37a6d97098fa8d4de70b125f6303de5b5fa92357 Mon Sep 17 00:00:00 2001 Based-on-From: Peter Urbanec <winehq.org(a)urbanec.net> Date: Wed, 25 Jun 2008 02:45:46 +1000 Subject: [PATCH] ntdll: Add timestamp channel to log output. This patch will prefix every line of log output with a time stamp if the "timestamps" debug channel is enabled. The time stamps are formatted as [seconds.microseconds] and measured as elapsed time from the epoch. This helps with tracking down time sensitive bugs and it may also come in handy when investigating performance. --- dlls/ntdll/debugtools.c | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/dlls/ntdll/debugtools.c b/dlls/ntdll/debugtools.c index cb08285..324cff4 100644 --- a/dlls/ntdll/debugtools.c +++ b/dlls/ntdll/debugtools.c @@ -29,6 +29,7 @@ # include <unistd.h> #endif #include <ctype.h> +#include <sys/time.h> #include "wine/debug.h" #include "wine/exception.h" @@ -39,6 +40,7 @@ #include "ntdll_misc.h" WINE_DECLARE_DEBUG_CHANNEL(tid); +WINE_DECLARE_DEBUG_CHANNEL(timestamps); static struct __wine_debug_functions default_funcs; @@ -164,8 +166,16 @@ static int NTDLL_dbg_vlog( enum __wine_debug_class cls, struct __wine_debug_chan /* only print header if we are at the beginning of the line */ if (info->out_pos == info->output || info->out_pos[-1] == '\n') { + /* Prepend a timestamp to each line, if requested. */ + if (TRACE_ON(timestamps)) + { + struct timeval tv; + if (!gettimeofday(&tv, NULL)) + ret += wine_dbg_printf( "[%ld.%06ld] ", tv.tv_sec, tv.tv_usec); + } + if (TRACE_ON(tid)) - ret = wine_dbg_printf( "%04x:", GetCurrentThreadId() ); + ret += wine_dbg_printf( "%04x:", GetCurrentThreadId() ); if (cls < sizeof(classes)/sizeof(classes[0])) ret += wine_dbg_printf( "%s:%s:%s ", classes[cls], channel->name, function ); } -- 1.5.6.5

2 2

Re: Opengl32: add a test case for WGL_ARB_create_context/opengl3 [try2]
by Christoph Frick 10 Oct '08

10 Oct '08

On Fri, Oct 10, 2008 at 10:42:05AM +0200, Roderick Colenbrander wrote: > + /* Try to create an OpenGL 3.0 contet */ content? context? -- cu

1 0

Re: Opengl32: add a test case for WGL_ARB_create_context/opengl3 [try2]
by Paul Vriens 10 Oct '08

10 Oct '08

Roderick Colenbrander wrote: > Hi, > > This is a resubmit of the same patch but not part of a series which contained a failing patch, so it should pass patchwatcher. > > Regards, > Roderick Colenbrander > > > > > ------------------------------------------------------------------------ > > Hi Roderick, Why did you add all the (unneeded) indentation? -- Cheers, Paul.

2 1

Re: Resend: mshtml.dll:Add implementation HTMLDocument_get_referrer
by Jacek Caban 10 Oct '08

10 Oct '08

Ivan Sinitsin wrote: > Add implementation of HTMLDocument_get_referrer function, in unit `htmldoc.c` > (mshtml.dll). > > Changelog: > Add implementation of HTMLDocument_get_referrer function. > > > > + if(!This->nscontainer) > + return E_FAIL; > + > + nsres = nsIWebNavigation_GetDocument(This->nscontainer->navigation, &nsdoc); > + if(NS_FAILED(nsres) || (!nsdoc)) { > + ERR("GetDocument failed: %08x\n", nsres); > + return E_FAIL; > + } > + > + nsIDOMDocument_QueryInterface(nsdoc, &IID_nsIDOMHTMLDocument, (void**)&nshtmldoc); > + nsIDOMDocument_Release(nsdoc); > + Please use nsdoc stored in HTMLDocument. It currently doesn't make much difference, but with changes from my tree it will. Jacek

1 0

d3d: Bug in handling of depth-stencil surfaces, and potential patch
by Jim Cameron 10 Oct '08

10 Oct '08

See bug 10758. If you create a depth-stencil surface with Direct3D 9 on Windows, select it into a D3D9 device with SetDepthStencilSurface() and then release it (so its reference count goes to zero), the surface will not be deleted. It will persist until its external reference count is zero /and/ it has been deselected with SetDepthStencilSurface() or Reset(). However, Wine's D3D implementation will delete the surface as soon as its refcount goes to zero, even if it is still selected into the device. This causes a crash with Myst IV. Attached is a patch that adds a private reference count to IDirect3DSurface9_Impl, plus a test case for it. The patch fixes the problem with Myst IV; could one of the resident D3D gurus have a look at it and see if I've got the approach right or if there's something else we should be doing? We'll probably also have to make the equivalent change in D3D8 as well, but I haven't considered that. Cheers, jim

2 1

Re: DrawTextEx parameter return value fix
by James Hawkins 10 Oct '08

10 Oct '08

On Thu, Oct 9, 2008 at 9:13 PM, Dean <dean(a)dnaml.com> wrote: > What are you trying to fix? You need to add a test to the test suite to verify that this change is correct. -- James Hawkins

1 0

Re: configure.ac: add -Werror to default compiler options
by Dan Kegel 09 Oct '08

09 Oct '08

Juan wrote: > Since Rob was noncommittal about whether -Werror was a good or a bad > idea, I'll take a stance: I think it's a bad one. ... > some warnings are just plain wrong. In some cases the "fix" > to quiet the warning is uglier than the warning. In those cases, we can disable the warning. > Having a code base that has hundreds of warnings is also a problem, > but we're fortunate enough not to be in that situation. Are you sure about that? When I configure with -Wall -Werror, I can't even configure properly; one gets the errors configure: libxrandr development files not found, XRandr won't be supported. configure: libxinerama development files not found, multi-monitor setups won't be supported. configure: WARNING: Old Mesa headers detected. Consider upgrading your Mesa libraries. OpenGL and Direct3D won't be supported. And if one blows past those, "make depend" fails. In fact, everything fails pretty spectacularly. We should probably have a look at -Wall errors in more detail and breadth before we assume that we're ok. - Dan

8 17

Re: [PATCH] Revert "comctl32: Fix a test on locales where default first day of week is not the max value."
by James Hawkins 09 Oct '08

09 Oct '08

On Thu, Oct 9, 2008 at 4:27 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > > Hi, > > This is breaking my "make test" run for 2 weeks now. > (LANG=de_DE.utf8) > > This reverts commit 2f8830d55b71d2fb8be912c7041d7adab7580391. > --- > dlls/comctl32/tests/monthcal.c | 3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/dlls/comctl32/tests/monthcal.c b/dlls/comctl32/tests/monthcal.c > index 6f2ae70..271dfd1 100644 > --- a/dlls/comctl32/tests/monthcal.c > +++ b/dlls/comctl32/tests/monthcal.c > @@ -673,8 +673,7 @@ static void test_monthcal_firstDay(HWND hwnd) > if (i == -1){ > expect(MAKELONG(fday, FALSE), res); > }else if (i >= 7){ > - /* out of range sets max first day of week, locale is ignored */ > - expect(MAKELONG(6, TRUE), res); > + expect(MAKELONG(fday, TRUE), res); > }else{ > expect(MAKELONG(i, TRUE), res); > } Reverting a change that makes the tests pass on all platforms is not the correct fix. Fixing the implementation to match the tests is the correct fix. Please don't apply this. I've sent a patch that fixes the problem for other locales. -- James Hawkins

1 0

Need help with the quartz filtermapper tests
by Juan Lang 09 Oct '08

09 Oct '08

Hi Alexander, my recent patch to improve the GUIDs generated by rpcrt4[1] causes a failure in the quartz filtermapper tests. Specifically, I get the following error: quartz:filtermapper.c:142: Test failed: EnumMatchingFilters failed to return the test filter 2 The trouble is, I can't imagine how changing a generated GUID from one random sequence of bytes to another random sequence of bytes should cause this to fail. On Dan's suggestion, I inserted a Sleep(2000); in UuidCreate, and that causes the tests to pass once again. So, I suspect there's a race condition somewhere in quartz or the tests. I really know nothing at all about what quartz does or what the tests are trying to verify. Might you be able to shed some insight? Thanks, --Juan [1]: http://www.winehq.org/pipermail/wine-patches/2008-October/062833.html

1 0

Favor: review refactor of gdi32/freetype.c - AddFontToList
by Jeremy White 09 Oct '08

09 Oct '08

So in my ongoing quest to get CreateScalableFontResource completed, I believe that I need to refactor gdi32/freetype.c - AddFontToList to expose an interface to allow me to retrieve a Face *. Attached is a series of 4 patches that accomplish what I believe to be a reasonable refactoring of that function. >From my analysis, the only material change in the logic flow is that the old code would skip a face that existed prior to building the new Face * structure. The new code goes ahead and builds up a proposed Face * before testing to see if the proposed new Face should be skipped. It passes the font tests and notepad still runs, but I recognize that this is a much more invasive change than I am really qualified to make. I would appreciate others with expertise in this area reviewing this series. Also, if there is advice on a standard bevy of tests I could run, I would appreciate it. There is a fair amount of special case logic in this function, and I know that our regression tests do not exercise it all. Thanks, Jeremy

1 0

Re: [PATCH 3/4] msi: Add initial implementation of MsiDatabaseMerge, with tests.
by Paul Vriens 09 Oct '08

09 Oct '08

James Hawkins wrote: > --- > dlls/msi/database.c | 497 ++++++++++++++++++++++++++++++++++++++++++++++++++- > dlls/msi/msipriv.h | 2 + > dlls/msi/record.c | 71 ++++++++ > dlls/msi/tests/db.c | 449 +++++++++++++++++++++++++++++++++++++++++++++- > 4 files changed, 1014 insertions(+), 5 deletions(-) > > > ------------------------------------------------------------------------ > > Hi James, There seems to be 1 test failure introduced on W2K and below: http://test.winehq.org/data/tests/msi:db.html Could you have a look? -- Cheers, Paul.

1 0

Re: actxprxy/qmgrprxy: Specify dlldata.c in C_SRCS instead of in EXTRA_OBJS to allow dependencies to be generated.
by Alexandre Julliard 09 Oct '08

09 Oct '08

"Rob Shearman" <robertshearman(a)gmail.com> writes: > @@ -6,9 +6,9 @@ MODULE = actxprxy.dll > IMPORTS = rpcrt4 kernel32 ntdll > EXTRADEFS = -DREGISTER_PROXY_DLL -DPROXY_CLSID_IS="{ 0xb8da6310, 0xe19b, 0x11d0, { 0x93, 0x3c, 0x00, 0xa0, 0xc9, 0x0d, 0xca, 0xa9 } }" > > -EXTRA_OBJS = dlldata.o > - > +# Note: dlldata.c is auto-generated > C_SRCS = \ > + dlldata.c \ > usrmarshal.c This is wrong, C_SRCS is for source files only. Dependencies for dlldata.c are already generated automatically anyway. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: oleacc: implemented GetRoleText[A/W] with tests (try6 - rebased)
by Nikolay Sivov 09 Oct '08

09 Oct '08

On Tue, 2008-10-07 at 21:23 +0400, Nikolay Sivov wrote: > Changelog(try5, try6): > - rebased with current git > Changelog(try4): > - tests for string length added > - configure.ac in the same patch > Changelog: > - implemented GetRoleText[A/W] with tests > > >From 82eeac4de0a082b3c665d9f46a84fa634d847b91 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Tue, 7 Oct 2008 21:10:37 +0400 > Subject: Impl. GetRoleText[A/W] > > --- > configure.ac | 1 + > dlls/oleacc/Makefile.in | 4 +- > dlls/oleacc/main.c | 74 +++++++++++++++++++++++++ > dlls/oleacc/oleacc.rc | 24 ++++++++ > dlls/oleacc/oleacc.spec | 4 +- > dlls/oleacc/oleacc_En.rc | 90 ++++++++++++++++++++++++++++++ > dlls/oleacc/tests/Makefile.in | 13 +++++ > dlls/oleacc/tests/main.c | 121 +++++++++++++++++++++++++++++++++++++++++ > 8 files changed, 328 insertions(+), 3 deletions(-) > > diff --git a/configure.ac b/configure.ac > index dac47c6..e68ccf3 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1942,6 +1942,7 @@ WINE_CONFIG_MAKEFILE([dlls/odbccp32/tests/Makefile],[dlls/Maketest.rules],[dlls] > WINE_CONFIG_MAKEFILE([dlls/ole32/Makefile],[dlls/Makedll.rules],[dlls],[ALL_DLL_DIRS]) > WINE_CONFIG_MAKEFILE([dlls/ole32/tests/Makefile],[dlls/Maketest.rules],[dlls],[ALL_TEST_DIRS]) > WINE_CONFIG_MAKEFILE([dlls/oleacc/Makefile],[dlls/Makedll.rules],[dlls],[ALL_DLL_DIRS]) > +WINE_CONFIG_MAKEFILE([dlls/oleacc/tests/Makefile],[dlls/Maketest.rules],[dlls],[ALL_TEST_DIRS]) > WINE_CONFIG_MAKEFILE([dlls/oleaut32/Makefile],[dlls/Makedll.rules],[dlls],[ALL_DLL_DIRS]) > WINE_CONFIG_MAKEFILE([dlls/oleaut32/tests/Makefile],[dlls/Maketest.rules],[dlls],[ALL_TEST_DIRS]) > WINE_CONFIG_MAKEFILE([dlls/olecli32/Makefile],[dlls/Makedll.rules],[dlls],[ALL_DLL_DIRS]) > diff --git a/dlls/oleacc/Makefile.in b/dlls/oleacc/Makefile.in > index 5822916..882edcb 100644 > --- a/dlls/oleacc/Makefile.in > +++ b/dlls/oleacc/Makefile.in > @@ -4,11 +4,13 @@ SRCDIR = @srcdir@ > VPATH = @srcdir@ > MODULE = oleacc.dll > IMPORTLIB = oleacc > -IMPORTS = kernel32 > +IMPORTS = kernel32 user32 > > C_SRCS = \ > main.c > > +RC_SRCS = oleacc.rc > + > @MAKE_DLL_RULES@ > > @DEPENDENCIES@ # everything below this line is overwritten by make depend > diff --git a/dlls/oleacc/main.c b/dlls/oleacc/main.c > index 9a6f765..5076e00 100644 > --- a/dlls/oleacc/main.c > +++ b/dlls/oleacc/main.c > @@ -24,10 +24,13 @@ > #include "winuser.h" > #include "ole2.h" > > +#include "wine/unicode.h" > #include "wine/debug.h" > > WINE_DEFAULT_DEBUG_CHANNEL(oleacc); > > +static HINSTANCE oleacc_handle = 0; > + > HRESULT WINAPI CreateStdAccessibleObject( HWND hwnd, LONG idObject, > REFIID riidInterface, void** ppvObject ) > { > @@ -50,6 +53,21 @@ HRESULT WINAPI AccessibleObjectFromWindow( HWND hwnd, DWORD dwObjectID, > return E_NOTIMPL; > } > > +BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, > + LPVOID lpvReserved) > +{ > + TRACE("%p, %d, %p\n", hinstDLL, fdwReason, lpvReserved); > + > + switch (fdwReason) > + { > + case DLL_PROCESS_ATTACH: > + oleacc_handle = hinstDLL; > + DisableThreadLibraryCalls(hinstDLL); > + break; > + } > + return TRUE; > +} > + > HRESULT WINAPI DllRegisterServer(void) > { > FIXME("\n"); > @@ -67,3 +85,59 @@ void WINAPI GetOleaccVersionInfo(DWORD* pVersion, DWORD* pBuild) > *pVersion = MAKELONG(2,4); /* Windows XP version of oleacc: 4.2.5406.0 */ > *pBuild = MAKELONG(0,5406); > } > + > +UINT WINAPI GetRoleTextW(DWORD role, LPWSTR lpRole, UINT rolemax) > +{ > + INT ret; > + WCHAR *resptr; > + > + TRACE("%u %p %u\n", role, lpRole, rolemax); > + > + /* return role text length */ > + if(!lpRole) > + return LoadStringW(oleacc_handle, role, (LPWSTR)&resptr, 0); > + > + ret = LoadStringW(oleacc_handle, role, lpRole, rolemax); > + if(!(ret > 0)){ > + if(rolemax > 0) lpRole[0] = '\0'; > + return 0; > + } > + > + return ret; > +} > + > +UINT WINAPI GetRoleTextA(DWORD role, LPSTR lpRole, UINT rolemax) > +{ > + UINT length; > + WCHAR *roletextW; > + > + TRACE("%u %p %u\n", role, lpRole, rolemax); > + > + length = GetRoleTextW(role, NULL, 0); > + if((length == 0) || (lpRole && !rolemax)) > + return 0; > + > + roletextW = HeapAlloc(GetProcessHeap(), 0, (length + 1)*sizeof(WCHAR)); > + if(!roletextW) > + return 0; > + > + GetRoleTextW(role, roletextW, length + 1); > + > + length = WideCharToMultiByte( CP_ACP, 0, roletextW, -1, NULL, 0, NULL, NULL ); > + > + if(!lpRole){ > + HeapFree(GetProcessHeap(), 0, roletextW); > + return length - 1; > + } > + > + WideCharToMultiByte( CP_ACP, 0, roletextW, -1, lpRole, rolemax, NULL, NULL ); > + > + if(rolemax < length){ > + lpRole[rolemax-1] = '\0'; > + length = rolemax; > + } > + > + HeapFree(GetProcessHeap(), 0, roletextW); > + > + return length - 1; > +} > diff --git a/dlls/oleacc/oleacc.rc b/dlls/oleacc/oleacc.rc > new file mode 100644 > index 0000000..0795a9b > --- /dev/null > +++ b/dlls/oleacc/oleacc.rc > @@ -0,0 +1,24 @@ > +/* > + * Top level resource file for oleacc > + * > + * Copyright 2008 Nikolay Sivov > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "windef.h" > +#include "oleacc.h" > + > +#include "oleacc_En.rc" > diff --git a/dlls/oleacc/oleacc.spec b/dlls/oleacc/oleacc.spec > index 23b84b3..75b743a 100644 > --- a/dlls/oleacc/oleacc.spec > +++ b/dlls/oleacc/oleacc.spec > @@ -8,8 +8,8 @@ > @ stdcall -private DllRegisterServer() > @ stdcall -private DllUnregisterServer() > @ stdcall GetOleaccVersionInfo(ptr ptr) > -@ stub GetRoleTextA > -@ stub GetRoleTextW > +@ stdcall GetRoleTextA(long ptr long) > +@ stdcall GetRoleTextW(long wstr long) > @ stub GetStateTextA > @ stub GetStateTextW > @ stub IID_IAccessible > diff --git a/dlls/oleacc/oleacc_En.rc b/dlls/oleacc/oleacc_En.rc > new file mode 100644 > index 0000000..992d29c > --- /dev/null > +++ b/dlls/oleacc/oleacc_En.rc > @@ -0,0 +1,90 @@ > +/* > + * English resources for oleacc > + * > + * Copyright 2008 Nikolay Sivov > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +LANGUAGE LANG_ENGLISH, SUBLANG_DEFAULT > + > +STRINGTABLE DISCARDABLE > +{ > + 0 "unknown object" /* undocumented */ > + ROLE_SYSTEM_TITLEBAR "title bar" > + ROLE_SYSTEM_MENUBAR "menu bar" > + ROLE_SYSTEM_SCROLLBAR "scroll bar" > + ROLE_SYSTEM_GRIP "grip" > + ROLE_SYSTEM_SOUND "sound" > + ROLE_SYSTEM_CURSOR "cursor" > + ROLE_SYSTEM_CARET "caret" > + ROLE_SYSTEM_ALERT "alert" > + ROLE_SYSTEM_WINDOW "window" > + ROLE_SYSTEM_CLIENT "client" > + ROLE_SYSTEM_MENUPOPUP "popup menu" > + ROLE_SYSTEM_MENUITEM "menu item" > + ROLE_SYSTEM_TOOLTIP "tool tip" > + ROLE_SYSTEM_APPLICATION "application" > + ROLE_SYSTEM_DOCUMENT "document" > + ROLE_SYSTEM_PANE "pane" > + ROLE_SYSTEM_CHART "chart" > + ROLE_SYSTEM_DIALOG "dialog" > + ROLE_SYSTEM_BORDER "border" > + ROLE_SYSTEM_GROUPING "grouping" > + ROLE_SYSTEM_SEPARATOR "separator" > + ROLE_SYSTEM_TOOLBAR "tool bar" > + ROLE_SYSTEM_STATUSBAR "status bar" > + ROLE_SYSTEM_TABLE "table" > + ROLE_SYSTEM_COLUMNHEADER "column header" > + ROLE_SYSTEM_ROWHEADER "row header" > + ROLE_SYSTEM_COLUMN "column" > + ROLE_SYSTEM_ROW "row" > + ROLE_SYSTEM_CELL "cell" > + ROLE_SYSTEM_LINK "link" > + ROLE_SYSTEM_HELPBALLOON "help balloon" > + ROLE_SYSTEM_CHARACTER "character" > + ROLE_SYSTEM_LIST "list" > + ROLE_SYSTEM_LISTITEM "list item" > + ROLE_SYSTEM_OUTLINE "outline" > + ROLE_SYSTEM_OUTLINEITEM "outline item" > + ROLE_SYSTEM_PAGETAB "page tab" > + ROLE_SYSTEM_PROPERTYPAGE "property page" > + ROLE_SYSTEM_INDICATOR "indicator" > + ROLE_SYSTEM_GRAPHIC "graphic" > + ROLE_SYSTEM_STATICTEXT "static text" > + ROLE_SYSTEM_TEXT "text" > + ROLE_SYSTEM_PUSHBUTTON "push button" > + ROLE_SYSTEM_CHECKBUTTON "check button" > + ROLE_SYSTEM_RADIOBUTTON "radio button" > + ROLE_SYSTEM_COMBOBOX "combo box" > + ROLE_SYSTEM_DROPLIST "drop down" > + ROLE_SYSTEM_PROGRESSBAR "progress bar" > + ROLE_SYSTEM_DIAL "dial" > + ROLE_SYSTEM_HOTKEYFIELD "hot key field" > + ROLE_SYSTEM_SLIDER "slider" > + ROLE_SYSTEM_SPINBUTTON "spin box" > + ROLE_SYSTEM_DIAGRAM "diagram" > + ROLE_SYSTEM_ANIMATION "animation" > + ROLE_SYSTEM_EQUATION "equation" > + ROLE_SYSTEM_BUTTONDROPDOWN "drop down button" > + ROLE_SYSTEM_BUTTONMENU "menu button" > + ROLE_SYSTEM_BUTTONDROPDOWNGRID "grid drop down button" > + ROLE_SYSTEM_WHITESPACE "white space" > + ROLE_SYSTEM_PAGETABLIST "page tab list" > + ROLE_SYSTEM_CLOCK "clock" > + ROLE_SYSTEM_SPLITBUTTON "split button" > + ROLE_SYSTEM_IPADDRESS "IP address" > + ROLE_SYSTEM_OUTLINEBUTTON "outline button" > +} > diff --git a/dlls/oleacc/tests/Makefile.in b/dlls/oleacc/tests/Makefile.in > new file mode 100644 > index 0000000..6e2bc8d > --- /dev/null > +++ b/dlls/oleacc/tests/Makefile.in > @@ -0,0 +1,13 @@ > +TOPSRCDIR = @top_srcdir@ > +TOPOBJDIR = ../../.. > +SRCDIR = @srcdir@ > +VPATH = @srcdir@ > +TESTDLL = oleacc.dll > +IMPORTS = kernel32 oleacc > + > +CTESTS = \ > + main.c > + > +@MAKE_TEST_RULES@ > + > +@DEPENDENCIES@ # everything below this line is overwritten by make depend > diff --git a/dlls/oleacc/tests/main.c b/dlls/oleacc/tests/main.c > new file mode 100644 > index 0000000..66b25af > --- /dev/null > +++ b/dlls/oleacc/tests/main.c > @@ -0,0 +1,121 @@ > +/* > + * oleacc tests > + * > + * Copyright 2008 Nikolay Sivov > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include <oleacc.h> > +#include "wine/test.h" > + > +static void test_getroletext(void) > +{ > + INT ret, role; > + CHAR buf[2], *buff, buff2[100]; > + WCHAR bufW[2], *buffW, buff2W[100]; > + > + /* wrong role number */ > + ret = GetRoleTextA(-1, NULL, 0); > + ok(ret == 0, "GetRoleTextA doesn't return zero on wrong role number, got %d\n", ret); > + buf[0] = '*'; > + ret = GetRoleTextA(-1, buf, 2); > + ok(ret == 0, "GetRoleTextA doesn't return zero on wrong role number, got %d\n", ret); > + ok(buf[0] == '*', "GetRoleTextA modified buffer on wrong role number\n"); > + buf[0] = '*'; > + ret = GetRoleTextA(-1, buf, 0); > + ok(ret == 0, "GetRoleTextA doesn't return zero on wrong role number, got %d\n", ret); > + ok(buf[0] == '*', "GetRoleTextA modified buffer on wrong role number\n"); > + > + ret = GetRoleTextW(-1, NULL, 0); > + ok(ret == 0, "GetRoleTextW doesn't return zero on wrong role number, got %d\n", ret); > + bufW[0] = '*'; > + ret = GetRoleTextW(-1, bufW, 2); > + ok(ret == 0, "GetRoleTextW doesn't return zero on wrong role number, got %d\n", ret); > + ok(bufW[0] == '\0', "GetRoleTextW doesn't return NULL char on wrong role number\n"); > + bufW[0] = '*'; > + ret = GetRoleTextW(-1, bufW, 0); > + ok(ret == 0, "GetRoleTextW doesn't return zero on wrong role number, got %d\n", ret); > + /* don't know why this char */ > + todo_wine ok(bufW[0] == 0x1e90, "GetRoleTextW returned wrong char, got %u\n", bufW[0]); > + > + /* zero role number - not documented */ > + ret = GetRoleTextA(0, NULL, 0); > + ok(ret > 0, "GetRoleTextA doesn't return (>0) for zero role number, got %d\n", ret); > + ret = GetRoleTextW(0, NULL, 0); > + ok(ret > 0, "GetRoleTextW doesn't return (>0) for zero role number, got %d\n", ret); > + > + /* NULL buffer, return length */ > + ret = GetRoleTextA(ROLE_SYSTEM_TITLEBAR, NULL, 0); > + ok(ret > 0, "GetRoleTextA doesn't return length on NULL buffer, got %d\n", ret); > + ret = GetRoleTextA(ROLE_SYSTEM_TITLEBAR, NULL, 1); > + ok(ret > 0, "GetRoleTextA doesn't return length on NULL buffer, got %d\n", ret); > + ret = GetRoleTextW(ROLE_SYSTEM_TITLEBAR, NULL, 0); > + ok(ret > 0, "GetRoleTextW doesn't return length on NULL buffer, got %d\n", ret); > + ret = GetRoleTextW(ROLE_SYSTEM_TITLEBAR, NULL, 1); > + ok(ret > 0, "GetRoleTextW doesn't return length on NULL buffer, got %d\n", ret); > + > + /* use a smaller buffer */ > + buf[0] = '*'; > + ret = GetRoleTextA(ROLE_SYSTEM_TITLEBAR, buf, 1); > + ok(ret == 0, "GetRoleTextA returned wrong length\n"); > + ok(buf[0] == '\0', "GetRoleTextA returned not zero-length buffer\n"); > + buf[1] = '*'; > + ret = GetRoleTextA(ROLE_SYSTEM_TITLEBAR, buf, 2); > + ok(ret == 1, "GetRoleTextA returned wrong length, got %d, expected 1\n", ret); > + ok(buf[1] == '\0', "GetRoleTextA returned not zero-length buffer\n"); > + > + bufW[0] = '*'; > + ret = GetRoleTextW(ROLE_SYSTEM_TITLEBAR, bufW, 1); > + ok(ret == 0, "GetRoleTextW returned wrong length, got %d, expected 1\n", ret); > + ok(bufW[0] == '\0', "GetRoleTextW returned not zero-length buffer\n"); > + bufW[1] = '*'; > + ret = GetRoleTextW(ROLE_SYSTEM_TITLEBAR, bufW, 2); > + ok(ret == 1, "GetRoleTextW returned wrong length, got %d, expected 1\n", ret); > + ok(bufW[1] == '\0', "GetRoleTextW returned not zero-length buffer\n"); > + > + /* use bigger buffer */ > + ret = GetRoleTextA(ROLE_SYSTEM_TITLEBAR, NULL, 0); > + buff = HeapAlloc(GetProcessHeap(), 0, 2*ret); > + buff[2*ret-1] = '*'; > + ret = GetRoleTextA(ROLE_SYSTEM_TITLEBAR, buff, 2*ret); > + ok(buff[2*ret-1] == '*', "GetRoleTextA shouldn't modify this part of buffer\n"); > + HeapFree(GetProcessHeap(), 0, buff); > + > + ret = GetRoleTextW(ROLE_SYSTEM_TITLEBAR, NULL, 0); > + buffW = HeapAlloc(GetProcessHeap(), 0, 2*ret*sizeof(WCHAR)); > + buffW[2*ret-1] = '*'; > + ret = GetRoleTextW(ROLE_SYSTEM_TITLEBAR, buffW, 2*ret); > + ok(buffW[2*ret-1] == '*', "GetRoleTextW shouldn't modify this part of buffer\n"); > + HeapFree(GetProcessHeap(), 0, buffW); > + > + /* check returned length for all roles */ > + for(role = 0; role <= ROLE_SYSTEM_OUTLINEBUTTON; role++){ > + ret = GetRoleTextA(role, NULL, 0); > + GetRoleTextA(role, buff2, sizeof(buff2)); > + ok(ret == lstrlenA(buff2), > + "GetRoleTextA: returned length doesn't match returned buffer for role %d\n", role); > + > + ret = GetRoleTextW(role, NULL, 0); > + GetRoleTextW(role, buff2W, sizeof(buff2W)/sizeof(WCHAR)); > + ok(ret == lstrlenW(buff2W), > + "GetRoleTextW: returned length doesn't match returned buffer for role %d\n", role); > + } > +} > + > +START_TEST(main) > +{ > + test_getroletext(); > +} Something wrong with this? Please let me know if it's so.

1 0

Re: mlang: tests, converstion test was falsely failing on windows xp for codepage 1361 (Korean, Johab) because of lack of roman characters
by Alexandre Julliard 09 Oct '08

09 Oct '08

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -259,6 +259,15 @@ static BOOL check_convertible(IMultiLanguage2 *iML2, UINT from, UINT to) > > static WCHAR strW[] = {'a','b','c',0}; > > + if (from == 1361 || to == 1361) > + { > + /* > + * This is Korean (Johab). This codepages does not have latin > + * characters so these checks fail causing confusions later. > + */ > + return TRUE; > + } There should be a way to detect this with a generic check, instead of having to hardcode specific codepages. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Resend patch for 15494
by James Hawkins 09 Oct '08

09 Oct '08

2008/10/8 Chris Ahrendt <celticht32(a)aol.com>: > per dan resending > > > chris > > From e8ec03471e1206ea93fa6224d7c6b8b61422d80e Mon Sep 17 00:00:00 2001 > From: Chris Ahrendt <celticht32(a)aol.com> > Date: Tue, 7 Oct 2008 21:02:36 -0400 > Subject: [PATCH] Checked all the states of variables in test to ensure that > they are not NULL > This broad-sweep approach is not correct. If there is a machine that is crashing on a NULL interface, then a check needs to be added where that machine returns a NULL interface and we should then skip those particular tests. There are plenty of examples of this you can look for. -- James Hawkins

3 8

Re: gdi32: Add more font substitution tests, make them pass under Wine
by Jeremy White 09 Oct '08

09 Oct '08

Dmitry, This patch has triggered a bug in make test for me; I only notice it when I put a Windows flavor of arial.ttf into my windows/fonts directory. The specific failure is in get_glyph_indices when we're passing in a symbol charset (i.e. the 3rd loop). I've tracked it to line 3461 of gdi32/freetype.c. Specifically, the lfWeight is set to FW_DONTCARE but the charset is Symbol. Git-blame pointed at this patch. I find that if I modify tests/font.c to set a lfWeight of normal in get_glyph_indices, then the tests no longer fail. However, the test passes on Windows XP without needing that change, so I'm afraid that this code must be wrong. Here are the full commit details: commit a5d288f08c08dc19d217093fdf8622605c92a4e0 Author: Dmitry Timoshkov <dmitry(a)codeweavers.com> Date: Tue May 13 22:10:05 2008 +0900 gdi32: Add more font substitution tests, make them pass under Wine. I was hoping that a resolution to this would be obvious to you, as you clearly understood this issue in depth when you wrote the patch. Cheers, Jeremy

2 1

Re: Jacek Caban : mshtml: Added IHTMLElement3 stub implementation.
by Michael Stefaniuc 08 Oct '08

08 Oct '08

Hello Jacek, Smatch complains about unreachable code introduced by this patch: Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 536fac7c1b4ef7f6f124d7f3100d3284313f3018 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=536fac7c1b4ef7f6f124d7f31… > > Author: Jacek Caban <jacek(a)codeweavers.com> > Date: Tue Oct 7 14:44:18 2008 -0500 > > mshtml: Added IHTMLElement3 stub implementation. > > --- > > dlls/mshtml/Makefile.in | 1 + > dlls/mshtml/htmlelem.c | 4 + > dlls/mshtml/htmlelem3.c | 447 ++++++++++++++++++++++++++++++++++++++++++ > dlls/mshtml/mshtml_private.h | 3 + > dlls/mshtml/tests/dom.c | 14 ++ > 5 files changed, 469 insertions(+), 0 deletions(-) > > Diff: http://source.winehq.org/git/wine.git/?a=commitdiff;h=536fac7c1b4ef7f6f124d… diff --git a/dlls/mshtml/htmlelem3.c b/dlls/mshtml/htmlelem3.c new file mode 100644 index 0000000..f85b065 --- /dev/null +++ b/dlls/mshtml/htmlelem3.c ... + +static HRESULT WINAPI HTMLElement3_put_disabled(IHTMLElement3 *iface, VARIANT_B +{ + HTMLElement *This = HTMLELEM3_THIS(iface); + FIXME("(%p)->(%x)\n", This, v); + return S_OK; + return E_NOTIMPL; +} + ... I would say to remove the S_OK return but I really don't know what is the best here. thanks bye michael

2 2

Re: [5/6] WineD3D: Remove some #ifdefs
by H. Verbeet 08 Oct '08

08 Oct '08

Right now it's simply broken of course. The extension being defined in the header is no guarantee the driver actually supports it.

3 3

Usability: WineCfg Part 1 -- Desktop Integration tab
by Reece Dunn 08 Oct '08

08 Oct '08

Hi, Reading up on the wineconf WWN issue, I noticed that it mentions usability and winecfg. Therefore, I decided to dig up my RFC relating to some ideas I had about winecfg that I sent to the list. I have attached a mockup of my ideas, which I have added to since my original mail. == APPEARANCE == NOTE: Ignore the groupbox being called "Theme", it should be "Appearance". 1. The "(No Theme)" text is replaced with "Wine Default". No theme does not make sense -- there is a theme, it is just the default one that Wine is using. 2. The "Install theme..." button is now "Load...". 3. There is a "Save..." button to save a users theme modifications. This makes it easier to create custom themes (especially colour-based themes). 4. There is a divider between the theme and appearance settings. This is to make it clearer that these are separate, but related. 5. The "Item" list field always has an item selected (currently does not select an item by default). This helps keyboard navigation. 6. The "Font" button has an elipsis at the end. This button brings up another dialog, so should have an elipsis. == FOLDERS == 1. The term "Shell folders" is replaced with "Folders". Using the word "shell" is too confusing for users, as they don't know what the shell is. 2. The "Map the Wine folders to the default locations" option allows the user to set all known folder types to be mapped to their Linux desktop equivalents. 3. The list has been replaced with a dropdown and restructured. This should provide a better user experience (no more link to) and accessability. 4. There is a "Reset to default" option that sets the current folder to its Linux desktop equivalent. 5. The "Browse" button now has an elipsis. This is because it launches a dialog. == OTHER == 1. We may want to provide a set of colour themes (e.g. Windows 95, Windows 2000, Ubuntu Human, ClearLooks, KDE Oxygen) to provide a better experience for the user by default - i.e. not just have the "No Theme" option initially. 2. We may want to be able to load a theme using the command line. This would allow - for example - distributions to setup Wine with a theme that matches their desktop, providing a more integrated experience to the user. 3. We may want to have a "Use the system's appearance" checkbox to enable Gnome/KDE/other integration, so that the colours and/or appearance is picked up from (and updated with) the native Linux environment. This would go above the theme drop-down. Comments welcome. - Reece

4 6

Re: mapi32: initialize session pointer to zero in MAPILogonEx (2nd resend)
by Louis. Lenders 08 Oct '08

08 Oct '08

diff --git a/dlls/mapi32/mapi32_main.c b/dlls/mapi32/mapi32_main.c index 936d435..5aace9a 100644 --- a/dlls/mapi32/mapi32_main.c +++ b/dlls/mapi32/mapi32_main.c @@ -109,6 +109,7 @@ HRESULT WINAPI MAPILogonEx(ULONG_PTR uiparam, LPWSTR profile, { FIXME("(0x%08lx %s %p 0x%08x %p) Stub\n", uiparam, debugstr_w(profile), password, flags, session); + *session=0; return SUCCESS_SUCCESS; } >Are you guaranteed that session is not NULL? No, no garantueed, but i looked up some code-samples by google, and as far as i can tell, the current stub for MAPILogonEx will pass back garbage anyway to the application, so my thought was this patch would be rather harmless anyway. >A test case would help. I guess you're right about that, thanks anyway for the comments. --Juan

3 2

Re: [PATCH 1/3] wininet: Validate parameters passed to RetrieveUrlCacheEntryInfoA/W.
by Paul Vriens 08 Oct '08

08 Oct '08

Rob Shearman wrote: > Add tests for this. > --- > dlls/wininet/tests/urlcache.c | 25 +++++++++++++++++++++++++ > dlls/wininet/urlcache.c | 14 ++++++++++++++ > 2 files changed, 39 insertions(+), 0 deletions(-) > > Hi Rob, Is the following test needed for an app? + ret = RetrieveUrlCacheEntryFile(TEST_URL, NULL, NULL, 0); This crashes on Win9x and NT4. Can we if(0) this test or should we work around the issue? -- Cheers, Paul.

2 2

Re: [PATCH] regedit: Pass VK_DELETE messages to edit controls. (try 2)
by Alexandre Julliard 08 Oct '08

08 Oct '08

"Lei Zhang" <thestig(a)google.com> writes: > In regedit, while renaming registry keys / values, the delete key does > not work. This should fix it. > > This version increased the len variable by 1, so comparing "Edit" to > "EditX" will fail. Testing class names is almost always the wrong thing to do. Surely there's a better way to identify the edit window. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [resend] advapi32: Implement CredReadDomainCredentials stub
by James Hawkins 07 Oct '08

07 Oct '08

On Tue, Oct 7, 2008 at 11:17 AM, Andrey Turkin <andrey.turkin(a)gmail.com> wrote: > [wasn't submitted nor rejected, so resending] > > Added CredReadDomainCredentialsA and CredReadDomainCredentialsW stub implementations. > Required for MSN Messenger 7.0 to start in WinXP mode > > --- > dlls/advapi32/advapi32.spec | 4 +- > dlls/advapi32/cred.c | 142 +++++++++++++++++++++++++++++++++++++++++++ > include/wincred.h | 39 ++++++++++++ > 3 files changed, 183 insertions(+), 2 deletions(-) > + if (TargetInformation->NetbiosServerName) len += sizeof(WCHAR) * MultiByteToWideChar(CP_ACP, 0, TargetInformation->NetbiosServerName, -1, NULL, 0); That is a seriously long line. Please try to keep line lengths close to 80 cols. + if (!TargetInformation || !Size || !Credentials || + !(TargetInformation->NetbiosServerName || TargetInformation->DnsServerName || TargetInformation->NetbiosDomainName + || TargetInformation->DnsDomainName ||TargetInformation->DnsTreeName)) + { + SetLastError(ERROR_INVALID_PARAMETER); + return FALSE; + } I don't think you should make such an implementation without at least some simple tests. -- James Hawkins

1 0

msi trouble; crashes on patchwatcher, valgrind warnings
by Dan Kegel 07 Oct '08

07 Oct '08

Lately I've been seeing a failure of ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so db.c on patchwatcher on lots of runs. e.g. http://kegel.com/wine/patchwatcher/results/2598.log It kind of looks like a memory corruption: wine: Unhandled page fault on read access to 0x00000018 at address 0x60432d58 (thread 0016), starting debugger... Backtrace: =>1 0x60432d58 CompareStringW+0xe8(lcid=1033, style=0, str1=0x12e0f8, len1=10, str2=0x18, len2=0) [include/wine/unicode.h:212] in kernel32 (0x0032f048) 2 0x60432eb5 lstrcmpW+0x75(str1=?, str2=0x18) [dlls/kernel32/locale.c:2830] in kernel32 (0x0032f078) 3 0x606b47bf find_cached_table+0x3f(db=?, name=0x12e0f8) [dlls/msi/table.c:571] in msi (0x0032f098) 4 0x606b8821 get_table+0x21(db=0x12b200, name=?, table_ret=0x12da80) [dlls/msi/table.c:770] in msi (0x0032f108) 6 0x606b8e9b TABLE_CreateView+0xdb(db=0x12b200, name=?, view=0x32f9a8) [dlls/msi/table.c:2143] in msi (0x0032f148) 6 0x606bfebc sql_parse+0x6bc(info=0x32f9f8) [dlls/msi/sql.y:481] in msi (0x0032f9c8) 7 0x606c08da MSI_ParseSQL+0x4a(db=0x12b200, command=0x12e7e8, phview=0x12e330, mem=0x12e33c) [dlls/msi/sql.y:915] in msi (0x0032fa18) 8 0x60699b3d MSI_DatabaseOpenViewW+0x9d(db=0x12b200, szQuery=0x12e7e8, pView=0x32fa78) [dlls/msi/msiquery.c:135] in msi (0x0032fa48) 9 0x60699cf3 MsiDatabaseOpenViewW+0x133(hdb=1, szQuery=?, phView=0x32faec) [dlls/msi/msiquery.c:277] in msi (0x0032fa88) 10 0x6069b07a MsiDatabaseOpenViewA+0xda(hdb=1, szQuery="SELECT * FROM `IDontExist`", phView=0x32faec) [dlls/msi/msiquery.c:105] in msi (0x0032fac8) 11 0x6052f5bf do_query+0x2f(hdb=?, query=?, phrec=?) [dlls/msi/tests/db.c:148] in msi_test (0x0032faf8) 12 0x6052f94a test_droptable+0x31a() [dlls/msi/tests/db.c:6371] in msi_test (0x0032fb38) 13 0x6054bb1a func_db+0x459a() [dlls/msi/tests/db.c:6444] in msi_test (0x0032fdd8) 14 0x605f07ca run_test+0x14a(name="db.c") [dlls/msi/tests/../../../include/wine/test.h:454] in msi_test (0x0032fe18) 15 0x605f1029 main+0x149(argc=?, argv=0x1103c0) [dlls/msi/tests/../../../include/wine/test.h:503] in msi_test (0x0032fed8) 16 0x605f118b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) [dlls/winecrt0/exe_entry.c:36] in msi_test (0x0032ff08) 17 0x60449b37 start_process+0xc7(arg=(nil)) [dlls/kernel32/process.c:904] in kernel32 (0x0032ffe8) 0x60432d58 CompareStringW+0xe8 [dlls/kernel32/../../include/wine/unicode.h:212] in kernel32: cmpw $0,0x0(%eax) 212 while (*s) s++; The problem isn't particularly repeatable by hand, so I ran that test under valgrind. It seems to have a few warnings, and sure enough, they seem to be in the same function (test_droptable): Invalid read of size 4 at 0x4ABF0AE: msi_table_get_row_size (table.c:492) by 0x4AC1609: msi_update_table_columns (table.c:1037) by 0x4AC3515: TABLE_remove_column (table.c:1813) by 0x4AC3592: TABLE_drop (table.c:2064) by 0x4A8913E: DROP_execute (drop.c:60) by 0x4AA1F0D: MSI_ViewExecute (msiquery.c:456) by 0x4AA2423: MsiViewExecute (msiquery.c:482) by 0x49388A5: test_droptable (db.c:6359) by 0x4954B19: func_db (db.c:6443) by 0x49F97C9: run_test (test.h:452) by 0x49FA028: main (test.h:502) Address 0x7f01ccc0 is not stack'd, malloc'd or (recently) free'd Invalid read of size 4 at 0x4ABF0B4: msi_table_get_row_size (table.c:127) by 0x4AC1609: msi_update_table_columns (table.c:1037) by 0x4AC3515: TABLE_remove_column (table.c:1813) by 0x4AC3592: TABLE_drop (table.c:2064) by 0x4A8913E: DROP_execute (drop.c:60) by 0x4AA1F0D: MSI_ViewExecute (msiquery.c:456) by 0x4AA2423: MsiViewExecute (msiquery.c:482) by 0x49388A5: test_droptable (db.c:6359) by 0x4954B19: func_db (db.c:6443) by 0x49F97C9: run_test (test.h:452) by 0x49FA028: main (test.h:502) Address 0x7f01ccbc is not stack'd, malloc'd or (recently) free'd Invalid read of size 4 at 0x4AC1614: msi_update_table_columns (table.c:1038) by 0x4AC3515: TABLE_remove_column (table.c:1813) by 0x4AC3592: TABLE_drop (table.c:2064) by 0x4A8913E: DROP_execute (drop.c:60) by 0x4AA1F0D: MSI_ViewExecute (msiquery.c:456) by 0x4AA2423: MsiViewExecute (msiquery.c:482) by 0x49388A5: test_droptable (db.c:6359) by 0x4954B19: func_db (db.c:6443) by 0x49F97C9: run_test (test.h:452) by 0x49FA028: main (test.h:502) Address 0x7f01ccc0 is not stack'd, malloc'd or (recently) free'd Invalid free() / delete / delete[] at 0x471C5CF: RtlFreeHeap (heap.c:1315) by 0x4ABEEC2: msi_free_colinfo (msipriv.h:1074) by 0x4ABEFED: free_table (table.c:481) by 0x4AC36A9: TABLE_drop (table.c:2089) by 0x4A8913E: DROP_execute (drop.c:60) by 0x4AA1F0D: MSI_ViewExecute (msiquery.c:456) by 0x4AA2423: MsiViewExecute (msiquery.c:482) by 0x49388A5: test_droptable (db.c:6359) by 0x4954B19: func_db (db.c:6443) by 0x49F97C9: run_test (test.h:452) by 0x49FA028: main (test.h:502) Address 0x4d434923 is not stack'd, malloc'd or (recently) free'd Invalid read of size 4 at 0x4A8E415: msiobj_release (handle.c:247) by 0x4AC3613: TABLE_drop (table.c:2093) by 0x4A8913E: DROP_execute (drop.c:60) by 0x4AA1F0D: MSI_ViewExecute (msiquery.c:456) by 0x4AA2423: MsiViewExecute (msiquery.c:482) by 0x49388A5: test_droptable (db.c:6359) by 0x4954B19: func_db (db.c:6443) by 0x49F97C9: run_test (test.h:452) by 0x49FA028: main (test.h:502) Address 0x7f01ccb0 is not stack'd, malloc'd or (recently) free'd Could you have a look? (BTW this is valgrind from svn. valgrind-3.3.0 didn't give me stack dumps for some reason.) - Dan

2 1

Re: Added VGA/VESA modes. Fix Attribute Configuration FIXMEs
by Rob Shearman 07 Oct '08

07 Oct '08

Hi Jeremiah, Thank you for your contribution to Wine. However, I have some comments about your patch: 2008/10/7 Jeremiah Flerchinger <jeremiah.flerchinger(a)gmail.com>: > Added additional VGA/VESA modes. Added missing information to VGA/VESA mode descriptions. > Used new mode information to fix attributes incorrectly set in int10.c > Moved VGA/VESA mode descriptions to vga.h, so they can be shared by emulated VGA/VESA hardware and > BIOS graphics routines. > --- > dlls/winedos/int10.c | 149 +++++++++++++++++++------------------------------ > dlls/winedos/vga.h | 90 ++++++++++++++++++++++++++++++ > 2 files changed, 148 insertions(+), 91 deletions(-) > mode change 100644 => 100755 dlls/winedos/int10.c Try not to change file modes unnecessarilly. > diff --git a/dlls/winedos/int10.c b/dlls/winedos/int10.c > old mode 100644 > new mode 100755 > index 94ea6ff..554b083 > --- a/dlls/winedos/int10.c > +++ b/dlls/winedos/int10.c > @@ -4,6 +4,8 @@ > * Copyright 1998 Ove Kven > * Copyright 1998 Joseph Pranevich > * > + * 10/2008 - Jeremiah Flerchinger - Extended VGA/VESA mode configuration support > + * The GIT changelog will tell everyone what code you have added so there is no need to state it at the top. If you feel that a significant portion of the file is your copyright now then feel free to add a copyright line similar to the others above. > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > * License as published by the Free Software Foundation; either > @@ -218,7 +155,9 @@ static const INT10_MODE *INT10_FindMode( WORD mode ) > while (ptr->Mode != 0xffff) > { > if (ptr->Mode == mode) > + { > return ptr; > + } > ptr++; > } > This change is unnecessary. > @@ -343,22 +282,34 @@ static BOOL INT10_FillModeInformation( struct _ModeInfoBlock *mib, WORD mode ) > * 13-15 - Reserved. > */ > { > - WORD attr = 0x000a; /* color mode, optional info */ > + WORD attr = 0x0002; /* set optional info available */ > + /* Enable color mode - if both Colors & Depth are 0, then assume monochrome*/ > + if (ptr->Colors || ptr->Depth) > + { > + attr |= 0x0008; > + } > > /* > * FIXME: Attribute handling is incomplete. > */ > > - /* Mode supported? FIXME: correct value */ > - attr |= 0x0001; > + /* Mode supported? */ > + if (ptr->Supported) > + { > + attr |= 0x0001; // set display mode supported C99-style comments are not portable as they don't work on some older compilers. Use "/* */" instead. .. > diff --git a/dlls/winedos/vga.h b/dlls/winedos/vga.h > index 36646a1..317b9ca 100644 > --- a/dlls/winedos/vga.h > +++ b/dlls/winedos/vga.h > @@ -3,6 +3,7 @@ > * > * Copyright 1998 Ove Kven > * > + * Please fix this spurious whitespace change. > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > * License as published by the Free Software Foundation; either ... > +static const VESA_MODE VESA_modelist[] = Don't put data in header files. If it needs to be shared, make it non-static in the original file and add an extern declaration for it. > +{ > + /* VGA modes */ > + {0x0000, TEXT, 40, 25, 9, 16, 360, 400, 0, 16, 8, TRUE}, /* VGA text mode 0 */ > + {0x0001, TEXT, 40, 25, 9, 16, 360, 400, 0, 16, 8, TRUE}, /* VGA text mode 1 */ > + {0x0002, TEXT, 80, 25, 9, 16, 360, 400, 0, 16, 8, TRUE}, /* VGA text mode 2 */ > + {0x0003, TEXT, 80, 25, 9, 16, 360, 400, 0, 16, 8, TRUE}, /* VGA text mode 3 */ > + {0x0004, GRAPHIC, 40, 25, 8, 8, 320, 200, 2, 4, 1, FALSE}, /* VGA graphics mode 4 */ > + {0x0005, GRAPHIC, 40, 25, 8, 8, 320, 200, 2, 4, 1, FALSE}, /* VGA graphics mode 5 */ > + {0x0006, GRAPHIC, 80, 25, 8, 8, 640, 200, 1, 2, 1, FALSE}, /* VGA graphics mode 6 */ > + {0x0007, TEXT, 80, 25, 9, 16, 720, 400, 0, 0, 8, FALSE}, /* VGA text mode 7 - FIXME bad default address */ > + {0x000d, GRAPHIC, 40, 25, 8, 8, 320, 200, 4, 16, 8, FALSE}, /* VGA graphics mode 13 */ > + {0x000e, GRAPHIC, 80, 25, 8, 8, 640, 200, 4, 16, 4, FALSE}, /* VGA graphics mode 14 */ > + {0x000f, GRAPHIC, 80, 25, 8, 14, 640, 350, 0, 0, 2, FALSE}, /* VGA graphics mode 15 */ > + {0x0010, GRAPHIC, 80, 25, 8, 14, 640, 350, 4, 16, 2, FALSE}, /* VGA graphics mode 16 */ > + {0x0012, GRAPHIC, 80, 30, 8, 16, 640, 480, 1, 2, 1, FALSE}, /* VGA graphics mode 17 */ > + {0x0012, GRAPHIC, 80, 30, 8, 16, 640, 480, 4, 16, 1, FALSE}, /* VGA graphics mode 18 */ > + {0x0013, GRAPHIC, 40, 25, 8, 8, 320, 200, 8, 256, 1, TRUE}, /* VGA graphics mode 19 */ > + /* VESA 7-bit modes */ > + {0x006a, GRAPHIC, 0, 0, 0, 0, 800, 600, 4, 16, 1, TRUE}, /* VESA graphics mode, same as 0x102 */ > + /* VESA 15-bit modes */ > + {0x0100, GRAPHIC, 0, 0, 0, 0, 640, 400, 8, 256, 1, TRUE}, /* VESA graphics mode */ > + {0x0101, GRAPHIC, 0, 0, 0, 0, 640, 480, 8, 256, 1, TRUE}, /* VESA graphics mode */ > + {0x0102, GRAPHIC, 0, 0, 0, 0, 800, 600, 4, 16, 1, TRUE}, /* VESA graphics mode */ > + {0x0103, GRAPHIC, 0, 0, 0, 0, 800, 600, 8, 256, 1, TRUE}, /* VESA graphics mode */ > + {0x0104, GRAPHIC, 0, 0, 0, 0, 1024, 768, 4, 16, 1, TRUE}, /* VESA graphics mode */ > + {0x0105, GRAPHIC, 0, 0, 0, 0, 1024, 768, 8, 256, 1, TRUE}, /* VESA graphics mode */ > + {0x0106, GRAPHIC, 0, 0, 0, 0, 1280, 1024, 4, 16, 1, TRUE}, /* VESA graphics mode */ > + {0x0107, GRAPHIC, 0, 0, 0, 0, 1280, 1024, 8, 256, 1, TRUE}, /* VESA graphics mode */ > + {0x0108, TEXT, 0, 0, 0, 0, 80, 60, 0, 0, 1, TRUE}, /* VESA text mode */ > + {0x0109, TEXT, 0, 0, 0, 0, 132, 25, 0, 0, 1, TRUE}, /* VESA text mode */ > + {0x010a, TEXT, 0, 0, 0, 0, 132, 43, 0, 0, 1, TRUE}, /* VESA text mode */ > + {0x010b, TEXT, 0, 0, 0, 0, 132, 50, 0, 0, 1, TRUE}, /* VESA text mode */ > + {0x010c, TEXT, 0, 0, 0, 0, 132, 60, 0, 0, 1, TRUE}, /* VESA text mode */ > + /* VESA 1.2 modes */ > + {0x010d, GRAPHIC, 0, 0, 0, 0, 320, 200, 15, 0, 1, TRUE}, /* VESA graphics mode, 32K colors */ > + {0x010e, GRAPHIC, 0, 0, 0, 0, 320, 200, 16, 0, 1, TRUE}, /* VESA graphics mode, 64K colors */ > + {0x010f, GRAPHIC, 0, 0, 0, 0, 320, 200, 24, 0, 1, TRUE}, /* VESA graphics mode, 16.8 Million colors */ > + {0x0110, GRAPHIC, 0, 0, 0, 0, 640, 480, 15, 0, 1, TRUE}, /* VESA graphics mode, 32K colors */ > + {0x0111, GRAPHIC, 0, 0, 0, 0, 640, 480, 16, 0, 1, TRUE}, /* VESA graphics mode, 64K colors */ > + {0x0112, GRAPHIC, 0, 0, 0, 0, 640, 480, 24, 0, 1, TRUE}, /* VESA graphics mode, 16.8 Million colors */ > + {0x0113, GRAPHIC, 0, 0, 0, 0, 800, 600, 15, 0, 1, TRUE}, /* VESA graphics mode, 32K colors */ > + {0x0114, GRAPHIC, 0, 0, 0, 0, 800, 600, 16, 0, 1, TRUE}, /* VESA graphics mode, 64K colors */ > + {0x0115, GRAPHIC, 0, 0, 0, 0, 800, 600, 24, 0, 1, TRUE}, /* VESA graphics mode, 16.8 Million colors */ > + {0x0116, GRAPHIC, 0, 0, 0, 0, 1024, 768, 15, 0, 1, TRUE}, /* VESA graphics mode, 32K colors */ > + {0x0117, GRAPHIC, 0, 0, 0, 0, 1024, 768, 16, 0, 1, TRUE}, /* VESA graphics mode, 64K colors */ > + {0x0118, GRAPHIC, 0, 0, 0, 0, 1024, 768, 24, 0, 1, TRUE}, /* VESA graphics mode, 16.8 Million colors */ > + {0x0119, GRAPHIC, 0, 0, 0, 0, 1280, 1024, 15, 0, 1, TRUE}, /* VESA graphics mode, 32K colors */ > + {0x011a, GRAPHIC, 0, 0, 0, 0, 1280, 1024, 16, 0, 1, TRUE}, /* VESA graphics mode, 64K colors */ > + {0x011b, GRAPHIC, 0, 0, 0, 0, 1280, 1024, 24, 0, 1, TRUE}, /* VESA graphics mode, 16.8 Million colors */ > + {0xffff, TEXT, 0, 0, 0, 0, 0, 0, 0, 0, 1, FALSE} > +}; > + > +/* True if video mode is a vesa mode, false otherwise. > + * More correct would be to use something like (x > 0xff || x == 0x6a) > + * but as long as we have only the standard VGA and VESA modes this is ok too */ > +#define IS_VESA_MODE(x) ((x) >= 0x6a) > + In general, you want to submit many small patches instead of one larger patch. Some of the things you are doing are renames of functions or variables and so could be done independently of functional changes. This will make the patch easier to review and hence more likely to get in quickly. -- Rob Shearman

1 0

Re: [1/5] di32: Call AbortProc from StartDoc instead of EndPage
by Henri Verbeet 07 Oct '08

07 Oct '08

That should read "gdi32" instead of "di32", of course.

1 0

New Coverity run Oct 1st. 58 fixed, 41 new warnings in cabinet, jscript, mshtml, wined3d, and code generated by widl
by Dan Kegel 07 Oct '08

07 Oct '08

Thanks to the half-dozen Wine developers attacking the Coverity warnings, we are slowly making progress. Here are the warnings that were new as of October 1st and which have not yet been classified. They fall into five areas (four DLLs and one kind of generated code): CID Checker Func File 765 FORWARD_NULL FDICopy dlls/cabinet/fdi.c 766 FORWARD_NULL FDICopy dlls/cabinet/fdi.c 770 NULL_RETURNS alloc_array dlls/jscript/array.c 771 NULL_RETURNS Array_sort dlls/jscript/array.c 773 NULL_RETURNS JScriptFactory_CreateInstance dlls/jscript/jscript.c 779 REVERSE_INULL JScript_Close dlls/jscript/jscript.c 780 REVERSE_INULL JScript_Close dlls/jscript/jscript.c 772 NULL_RETURNS alloc_number dlls/jscript/number.c 768 FORWARD_NULL EmitREBytecode dlls/jscript/regexp.c 767 FORWARD_NULL _test_elem_getelembytag dlls/mshtml/tests/dom.c 509 FORWARD_NULL drawStridedSlow dlls/wined3d/drawprim.c 781 REVERSE_INULL __finally_IEnumFORMATETC_RemoteNext_Stub dlls/ole32/ole32_objidl_p.c 782 REVERSE_INULL __finally_IEnumMoniker_RemoteNext_Stub dlls/ole32/ole32_objidl_p.c 783 REVERSE_INULL __finally_IEnumSTATDATA_RemoteNext_Stub dlls/ole32/ole32_objidl_p.c 784 REVERSE_INULL __finally_IEnumUnknown_RemoteNext_Stub dlls/ole32/ole32_objidl_p.c 785 REVERSE_INULL __finally_IDispatch_RemoteInvoke_Stub dlls/oleaut32/oleaut32_oaidl_p.c 786 REVERSE_INULL __finally_IEnumVARIANT_RemoteNext_Stub dlls/oleaut32/oleaut32_oaidl_p.c 787 REVERSE_INULL __finally_ITypeInfo_RemoteGetNames_Stub dlls/oleaut32/oleaut32_oaidl_p.c 788 REVERSE_INULL __finally_ITypeLib_RemoteFindName_Stub dlls/oleaut32/oleaut32_oaidl_p.c 789 REVERSE_INULL __finally_IEnumConnectionPoints_RemoteNext_Stub dlls/oleaut32/oleaut32_ocidl_p.c 790 REVERSE_INULL __finally_IEnumConnections_RemoteNext_Stub dlls/oleaut32/oleaut32_ocidl_p.c 791 REVERSE_INULL __finally_IEnumOleUndoUnits_RemoteNext_Stub dlls/oleaut32/oleaut32_ocidl_p.c 792 REVERSE_INULL __finally_IPropertyPage_SetObjects_Stub dlls/oleaut32/oleaut32_ocidl_p.c 774 REVERSE_INULL __finally_IEnumBackgroundCopyFiles_Next_Stub dlls/qmgrprxy/qmgrprxy_p.c 775 REVERSE_INULL __finally_IEnumBackgroundCopyJobs_Next_Stub dlls/qmgrprxy/qmgrprxy_p.c 793 REVERSE_INULL __finally_IServer_sum_padded2 dlls/rpcrt4/tests/server_s.c 794 REVERSE_INULL __finally_IServer_sum_padded_conf dlls/rpcrt4/tests/server_s.c 776 REVERSE_INULL __finally_epm_ept_delete programs/rpcss/epm_s.c 777 REVERSE_INULL __finally_epm_ept_insert programs/rpcss/epm_s.c 778 REVERSE_INULL __finally_epm_ept_lookup programs/rpcss/epm_s.c For more info, see http://wiki.winehq.org/StaticAnalysis

3 2

Re: gdi32: Fix for capella problem with codepages in symbol fonts
by Dmitry Timoshkov 07 Oct '08

07 Oct '08

"Stefan Ziel" <stefan.ziel(a)terra.com.br> wrote: > Ignore characterset bit for symbol fonts > - if(!TranslateCharsetInfo((DWORD*)(INT_PTR)lf.lfCharSet, &csi, TCI_SRCCHARSET)) { > + if (lf.lfCharSet == SYMBOL_CHARSET){ > + /* codepage for symbol is not definied -> ignore it */ > + csi.fs.fsCsb[0] = 0; This patch is obviously wrong, TranslateCharsetInfo does handle SYMBOL_CHARSET, and code page for symbol *is* defined. In any case the first thing to do is write a test case. -- Dmitry.

2 3

Re: msi: Added MsiInstallMissingComponentW stub implementation.
by Kai Blin 07 Oct '08

07 Oct '08

On Monday 06 October 2008 23:05:25 Jacek Caban wrote: > +UINT WINAPI MsiInstallMissingComponentW(LPCWSTR szProduct, LPCWSTR ... > 83 stub MsiInstallMissingComponentA > -84 stub MsiInstallMissingComponentW > +84 stdcall MsiInstallMissingComponentW(wstr wstr long) ... > diff --git a/include/msi.h b/include/msi.h > index 20dca3a..cf125ef 100644 > --- a/include/msi.h > +++ b/include/msi.h > @@ -603,6 +603,10 @@ UINT WINAPI MsiDatabaseMergeA(MSIHANDLE, MSIHANDLE, > LPCSTR); UINT WINAPI MsiDatabaseMergeW(MSIHANDLE, MSIHANDLE, LPCWSTR); > #define MsiDatabaseMerge WINELIB_NAME_AW(MsiDatabaseMerge) > > +UINT WINAPI MsiInstallMissingComponentA(LPCSTR, LPCSTR, INSTALLSTATE); > +UINT WINAPI MsiInstallMissingComponentW(LPCWSTR, LPCWSTR, INSTALLSTATE); > +#define MsiInstallMissingComponent WINELIB_NAME_AW(MsiInstallMissingComponent) + Isn't this going to break if an app is trying to use Ansi MsiInstallMissingComponent? 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.

2 1

Re: [PATCH 08/17] mshtml: Added IHTMLStyle::[get|put]_borderimplementation.
by Alistair Leslie-Hughes 07 Oct '08

07 Oct '08

Hi Jacek, >static HRESULT WINAPI HTMLStyle_put_border(IHTMLStyle *iface, BSTR v)> {> HTMLStyle *This = HTMLSTYLE_THIS(iface);>- FIXME("(%p)->(%s)\n", This, debugstr_w(v));>- return E_NOTIMPL;>+>+ TRACE("(%p)->(%s)\n", This, debugstr_w(v));>+>+ return set_style_attr(This, STYLEID_BORDER, v, 0);> } My sample code style->put_border(L"groove 5"); produced <BODY style="BORDER-RIGHT: 5px groove; BORDER-TOP: 5px groove; BORDER-LEFT: 5px groove; BORDER-BOTTOM: 5px groove" /BODY> Will gecko expand "border" to the above? Best Regards Alistair Leslie-Hughes _________________________________________________________________

2 1

Re: [try 2] [6/9] Add usbd.sys.
by winepatches＠kegel.com 07 Oct '08

07 Oct '08

amorozov wrote: > Changed as directed Rob Shearman. Please use this instead of previous > version of [6/9] patch. Patchwatcher doesn't know what to do with partial resends yet (eventually it will ignore them). At the moment I have to delete them manually, else patchwatcher gets confused and waits for the rest of the series. - Dan

2 1

Re: kernel32/tests: Actually store the return value before using it.
by Paul Vriens 07 Oct '08

07 Oct '08

Kai Blin wrote: > --- > dlls/kernel32/tests/locale.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > Hi Kai, Already sent a patch for this : http://www.winehq.org/pipermail/wine-patches/2008-October/062613.html -- Cheers, Paul.

1 0

Re: kernel32/tests: Actually store the return value before using it.
by Kai Blin 07 Oct '08

07 Oct '08

On Tuesday 07 October 2008 06:46:06 Kai Blin wrote: > --- > dlls/kernel32/tests/locale.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) I forgot to mention that Coverity found this one. Alexandre, can you please add (Coverity) to the subject before the commit? 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.

1 0

Re: mapi32: initialize session pointer to zero in MAPILogonEx (3nd resend (added extra spaces))
by James Hawkins 07 Oct '08

07 Oct '08

2008/10/6 Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk>: > fixes a crash reported on userlist: > http://forum.winehq.org/viewtopic.php?t=2447 > > As the function is a complete stub, it's probably a good ides to initialize > it to zero anyway. > You haven't addressed the concerns pointed out by Juan. -- James Hawkins

1 0

Re: [user32/tests] Fix failures on W2K and below
by Dmitry Timoshkov 07 Oct '08

07 Oct '08

"Paul Vriens" <paul.vriens.wine(a)gmail.com> wrote: > (Independent from the other user32/tests patch "Run tests on win95 again"). > > Basically the same patch/logic as in commit > 5cf418f5218d46e28c00f15ba2eb5748888794f6 but now for user32. The GetProcAddress > is needed as GetComboBoxInfo is not available on win95. > > I've also changed the ok() test to test for all outcomes of the > SendMessageA(hCombo, CB_ADDSTRING, 0, (LPARAM)&buffer). That's of course is not your fault, but the above SendMessage call is invalid, it should be SendMessageA(hCombo, CB_ADDSTRING, 0, (LPARAM)buffer) instead, notice the removal of '&'. -- Dmitry.

1 0

Re: [1/5] msxml3/tests: Valgrind fix.
by James Hawkins 07 Oct '08

07 Oct '08

On Mon, Oct 6, 2008 at 5:48 PM, Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> wrote: > sName is an uninitialized pointer if GetMemberName faild. > --- > dlls/msxml3/tests/domdoc.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/msxml3/tests/domdoc.c b/dlls/msxml3/tests/domdoc.c > index 1ad168b..0703f3d 100644 > --- a/dlls/msxml3/tests/domdoc.c > +++ b/dlls/msxml3/tests/domdoc.c > @@ -1565,7 +1565,8 @@ static void test_getElementsByTagName(void) > > r = IDispatchEx_GetMemberName(dispex, dispid, &sName); > ok(r == E_NOTIMPL, "expected E_NOTIMPL got %08x\n", r); > - SysFreeString(sName); > + if( !FAILED(r) ) > + SysFreeString(sName); > aka SUCCEEDED(r). -- James Hawkins

1 0

Re: msi: Added MsiInstallMissingComponentW stub implementation.
by James Hawkins 07 Oct '08

07 Oct '08

On Mon, Oct 6, 2008 at 4:05 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: > --- > dlls/msi/msi.c | 9 +++++++++ > dlls/msi/msi.spec | 2 +- > include/msi.h | 4 ++++ > 3 files changed, 14 insertions(+), 1 deletions(-) > +{ + FIXME("(%s %s %d\n", debugstr_w(szProduct), debugstr_w(szComponent), eInstallState); + return ERROR_SUCCESS; +} Missing the closing parenthesis on the format string. -- James Hawkins

1 0

Translation Patches for wine-1.0.1
by Michael Stefaniuc 06 Oct '08

06 Oct '08

Hello Alexandre, please cherry-pick the attached list of translation patches into the "stable" aka wine-1.0.x branch. Some of the patches seem to be already cherry-picked but as a git cherry-pick will just do nothing for those I didn't bother to find them and remove them. The list was generated by the attached shell script. It isn't beautiful nor fast but it gets the job done. The idea was to get all the patches that touch a language rc file up to but not including the first patch that modified the En.rc. That way it was trivial to make sure that the translation patch doesn't breaks the translation. The patches were cherry-picked onto a branch tracking "origin/stable", the generated commits were visually inspected and a "git diff --stat origin/stable.." shows only .rc files were modified. The resulting tree was compile tested with "wrc --verify-translation" and there were no DIFF or ERR lines introduced (means no translation errors). bye michael 2cb5773d7baefd56b4d83cbee63231569aa93fe1 shell32: Update Russian translation. 605d1e2f1e869927f9fe6d6fa74d5f35cbbf820c mshtml: Update Russian translation. 56c1ea6af415e76bfe562f796543c7dce87503bd regedit: Update Russian translation. 30899341cd6e6753f159dcf806c0cbb1f6bf7f94 winhlp32: Update Polish translation. ad0c267f748339f98fb27af11637284de1016674 oleview: Add Russian translation. 87b5e9448034e580f45541f4bf649604b89fc72e taskmgr: Add Russian translation. 2eee5fbfbe650541b3589f011bba2a589148f490 hhctrl.ocx: Update Russian translation. 872077674921c3e813b6be6760ec06b036606b58 notepad: Update simplified Chinese resource. f9bc73e25f549a8cf225929c269ee390b302c9e4 notepad: Update Japanese translation. b46ffb40c654e9175ebcffb6691660385641d4f7 clock: Update simplified Chinese resource. 5070763a0ea27934a350659658bdf995603de75b winefile: Update simplified Chinese resource. 1897f8369aa8f2abad0711c4e3863c52321072bc winconsole: Update simplified Chinese resource. d9e45488f62ede4b5801f39ee2c117266a6e0136 progman: Update simplified Chinese resource. d24b6e424fef650747fe1b37699f4570b9c1516f user32: Update simplified Chinese resource. 7fe167eeae1cb4a5659cc7f8c5fdf024403f6a24 comdlg32: Update simplified Chinese resource. a8a359ac6860f1801b7030ae427cee4c3246a7d2 comctl32: Update simplified Chinese resource. 7654b6aa7243f55ce9b01bdd65258f48c83e0cca comdlg32: Update Japanese translation. 4b8134a2427183c7b24d93127440e7a5aea3f7c5 user32: Update Japanese translation. 0eaabac5457467e7a53eafb6d0f8c4164f27f16d wineconsole: Convert simplified Chinese resource to utf8. 252243e932474d43e267ef4f82e24f3f0c3953c3 winefile: Convert simplified Chinese resource to utf8. 50b6ed4bb6b83f30ee2f9b5db9c239f17fc1a974 progman: Convert simplified Chinese resource to utf8. e2f5ab434ab775fe2cf8a72b587a2b14ae20c10e comctl32: Convert simplified Chinese resource to utf8. e3712879719faed51116bef658d7aafd81057b9c notepad: Convert simplified Chinese resource to utf8. 1ae5258472b2e421dcd64db890d932aef2a3ccd0 comdlg32: Convert traditional Chinese resource to utf8. 27670e715a7cc685ba643b6d7798000f198bab4f comdlg32: Convert simplified Chinese resource to utf8. adb63f9e8780d2d8451d91d84f42e4088f9bd334 user32: Convert Chinese resource to utf8. c808b9063a01ae27f557583671248a60caeeb9db clock: Convert simplified Chinese resource to utf8. 0b091fa5cb4d9d89d7779aa96eb2208f7e86dbe8 clock: Add traditional Chinese resource. c75fde2c0ab5421ae142ee5150497a058e4ed82d progman: Add traditional Chinese resource. e0676d2777904f843e7ced33eb77d14930996bcf winefile: Add traditional Chinese resource. a10d6ede6858b4fd7bc9e60dcb2899ab5c9b9d8e wineconsole: Add traditional Chinese resource. ecc1bf3d0e5a80f8e7de1dbfc5335296b55a9c0d notepad: Add traditional Chinese resource. 11295e708fcb17e10e803e7e6d1dc0332d7bec97 user32: Update traditional Chinese resource. b76433452ca239ef1cab06177b00586381af550c comdlg32: Update traditional Chinese resource. 698e8727513012d23e50ad242d93722042d45700 comdlg32: Update simplified Chinese resource. f4d2477b6c41cd9bbb299100d254c71b1670a4f0 comdlg32: Merge Chinese resources into a single file. c5ef467f4dd6d1d225294289f78113c5fd1eed7d comctl32: Rename the Chinese resources to comctl_Zh.rc. 5f680f92e50792b1bc79143d108b83085486f938 comdlg32: Update simplified Chinese resource. 0ef830d66b8e35d4687d508ef0db3734ef6100cd notepad: Update Chinese resources - dialog font. 0a11607dc85fbaad3ada576e68ad453e39772201 wineboot: Add simplified and traditional Chinese resources. d6017c1bedfffa09ffe9016201e7339e783a826d view: Add simplified and traditional Chinese resources. c8bafc3817abdcc32c0631044a198acd8c574d96 notepad: Remove spaces before '\n' in the Chinese resources. 874ff81640d1b4493911512e4cd0d93b79355007 comdlg32: Update Japanese translation. baf3460459c132acd7ceb4b77024bd2902f69db9 credui: Add simplified and traditional Chinese resources. ee288272a501e3a01a6ad331240a74d2c447df83 htctrl: Add simplified and traditional Chinese resources. 2c248cb0b1cef56d5406cd30d7ebfd909751532e localspl: Add simplified and traditional Chinese resources. cd01bf429180c7e04d066d6756879ec3978a5911 localui: Add simplified and traditional Chinese resources. 24a26a1435ee27ca1f01fda3b22cff0bdfb270dd mpr: Add simplified and traditional Chinese resources. dd0239e6cedd662cd1f7f8d96b9571cb00d70fb1 msacm32: Add simplified and traditional Chinese resources. 9eb3a9c1573455dcd4317a1e31fec9ce2b240a7d msi: Add simplified and traditional Chinese resources. 275a454823b296726c0948537a5ec1f9dbe7c8e4 oleaut32: Add simplified and traditional Chinese resources. 68aba12fb16d920bf39a2dccc5d690baca3d980b serialui: Add simplified and traditional Chinese resources. 4648b353e4cfcb0a128af35904ef3e54487a59cc setupapi: Add simplified and traditional Chinese resources. 7d35b15539530979533da3abb92ac1b33251c74d shlwapi: Add simplified and traditional Chinese resources. 2656c02dd64dc7a7acbfef4bfa2c27669ba55c59 winspool: Add simplified and traditional Chinese resources. fcb488f3f82ee44277c5efa615de3ebe5aab15f9 notepad: Update Japanese translation. 8d97c6e1abdf738f5f76648f37b0eb2d142bae6f wininet: Update Japanese translation. 3a6373d1a8942263453acad7f920c7357740bf78 view: Add Japanese resources. 48dfff85771ed9e915f0ffe62576fa8512b38af9 cmdlgtst: Add Japanese resources. 2ca3a80ba8d14ff89a732b367322343d3ff616d0 comdlg32: Update Japanese translation. 521ad0c7e5e693bb8da90addaca3d00377a7f5d8 wineboot: Use "MS Shell Dlg" 9 in Japanese resources. f94ab4f482c87021fc0070a1b5d51f3731140b09 notepad: Use "MS Shell Dlg" 9 in Japanese resources. 5fb9ed227d77c96ead8857ebb561541293d3e950 avifil32: Use "MS Shell Dlg" 9 in Japanese resources. 8448a9f1f4dd468ec5bfae8447fc9ec2f1637a18 setupapi: Use "MS Shell Dlg" 9 in Japanese resources. bcff2eb2880f7c9d3a3a56af96b269f5554ae8f6 user32: Use "MS Shell Dlg" 9 in Japanese resources. 4d41ea4f7b7307421ab3d874fe7cd1765717855e wineps.drv: Use "MS Shell Dlg" 9 in Japanese resources. 6c0c3fdaace2a34a68ad364043f9f77c5b6a1515 wininet: Use "MS Shell Dlg" 9 in Japanese resources. adb32f76fc05b7db2939f15caf56f2bbceb5da85 comctl32: Use "MS Shell Dlg" 9 in Japanese resources. d1fbd962431cd3db0d7d548eff733251575dafc0 msacm32: Use "MS Shell Dlg" 9 in Japanese resources. 7d6c52d6472a9527257279594bc626a6a70f32bf oledlg: Use "MS Shell Dlg" 9 in Japanese resources. 10c996acbfe39bd4672b028e45de4a72dd63a671 serialui: Use "MS Shell Dlg" 9 in Japanese resources. 7ddd48da2d1ec12b7cc0896cf0ef97481c2fc672 shlwapi: Use "MS Shell Dlg" 9 in Japanese resources.

1 0

Re: mapi32: initialize session pointer to zero in MAPILogonEx (2nd resend)
by Juan Lang 06 Oct '08

06 Oct '08

Hi Louis, this isn't about spaces this time. diff --git a/dlls/mapi32/mapi32_main.c b/dlls/mapi32/mapi32_main.c index 936d435..5aace9a 100644 --- a/dlls/mapi32/mapi32_main.c +++ b/dlls/mapi32/mapi32_main.c @@ -109,6 +109,7 @@ HRESULT WINAPI MAPILogonEx(ULONG_PTR uiparam, LPWSTR profile, { FIXME("(0x%08lx %s %p 0x%08x %p) Stub\n", uiparam, debugstr_w(profile), password, flags, session); + *session=0; return SUCCESS_SUCCESS; } Are you guaranteed that session is not NULL? A test case would help. --Juan

1 0

Re: mapi32: initialize session pointer to zero in MAPILogonEx (2nd resend)
by Louis. Lenders 06 Oct '08

06 Oct '08

----- Original Message ---- From: Juan Lang <juan.lang(a)gmail.com> To: Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> Cc: wine-devel(a)winehq.org Sent: Monday, 6 October, 2008 13:36:52 Subject: Re: mapi32: initialize session pointer to zero in MAPILogonEx (2nd resend) > diff --git a/dlls/mapi32/mapi32_main.c b/dlls/mapi32/mapi32_main.c > index 936d435..5aace9a 100644 > --- a/dlls/mapi32/mapi32_main.c > +++ b/dlls/mapi32/mapi32_main.c > @@ -109,6 +109,7 @@ HRESULT WINAPI MAPILogonEx(ULONG_PTR uiparam, > LPWSTR profile, > { > FIXME("(0x%08lx %s %p 0x%08x %p) Stub\n", uiparam, > debugstr_w(profile), password, flags, session); > + *session=0; > return SUCCESS_SUCCESS; > } > > The rest of the file uses ' = 0', so please stay consistent. Also, the indenting is inconsistent: the function uses 2-space indenting, whereas your change uses 4-space indenting. Please match the file's existing style. --Juan Sorry , i don't understand what you mean with that comment above. When i apply the patch i get the code below: HRESULT WINAPI MAPILogonEx(ULONG_PTR uiparam, LPWSTR profile, LPWSTR password, ULONG flags, LPMAPISESSION *session) { FIXME("(0x%08lx %s %p 0x%08x %p) Stub\n", uiparam, debugstr_w(profile), password, flags, session); *session=0; return SUCCESS_SUCCESS; } I don't see any 2-space nor 4-space indention introduced by this patch. I'll try to be more consistent with all this "space-thing" stuff, but is it now policy to reject patches because of missing/too much spaces? I'm just trying to fix a bug you know....... I'll resend this patch, as for the other patch, i sent it in 5 times already, 2 times because of changing "stylish things" i was requested, then 3 times resend because it was not applied and i didn't receive any comments anymore about it. I don't think it's good idea to spam the list with just another resend, if there's another reason why it was rejected i'd be happy to know about it........

3 2

Re: wined3d: quiet a noisy fixme
by Henri Verbeet 06 Oct '08

06 Oct '08

2008/10/6 Austin English <austinenglish(a)gmail.com>: > - if(DepthStencilFormat != WINED3DFMT_D24S8) > - FIXME("Add OpenGL context recreation support to SetDepthStencilSurface\n"); > > + if(DepthStencilFormat != WINED3DFMT_D24S8) { > + if (warn) { > + FIXME("Add OpenGL context recreation support to SetDepthStencilSurface\n"); > + warn = FALSE; > + } > + } Style issues aside, I don't think so. That FIXME is quite valid, and doesn't get printed *that* often. If you don't want to see the output, run with WINEDEBUG=-all, it should give a small performance boost as well.

3 2

Re: [PATCH 17/17] mshtml: Added DispHTMLIFrame dispinterface declaration.
by Austin English 06 Oct '08

06 Oct '08

On Mon, Oct 6, 2008 at 9:54 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > --- > include/mshtmdid.h | 12 + > include/mshtml.idl | 957 > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 969 insertions(+), 0 deletions(-) > > > > + [propget, id(DISPID_IHTMLELEMENT2_ONROWSINSERTED), displaybind, bindable] + VARIANT onrowsinserted(); + Extra space before VARIANT

2 1

Re: [PATCH 04/17] mshtml: Use IDs instead of strings in HTMLStyle implementation.
by Austin English 06 Oct '08

06 Oct '08

On Mon, Oct 6, 2008 at 9:48 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > --- > dlls/mshtml/htmlstyle.c | 108 > ++++++++++++++++++++++++++++------------------- > dlls/mshtml/htmlstyle.h | 21 +++++++++ > 2 files changed, 85 insertions(+), 44 deletions(-) > > > > +/* NOTE: Make sure to keep in sync with stryle_strings in htmlstrle.c */ s/stryle_strings/style_strings && s/htmlstrle.c/htmlstyle.c -Austin

2 1

Re: [PATCH 01/17] mshtml.idl: Added DispHTMLCurrentStyle dispinterface declaration.
by Austin English 06 Oct '08

06 Oct '08

On Mon, Oct 6, 2008 at 9:47 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > --- > include/mshtmdid.h | 26 ++++ > include/mshtml.idl | 355 > +++++++++++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 380 insertions(+), 1 deletions(-) > > > > + [propget, id(DISPID_IHTMLCURRENTSTYLE_TEXTKASHIDA), displaybind, bindable] + VARIANT textKashida(); + Missing a leading space before VARIANT. -Austin

1 0

Re: mapi32: initialize session pointer to zero in MAPILogonEx (2nd resend)
by Austin English 06 Oct '08

06 Oct '08

On Mon, Oct 6, 2008 at 12:26 PM, Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > > 2nd resend. If the patch is wrong, could you just tell me what's wrong with > it? Might be handier, then me having to guess what's wrong... > > > As the function is a complete stub, it's probably a good idea to initialize > it to zero anyway. > > > > > > diff --git a/dlls/mapi32/mapi32_main.c b/dlls/mapi32/mapi32_main.c index 936d435..5aace9a 100644 --- a/dlls/mapi32/mapi32_main.c +++ b/dlls/mapi32/mapi32_main.c @@ -109,6 +109,7 @@ HRESULT WINAPI MAPILogonEx(ULONG_PTR uiparam, LPWSTR profile, { FIXME("(0x%08lx %s %p 0x%08x %p) Stub\n", uiparam, debugstr_w(profile), password, flags, session); + *session=0; return SUCCESS_SUCCESS; } The rest of the file uses ' = 0', so please stay consistent. - Austin

2 1

Re: msi:add stub for MsiDetermineApplicablePatches{A,W} (3rd resend)
by Austin English 06 Oct '08

06 Oct '08

On Mon, Oct 6, 2008 at 12:23 PM, Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > 3rd resend. If the patch is wrong, could you just tell me what's wrong with > it? Might be handier, then me having to guess what's wrong... > > > > > > +typedef enum tagMSIPATCHDATATYPE +{ + MSIPATCH_DATATYPE_PATCHFILE = 0, + MSIPATCH_DATATYPE_XMLPATH = 1, + MSIPATCH_DATATYPE_XMLBLOB =2, +} MSIPATCHDATATYPE, *PMSIPATCHDATATYPE; + Missing a space before the 2.

1 0

re: Wineconf follow up: Cosmetic website changes
by Dan Kegel 06 Oct '08

06 Oct '08

That's right, I foolishly volunteered to put together a draft for winehq.org's front page inspired by openoffice.org's front page. The main constraint discussed at wineconf was that the site navigation should not change with this redesign ('cause that requires lots more work). Also, it's inaccurate to call this a cosmetic change; it's really driven by usability concerns. I have a sneaking suspicion that http://wiki.winehq.org is at this point a better place to send beginners to than http://winehq.org, and that's just wrong... our simplest URL should also be our best foot forward. - Dan

3 4

Re: [6/9] Add usbd.sys.
by Rob Shearman 06 Oct '08

06 Oct '08

2008/10/6 Alexander Morozov <amorozov(a)etersoft.ru>: > +@ stdcall _USBD_CreateConfigurationRequestEx\@8(ptr ptr) USBD_CreateConfigurationRequestEx ... > +@ stdcall _USBD_ParseConfigurationDescriptorEx\@28(ptr ptr long long long long long) USBD_ParseConfigurationDescriptorEx > +@ stub _USBD_ParseDescriptors\@16 The stdcall calling convention specifies a decoration of a leading underscore and an @ followed by the number of bytes to push onto the stack, which is added automatically by winebuild. Is there a reason why you are adding this on yourself? Even if there is a good reason, you don't need to quote the @ symbols. -- Rob Shearman

2 1

Re: [2/2] oleacc: implemented GetRoleText[A/W] with tests (try3)
by Dmitry Timoshkov 06 Oct '08

06 Oct '08

"Nikolay Sivov" <bunglehead(a)gmail.com> wrote: First of all there is no need to send the configure.ac patch separately. > + /* zero role number - not documented */ > + ret = GetRoleTextA(0, NULL, 0); > + ok(ret > 0, "GetRoleTextA doesn't return length for zero role number, got %d\n", ret); > + ret = GetRoleTextW(0, NULL, 0); > + ok(ret > 0, "GetRoleTextW doesn't return length for zero role number, got %d\n", ret); > + > + /* NULL buffer, return length */ > + ret = GetRoleTextA(ROLE_SYSTEM_TITLEBAR, NULL, 0); > + ok(ret > 0, "GetRoleTextA doesn't return length on NULL buffer, got %d\n", ret); > + ret = GetRoleTextA(ROLE_SYSTEM_TITLEBAR, NULL, 1); > + ok(ret > 0, "GetRoleTextA doesn't return length on NULL buffer, got %d\n", ret); > + ret = GetRoleTextW(ROLE_SYSTEM_TITLEBAR, NULL, 0); > + ok(ret > 0, "GetRoleTextW doesn't return length on NULL buffer, got %d\n", ret); > + ret = GetRoleTextW(ROLE_SYSTEM_TITLEBAR, NULL, 1); > + ok(ret > 0, "GetRoleTextW doesn't return length on NULL buffer, got %d\n", ret); If you mean that the above tests do test that the returned value is the length of the string that's not true, ret > 0 doesn't mean anything. > + /* use bigger buffer */ > + ret = GetRoleTextA(ROLE_SYSTEM_TITLEBAR, NULL, 0); > + buff = HeapAlloc(GetProcessHeap(), 0, 2*ret); > + buff[2*ret-1] = '*'; > + ret = GetRoleTextA(ROLE_SYSTEM_TITLEBAR, buff, 2*ret); > + ok(buff[2*ret-1] == '*', "GetRoleTextA shouldn't fill buffer with NULLs\n"); > + HeapFree(GetProcessHeap(), 0, buff); > + > + ret = GetRoleTextW(ROLE_SYSTEM_TITLEBAR, NULL, 0); > + buffW = HeapAlloc(GetProcessHeap(), 0, 2*ret*sizeof(WCHAR)); > + buffW[2*ret-1] = '*'; > + ret = GetRoleTextW(ROLE_SYSTEM_TITLEBAR, buffW, 2*ret); > + ok(buffW[2*ret-1] == '*', "GetRoleTextW shouldn't fill buffer with NULLs\n"); > + HeapFree(GetProcessHeap(), 0, buffW); > +} You are confusing yourself in the above tests. What that 2*ret and 2*ret*sizeof(WCHAR) above values are supposed to mean? Besides you never check the 'ret' for a presumably expected result. -- Dmitry.

2 5

Re: quartz: check hr so we are not incrementing a NULL (coverity 106)
by Dmitry Timoshkov 06 Oct '08

06 Oct '08

"Aric Stewart" <aric(a)codeweavers.com> wrote: > - wszPatternString++; /* skip ',' */ > + if (hr == S_OK) > + wszPatternString++; /* skip ',' */ > > if (hr == S_OK) > { Why not just move it into the below block? -- Dmitry.

2 1

Re: [2/2] oleacc: implemented GetRoleText[A/W] with tests
by Dmitry Timoshkov 06 Oct '08

06 Oct '08

"Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > +UINT WINAPI GetRoleTextA(DWORD role, LPSTR lpRole, UINT rolemax) > +{ > + UINT length; > + WCHAR *roletextW; > + CHAR *roletextA; > + > + TRACE("%u %p %u\n", role, lpRole, rolemax); > + > + length = GetRoleTextW(role, NULL, 0); > + if(length == 0) > + return 0; > + > + roletextW = HeapAlloc(GetProcessHeap(), 0, (length + 1)*sizeof(WCHAR)); > + if(!roletextW) > + return 0; > + > + GetRoleTextW(role, roletextW, length + 1); > + > + length = WideCharToMultiByte( CP_ACP, 0, roletextW, -1, NULL, 0, NULL, NULL ); > + > + if(!lpRole){ > + HeapFree(GetProcessHeap(), 0, roletextW); > + return length - 1; > + } > + > + roletextA = HeapAlloc(GetProcessHeap(), 0, length); > + WideCharToMultiByte( CP_ACP, 0, roletextW, -1, roletextA, length, NULL, NULL ); > + > + if(rolemax < length) > + length = rolemax; > + > + memcpy(lpRole, roletextA, length); > + lpRole[length-1] = '\0'; > + > + HeapFree(GetProcessHeap(), 0, roletextA); > + HeapFree(GetProcessHeap(), 0, roletextW); > + > + return length - 1; > +} Why do you need to allocate an intermediate roletextA? -- Dmitry.

2 12

Please Review WWN 353
by Zachary Goldberg 06 Oct '08

06 Oct '08

All, This WWN is all my writing and no quotes, and thus a lot more room for typographical and other errors. Thus I wanted to send everybody the WWN for review before publication. In particular please check the first section for name typos etc. http://home.bluesata.com/WineWWN/WineHQ/?issue=353 -Zach

4 3

Re: [PATCH] also remove backbuffer flags in the v1 DDRAW interface
by Austin English 06 Oct '08

06 Oct '08

On Sun, Oct 5, 2008 at 2:26 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > Hi, > > This fixes http://bugs.winehq.org/show_bug.cgi?id=9008 > by also filtering out the backbuffer flag. > > Ciao, Marcus > --- > dlls/ddraw/ddraw_thunks.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/ddraw/ddraw_thunks.c b/dlls/ddraw/ddraw_thunks.c > index b748ad4..c77b3bb 100644 > --- a/dlls/ddraw/ddraw_thunks.c > +++ b/dlls/ddraw/ddraw_thunks.c > @@ -386,10 +386,10 @@ IDirectDrawImpl_CreateSurface(LPDIRECTDRAW This, LPDDSURFACEDESC pSDesc, > IDirectDrawSurfaceImpl *impl; > HRESULT hr; > > - /* Remove front buffer flag, this causes failure in v7, and its added to normal > - * primaries anyway > + /* Remove front and back buffer flag, this causes failure in v7, > + * and its added to normal primaries anyway. Nitpick, but typo there: should be "it's", not "its" -Austin

2 1

Re: [1/2] user32: Converted rcScrollBar to screen coordinates.
by Dmitry Timoshkov 06 Oct '08

06 Oct '08

"Dylan Smith" <dylan.ah.smith(a)gmail.com> wrote: > @@ -1252,6 +1253,9 @@ static BOOL SCROLL_GetScrollBarInfo(HWND hwnd, LONG idObject, LPSCROLLBARINFO in > > SCROLL_GetScrollBarRect(hwnd, nBar, &info->rcScrollBar, &nDummy, > &info->dxyLineButton, &info->xyThumbTop); > + /* rcScrollBar needs to be in screen coordinates */ > + GetWindowRect(hwnd, &rect); > + OffsetRect(&info->rcScrollBar, rect.left, rect.top); You need to fix SCROLL_GetScrollBarRect for the SB_CTL case instead. > +static void scrollbar_test4(void) > +{ > + BOOL ret; > + SCROLLBARINFO sbi; > + RECT rect; > + > + /* Test GetScrollBarInfo to make sure it returns rcScrollBar in screen > + * coordinates. */ > + sbi.cbSize = sizeof(sbi); > + ret = GetScrollBarInfo( hScroll, OBJID_CLIENT, &sbi); > + ok( ret, "The GetScrollBarInfo() call should not fail.\n" ); > + GetWindowRect( hScroll, &rect ); > + ok( ret, "The GetWindowRect() call should not fail.\n" ); > + ok( !(sbi.rgstate[0] & (STATE_SYSTEM_INVISIBLE|STATE_SYSTEM_OFFSCREEN)), > + "unexpected rgstate(0x%x)\n", sbi.rgstate[0]); > + ok( !memcmp(&rect, &sbi.rcScrollBar, sizeof(RECT)), > + "WindowRect(%d, %d, %d, %d) != rcScrollBar(%d, %d, %d, %d)\n", EqualRect is better than memcmp. -- Dmitry.

2 2

Wineconf follow up: Cosmetic website changes
by Zachary Goldberg 06 Oct '08

06 Oct '08

Hello all, I just wanted to start up a thread to continue the conversation from Wineconf about revamping the WineHQ homepage. The last notes I took on the subject had Dan Kegel considering doing an actual redesign. --Zach

1 0

request for windows test ddraw/dsurface
by Marcus Meissner 05 Oct '08

05 Oct '08

Hi, I am suspecting that in IDirectDraw1 the behaviour regarding backbuffer creation might change if we have a just created frontbuffer of the same size. (This is similar to behaviour shown by bulanci.exe of http://bugs.winehq.org/show_bug.cgi?id=9008 ) Can someone please try this on Windows please? Ciao, Marcus diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c index fc7bb88..50f6986 100644 --- a/dlls/ddraw/tests/dsurface.c +++ b/dlls/ddraw/tests/dsurface.c @@ -1331,10 +1331,21 @@ static void AttachmentTest(void) /* This old ddraw version happily creates explicit front buffers */ memset(&ddsd, 0, sizeof(ddsd)); ddsd.dwSize = sizeof(ddsd); + ddsd.dwHeight = 800; + ddsd.dwWidth = 600; ddsd.dwFlags = DDSD_CAPS; ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE | DDSCAPS_FRONTBUFFER; hr = IDirectDraw_CreateSurface(lpDD, &ddsd, &surface1, NULL); ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); + + /* MARCUS: Lets try creating a backbuffer with frontbuffer live... */ + memset(&ddsd, 0, sizeof(ddsd)); + ddsd.dwSize = sizeof(ddsd); + ddsd.dwFlags = DDSD_CAPS; + ddsd.ddsCaps.dwCaps = DDSCAPS_BACKBUFFER; + hr = IDirectDraw_CreateSurface(lpDD, &ddsd, &surface2, NULL); + ok(hr==DDERR_INVALIDCAPS,"CreateSurface backbuffer after frontbuffer returned: %x\n",hr); + IDirectDrawSurface_Release(surface1); /* Try a single primary and two offscreen plain surfaces */

2 1

Re: d3d8: initialize IDirect3DDevice8 *device to NULL incase of immedient cleanup. (coverity 795)
by Rob Shearman 05 Oct '08

05 Oct '08

2008/10/3 Aric Stewart <aric(a)codeweavers.com>: > - IDirect3DDevice8 *device; > + IDirect3DDevice8 *device=NULL; Add spaces around the "=" here to match the rest of the code. -- Rob Shearman

1 0

Re: [try 4][PATCH 1/2] user32/tests: Added test about minimal child windowsizes.
by Dmitry Timoshkov 05 Oct '08

05 Oct '08

"Florian Köberle" <florian(a)fkoeberle.de> wrote: > Changes since try 3: > + I found out that the minimal child window size is "4 + 2*borderWidth" > by testing multiple values for some registery keys like > "HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics\BorderWidth" on a > Windows XP machine. I don't know where the 4 comes from, but it could be > hard coded in Windows too. That still looks more like a hack and you still need find what that values mean. "4 + 2*borderWidth" is not something to trust in general. -- Dmitry.

1 0

Wine: Possible typo in dll/msxml3/tests/domdoc.c
by Michael Karcher 04 Oct '08

04 Oct '08

Hello Huw Davies, it looks like test_removeChild (introduced by you in commit 187ab1c0) contains a typo. The test passes both ways, but from the code flow I suspect that node_list2 was obtained for a reason, namely using it. Regards, Michael Karcher This patch fixes the type, if it turn out to really be a typo. diff --git a/dlls/msxml3/tests/domdoc.c b/dlls/msxml3/tests/domdoc.c index 29bebb9..0494e9f 100644 --- a/dlls/msxml3/tests/domdoc.c +++ b/dlls/msxml3/tests/domdoc.c @@ -1785,7 +1785,7 @@ static void test_removeChild(void) r = IXMLDOMNode_get_childNodes( node, &node_list2 ); ok( r == S_OK, "ret %08x\n", r); - r = IXMLDOMNodeList_get_item( node_list, 0, &node4 ); + r = IXMLDOMNodeList_get_item( node_list2, 0, &node4 ); ok( r == S_OK, "ret %08x\n", r); r = IXMLDOMElement_removeChild( element, NULL, &node2 );

2 3

Layered windows required to support Clippy properly?
by Dan Kegel 04 Oct '08

04 Oct '08

I see in wine-1.1.5's announcement that we now have partial support for "Layered Windows", http://msdn.microsoft.com/en-us/library/ms997507.aspx Which apps use this? Seems that it used to make screen captures hard, so one way to find them is to look for apps that say you have to turn on "Capture Alpha-Blending" on in UltraVNC to see them remotely. Candidates include: Visual Studio - tooltips Microsoft Office - Clippy Possibly photoshop cs3 Another way is to look for apps that recommend the Vista Layered Windows Performance hotfix or Vista SP1. Candidates include: Yahoo Messenger for Windows Vista Another way is to look for apps that make Wine output fixme:xrender:X11DRV_AlphaBlend Ignoring SourceConstantAlpha ... Candidates include: Miranda IM http://bugs.winehq.org/show_bug.cgi?id=11902 MSN Messenger http://bugs.winehq.org/show_bug.cgi?id=8555 Skype http://bugs.winehq.org/show_bug.cgi?id=12334 I'm getting the feeling it's widespread. Anyone else know of examples of apps that Wine displays poorly because of the lack of this feature? - Dan

2 1

Re: richedit: Show arrow cursor over scrollbar. (Fixes bug 15334)
by Dylan Smith 04 Oct '08

04 Oct '08

On Sat, Oct 4, 2008 at 1:21 AM, Dylan Smith <dylan.ah.smith(a)gmail.com>wrote: > Implemented the code to check for this condition in the function that > handles WM_SETCURSOR. For each scrollbar I checked for visibility and > checked the MessagePos to see if the mouse was over the scrollbar. > --- > dlls/riched20/editor.c | 19 +++++++++++++++++++ > 1 files changed, 19 insertions(+), 0 deletions(-) > This fix works alright in Wine, but I found out that it wasn't working when I cross-compiled riched20.dll and wordpad and then ran it on Windows XP. It seems as if GetScrollBarInfo was returning a SCROLLBARINFO struct with an rcScrollBar RECT in client coordinates in Wine and in screen coordinates in Windows XP. This underlying problem should be fixed first before fixing richedit. Later this patch would be modified to move the call to ScreenToClient after the check to see if the position is within the scrollbars, which I found fixes the problem on Windows.

1 0

Silencing a noisy fixme - feedback requested
by Austin English 03 Oct '08

03 Oct '08

Howdy, I was taking a look at some of the noisy fixme's, and wanted some feedback on the attached patch. This particular fixme is _really_ noisy...out of this (http://bugs.winehq.org/attachment.cgi?id=16447) log, it has 9635 of the 13117 lines! "fixme:ntdll:NtLockFile I/O completion on lock not implemented yet" 9635 times! Not sure if this is the best way to go about this or not. Any advice appreciated (or if anyone else wants to silence it :-P). -Austin

5 6

RE: d3d8/9: Use WINED3D_OK instead of D3D_OK in vertexshader.c.
by Stefan Dösinger 03 Oct '08

03 Oct '08

> -----Original Message----- > From: Henri Verbeet [mailto:hverbeet@gmail.com] > Sent: Friday, October 03, 2008 10:25 AM > To: Stefan Dösinger > Subject: Re: d3d8/9: Use WINED3D_OK instead of D3D_OK in vertexshader.c. > > 2008/10/3 Stefan Dösinger <stefan(a)codeweavers.com>: > > Actually, since the return value comes from WineD3D, we should use > WINED3D_OK here. Although there is not really a scheme behind all this > and we never cared about that because both WINED3D_OK and D3D_OK are > #define'd to S_OK. > > > Yes, that's what the patch does :-) Woops. Confusion

1 0

RE: d3d8/9: Use WINED3D_OK instead of D3D_OK in vertexshader.c.
by Stefan Dösinger 03 Oct '08

03 Oct '08

Actually, since the return value comes from WineD3D, we should use WINED3D_OK here. Although there is not really a scheme behind all this and we never cared about that because both WINED3D_OK and D3D_OK are #define'd to S_OK. > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Rob Shearman > Sent: Friday, October 03, 2008 6:56 AM > To: wine-patches > Subject: d3d8/9: Use WINED3D_OK instead of D3D_OK in vertexshader.c. > > --- > dlls/d3d8/vertexshader.c | 4 ++-- > dlls/d3d9/vertexshader.c | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-)

1 0

D3DXAssembleShader, unknown texture formats and misc
by Kjell Rune Skaaraas 03 Oct '08

03 Oct '08

Hello,I'm taking a stab at implmenting D3DXAssembleShader, which takes shader instructions like "mul r1, r2.xy, r3.z" and turns them into binary code (one-to-one mapping). Although I've got very little clue what I'm really doing, I've come quite a way on a parser that breaks it down into the separate parts and made some reverse lookups on tables of opcodes, registrys, masks etc. that I found in the wine code. I've basicly come so far that I got the parts like mul = 0x00000005, r = temp registry = 0x00000000, register number = 0x00000001, writemask = 0x000F0000 etc. for all the arguments, but I'm struggling a bit putting it all together into the correct binary format. I have found a lot of material on the *text* format of the shader instructions, but pretty much none on the binary format. Clearly some documentation must have been used/made when you implemented glsl and the other shader backends as they read this stuff and translates it to OpenGL calls. Does anyone have anything they could share with me? P.S. Don't expect too much of me though, 1) It's so ugly it makes grown men cry, 2) Current it leaks memory bigtime and 3) It's a text hack that will never validate shader code or anything like that BUT I think I can make this work for code that already works.On a different note, a game I have is pulling up two completely unknown texture formats R16 and AL16 as fourcc. I figured I could at least find out something about them and add them to the debug tables, but the only references I find on google are to wine and wine bug reports. I figure they may be related to R16F (same with ints?) and L16 (luminosity, so AL16 with alpha?) but I can't find anything on them.Oh yeah and for the misc question - where's the right place to add test code? I expect my D3DXAssembleShader function will need a lot of it - at least one for each opcode, registry tests, write mask tests, whitespace and commenting tests+++. No code for you to review yet, not until it works. THEN you can bring out the tar and feathers over the code. Regards,Kjell Rune _________________________________________________________ Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og notisblokk. http://no.mail.yahoo.com

2 1

Re: msxml3: Add IXMLHTTPRequest support (try 2)
by Juan Lang 03 Oct '08

03 Oct '08

Hi Alistair, maybe I'm being overly picky, but:: --- /dev/null +++ b/dlls/msxml3/httprequest.c @@ -0,0 +1,343 @@ +/* This file has DOS line endings. The rest of the files do not. It's really distracting in the patch, since this portion of the patch has ^M at the end of every line. --Juan

1 0

Re: msxml3: Add IXMLHTTPRequest support
by Alistair Leslie-Hughes 03 Oct '08

03 Oct '08

From: "Hans Leidekker" <hans(a)meelstraat.net> Sent: Friday, October 03, 2008 9:45 PM To: <wine-devel(a)winehq.org>; "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> Subject: Re: msxml3: Add IXMLHTTPRequest support > On Friday 03 October 2008 13:23:14 Alistair Leslie-Hughes wrote: > >> Changelog: >> msxml3: Add IXMLHTTPRequest support > > Would it be possible to use winhttp instead of nanohttp? The less > we depend on libxml the better I'd say. > Sure. This nanphttp was just my initial thought. I'll resend a corrected patch shortly. Best Regards Alistair Leslie-Hughes

1 0

Re: msxml3: Add IXMLHTTPRequest support
by Hans Leidekker 03 Oct '08

03 Oct '08

On Friday 03 October 2008 13:23:14 Alistair Leslie-Hughes wrote: > Changelog: > msxml3: Add IXMLHTTPRequest support Would it be possible to use winhttp instead of nanohttp? The less we depend on libxml the better I'd say. -Hans

2 1

Re: [PATCH 1/2] wininet: Return error codes explicitly from URLCache functions instead of returning a BOOL and storing the error code in the last error value.
by Juan Lang 03 Oct '08

03 Oct '08

Hi Rob, + * Locks the index for system-wide exclusive access. + * + * RETURNS + * TRUE if successful + * FALSE if failed and calls SetLastError. */ static LPURLCACHE_HEADER URLCacheContainer_LockIndex(URLCACHECONTAINER * pContainer) The comment's off here. @@ -1346,34 +1353,32 @@ static BOOL URLCache_AddEntryToHash(LPURLCACHE_HEADER pHeader, LPCSTR lpszUrl, D * FALSE if the hash table could not be created * */ -static HASH_CACHEFILE_ENTRY *URLCache_CreateHashTable(LPURLCACHE_HEADER pHeader, HASH_CACHEFILE_ENTRY *pPrevHash) +static DWORD URLCache_CreateHashTable(LPURLCACHE_HEADER pHeader, HASH_CACHEFILE_ENTRY *pPrevHash, HASH_CACHEFILE_ENTRY **ppHash) I think you forgot to update the comment here. --Juan

2 1

Re: msi: Implement the DROP TABLE sql command.
by Steven Edwards 03 Oct '08

03 Oct '08

On Thu, Oct 2, 2008 at 3:25 PM, James Hawkins <jhawkins(a)codeweavers.com> wrote: > Hi, I can't repro this problem on my machine, so I'm sending this > patch to patchwatcher by way of wine-patches to get some info. Please > do not apply. Regarding our wineconf discussion about patchwatcher spam on wine-patches and filtering. Perhaps we need 2 email address patches can be sent to. My thinking is the flow could be something like: 1. By default everyone sends a patch to wine-patches 2. If a patch gets rejected the author gets a failure mail in private, and now retries or testing patches should go to wine-patches-testing N times until they get it right 3. once its right, patchwatch could then forward the new good patch to wine-patches or could send an email to the dev saying that its good enough to now send to wine-patches. Doing it like this, if everyone follows the rules, we won't get a ton of patchwatcher retries filling up wine-patches. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

4 6

Re: howto fix bug 13462
by Louis. Lenders 02 Oct '08

02 Oct '08

Rob Shearman <robertshearman <at> gmail.com> writes: Hi Rob, i think i got the test ready now, i'll send it when the defenitions are in place in ctxtcall.idl. Now still strugling how to fix the bug. I fixed up the patch below, also by looking how things are done in similar places in wine-code. With patch applied I can see that ContextCallback_ContextCallback and ContextCallback_Release are called from the application (tested with NASA WorldWind), and the simple stubs are enough to let the app continue fine. But i'm not sure if everything is 100% ok. Is this what you more or less meant in your first comment? diff --git a/dlls/ole32/compobj.c b/dlls/ole32/compobj.c index 37907ec..a1f41fd 100644 --- a/dlls/ole32/compobj.c +++ b/dlls/ole32/compobj.c @@ -55,6 +55,7 @@ #include "objbase.h" #include "ole2.h" #include "ole2ver.h" +#include "ctxtcall.h" #include "compobj_private.h" @@ -3615,25 +3616,39 @@ HRESULT WINAPI CoRegisterChannelHook(REFGUID guidExtension, IChannelHook *pChann typedef struct Context { const IComThreadingInfoVtbl *lpVtbl; + const IContextCallback *lpVtblIContextCallback; LONG refs; APTTYPE apttype; } Context; +static inline Context *impl_from_Context(IComThreadingInfo *iface) +{ + return (Context *)((char*)iface - FIELD_OFFSET(Context, lpVtbl)); +} + static HRESULT WINAPI Context_QueryInterface(IComThreadingInfo *iface, REFIID riid, LPVOID *ppv) { + Context* This=impl_from_Context((IComThreadingInfo*) iface); *ppv = NULL; if (IsEqualIID(riid, &IID_IComThreadingInfo) || IsEqualIID(riid, &IID_IUnknown)) { *ppv = iface; - IUnknown_AddRef(iface); - return S_OK; } + else if(IsEqualIID(riid, &IID_IContextCallback)) + { + *ppv = &This->lpVtblIContextCallback; + } + else + { + FIXME("interface not implemented %s\n", debugstr_guid(riid)); + return E_NOINTERFACE; + } - FIXME("interface not implemented %s\n", debugstr_guid(riid)); - return E_NOINTERFACE; -} + IUnknown_AddRef(iface); + return S_OK; +} static ULONG WINAPI Context_AddRef(IComThreadingInfo *iface) { @@ -3691,6 +3706,31 @@ static HRESULT WINAPI Context_SetCurrentLogicalThreadId(IComThreadingInfo *iface return E_NOTIMPL; } + +static HRESULT WINAPI ContextCallback_QueryInterface(IContextCallback *iface, REFIID riid, LPVOID *ppv) +{ + FIXME("\n"); + return E_NOTIMPL; +} + +static ULONG WINAPI ContextCallback_AddRef(IContextCallback *iface) +{ + FIXME("\n"); + return E_NOTIMPL; +} + +static ULONG WINAPI ContextCallback_Release(IContextCallback *iface) +{ + FIXME("\n"); + return E_NOTIMPL; +} + +static HRESULT WINAPI ContextCallback_ContextCallback(IContextCallback *iface, PFNCONTEXTCALL pfnCallback, ComCallData* pParam, REFIID riid, int iMethod, IUnknown* pUnk) +{ + FIXME("not implemented yet\n"); + return E_NOTIMPL; +} + static const IComThreadingInfoVtbl Context_Threading_Vtbl = { Context_QueryInterface, @@ -3702,6 +3742,14 @@ static const IComThreadingInfoVtbl Context_Threading_Vtbl = Context_SetCurrentLogicalThreadId }; +static const IContextCallbackVtbl Context_Callback_Vtbl = +{ + ContextCallback_QueryInterface, + ContextCallback_AddRef, + ContextCallback_Release, + ContextCallback_ContextCallback +}; + /*********************************************************************** * CoGetObjectContext [OLE32.@] * @@ -3735,6 +3783,7 @@ HRESULT WINAPI CoGetObjectContext(REFIID riid, void **ppv) return E_OUTOFMEMORY; context->lpVtbl = &Context_Threading_Vtbl; + context->lpVtblIContextCallback=(IContextCallback*)&Context_Callback_Vtbl; context->refs = 1; if (apt->multi_threaded) context->apttype = APTTYPE_MTA;

3 2

Re: [PATCH 4/4] jscript: Added possibility to run test scripts from file.
by winepatches＠kegel.com 02 Oct '08

02 Oct '08

> > With this patch it's possible to test scripts by running > wine jscript_test.exe.so run <file_name> > Although it's not what Wine tests are for, it proved to be very useful > for me. That's the second time in the last couple days that your patches confused patchwatcher's patch series detector. You resent patch 4/4 from a different series, and patchwatcher took that other 4/4 and used it in place of this one, leaving this patch as a stuck singleton. Tips: 1) never send two series of the same length on the same day (This confuses even humans.) 2) never partially resend patch series, always resend the whole series. (Eventually patchwatcher will handle this better.)

1 0

Detecting Wine
by Mark Wagner 02 Oct '08

02 Oct '08

What's the best way for an application to detect that it's running under Wine? As part of the installation process, under Windows our program does a full-disk search of all local hard drives, but ignoring network drives and removable media. Under Wine, this doesn't work too well, as there's not a one-to-one mapping between disks and drive letters, and there's usually at least one way to access the entire *nix filesystem. If someone's got a few network drives mounted, the installer could spend hours searching them. -- Mark Wagner

10 17

Be careful out there
by Juan Lang 02 Oct '08

02 Oct '08

Unfortunately, there is some Microsoft code available on the Internet. More unfortunately, Google has indexed some of it. I was searching for an undocumented function and ran across something that seemed to describe it. I clicked on the link, and fortunately the indexed page was just a reference to the actual source file, because the source file was Microsoft's. (The source file was also available. No, I didn't look at it.) Be very careful: reading Microsoft's source code is a clear way to taint yourself as a developer. --Juan

4 3

Fullscreen window in metacity hides owned window
by Michael Ost 02 Oct '08

02 Oct '08

We are seeing a problem in Metacity where a fullscreen window obscures a second created window that has a particular style: WS_DLGFRAME | WS_THICKFRAME. When window A is created fullscreen (WS_POPUP, size matches screen res) and window B is created as an "owned window" (WS_DLGFRAME|WS_THICKFRAME|WS_OVERLAPPED style with "A" as its parent) you cannot see "B" if Metacity is running. You can if other window managers are running. We tried kwin, xfce, fluxbox, enlightenment or fvvm. So the problem is something specific to Metacity. You can also see window "B" if you remove either the WS_DLGFRAME or WS_THICKFRAME bit from the style. Any hints about where to look within Wine or what could be happening? - mo PS: the code (ctrl+c to quit)... #include <windows.h> const char g_szClassName[] = "myWindowClass"; // Step 4: the Window Procedure LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) { switch(msg) { case WM_CLOSE: DestroyWindow(hwnd); break; case WM_DESTROY: PostQuitMessage(0); break; default: return DefWindowProc(hwnd, msg, wParam, lParam); } return 0; } int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { WNDCLASSEX wc; HWND hwnd, hwnd4; MSG Msg; //Step 1: Registering the Window Class wc.cbSize = sizeof(WNDCLASSEX); wc.style = 0; wc.lpfnWndProc = WndProc; wc.cbClsExtra = 0; wc.cbWndExtra = 0; wc.hInstance = hInstance; wc.hIcon = LoadIcon(NULL, IDI_APPLICATION); wc.hCursor = LoadCursor(NULL, IDC_ARROW); wc.hbrBackground = (HBRUSH)(COLOR_WINDOW+1); wc.lpszMenuName = NULL; wc.lpszClassName = g_szClassName; wc.hIconSm = LoadIcon(NULL, IDI_APPLICATION); if(!RegisterClassEx(&wc)) { MessageBox(NULL, "Window Registration Failed!", "Error!", MB_ICONEXCLAMATION | MB_OK); return 0; } // Step 2: Creating the Window int width = ::GetSystemMetrics(SM_CXSCREEN); int height = ::GetSystemMetrics(SM_CYSCREEN); hwnd = CreateWindowEx( WS_EX_CLIENTEDGE, g_szClassName, "A", WS_POPUP, CW_USEDEFAULT, CW_USEDEFAULT, width, height, NULL, NULL, hInstance, NULL); if(hwnd == NULL) { MessageBox(NULL, "Window Creation Failed!", "Error!", MB_ICONEXCLAMATION | MB_OK); return 0; } hwnd4 = CreateWindowEx( WS_EX_CLIENTEDGE, g_szClassName, "B", #if 1 // invisible WS_DLGFRAME|WS_THICKFRAME|WS_OVERLAPPED, #else // visible WS_THICKFRAME|WS_OVERLAPPED, #endif 300, 300, 240, 120, hwnd, NULL, hInstance, NULL); if(hwnd4 == NULL) { MessageBox(NULL, "Window Creation Failed!", "Error!", MB_ICONEXCLAMATION | MB_OK); return 0; } ShowWindow(hwnd, nCmdShow); ShowWindow(hwnd4, nCmdShow); UpdateWindow(hwnd); UpdateWindow(hwnd4); // Step 3: The Message Loop while(GetMessage(&Msg, NULL, 0, 0) > 0) { TranslateMessage(&Msg); DispatchMessage(&Msg); } return Msg.wParam; }

2 3

Re: (try 2)version: check for out of memory when VerInstallFileA/W converstion. (response to coverity 635)
by Rob Shearman 02 Oct '08

02 Oct '08

2008/10/2 Aric Stewart <aric(a)codeweavers.com>: > @@ -543,34 +543,50 @@ DWORD WINAPI VerInstallFileW( > len = WideCharToMultiByte( CP_ACP, 0, srcfilename, -1, NULL, 0, NULL, NULL ); > if ((wsrcf = HeapAlloc( GetProcessHeap(), 0, len ))) > WideCharToMultiByte( CP_ACP, 0, srcfilename, -1, wsrcf, len, NULL, NULL ); > + else > + ret = VIF_OUTOFMEMORY; > } > - if (srcdir) > + if (srcdir && !ret) Remove the extra space here. > + static const CHAR szSrcDir[] = "C:\\windows\\temp"; > + static const CHAR szDestDir[] = "C:\\windows\\temp\\test"; > + static const CHAR szCurDir[] = "C:\\"; This isn't exactly what I meant. C:\Windows might not even exist on NT4/Win2000 and the temp directory might not be in %WINDIR%\temp. You should use GetTempPath instead. (Hard-coding C:\ is also something to be avoided if at all possible.) -- Rob Shearman

2 2

Re: gdi32: if a font substitution is given then only match to that substitution not to the original family name.
by Dmitry Timoshkov 02 Oct '08

02 Oct '08

Aric Stewart <aric(a)codeweavers.com> wrote: > LIST_FOR_EACH(family_elem_ptr, &font_list) { > family = LIST_ENTRY(family_elem_ptr, Family, entry); > - if (!strcmpiW(family->FamilyName, FaceName) || > - (psub && !strcmpiW(family->FamilyName, psub->to.name))) > + if ((!psub && !strcmpiW(family->FamilyName, FaceName)) || > + ( psub && !strcmpiW(family->FamilyName, psub->to.name))) > { > LIST_FOR_EACH(face_elem_ptr, &family->faces) { > face = LIST_ENTRY(face_elem_ptr, Face, entry); Changing the order of 2 comparisons in the 'if' block would be clear IMO, and would help avoiding to check psub twice. -- Dmitry.

1 0

Re: version: check for out of memory when VerInstallFileA/W converstion. (response to coverity 635)
by Rob Shearman 02 Oct '08

02 Oct '08

2008/10/2 Aric Stewart <aric(a)codeweavers.com>: > @@ -543,34 +543,50 @@ DWORD WINAPI VerInstallFileW( > len = WideCharToMultiByte( CP_ACP, 0, srcfilename, -1, NULL, 0, NULL, NULL ); > if ((wsrcf = HeapAlloc( GetProcessHeap(), 0, len ))) > WideCharToMultiByte( CP_ACP, 0, srcfilename, -1, wsrcf, len, NULL, NULL ); > + else if (len) > + ret = VIF_OUTOFMEMORY; IIRC HeapAlloc(..., 0) returns a non-NULL value, so the "if (len)" part is not needed. ... > + rc = VerInstallFileA(0x0, "in.txt", "out.txt", "C:\\windows\\temp", "C:\\windows\\temp\\test\\", "C:\\", tmpname, &size); > + ok (rc == 0x10000 && tmpname[0]==0," expected return 0x10000 and no tempname, got %08x/\'%s\'\n",rc,tmpname); You shouldn't hard-code paths such as this. -- Rob Shearman

1 0

Re: gdiplus: Stub GdipRecordMetafileFileName andGdipRecordMetafileFileNameI
by Alistair Leslie-Hughes 02 Oct '08

02 Oct '08

"Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote in message news:48DCB2A0.9070405@hotmail.com... > Hi, > > Changelog: > gdiplus: Stub GdipRecordMetafileFileName and GdipRecordMetafileFileNameI > Was there anything wrong with this patch? Best Regards Alistair Leslie-Hughes

2 1

Re: msi: Implement the DROP TABLE sql command.
by James Hawkins 02 Oct '08

02 Oct '08

Hold off on this patch. There's a missing debugstr_w and a crash on patchwatcher. -- James Hawkins

1 0

Re: [PATCH] wintrust: Add a stub for OpenPersonalTrustDBDialog
by Juan Lang 01 Oct '08

01 Oct '08

Hi Detlef, I'm not sure why this wasn't committed, but my hunch is this: + * RETURNS + * Success: TRUE (The Dialog was opened) + * Failure: FALSE + * + */ +BOOL WINAPI OpenPersonalTrustDBDialog(HWND hwnd) +{ + FIXME("(%p) stub\n", hwnd); + return TRUE; Shouldn't it return FALSE instead? In any case, this is a very simple function to implement: it calls cryptui:CryptUIDlgCertMgr. I'll send in a patch that implements it, if you don't mind. --Juan

1 0

Re: [2/2] inetcomm: Add a stub implementation of IIMAPTransport.
by Paul Vriens 01 Oct '08

01 Oct '08

Hans Leidekker wrote: > diff --git a/dlls/inetcomm/imaptransport.c b/dlls/inetcomm/imaptransport.c > new file mode 100644 > index 0000000..99011b2 > --- /dev/null > +++ b/dlls/inetcomm/imaptransport.c > @@ -0,0 +1,498 @@ > +/* > + * IMAP Transport > + * > + * Copyright 2008 Hans Leidekker for CodeWeavers > + * > + */ This one misses license information. (Patch is already committed though). -- Cheers, Paul.

1 0

Re: wine.inf: Add entry for fake wintab32.dll
by John Klehm 01 Oct '08

01 Oct '08

On Wed, Oct 1, 2008 at 1:05 PM, Andrew Nguyen <arethusa26(a)gmail.com> wrote: > --- > tools/wine.inf.in | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > Add entry for fake wintab32.dll We have a real wintab32.dll. What are you trying to fix? Cheers, --John

2 2

Re: winhttp: tests/server.c[new]: Add basic internal server test
by Zac Brown 01 Oct '08

01 Oct '08

Zac Brown wrote: > Add basic internal server test. Thanks to Hans for some help. > > > ------------------------------------------------------------------------ > > As a note, these tests pass on XP and 2003.

1 0

Re: wintab32: Avoid memorizing LOGCONTEXT struct
by Rob Shearman 01 Oct '08

01 Oct '08

2008/9/30 John Klehm <xixsimplicityxix(a)gmail.com>: > + TRACE("Name: %s, Options: %x, Status: %x, Locks: %x, MsgBase: %x, Device: %x, PktRate: %x, %x%s, %x%s, %x%s, BtnDnMask: %x, BtnUpMask: %x, InOrgX: %i, InOrgY: %i, InOrgZ: %i, InExtX: %i, InExtY: %i, InExtZ: %i, OutOrgX: %i, OutOrgY: %i, OutOrgZ: %i, OutExtX: %i, OutExtY: %i, OutExtZ: %i, SensX: %i, SensY: %i, SensZ: %i, SysMode: %i, SysOrgX: %i, SysOrgY: %i, SysExtX: %i, SysExtY: %i, SysSensX: %i, SysSensY: %i\n", Even in the age of widescreen displays, a line of 421 columns in length is too long... -- Rob Shearman

2 1

Re: wininet: Add tests for InternetTimeFromSystemTimeW with insufficient buffer.
by Rob Shearman 01 Oct '08

01 Oct '08

2008/10/1 Rob Shearman <robertshearman(a)gmail.com>: > --- > dlls/wininet/tests/http.c | 18 ++++++++++++++++++ > 1 files changed, 18 insertions(+), 0 deletions(-) > Please ignore this message. There are several problems with the patch, one of which is that the tests weren't run with Wine and currently fail. -- Rob Shearman

1 0

Marcus pictures
by Marcus Meissner 01 Oct '08

01 Oct '08

Hi, http://gallery.kuschelt.net/main.php?g2_view=core.ShowItem&g2_itemId=163676… has my pictures of Wine Conf. Ciao, Marcus

1 0

Discussion of bug versions
by Jeremy White 01 Oct '08

01 Oct '08

We discussed bugzilla versions at Wineconf, re: http://bugs.winehq.org/show_bug.cgi?id=12728 There were several points of consensus. First, it would be helpful if we could reduce the number of versions visible in the drop down box when entering a new bug. That would seem to require a bugzilla code change, though. Anyone know of an easy way to accomplish this? Second, we'd like new bug reporters to not be able to use the 'CVS/GIT' version choice, but to instead be encouraged to report the current version. (wine --version reports something that is easy to match up to the choices). Obviously, it seems that it would be really nice if, when we did that, it was a lot easier to find 1.1.5... Cheers, Jeremy

10 10

Re: [2/2] runtest: Let the test program handle the lack of a test name.
by Rob Shearman 01 Oct '08

01 Oct '08

2008/9/30 Dylan Smith <dylan.ah.smith(a)gmail.com>: > -exec $WINETEST_WRAPPER "$topobjdir/wine" "$program" "$infile" "$@" > +exec $WINETEST_WRAPPER "$topobjdir/wine" "$program" $infile $@ It looks like this will cause problems now if $infile contains spaces or if any of the arguments in $@ contain spaces. -- Rob Shearman

2 1

Re: add ctxtcall.idl (resend)
by Rob Shearman 01 Oct '08

01 Oct '08

2008/9/28 Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk>: > Hi, this is part of bug http://bugs.winehq.org/show_bug.cgi?id=13462. > test shows the interface is available (in winxp) , test follows This patch looks good to me. -- Rob Shearman

1 0

Re: Noisy FIXME
by Rob Shearman 01 Oct '08

01 Oct '08

2008/9/28 Dimi Paun <dimi(a)lattica.com>: > Silence noisy FIXME about uninteresting ExtTextOut() flags. > Keep the FIXME in the string to make it easily grep-able. > > diff --git a/dlls/gdi32/font.c b/dlls/gdi32/font.c > index 1e8cac3..c3e4840 100644 > --- a/dlls/gdi32/font.c > +++ b/dlls/gdi32/font.c > @@ -1657,7 +1657,7 @@ BOOL WINAPI ExtTextOutW( HDC hdc, INT x, INT y, UINT flags, > breakRem = dc->breakRem; > > if (flags & (ETO_NUMERICSLOCAL | ETO_NUMERICSLATIN | ETO_PDY)) > - FIXME("flags ETO_NUMERICSLOCAL | ETO_NUMERICSLATIN | ETO_PDY unimplemented\n"); > + TRACE("FIXME: flags ETO_NUMERICSLOCAL | ETO_NUMERICSLATIN | ETO_PDY unimplemented\n"); I think the FIXME should at least by fired once since some of the flags may cause hard-to-debug display issues. -- Rob Shearman

1 0

WineConf 2008 Keynote Video
by Jeremy Newman 30 Sep '08

30 Sep '08

http://www.winehq.org/site/wineconf/media -Newman

1 0

Re: OpenGL child windows
by Florian Köberle 30 Sep '08

30 Sep '08

Hello Chris Robinson, A long time ago you wrote in http://www.winehq.org/pipermail/wine-devel/2007-October/059550.html that you got my example program running: "If I force offscreen rendering and add the flag, the demo works." Could you have a look at the following bug report and may explain how to "force offscreen rendering"? http://bugs.winehq.org/show_bug.cgi?id=15232 Best regards, Florian Köberle

2 1

RE: IWineD3DResourceImpl_GetPriority/SetPriority
by Stefan Dösinger 30 Sep '08

30 Sep '08

Can you add a test for the default priority? From: wine-patches-bounces(a)winehq.org [mailto:wine-patches-bounces@winehq.org] On Behalf Of Kjell Rune Skaaraas Sent: Tuesday, September 30, 2008 11:18 AM To: wine-patches(a)winehq.org Subject: Re: IWineD3DResourceImpl_GetPriority/SetPriority Hello, Please don't use the previously attached patch since it makes changes to exception.c that should never have been part of the patch. Corrected patch is attached to this mail. Regards, Kjell Rune _____ Alt i ett. Få Yahoo! <http://no.mail.yahoo.com> Mail med adressekartotek, kalender og notisblokk.

1 0

make test .. monthcal new failure
by Marcus Meissner 30 Sep '08

30 Sep '08

Hi, I get these new errors after todays git update: monthcal.c:677: Test failed: Expected 65542, got 65536 monthcal.c:677: Test failed: Expected 65542, got 65536 monthcal.c:677: Test failed: Expected 65542, got 65536 monthcal.c:677: Test failed: Expected 65542, got 65536 monthcal.c:677: Test failed: Expected 65542, got 65536 err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000001 lp=00000000 err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000000 lp=00000000 err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000001 lp=00000000 monthcal.c:956: Tests skipped: cannot perform today link test make: *** [monthcal.ok] Fehler 5 Ciao, Marcus

2 2

Re: d3d8: Fix incorrect ordering of brackets in IDirect3DVertexShader8Impl_GetDevice.
by Henri Verbeet 30 Sep '08

30 Sep '08

2008/9/30 Rob Shearman <robertshearman(a)gmail.com>: > The comparison should be (D3D_OK == hr && myDevice), not (D3D_OK == > (hr && myDevice)). > d3d8 and d3d9 are pretty bad at stuff like this, unfortunately. Strictly speaking we should also compare to WINED3D_OK instead of D3D_OK here, but they have the same values.

2 1

Bad patch, what's the procedure?
by Kjell Rune Skaaraas 30 Sep '08

30 Sep '08

Hello,I've submitted a patch to wine-patches for IWineD3DResourceImpl_GetPriority/SetPriority that's incorrect (it makes changes to exception.c which shouldn't be there, they were just part of me trying to debug something). Is there anything like a cancel procedure I should do, or should I just fix up the patch and submit it again? Oh yeah and this will teach me to read the diff more thoroughly next time...Regards,Kjell Rune _________________________________________________________ Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og notisblokk. http://no.mail.yahoo.com

2 1

re: Detecting Wine
by Dan Kegel 30 Sep '08

30 Sep '08

Mark W. wrote: >As part of the installation process, under Windows our >program does a full-disk search of all local hard drives, >but ignoring network drives and removable media. >Under Wine, this doesn't work too well, as there's not >a one-to-one mapping between disks and drive letters, >and there's usually at least one way to access the entire *nix >filesystem. If someone's got a few network drives mounted, >the installer could spend hours searching them. We have a similar issue in Picasa. There, we try to default to just searching the user's home directory when running on Wine, and I think we blacklist known do-not-search directories like /proc. We have gone back and forth about whether to follow symlinks; there are often symlinks to network filesystems inside people's home directories. The right thing to do is probably something like: a) get the set of initial seeds by using the output of the 'mount' command and ignoring anything with a type field that is not a known local filesystem type (e.g. ext2, ext3, ufs, reiserfs, xfs); you'll need to expand this whitelist as customers complain about their pet filesystems (And you'll need to ignore any that can't be mapped to Wine paths, but people usually map Z: to /.) (You could use /proc/mounts under Linux, but better to use the standardized 'mount' command or maybe /etc/mtab, otherwise your code will break on MacOSX or Solaris.) b) when recursing, and you find a reparse point aka symlink, check the filesystem type of the symlink destination before following it. You might need to get bug http://bugs.winehq.org/show_bug.cgi?id=12401 fixed before this works the windows way, but you could probably do something wine-specific now by converting each directory path you encounter into a unix path, then using a unix api to check whether it's a symbolic link. Bleah. Best way to do that is to patch wine, and then you're part way to fixing bug 12401 :-) c) beware: Wine's implementation of FindFirstChange/FindNextChange does not really work if you ask it to monitor two different names for the same directory. See http://bugs.winehq.org/show_bug.cgi?id=7216 - Dan

1 0

Re: wined3d: Convert between A8R8G8B8 and X8R8G8B8
by Kjell Rune Skaaraas 30 Sep '08

30 Sep '08

Henri Verbeet wrote: >2008/9/29 Kjell Rune Skaaraas <kjella79 at yahoo.no>: >> Hello, >> >> A simple patch which adds converting between A8R8G8B8 and X8R8G8B8 that >> gives me one less warning to deal with while trying to make a game function. >> It zeroes out the alpha channel to be on the safe side, though it should >> never be used in the destination format anyway. >> >What does this fix, in practice? A D3D surface is being converted from A8R8G8B8 to X8R8G8B8 and wine warns that there is no conversion function, so I added it. In practise it doesn't matter because the RGB parts are still valid, so nothing should change unless any app uses the X8 bits = unused. Just fixed a warning and was the right skill level for my first wine patch. I'm working on one that does a little more real work now. Regards, Kjell Rune _________________________________________________________ Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og notisblokk. http://no.mail.yahoo.com

1 0

OT [ReactOS-related] Win32s API dosumentation
by Wesley Parish 30 Sep '08

30 Sep '08

Hi. I'm wondering about doing a quick-n-dirty Win32s re-implementation for ReactOS, following an email [last-year-this-year] discussion on the ReactOS dev list. Based on Wine, of course, and operating as Windows-on-Windows in the Microsoft OS of the same name. Does anyone know where to get copies of the Win32s documentation, such as it is? Thanks Wesley Parish -- Clinersterton beademung, with all of love - RIP James Blish ----- Gaul is quartered into three halves. Things which are impossible are equal to each other. Guerrilla warfare means up to their monkey tricks. Extracts from "Schoolboy Howlers" - the collective wisdom of the foolish. ----- Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people.

2 2

Re: richedit: Fixed test failing on windows version with larger font sizes
by Juan Lang 29 Sep '08

29 Sep '08

Hi Dylan, @@ -402,6 +401,10 @@ static void test_EM_SCROLLCARET(void) "ff\n" "gg\n" "hh\n"; + HWND hwndRichEdit = CreateWindow(RICHEDIT_CLASS, NULL, + ES_MULTILINE|WS_POPUP|WS_HSCROLL|WS_VSCROLL|WS_VISIBLE, + 0, 0, 200, 80, NULL, NULL, hmoduleRichEdit, NULL); + ok(hwndRichEdit != NULL, "class: %s, error: %d\n", RICHEDIT_CLASS, (int) GetLastError()); It seems to me in this case that describing the relevant parameters to CreateWindow--I assume just height?--and why they're important to the test might help people not break the test in the future. --Juan

1 0

Free apps bundled with msvcp71?
by Dan Kegel 29 Sep '08

29 Sep '08

Adobe Contribute 4, released in Nov 2006 or so, had a nice online trial at http://trials.adobe.com/Applications/Contribute/Adobe_Contribute_4_Win/Adob… and still online, I think, at http://www.soft32.com/download/63-129953-1/Adobe_Contribute_4_Win.exe Starting it fails with err:module:import_dll Library MSVCP71.dll (which is needed by L"C:\\Program Files\\Adobe\\Contribute 4\\CoreTypes.dll") not found Wine has a nice implementation of msvcr71.dll, but not the C++-oriented msvcp71.dll, nor is it likely to get one soon. This brings back the question: what's a good place to legally and freely download an application bundled with a full set of msvcp71.dll et al? Ideally something at Microsoft.com and/or something small and suitable for use in winetricks. Any ideas? - Dan

2 3

Re: Patchwatcher: patchwatcher bug: richedit: Fixed test failure that happend on older builds ofriched20.dll
by Dan Kegel 29 Sep '08

29 Sep '08

Ignore this; patchwatcher probably got confused by the word difference at the beginning of a line. This is a known and very lame bug... On Mon, Sep 29, 2008 at 10:37 AM, Patchwatcher <patchwatcher(a)kegel.com> wrote: > Hi! This is the experimental automated wine patchwatcher thingy. > The latest git sources were built and tested with your patch > "richedit: Fixed test failure that happend on older builds ofriched20.dll" > Result: the patch patchwatcher bug. > > You can retrieve the full build results at > http://kegel.com/wine/patchwatcher/results/2284.log > and see the patch as parsed at > http://kegel.com/wine/patchwatcher/results/2284.txt > See > http://kegel.com/wine/patchwatcher/results > for more info. > >

1 0

Bug squish party!
by Dan Kegel 29 Sep '08

29 Sep '08

All the cool kids at Wineconf are busily fixing "make test" failures. If you're not at Wineconf, you can still play along! See http://wiki.winehq.org/BugSquishParty for details and how to claim a bug to fix.

2 1

DIB engine status
by Huw Davies 29 Sep '08

29 Sep '08

Hi folks, Here's an update on the DIB engine that I've been working on for the last few months. This work has been made possible by the generosity of Google - so thanks go to them and of course to Dan. You can find the code at http://repo.or.cz/w/wine/dibeng-hd.git What's supported ================ - All dib section depths (including BI_BITFIELD support). - Single pixel solid and dashed pens. - The 16 rop2s. - Solid and dib pattern brushes. - A brunch of primitives for drawing onto all dib section surfaces. - GDI32 apis: LineTo, Rectangle and PatBlt. - An extensive test suite for all of the above. What needs to be done ===================== - Blitting (eg BitBlt, StretchBlt and StretchDIBits) - I have some hacks for these in my tree. - ExtTextOut - Many more GDI32 apis - a lot of these should be easy given that we have a set of underlying dib drawing primitives. - Non-MM_TEXT mapping modes and world transforms. - The initial interaction with GDI32 in BITMAP_SelectObject is hacky and needs some work. - Lots more... Note that at the moment it's essentially useless because of the lack of blitting, so unless you fancy hacking on that yourself then you probably don't want to bother fetching the tree. I'm going to stop working on this for a while (lots of fun Outlook 2007 bugs for me to look at!), but will endeavour to keep the tree up to date with respect to WineHQ. If someone *does* want to hack on this then feel free to send me patches! Thanks, Huw. -- Huw Davies huw(a)codeweavers.com

6 8

Wineconf-er caught at security.
by Zachary Goldberg 29 Sep '08

29 Sep '08

I was stopped at security for carrying 'a wine bottle' through security. Upon a brief inspection it was revealed that my super-awesome crossover t-shirts had tripped the machine due to their lusciously exquisite compressed shape. Whoops. --Zach

3 2

Wineconf photos
by Zachary Goldberg 29 Sep '08

29 Sep '08

http://picasaweb.google.com/zgold550/Wineconf2008 (a.k.a. an exhibit in terrible white balance). I haven't edited any of the shots, just uploaded straight from Picasa. If you want a full 10MP RAW or JPG of any of the shots with some actual editing / touchups let me know. -Zach

1 0

Re: DirectDraw: fix compilation on mingw
by Henri Verbeet 29 Sep '08

29 Sep '08

2008/9/28 Roderick Colenbrander <thunderbird2k(a)gmx.net>: > From: Roderick Colenbrander <roderick(a)roderick-laptop.(none)> You're certainly not the only one who does this, but you're supposed to have a proper email address in there.

1 0

Re: wined3d: Convert between A8R8G8B8 and X8R8G8B8
by Henri Verbeet 29 Sep '08

29 Sep '08

2008/9/29 Kjell Rune Skaaraas <kjella79(a)yahoo.no>: > Hello, > > A simple patch which adds converting between A8R8G8B8 and X8R8G8B8 that > gives me one less warning to deal with while trying to make a game function. > It zeroes out the alpha channel to be on the safe side, though it should > never be used in the destination format anyway. > What does this fix, in practice?

1 0

Re: dsound: GetVolume should check error from driver (resend)
by Kirill K. Smirnov 29 Sep '08

29 Sep '08

Hi, Dan! >ALSA_CheckSetVolume returns right early because hctl is NULL, >but that error is not propagated through dsound properly. >While we should figure out the alsa part, for now, let's at least >propagate the error, and skip tests that can't be done without >sensing volume. >If this patch is accepted, I'll send a second one to add a >similar skip() to tests/ds3d8.c. 0) Prehistory. I've fought with this issue too and sent a patch: http://www.winehq.org/pipermail/wine-patches/2008-July/058124.html Reply was: http://www.winehq.org/pipermail/wine-devel/2008-July/067803.html 1) About your patch. There are 4 places which suffers from this issue: @@ -599,9 +599,14 @@ static HRESULT WINAPI PrimaryBufferImpl_SetVolume( @@ -640,9 +645,14 @@ static HRESULT WINAPI PrimaryBufferImpl_GetVolume( @@ -924,9 +934,14 @@ static HRESULT WINAPI PrimaryBufferImpl_SetPan( @@ -965,9 +980,14 @@ static HRESULT WINAPI PrimaryBufferImpl_GetPan( Your patch fixes only two of them: @@ -640,7 +641,12 @@ static HRESULT WINAPI PrimaryBufferImpl_GetVolume( @@ -965,7 +973,11 @@ static HRESULT WINAPI PrimaryBufferImpl_GetPan( 2) About this bug. This behaviour was introduced by this patch: Author: Francois Gouget <fgouget(a)codeweavers.com> Date: 23.07.2004 23:06:31 Parent: Sort the winmm test formats by increasing sampling rate. Child: Added Italian strings. Branch: master (ntdll: Add stubbed implementations for NtQueryEaFile and...) origin (ntdll: Add stubbed implementations for NtQueryEaFile and...) Follows: wine-20040716 (Release 20040716.) Precedes: wine-20040813 (Release 20040813.) Fix the volume and balance of primary buffers so it is the system's volume and balance, like on Windows. In that time both alsa/oss drivers asked dsound to open mmdevice by setting DSDDESC_DOMMSYSTEMOPEN flag, so it was correct. But three years later, alsa driver stopped to use mmsystem: Author: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> Date: 02.06.2007 19:03:24 Parent: rsaenh: Allow CRYPT_NEWKEYSET and CRYPT_VERIFYCONTEXT at... Child: mshtml: Use the implementation of IHlink in hlink.dll ins... Branch: master (ntdll: Add stubbed implementations for NtQueryEaFile and...) origin (ntdll: Add stubbed implementations for NtQueryEaFile and...) Follows: wine-0.9.38 (Release 0.9.38.) Precedes: wine-0.9.39 (Release 0.9.39.) winealsa: Detach directsound implementation from waveout implementation. As far as I understand, the most correct way to fix this issue is to force alsa (and others) drivers to use DSDDESC_DOMMSYSTEMOPEN flag. Reporting error to high-level (as you and Alexandre suggest) or using default values (as I tried) are just hiding the bug instead of fixing it. I tried this last way, but alsa began to complain: "Why are we called with DirectSound flag? It doesn't use MMSYSTEM any more" Thus I stopped fighting and switched to bug-free OSS ;-) -- Kirill

1 0

Getting Coverity access
by Juan Lang 28 Sep '08

28 Sep '08

As we're talking about this at WineConf and not everyone has an account, you can get one by emailing scan-admin(a)coverity.com and asking. There are fewer than 100 bugs that we haven't looked at it, and I'd appreciate the help! --Juan

2 1

Re: [PATCH 1/2] gdiplus: Allocate enough space for BITMAPINFO in GdipCreateTextureIA.
by Nikolay Sivov 28 Sep '08

28 Sep '08

Lei Zhang wrote: > @@ -512,8 +512,11 @@ GpStatus WINGDIPAPI GdipCreateTextureIA(GpImage *image, > IPicture_get_CurDC(image->picture, &hdc); > bm_is_selected = (hdc != 0); > > - bmi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER); > - bmi.bmiHeader.biBitCount = 0; > + pbmi = GdipAlloc(sizeof(BITMAPINFOHEADER) + 256 * sizeof(RGBQUAD)); Why 256?

3 2

comctl32:listview crash on Win98
by Francois Gouget 28 Sep '08

28 Sep '08

Listview has a test to ensure that sending a LVM_SETIMAGELIST between WM_NCCREATE and WM_CREATE works fine. The problem is that this causes the conformance test to crash on my Windows 98 OSR0 VM. Right on this line: static LRESULT CALLBACK create_test_wndproc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) { [...] return CallWindowProc(listviewWndProc, hwnd, uMsg, wParam, lParam); } I cannot check here but the logs from Windows 95 VM also really look like it crashes there. So I suspect this happens on all comctl32.dll < 5.0. The problem is I'm not sure how to check for this so I can skip the test. Checking the Windows or comctl32 version seems likely to be rejected. Any other suggestion? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

1 0

Re: howto fix bug 13462
by Louis. Lenders 28 Sep '08

28 Sep '08

Rob Shearman <robertshearman <at> gmail.com> writes: > > 2008/9/15 Louis Lenders <xerox_xerox2000 <at> yahoo.co.uk>: > > Rob Shearman <robertshearman <at> gmail.com> writes: > I suggest you write a test case that replicates what the > application does and either send it to wine-patches > with appropriate todo_wine's or attach it to the bug. > > Well, it looks like the app is only checking if the uuid of the > interface is defined using Context_QueryInterface, > and that's about it. > It doesn't really seem to try to use anything from it, as > Erich's initial hack is already enough to get the apps running as > well (this one:http://bugs.winehq.org/attachment.cgi?id=13379) > > That's fine. You can still add a test that does the same > > as what the app does. > Hi, as there isn't really much activity in the bug (understatement haha) i tried to hack up a test myself. Rob, is the test below more or less what you meant? or am i way off... (The test passes on winxp, and fails in wine, so afaics shows we should support the interface ) diff --git a/dlls/ole32/tests/compobj.c b/dlls/ole32/tests/compobj.c index bdc34d9...49c3276 100644 --- a/dlls/ole32/tests/compobj.c +++ b/dlls/ole32/tests/compobj.c @@ -28,6 +28,7 @@ #include "objbase.h" #include "shlguid..h" #include "urlmon.h" /* for CLSID_FileProtocol */ +//#include "ctxtcall.h" #include "wine/test.h" @@ -61,6 +62,15 @@ static const IID IID_IWineTest = 0x4fd0, {0xa1, 0xa2, 0x5d, 0x5a, 0x36, 0x54, 0xd3, 0xbd} }; /* 5201163f-8164-4fd0-a1a2-5d5a3654d3bd */ + +static const IID IID_IContextCallback = +{ + 0x000001da , + 0x0000, + 0x0000, + {0xc0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46 } +}; + static const CLSID CLSID_WineOOPTest = { 0x5201163f, 0x8164, @@ -1022,6 +1032,26 @@ static void test_CoGetObjectContext(void) CoUninitialize(); } +static void test_ContextCallBack(void) +{ + + HRESULT hr; + IComThreadingInfo *pComThreadingInfo; + + if (!pCoGetObjectContext) + { + skip("CoGetObjectContext not present\n"); + return; + } + + pCoInitializeEx(NULL, COINIT_APARTMENTTHREADED); + + hr = pCoGetObjectContext(&IID_IContextCallback, (void **)&pComThreadingInfo); + + ok_ole_success(hr, "CoGetObjectContext"); + CoUninitialize(); +} + START_TEST(compobj) { HMODULE hOle32 = GetModuleHandle("ole32"); @@ -1050,4 +1080,5 @@ START_TEST(compobj) test_registered_object_thread_affinity(); test_CoFreeUnusedLibraries(); test_CoGetObjectContext(); + test_ContextCallBack(); }

4 4

Re: user32/tests: Move shell test to the end - killing explorer affects lots of tests
by Dmitry Timoshkov 28 Sep '08

28 Sep '08

Vitaliy Margolen <wine-patches(a)kievinfo.com> wrote: > This fixes all win tests except 2 on win2k. If it will affect other test(s) > following win test then we either shouldn't kill explorer or restart it or > more correctly configured shell. Probably adding a comment requesting to keep the test at the end would be a good idea. -- Dmitry.

1 0

Re: [PATCH] shell32: print the correct GUIDs in the shellpath tests.
by Juan Lang 28 Sep '08

28 Sep '08

Hi Reece, I'm not nak'ing your patch. I just wanted to point out a simpler way: -static const char *printGUID(const GUID *guid) +static char *printGUID(const GUID *guid) { - static char guidSTR[39]; + char *guidSTR = HeapAlloc(GetProcessHeap(), 0, 39); Rather than allocating the necessary buffer, you can pass a pointer to a buffer to printGUID, and have printGUID return that buffer. Have the caller declare two GUID buffers, and pass one for the expected value and the other for the received value. Cheers, and thanks for looking into the failing tests, --Juan

3 4

Patchwatcher: boldly going where MS has gone before
by Dan Kegel 28 Sep '08

28 Sep '08

Pre-commit tests were done commonly at Microsoft as early as 2001 by a system named Gauntlet, see http://blogs.msdn.com/misampso/archive/2005/03/14/395374.aspx http://blogs.msdn.com/vcblog/archive/2006/11/02/gauntlet-a-peek-into-visual… Well, better late than never!

1 0

RFC: Adding annotations to function declarations to improve static analysis
by Rob Shearman 28 Sep '08

28 Sep '08

Hi all, This will be talked about in more detail at WineConf tomorrow, but I just thought I'd throw this out there as a bit of background to any discussions. Adding annotations to function declarations allows Prefast to pick up certain classes of bugs with varying degrees of false positives. In particular, with patches like the attached applied byte-count/element-count mismatches can be detected with no false positives and relatively few false positives for off-by-one errors and other buffer overruns. Whilst this could be maintained outside of the main Wine tree it would be more convenient in terms of automation of Prefast runs if a vanilla Wine tree can be used (i.e. the annotation patches are in the official tree). -- Rob Shearman

3 3

Re: [WineHQ] Remove google adds box
by Tom Wickline 28 Sep '08

28 Sep '08

Can I object the removal? There will be a WineConf next year right? On Sat, Sep 27, 2008 at 2:28 PM, Zachary Goldberg <zgold(a)bluesata.com> wrote: > Was for sponsoring WineConf. > > > > -- http://www.wine-reviews.net/

2 1

Re: mlang: test, make sure UNICODE->1252 is convertable before failing when we cannot convert. (this fixes the tests on japanese windows installs)
by Aric Stewart 27 Sep '08

27 Sep '08

Sorry all, this patch is clearly incorrect. I am continuing to try to find out why these test fail on my windows 2000 japanese vm. -aric Aric Stewart wrote: > --- > dlls/mlang/tests/mlang.c | 100 > +++++++++++++++++++++++++++++----------------- > 1 files changed, 63 insertions(+), 37 deletions(-) > > > > ------------------------------------------------------------------------ > >

1 0

Re: mlang: tests update IMultiLanguage2_GetRfc1766FromLcid can return S_FALSE on partial name matching so deal with this properly
by Rob Shearman 27 Sep '08

27 Sep '08

2008/9/27 Aric Stewart <aric(a)codeweavers.com>: > + if (hr != S_FALSE) > + /* > + * this happens when 'kok' instead matches to a different Rfc1766 name > + * for example 'ko' so it is not a falure but does not give us what "falure" -> spelling mistake > + * we are looking for > + */ > + { Slight style issue - comment between if statement and open block character doesn't look very nice. -- Rob Shearman

1 0

re: Compiling WINE from source - Documentation needs to be updated?
by Dan Kegel 27 Sep '08

27 Sep '08

And while we're on the subject, is "make depend" really needed anymore? I thought it happened automatically.

3 3

WineConf
by Zachary Goldberg 27 Sep '08

27 Sep '08

If you're reading this now at Wineconf, shame on you.

2 1

Size of SUBHEAP in heap.c
by Martin Profittlich 27 Sep '08

27 Sep '08

Hello, when trying to fix an issue with Guitar Rig 3 on Wine (Bug 10129, "Guitar Rig 3 crashes"), I found out something odd: The crash is affected by the size of the SUBHEAP structure in dlls/ntdll/heap.c. Just by adding 8 unused bytes to SUBHEAP, GR3 does not crash anymore. Add another 8 bytes, GR3 crashes again, yet another 8 bytes - no crash and so on. The bug surfaced with this commit: [1d063ae18d990343fc077dcbf650add797924018] ntdll: Remove assumptions that the subheap is at the beginning of the memory block. I don't think the commit is the cause of the problem. It merely changed the size of SUBHEAP to a problematic value. I don't really understand the inner workings of heap.c. Does anyone have an idea what the cause might be, or where to look for more information? Cheers, Martin P.S. Link to the bug: http://bugs.winehq.org/show_bug.cgi?id=10129 -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

5 8

Compiling WINE from source - Documentation needs to be updated?
by chengas123 26 Sep '08

26 Sep '08

I see different advice on the best way to compile in various places. The http://www.winehq.org/site/docs/wineusr-guide/installing-wine-source user guide says to run: $ ./configure $ make depend $ make $ make install The README in the root of the source directory says to run: ./tools/wineinstall Which is the preferred method? Is there any difference? I'm thinking the docs in one of those two places probably needs to be updated. -- View this message in context: http://www.nabble.com/Compiling-WINE-from-source---Documentation-needs-to-b… Sent from the Wine - Devel mailing list archive at Nabble.com.

1 0

Re: LookupAccountNameW() use ACCOUNT_SIDS domain and name_use fields for well known SIDs
by Rob Shearman 26 Sep '08

26 Sep '08

2008/9/26 Paul Bryan Roberts <pbronline-wine(a)yahoo.co.uk>: > @@ -2532,11 +2532,30 @@ BOOL WINAPI LookupAccountNameW( LPCWSTR > lpSystemName, LPCWSTR lpAccountName, PSI > { > if (!strcmpW(lpAccountName, ACCOUNT_SIDS[i].account)) > { > - if (*cchReferencedDomainName) > - *ReferencedDomainName = '\0'; > - *cchReferencedDomainName = 0; > - *peUse = SidTypeWellKnownGroup; > - return CreateWellKnownSid(ACCOUNT_SIDS[i].type, NULL, Sid, > cbSid); > + ret = CreateWellKnownSid(ACCOUNT_SIDS[i].type, NULL, Sid, > cbSid); > + > + domainName = ACCOUNT_SIDS[i].domain; > + nameLen = strlenW(domainName); > + > + if (*cchReferencedDomainName <= nameLen && > ReferencedDomainName) > + { > + SetLastError(ERROR_INSUFFICIENT_BUFFER); > + nameLen += 1; > + ret = FALSE; > + } > + else if (ReferencedDomainName && domainName) > + { > + strcpyW(ReferencedDomainName, domainName); > + } > + > + *cchReferencedDomainName = nameLen; > + > + if (ret) > + { > + *peUse = ACCOUNT_SIDS[i].name_use; You could move this into the else block above. > + } > + > + return ret; > } > } -- Rob Shearman

1 0

Re: LookupAccountNameW() any account but first user rejected
by Rob Shearman 26 Sep '08

26 Sep '08

2008/9/26 Paul Bryan Roberts <pbronline-wine(a)yahoo.co.uk>: > + if (!ADVAPI_IsLocalComputer(lpSystemName)) > + { > + /*FIXME("Only local computer supported!\n");*/ > + SetLastError(ERROR_NONE_MAPPED); > + return FALSE; > + } There's no need to comment this FIXME out. > @@ -2546,7 +2553,6 @@ BOOL WINAPI LookupAccountNameW( LPCWSTR lpSystemName, > LPCWSTR lpAccountName, PSI > if (!strcmpW(lpAccountName, ACCOUNT_SIDS[i].account)) > { > char sidBuffer [SECURITY_MAX_SID_SIZE]; > - > size_t sidLen = SECURITY_MAX_SID_SIZE; You should combine this whitespace change into the patch that introduces the whitespace. > > ret = CreateWellKnownSid(ACCOUNT_SIDS[i].type, NULL, sidBuffer, > &sidLen); > @@ -2583,6 +2589,26 @@ BOOL WINAPI LookupAccountNameW( LPCWSTR lpSystemName, > LPCWSTR lpAccountName, PSI > } > } > > + > + { > + WCHAR userName [UNLEN + 1]; > + size_t nameLen = UNLEN + 1; Don't create a block for no reason. Please make sure you're not using excessive stack space in this function with all of these buffers on the stack. Also, nameLen should be of type DWORD instead of size_t, which is platform dependent and might not match the type of DWORD and cause warnings when passing the address of the parameter to the function below. > + > + ret = GetUserNameW(userName, &nameLen); > + > + if (ret && strcmpW(lpAccountName, userName) != 0) > + { > + /* FIXME("Only first user account supported!\n"); */ > + SetLastError(ERROR_NONE_MAPPED); > + ret = FALSE; > + } > + > + if (!ret) > + { > + return ret; > + } > + } > + -- Rob Shearman

1 0

Re: Patchwatcher: failed to apply: LookupAccountNameW() passes Expected SidTypeUser test
by Dan Kegel 26 Sep '08

26 Sep '08

Paul Bryan Roberts wrote: > This is the SECOND of a series of NINE patches ... When you send a series of 9 patches that depend on each other, please number them 1/9, 2/9, ... 7/9 in the subject line. Otherwise patchwatcher will try to apply each patch independently to current git, which won't work too well. Also, please make sure that tests still pass after each patch in the series. - Dan On Fri, Sep 26, 2008 at 4:06 AM, Patchwatcher <patchwatcher(a)kegel.com> wrote: > Hi! This is the experimental automated wine patchwatcher thingy. > The latest git sources were built and tested with your patch > "LookupAccountNameW() passes Expected SidTypeUser test" > Result: the patch failed to apply. > > You can retrieve the full build results at > http://kegel.com/wine/patchwatcher/results/2195.log > and see the patch as parsed at > http://kegel.com/wine/patchwatcher/results/2195.txt > See > http://kegel.com/wine/patchwatcher/results > for more info. > >

1 0

Re: [3/5] secur32: Basic implementation of schannel AcquireCredentialsHandle/FreeCredentialsHandle
by Rob Shearman 26 Sep '08

26 Sep '08

2008/9/22 Henri Verbeet <hverbeet(a)gmail.com>: > +static ULONG_PTR schan_alloc_handle(void *object, enum schan_handle_type type) > +{ > + struct schan_handle *handle; > + > + if (schan_free_handles) > + { > + /* Use a free handle */ > + handle = schan_free_handles; > + if (handle->type != SCHAN_HANDLE_FREE) > + { > + ERR("Handle %d(%p) is in the free list, but has type %#x.\n", (handle-schan_handle_table), handle, handle->type); > + return -1; > + } Using a signed constant for an unsigned value isn't good practice. I'd recommend defining a constant at the top of the file like so: #define SCHANNEL_INVALID_HANDLE ~0UL And then using that everywhere that you use -1 now. -- Rob Shearman

2 1

Flaky test update
by Dan Kegel 25 Sep '08

25 Sep '08

Here's some data over 1042 test runs over the last three weeks, all on a dual core Ubuntu 8.04 linux box with a cheap nVidia GeForce 8500 GT graphics card. Three tests crashed from 1% to 10% of the time (as opposed to failed): ddraw 136 d3d9 48 d3d8 12 Three tests always failed: urlmon:protocol.c 1042 dsound:ds3d8.c 1042 dsound:ds3d.c 1042 Two tests usually failed: user32:msg.c 940 user32:input.c 756 Nine tests failed from 0.1% to 20% of the time. (Even tests that only fail once in a thousand runs are bad, since they cause spurious patch failure reports. I've blacklisted all the tests listed here, which means patchwatcher *ignores* these tests, even if they have valid failures.) comctl32:tooltips.c 206 user32:win.c 205 riched20:editor.c 174 kernel32:thread.c 124 wininet:http.c 59 ddraw:visual.c 7 advapi32:service.c 7 kernel32:debugger.c 2 urlmon:url.c 1 Of those nine test, the following six had a fairly small number of characteristic error messages: comctl32:tooltips.c riched20:editor.c kernel32:thread.c advapi32:service.c kernel32:debugger.c urlmon:url.c And here are those error messages: 206 comctl32:tooltips.c:223: Test failed: CustomDraw run 0 stages 0, expected 1 174 riched20:editor.c:5322: Test failed: Cursor is at 0 instead of 4 174 riched20:editor.c:5328: Test failed: Cursor is at 4 instead of 9 174 riched20:editor.c:5334: Test failed: Cursor is at 0 instead of 4 20 kernel32:thread.c:1181: Test failed: WaitForMultipleObjects failed 4 kernel32:thread.c:1181: Test failedthread.c:130: Test failed: WaitForSingleObject failed 4 kernel32:thread.c:1181: Test failedthread.c:144: Test failed: WaitForSingleObject failed 17 kernel32:thread.c:1184: Test failed: WaitForMultipleObjects failed 8 kernel32:thread.c:1184: Test failed: thread.c:144: Test failed: WaitForSingleObject failed 22 kernel32:thread.c:1186: Test failed: WaitForMultipleObjects failed 11 kernel32:thread.c:1186: Test failed: thread.c:144: Test failed: WaitForSingleObject failed 120 kernel32:thread.c:130: Test failed: WaitForSingleObject failed 1 kernel32:thread.c:130: Test failedthread.c:1181: Test failed: : WaitForSingleObject failed 134 kernel32:thread.c:144: Test failed: WaitForSingleObject failed 6 advapi32:service.c:2032: Test failed: Expected success 7 advapi32:service.c:2043: Test failed: Expected success 7 advapi32:service.c:2047: Test failed: Expected success 2 kernel32:debugger.c:300: Test failed: exit code = 00000000 1 urlmon:url.c:2125: Test succeeded inside todo block: unexpected OnProgress_CONNECTING 1 urlmon:url.c:2129: Test failed: expected OnProgress_SENDINGREQUEST 1 urlmon:url.c:2131: Test failed: expected OnResponse All the data is online at http://kegel.com/wine/patchwatcher/results if you want to look for details. - Dan

2 2

Re: [4/5] secur32: Allocate schannel client credentials
by Rob Shearman 25 Sep '08

25 Sep '08

2008/9/22 Henri Verbeet <hverbeet(a)gmail.com>: > @@ -47,6 +61,7 @@ struct schan_handle > struct schan_credentials > { > ULONG credential_use; > + gnutls_certificate_credentials_t credentials; > }; > > static struct schan_handle *schan_handle_table; > @@ -273,6 +288,7 @@ static SECURITY_STATUS schan_AcquireClientCredentials(const SCHANNEL_CRED *schan > } > > creds->credential_use = SECPKG_CRED_OUTBOUND; > + pgnutls_certificate_allocate_credentials(&creds->credentials); > > phCredential->dwLower = handle; > phCredential->dwUpper = 0; You should check the return value from gnutls_certificate_allocate_credentials, in case it fails and return a failure code to the caller. -- Rob Shearman

1 0

Re: [2/2] oleacc: implemented GetRoleText[A/W] with some tests
by Alexandre Julliard 25 Sep '08

25 Sep '08

Nikolay Sivov <bunglehead(a)gmail.com> writes: > +UINT WINAPI GetRoleTextA(DWORD role, LPSTR lpRole, UINT rolemax) > +{ > + UINT length; > + WCHAR *roletext; > + INT ret; > + > + TRACE("%u %p %u\n", role, lpRole, rolemax); > + > + length = GetRoleTextW(role, NULL, 0); > + > + if(!length || !lpRole) > + return length; You can't return the W length from the A function. > + roletext = HeapAlloc(GetProcessHeap(), 0, (length + 1)*sizeof(WCHAR)); > + if(!roletext) > + return 0; > + > + GetRoleTextW(role, roletext, length + 1); > + > + ret = WideCharToMultiByte( CP_ACP, 0, roletext, -1, lpRole, rolemax, NULL, NULL ); This won't return the correct length. Also you need to test how overflow should be handled. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: comctl32: comboex - fix some unintialized variables
by Dan Kegel 25 Sep '08

25 Sep '08

You wrote: > Fixes a compiler bug when using gcc-4.1 Wait- which is it, uninitialized variables (as your subject line said), or a compiler bug (as your message said)? If it's a compiler bug, which one? Probably http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639, right? Would setting the fields to any random value work as well? Can we instead tell the compiler to avoid the bug? (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9049 says there's no way yet to turn warnings on and off for individual functions, sadly, but we can do it for individual files.) A link to the bug report at gcc.gnu.org, and/or a wine wiki page about the general issue, would be helpful.

2 1

Re: msi: add stub for MsiDetermineApplicablePatches{A,W} (resend)
by James Hawkins 25 Sep '08

25 Sep '08

On Thu, Sep 25, 2008 at 2:10 AM, Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > Resend: removed spaces around brackets, and added also A-version. > > +/*********************************************************************** + * * MsiDetermineApplicablePatchesA [MSI.@] + * */ Copy/paste error? -- James Hawkins

1 0

Re: msi: add stub for MsiDetermineApplicablePatchesW
by Louis. Lenders 25 Sep '08

25 Sep '08

----- Original Message ---- From: James Hawkins <truiken(a)gmail.com> >The vast majority of this file does not put spaces around parenthesis, >so can you resend with that fixed? well, the last functions from that file do put the spaces around them, but if you prefer otherwise, i'll resend it >Also, why don't you add MsiDetermineApplicablePatchesA at the same time? i tried to keep patch as small as possible, and this is enough to fix the bug, but i'll add the A-version along the way in the resend. James Hawkins

1 0

Re: [2/2] oleacc: implemented GetRoleText[A/W] with some tests
by Dmitry Timoshkov 25 Sep '08

25 Sep '08

Nikolay Sivov <bunglehead(a)gmail.com> wrote: > +UINT WINAPI GetRoleTextA(DWORD role, LPSTR lpRole, UINT rolemax) > +{ > + UINT length; > + WCHAR *roletext; > + INT ret; > + > + TRACE("%u %p %u\n", role, lpRole, rolemax); > + > + length = GetRoleTextW(role, NULL, 0); > + > + if(!length || !lpRole) > + return length; This won't work for a multibyte locale. -- Dmitry.

1 0

RE: [5/5] wined3d: Handle texture coordinates the same way we handle other vertex attributes
by Stefan Dösinger 24 Sep '08

24 Sep '08

Here's a thought regarding handling the lack of GL_ARB_multitexture support. Since pretty much all cards out there have multitexture support(even my junky Mach64 card), we could just use one texcoord function array, and if multitextures are really not supported, use a wrapper function that calls the non-multitexture gl function and just drops the texture unit. That avoids the if check in this pretty performance critical part on probably all cards out there that are in use. > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Henri Verbeet > Sent: Wednesday, September 24, 2008 9:14 AM > To: wine-patches(a)winehq.org > Subject: [5/5] wined3d: Handle texture coordinates the same way we > handle other vertex attributes >

2 2

user32:input.c fails only when run from make?!
by Dan Kegel 24 Sep '08

24 Sep '08

Here's an odd one. On my Levnovo x60 running Hardy, with or without metacity-2.23.8 built from source, the user32 test input.c fails when run from make nearly all of the time, but doesn't fail if run standalone. The problem persists even with a trivial makefile, e.g. foo.ok: env WINETEST_DEBUG=1 WINETEST_PLATFORM=wine ~/wine-git/wine user32_test.exe.so input.c && touch foo.ok This usually fails with input.c:648: Test failed: 49: a1 from 00 -> 00 instead of 00 -> 80 or

1 1

Re: msi: add stub for MsiDetermineApplicablePatchesW
by James Hawkins 24 Sep '08

24 Sep '08

On Wed, Sep 24, 2008 at 1:12 PM, Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > This is the 2nd stub needed to let .net 2.0 SP1 installer finish fine. I'll > resend the first one (corrected) > The vast majority of this file does not put spaces around parenthesis, so can you resend with that fixed? +UINT WINAPI MsiDetermineApplicablePatchesW( LPCWSTR szProductPackagePath, + DWORD cPatchInfo, PMSIPATCHSEQUENCEINFOW pPatchInfo) Also, why don't you add MsiDetermineApplicablePatchesA at the same time? -- James Hawkins

1 0

Re: secur32: Fix a failing test in win95
by Paul Vriens 24 Sep '08

24 Sep '08

On Wed, Sep 24, 2008 at 10:06 AM, James Hawkins <jhawkins(a)codeweavers.com> wrote: > Hi, > > Changelog: > * Fix a failing test in win95. > > dlls/secur32/tests/main.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > -- > James Hawkins > But if the result is SEC_E_UNSUPPORTED_FUNCTION it's not broken is it? Shouldn't we use some kind of skip here? (The end result will be the same, as we should use win_skip, it just doesn't look correct). Cheers, Paul.

2 3

Re: d3dx9: Add d3dx9effect.h
by Alexandre Julliard 24 Sep '08

24 Sep '08

Busquets Pérez Luis C. <luiscar2001(a)yahoo.es> writes: > +typedef struct D3DXEFFECT_DESC { > + LPCSTR Creator; > + UINT Parameters; > + UINT Techniques; > + UINT Functions; > +} D3DXEFFECT_DESC, *LPD3DXEFFECT_DESC; > + > +typedef struct D3DXPARAMETER_DESC { > + LPCSTR Name; > + LPCSTR Semantic; > + D3DXPARAMETER_CLASS Class; > + D3DXPARAMETER_TYPE Type; > + UINT Rows; > + UINT Columns; > + UINT Elements; > + UINT Annotations; > + UINT StructMembers; > + DWORD Flags; > + UINT Bytes; > +} D3DXPARAMETER_DESC, *LPD3DXPARAMETER_DESC; > + > +typedef struct D3DXTECHNIQUE_DESC { > + LPCSTR Name; > + UINT Passes; > + UINT Annotations; > +} D3DXTECHNIQUE_DESC, *LPD3DXTECHNIQUE_DESC; > + > +typedef struct D3DXPASS_DESC { > + LPCSTR Name; > + UINT Annotations; > + CONST DWORD * pVertexShaderFunction; > + CONST DWORD * pPixelShaderFunction; > +} D3DXPASS_DESC, *LPD3DXPASS_DESC; > + > +typedef struct D3DXFUNCTION_DESC { > + LPCSTR Name; > + UINT Annotations; > +} D3DXFUNCTION_DESC, *LPD3DXFUNCTION_DESC; > + > +typedef interface ID3DXInclude *LPD3DXINCLUDE; A lot of these LP* types don't seem to exist in the PSDK. > +#define INTERFACE ID3DXEffect > +DECLARE_INTERFACE_(ID3DXEffect, ID3DXBaseEffect) If you derive from ID3DXBaseEffect you have to define that one first. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: Patchwatcher problems
by Dan Kegel 24 Sep '08

24 Sep '08

Andrew Fenn wrote: > I just submitted a patch to wine patches (Started implementing the > xinput library for xbox 360 joystick support ) and I believe patch > watcher failed for a few reasons. > >1) Although it applied my patch it didn't build it as >./tools/make_makefiles isn't called so it isn't built? I think make_makefiles is called: http://code.google.com/p/winezeug/source/browse/trunk/patchwatcher/patchwat… Maybe I should make the log more verbose... > 2) Patch watcher seems to fail because of another patch, perhaps the > latest known good build should be tested if the patch fails and then > compared with the first failed attempt? We don't accumulate patches. There was no other patch active when yours was tested. This was probably just a rare failure of a slightly flaky test. When I verify that tests are flaky, I add them to a blacklist. You just got unlucky, I think. Once you figure out why your patch didn't trigger your stuff to be built, resubmit... - Dan

3 3

Re: secur32: Fix compilation with GNU TLS 1.0.16.
by Henri Verbeet 24 Sep '08

24 Sep '08

2008/9/24 Francois Gouget <fgouget(a)free.fr>: > --- > > On my system I have libgnutls11-dev 1.0.16-14+b1 which has > gnutls_certificate_credentials but not the corresponding ..._t type. So > this patch lets it compile on my system. Hopefully it will still work > with the newer headers (otherwise we'll have to introduce a configure > check :-( ) > I don't think that'll work, this is what newer versions of gnutls have: struct gnutls_certificate_credentials_st; typedef struct gnutls_certificate_credentials_st *gnutls_certificate_credentials_t; typedef gnutls_certificate_credentials_t gnutls_certificate_server_credentials; typedef gnutls_certificate_credentials_t gnutls_certificate_client_credentials; gnutls_certificate_client_credentials and gnutls_certificate_server_credentials should be available in both versions though. Considering we're only setting client credentials anyway for the moment, just using gnutls_certificate_client_credentials would probably be fine.

1 1

Re: Call SetLastError() in ParseStringAclToAcl() to correct Conformance Test failure
by James Hawkins 24 Sep '08

24 Sep '08

On Wed, Sep 24, 2008 at 1:19 AM, Paul Bryan Roberts <pbronline-wine(a)yahoo.co.uk> wrote: > From 2f6d33f2d66e252bbd6ad3bc0f3e93a1fb780485 Mon Sep 17 00:00:00 2001 > From: Paul Bryan Roberts <pbronline-wine(a)yahoo.co.uk> > Date: Wed, 24 Sep 2008 06:57:33 +0100 > Subject: Call SetLastError() in ParseStringAclToAcl() to correct > Conformance Test failure > > --- > dlls/advapi32/security.c | 7 ++++++- > dlls/advapi32/tests/security.c | 1 - > 2 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/dlls/advapi32/security.c b/dlls/advapi32/security.c > index ef9ce6e..83bb08e 100644 > --- a/dlls/advapi32/security.c > +++ b/dlls/advapi32/security.c > @@ -3735,7 +3735,11 @@ static BOOL ParseStringAclToAcl(LPCWSTR > StringAcl, LPDWORD lpdwFlags, > TRACE("%s\n", debugstr_w(StringAcl)); > > if (!StringAcl) > - return FALSE; > + { > + SetLastError(ERROR_INVALID_PARAMETER); > + TRACE("StringAcl is NULL, returning FALSE\n"); > + return FALSE; > + } > You've added a change (above) that is not verified by a test. Please add one before making such a change. Also, that TRACE is highly superfluous; please remove it from the patch. -- James Hawkins

1 0

Re: secur32: Add kerberos tests. (try 3)
by Kai Blin 24 Sep '08

24 Sep '08

On Wednesday 24 September 2008 06:24:15 Kai Blin wrote: This breaks on Win2k3 and newer. It worked on XP, dammit. I'll have to poke this some more tomorrow. 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

Re: secur32: Add kerberos tests. (try 2)
by Kai Blin 24 Sep '08

24 Sep '08

On Wednesday 24 September 2008 05:32:20 Kai Blin wrote: Aw, coding while being jet-lagged sucks. I'll resend a version without warnings and memory leaks. 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

Re: secur32: Add kerberos tests.
by Kai Blin 24 Sep '08

24 Sep '08

On Wednesday 24 September 2008 04:18:42 Kai Blin wrote: Actually, never mind this one. I just realized one of the tests doesn't run on windows after all. 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.

1 0

What broken in ubuntu Wine packages?
by Vitaliy Margolen 24 Sep '08

24 Sep '08

Almost all bugs that come from Ubuntu users don't have usable backtraces. Instead they have this: Process of pid=0008 has terminated No process loaded, cannot execute 'echo Modules:' Cannot get info on module while no process is loaded Needless to say this doesn't help with troubleshooting the problem. Does anyone have a clue what might be the problem? Vitaliy.

6 12

Re: gdi32: "StretchDIBits" with value of zero for "xSrc" and "ySrc"
by Juan Lang 24 Sep '08

24 Sep '08

Hi Mathias, + * mkosch (2008/09/22) Please don't put such comments in source files, the source files aren't a changelog. + hProcessHeap = GetProcessHeap(); + assert(hProcessHeap != NULL); This assert is pointless, GetProcessHeap cannot reasonably fail. And more generally.. + assert(hDC != NULL); dont' use assert() in the tests, especially for conditions such as this which have nothing to do with the function you're testing. These will only fail in out-of-memory type situations, and many other things will fail before your particular test. So either assume that such basic functions will succeed, or use ok to check them if there's some reasonable probability they may fail, or use a combination of skip and return if one fails. Just please don't use so many asserts in the tests. + // Initializing random number generator: In the first place, such a comment is unnecessary, is it's quite clear what the following line does. In the second place, C++-style comments are not allowed in Wine source. --Juan

4 4

Re: wine.inf.in: create default key App Paths (and key for IEXPLORE)
by Louis. Lenders 23 Sep '08

23 Sep '08

----- Original Message ---- From: Alexandre Julliard <julliard(a)winehq.org> "Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> writes: > Hi, the key HKLM//Software\\Microsoft\\Windows\\CurrentVersion\\App Paths is needed by LexWare installer (bug http://bugs.winehq.org/show_bug.cgi?id=15347) > > This patch creates that key by default, but also creates the key for IEXPLORE along the way, needed to fix http://bugs.winehq.org/show_bug.cgi?id=7257. The key is present on a default winxp installation > > btw, was there anything wrong with this patch: > http://www.winehq.org/pipermail/wine-patches/attachments/20080918/e269df3c/… ? >Yes, it doesn't match the Windows definitions. And this patch doesn't >either. You really need to pay more attention to what you are doing. honestly, i'm trying to be as careful as i can. But I see an extra semi-colon crawled in in the patch for the registry key for App Paths. Is that what you meant with 'doesn't match Windows definitions'? Or is there something more wrong? As for the patch for MsiSetExternalUIRecord , i compared again with de definition at http://msdn.microsoft.com/en-us/library/aa370385(VS.85).aspx, but i don't see a problem there. Also i matched the definition for InstalluiHandlerRecord to the definition of InstalluiHandler in wine's msi.h, as that seemed more consistent to me. I'm happy to fix up any patch , if only i knew what was wrong with them... louis

2 1

Re: [4/5] wined3d: Merge pshader_hw_map2gl() and vshader_hw_map2gl()
by Ivan Gyurdiev 23 Sep '08

23 Sep '08

> This isn't the prettiest way to merge those functions, but it's a start Will you be cleaning this up further to get rid of the huge if-else ? I think at least all the MOV-specific stuff should go in its own instr. function. Ivan

2 1

Re: wine.inf.in: create default key App Paths (and key for IEXPLORE)
by Alexandre Julliard 23 Sep '08

23 Sep '08

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> writes: > Hi, the key HKLM//Software\\Microsoft\\Windows\\CurrentVersion\\App Paths is needed by LexWare installer (bug http://bugs.winehq.org/show_bug.cgi?id=15347) > > This patch creates that key by default, but also creates the key for IEXPLORE along the way, needed to fix http://bugs.winehq.org/show_bug.cgi?id=7257. The key is present on a default winxp installation > > btw, was there anything wrong with this patch: > http://www.winehq.org/pipermail/wine-patches/attachments/20080918/e269df3c/… ? Yes, it doesn't match the Windows definitions. And this patch doesn't either. You really need to pay more attention to what you are doing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Jacek Caban : jscript: Added with statement implementation.
by Michael Stefaniuc 23 Sep '08

23 Sep '08

Hello Jacek, this patch introduces a gcc warning: dlls/jscript/engine.c:954: warning: empty body in an if-statement Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: dfb867af56f4b15986482deef588d33d2458b101 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=dfb867af56f4b15986482deef… > > Author: Jacek Caban <jacek(a)codeweavers.com> > Date: Fri Sep 19 00:43:53 2008 +0200 > > jscript: Added with statement implementation. > > --- > > dlls/jscript/engine.c | 44 +++++++++++++++++++++++++++++++++++++++++--- > dlls/jscript/tests/lang.js | 4 ++++ > 2 files changed, 45 insertions(+), 3 deletions(-) > > diff --git a/dlls/jscript/engine.c b/dlls/jscript/engine.c > index f4b065f..b89d808 100644 > --- a/dlls/jscript/engine.c > +++ b/dlls/jscript/engine.c > @@ -924,12 +924,50 @@ HRESULT return_statement_eval(exec_ctx_t *ctx, statement_t *_stat, return_type_t > return S_OK; > } > > -HRESULT with_statement_eval(exec_ctx_t *ctx, statement_t *stat, return_type_t *rt, VARIANT *ret) > +/* ECMA-262 3rd Edition 12.10 */ > +HRESULT with_statement_eval(exec_ctx_t *ctx, statement_t *_stat, return_type_t *rt, VARIANT *ret) > { > - FIXME("\n"); > - return E_NOTIMPL; > + with_statement_t *stat = (with_statement_t*)_stat; > + exprval_t exprval; > + IDispatch *disp; > + DispatchEx *obj; > + VARIANT val; > + HRESULT hres; > + > + TRACE("\n"); > + > + hres = expr_eval(ctx, stat->expr, 0, &rt->ei, &exprval); > + if(FAILED(hres)) > + return hres; > + > + hres = exprval_to_value(ctx->parser->script, &exprval, &rt->ei, &val); > + exprval_release(&exprval); > + if(FAILED(hres)) > + return hres; > + > + hres = to_object(ctx, &val, &disp); > + VariantClear(&val); > + if(FAILED(hres)) > + return hres; > + > + obj = iface_to_jsdisp((IUnknown*)disp); > + IDispatch_Release(disp); > + if(!obj) { > + FIXME("disp id not jsdisp\n"); > + return E_NOTIMPL; > + } > + > + hres = scope_push(ctx->scope_chain, obj, &ctx->scope_chain); > + jsdisp_release(obj); > + if(FAILED(hres)); Not sure if the if should be just removed or the two statements swapped and become if(FAILED(hres)) jsdisp_release(obj); > + > + hres = stat_eval(ctx, stat->statement, rt, ret); > + > + scope_pop(&ctx->scope_chain); > + return hres; > } > > +/* ECMA-262 3rd Edition 12.12 */ > HRESULT labelled_statement_eval(exec_ctx_t *ctx, statement_t *stat, return_type_t *rt, VARIANT *ret) > { > FIXME("\n"); bye michael

1 0

[Fwd: gdi32: "StretchDIBits" with value of zero for "xSrc" and "ySrc"]
by James McKenzie 23 Sep '08

23 Sep '08

+ /* This might not work for values of "dwRop" much different than "SRCCOPY". + * Further testing is required. + * mkosch (2008/09/22) + */ Add a test case for this if it is possible and test it, if possible. Then you will know if it works/does not work. James McKenzie From da2f416c33348ef059e0c3958392d5231b6fd774 Mon Sep 17 00:00:00 2001 From: Mathias Kosch <info(a)mkosch.de> Date: Tue, 23 Sep 2008 01:36:34 +0200 Subject: gdi32: "StretchDIBits" with value of zero for "xSrc" and "ySrc" This patch fixes Bug#13344. The function "StretchDIBits" behaves odd in case of "top-down" bitmaps with values of zero for "xSrc" and "ySrc". Tests using Windows Server 2003 shew that in this particular case the source rectangle is selected starting at the upper left corner of the bitmap. In all other cases the rectangle is aligned to the bottom of the bitmap. I provided a test case which tests several combinations, especially those with some of the values set to zero. (Some additional cosmetic corrections have been applied to the test case.) It passes under "Windows Server 2003 R2 SP2" and Wine 1.1.5 (only) with this path applied. --- dlls/gdi32/dib.c | 20 +++- dlls/gdi32/tests/Makefile.in | 1 + dlls/gdi32/tests/dib.c | 238 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 257 insertions(+), 2 deletions(-) create mode 100644 dlls/gdi32/tests/dib.c diff --git a/dlls/gdi32/dib.c b/dlls/gdi32/dib.c index 440857d..a59a02e 100644 --- a/dlls/gdi32/dib.c +++ b/dlls/gdi32/dib.c @@ -212,6 +212,7 @@ INT WINAPI StretchDIBits(HDC hdc, INT xDst, INT yDst, INT widthDst, DWORD compr, size; HBITMAP hBitmap; BOOL fastpath = FALSE; + int ySrcAdjusted; release_dc_ptr( dc ); @@ -227,6 +228,16 @@ INT WINAPI StretchDIBits(HDC hdc, INT xDst, INT yDst, INT widthDst, return 0; } + /* Computation of source coordinates behaves different in case of "top down" + bitmaps and values of zero for "xSrc" and "ySrc": */ + if (height < 0) + { + height = -height; /* Positive from now on. */ + ySrcAdjusted = ((xSrc) || (ySrc)) ? height - heightSrc - ySrc : 0; + } + else + ySrcAdjusted = height - heightSrc - ySrc; + hBitmap = GetCurrentObject(hdc, OBJ_BITMAP); if (xDst == 0 && yDst == 0 && xSrc == 0 && ySrc == 0 && @@ -286,8 +297,13 @@ INT WINAPI StretchDIBits(HDC hdc, INT xDst, INT yDst, INT widthDst, * ericP (2000/09/09) */ + /* This might not work for values of "dwRop" much different than "SRCCOPY". + * Further testing is required. + * mkosch (2008/09/22) + */ + /* copy existing bitmap from destination dc */ - StretchBlt( hdcMem, xSrc, abs(height) - heightSrc - ySrc, + StretchBlt( hdcMem, xSrc, ySrcAdjusted, widthSrc, heightSrc, hdc, xDst, yDst, widthDst, heightDst, dwRop ); } @@ -297,7 +313,7 @@ INT WINAPI StretchDIBits(HDC hdc, INT xDst, INT yDst, INT widthDst, /* Origin for DIBitmap may be bottom left (positive biHeight) or top left (negative biHeight) */ if (ret) StretchBlt( hdc, xDst, yDst, widthDst, heightDst, - hdcMem, xSrc, abs(height) - heightSrc - ySrc, + hdcMem, xSrc, ySrcAdjusted, widthSrc, heightSrc, dwRop ); if(hpal) SelectPalette(hdcMem, hpal, FALSE); diff --git a/dlls/gdi32/tests/Makefile.in b/dlls/gdi32/tests/Makefile.in index 866615c..86c931b 100644 --- a/dlls/gdi32/tests/Makefile.in +++ b/dlls/gdi32/tests/Makefile.in @@ -10,6 +10,7 @@ CTESTS = \ brush.c \ clipping.c \ dc.c \ + dib.c \ font.c \ gdiobj.c \ generated.c \ diff --git a/dlls/gdi32/tests/dib.c b/dlls/gdi32/tests/dib.c new file mode 100644 index 0000000..130bf23 --- /dev/null +++ b/dlls/gdi32/tests/dib.c @@ -0,0 +1,238 @@ +/* + * Unit tests for dib functions + * + * Copyright (c) 2008 Mathias Kosch + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#include <assert.h> +#include <stdarg.h> +#include <time.h> + +#include "windef.h" +#include "winbase.h" +#include "wingdi.h" +#include "winuser.h" + +#include "wine/test.h" + + +static void test_StretchDIBits_internal(int xSrc, int ySrc, + int xDest, int yDest, int nWidth, int nHeight, BOOL bTopDown) +{ + BOOL bMatching; + int x, y, nResult; + int nBitmapWidth, nBitmapHeight, nNewBitmapWidth, nNewBitmapHeight; + ULONG i, nSize; + RGBTRIPLE *pBitmapData, *pNewBitmapData, *pStartLine, *pNewStartLine; + BITMAPINFO bmi, bmiNew; + HANDLE hProcessHeap; + HDC hDC, hMemDC; + HBITMAP hBitmap, hOldBitmap; + + + hProcessHeap = GetProcessHeap(); + assert(hProcessHeap != NULL); + + /* Compute bitmap widths and heights. The should be multiples of 4. */ + nBitmapWidth = ((nWidth+xSrc+37) | 3)+1; + nBitmapHeight = ((nHeight+ySrc+43) | 3)+1; + nNewBitmapWidth = ((nWidth+xDest+103) | 3)+1; + nNewBitmapHeight = ((nHeight+yDest+57) | 3)+1; + + /* Creating bitmap structure for bitmap: */ + bmi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER); + bmi.bmiHeader.biWidth = nBitmapWidth; + bmi.bmiHeader.biHeight = nBitmapHeight; + bmi.bmiHeader.biPlanes = 1; + bmi.bmiHeader.biBitCount = 24; + bmi.bmiHeader.biCompression = BI_RGB; + bmi.bmiHeader.biSizeImage = 0; + bmi.bmiHeader.biXPelsPerMeter = 0; + bmi.bmiHeader.biYPelsPerMeter = 0; + bmi.bmiHeader.biClrUsed = 0; + bmi.bmiHeader.biClrImportant = 0; + if (bTopDown) + bmi.bmiHeader.biHeight = -bmi.bmiHeader.biHeight; + + /* Creating bitmap structure for new bitmap: */ + bmiNew.bmiHeader.biSize = sizeof(BITMAPINFOHEADER); + bmiNew.bmiHeader.biWidth = nNewBitmapWidth; + bmiNew.bmiHeader.biHeight = nNewBitmapHeight; + bmiNew.bmiHeader.biPlanes = 1; + bmiNew.bmiHeader.biBitCount = 24; + bmiNew.bmiHeader.biCompression = BI_RGB; + bmiNew.bmiHeader.biSizeImage = 0; + bmiNew.bmiHeader.biXPelsPerMeter = 0; + bmiNew.bmiHeader.biYPelsPerMeter = 0; + bmiNew.bmiHeader.biClrUsed = 0; + bmiNew.bmiHeader.biClrImportant = 0; + if (bTopDown) + bmiNew.bmiHeader.biHeight = -bmiNew.bmiHeader.biHeight; + + /* Creating device context. */ + hDC = GetDC(NULL); + assert(hDC != NULL); + hMemDC = CreateCompatibleDC(hDC); + assert(hMemDC != NULL); + hBitmap = CreateCompatibleBitmap(hDC, nNewBitmapWidth, nNewBitmapHeight); + assert(hBitmap != NULL); + hOldBitmap = (HBITMAP)SelectObject(hMemDC, hBitmap); + assert(hOldBitmap != NULL); + + /* Allocating storage for bitmap data */ + pBitmapData = (RGBTRIPLE*)HeapAlloc(hProcessHeap, 0, + nBitmapWidth*nBitmapHeight*sizeof(RGBTRIPLE)); + assert(pBitmapData != NULL); + pNewBitmapData = (RGBTRIPLE*)HeapAlloc(hProcessHeap, 0, + nNewBitmapWidth*nNewBitmapHeight*sizeof(RGBTRIPLE)); + assert(pNewBitmapData != NULL); + + /* Initializing bitmap with random color data: */ + nSize = nBitmapWidth*nBitmapHeight; + for (i = 0; i < nSize; i++) + { + pBitmapData[i].rgbtBlue = rand(); + pBitmapData[i].rgbtGreen = rand(); + pBitmapData[i].rgbtRed = rand(); + } + + /* Drawing bitmap data as "bottom up" bitmap into first dc: */ + nResult = StretchDIBits(hMemDC, xDest, yDest, nWidth, nHeight, xSrc, ySrc, + nWidth, nHeight, pBitmapData, &bmi, DIB_RGB_COLORS, SRCCOPY); + assert(nResult != 0); + + /* Retrieving bitmap data: */ + nResult = GetDIBits(hMemDC, hBitmap, 0, nNewBitmapHeight, pNewBitmapData, + &bmiNew, DIB_RGB_COLORS); + assert(nResult != 0); + + /* Computing starting lines for comparision. "StretchDIBits" + seems to behave odd in case "xSrc" an "ySrc" is 0. */ + if (bTopDown) + { + pStartLine = pBitmapData; + if ((xSrc) || (ySrc)) + pStartLine += (nBitmapHeight-nHeight-ySrc)*nBitmapWidth; + pNewStartLine = pNewBitmapData + yDest*nNewBitmapWidth; + } + else + { + pStartLine = pBitmapData + (nHeight+ySrc-1)*nBitmapWidth; + pNewStartLine = pNewBitmapData + + (nNewBitmapHeight-yDest-1)*nNewBitmapWidth; + } + + /* Comparing bitmap data with supposed data. */ + bMatching = TRUE; + for (y = 0; y < nHeight; y++) + { + for (x = 0; x < nWidth; x++) + { + if ((pStartLine[x+xSrc].rgbtBlue != pNewStartLine[x+xDest].rgbtBlue) || + (pStartLine[x+xSrc].rgbtGreen != pNewStartLine[x+xDest].rgbtGreen) || + (pStartLine[x+xSrc].rgbtRed != pNewStartLine[x+xDest].rgbtRed)) + { + bMatching = FALSE; + break; + } + } + + if (bTopDown) + { + pStartLine += nBitmapWidth; + pNewStartLine += nNewBitmapWidth; + } + else + { + pStartLine -= nBitmapWidth; + pNewStartLine -= nNewBitmapWidth; + } + } + + ok(bMatching != FALSE, "Bitmap data not matching. [bTopDown=%s," + " StretchDIBits(hMemDC, %d, %d, %d, %d, %d, %d, %d, %d," + " pBitmapData, &bmi, DIB_RGB_COLORS, SRCCOPY)]\n", + (bTopDown) ? "true" : "false", + xDest, yDest, nWidth, nHeight, xSrc, ySrc, nWidth, nHeight); + + SelectObject(hMemDC, hOldBitmap); + DeleteObject(hBitmap); + DeleteDC(hMemDC); + HeapFree(hProcessHeap, 0, pNewBitmapData); + HeapFree(hProcessHeap, 0, pBitmapData); +} + + +static void test_StretchDIBits() +{ + test_StretchDIBits_internal(33, 61, 103, 227, 663, 459, FALSE); + test_StretchDIBits_internal(33, 61, 103, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 61, 103, 227, 663, 459, FALSE); + test_StretchDIBits_internal(0, 61, 103, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(33, 0, 103, 227, 663, 459, FALSE); + test_StretchDIBits_internal(33, 0, 103, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 0, 103, 227, 663, 459, FALSE); + test_StretchDIBits_internal(0, 0, 103, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(33, 61, 0, 227, 663, 459, FALSE); + test_StretchDIBits_internal(33, 61, 0, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 61, 0, 227, 663, 459, FALSE); + test_StretchDIBits_internal(0, 61, 0, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(33, 0, 0, 227, 663, 459, FALSE); + test_StretchDIBits_internal(33, 0, 0, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 0, 0, 227, 663, 459, FALSE); + test_StretchDIBits_internal(0, 0, 0, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(33, 61, 103, 0, 663, 459, FALSE); + test_StretchDIBits_internal(33, 61, 103, 0, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 61, 103, 0, 663, 459, FALSE); + test_StretchDIBits_internal(0, 61, 103, 0, 663, 459, TRUE); + + test_StretchDIBits_internal(33, 0, 103, 0, 663, 459, FALSE); + test_StretchDIBits_internal(33, 0, 103, 0, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 0, 103, 0, 663, 459, FALSE); + test_StretchDIBits_internal(0, 0, 103, 0, 663, 459, TRUE); + + test_StretchDIBits_internal(33, 61, 0, 0, 663, 459, FALSE); + test_StretchDIBits_internal(33, 61, 0, 0, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 61, 0, 0, 663, 459, FALSE); + test_StretchDIBits_internal(0, 61, 0, 0, 663, 459, TRUE); + + test_StretchDIBits_internal(33, 0, 0, 0, 663, 459, FALSE); + test_StretchDIBits_internal(33, 0, 0, 0, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 0, 0, 0, 663, 459, FALSE); + test_Str

1 0

Re: configure.ac: add -Werror to default compiler options
by Rob Shearman 22 Sep '08

22 Sep '08

2008/9/18 Austin English <austinenglish(a)gmail.com>: > Should help avoid bugs like bug 15266 and promote more proper, portable code. > Tried compiling Wine with -Werror, got a few interesting results. First one: > > austin@austin-desktop:~/wine-git/dlls/jscript$ make > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT > -fPIC -Wall -Werror -pipe -fno-strict-aliasing -Wdeclaration-after-statement > -Wwrite-strings -Wpointer-arith -g -O2 -o engine.o engine.c > cc1: warnings being treated as errors > engine.c: In function 'var_statement_eval': > engine.c:500: warning: 'hres' is used uninitialized in this function Or it could just be that they had a different compiler version to you and so the warning didn't appear for them. This is the trouble with using -Werror in an uncontrolled environment - a developer using one version of the compiler could commit code that compiles cleanly for them, but not for another developer using a different compiler version and so stop them from being able to build Wine. That's fine if we want to do it, but we have to consider whether it is worth the hassle for whatever increase in quality we get from it. -- Rob Shearman

4 3

re: msvcrt: scanf fix a typo
by Dan Kegel 22 Sep '08

22 Sep '08

Here's the gcc error: > scanf.c:66: warning: unknown conversion type character `P' in format I'm not a programmer, but I play one on TV. And here's what I came up with in five minutes of typing and not enough thinking: That particular error depends on gcc knowing intimate details of sscanf. Unless we teach gcc about the particular sscanf we're implementing, it's likely to give false errors. It could be that the line #include <stdio.h> at the top of that file is introducing a conflict. See http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Function-Attributes.html#Functi… for the function attributes used to teach gcc about scanf-like format arguments. This may be an example of the problem Juan was anticipating, where people rush to provide fixes to problems that they don't fully understand, just to try to get rid of gcc warnings :-( - Dan

6 15

Re: wine.inf.in: create default key App Paths (and key for IEXPLORE)
by Michael Karcher 22 Sep '08

22 Sep '08

Am Montag, den 22.09.2008, 15:42 +0000 schrieb Louis. Lenders: > btw, was there anything wrong with this patch: > http://www.winehq.org/pipermail/wine-patches/attachments/20080918/e269df3c/… ? As you were already told, IIRC, please do not link attachment, but mails. In this case: http://www.winehq.org/pipermail/wine-patches/2008-September/061760.html In that patch, you are definitely missing the prototype for MsiSetExternalUIRecord in msi.h. I didn't notice any further problems. Regards, Michael Karcher

1 0

Re: gdi32: "StretchDIBits" with value of zero for "xSrc" and "ySrc"
by Vitaliy Margolen 22 Sep '08

22 Sep '08

Mathias Kosch wrote: > This path fixes Bug#13344. > > The function "StretchDIBits" behaves odd in case of "top-down" bitmaps > with values of zero for "xSrc" and "ySrc". Tests using Windows Server > 2003 shew that in this particular case the source rectangle is > selected starting at the upper left corner of the bitmap. In all other > cases the rectangle is aligned to the bottom of the bitmap. > > I provided a test case which tests several combinations, especially > those with some of the values set to zero. > It passes under "Windows Server 2003 R2 SP2" and Wine 1.1.5 (only) > with this path applied. General note - Wine uses 4-spaces indentation, tabs = 8 spaces. Use of tabs discouraged. Mixing spaces and tabs highly not recommended. > +#include <stdbool.h> > +#include <inttypes.h> Please use windows types instead > + struct PIXEL > + { > + uint8_t blue; > + uint8_t green; > + uint8_t red; > + } __attribute__ ((__packed__)); You should use RGBTRIPLE instead. > + HDC hDC = NULL, hMemDC = NULL; > + HBITMAP hBitmap = NULL, hOldBitmap = NULL; What's the point initializing something you will overwrite anyway? Don't do this, it hides bugs. > > + pBitmapData = (struct PIXEL*)malloc(nBitmapWidth*nBitmapHeight*sizeof(struct PIXEL)); Malloc should not be used in winelib apps. Use HeapAlloc/HeapFree. > + if (!pBitmapData) > + ok(0, "Memory allocation failed.\n"); Don't do this. If allocation failed assert or skip the test entirely. Vitaliy.

1 0

Re: kernel32: fix PROFILE_Load to handle mac line endings (try 3)
by Michael Karcher 21 Sep '08

21 Sep '08

Am Sonntag, den 21.09.2008, 02:15 +0200 schrieb Erik Inge Bolsø: > + ok(1, "%s\n", content); Please use trace(...) instead of ok(1,...). Also, outputting a string with newline characters might be irritating, especially as one might need a hex viewer to see the difference between the CR-only and CR/LF variant. You might want to have trace("test_GetPrivateProfileStringA: Run %d\n"); Instead of a run number, you also might want to pass a description like "CR only" or "CR/LF". > - ok(ret == 18, "Expected 18, got %d\n", ret); > + ok(ret == 18, "Run %d: Expected 18, got %d\n", run, ret); Questions to everyone: I suppose if the trace above indicates the run number, these modifications are unneded. Do you agree? Regards, Michael Karcher

2 3

Re: Simplify dlls/atl/registrar.c
by Rob Shearman 21 Sep '08

21 Sep '08

2008/9/7 Gerald Pfeifer <gerald(a)pfeifer.com>: > --- dlls/atl/registrar.c 7 May 2008 12:06:02 -0000 1.29 > +++ dlls/atl/registrar.c 7 Sep 2008 13:42:54 -0000 > @@ -661,7 +661,7 @@ static const IRegistrarVtbl RegistrarVtb > Registrar_ResourceUnregister, > }; > > -static HRESULT Registrar_create(const IUnknown *pUnkOuter, REFIID riid, void **ppvObject) > +static HRESULT Registrar_create(REFIID riid, void **ppvObject) > { > Registrar *ret; > > @@ -711,7 +711,7 @@ static HRESULT WINAPI RegistrarCF_Create > REFIID riid, void **ppvObject) > { > TRACE("(%p)->(%s %p)\n", iface, debugstr_guid(riid), ppvObject); > - return Registrar_create(pUnkOuter, riid, ppvObject); > + return Registrar_create(riid, ppvObject); > } A test needs to be added to see whether or not the Registrar class factory supports aggregation. If it does then a FIXME should be emitted. If not then an ERR may be emitted and CLASS_E_NOAGGREGATION returned. Just removing pUnkOuter isn't the right thing to do. -- Rob Shearman

2 1

Re: [PATCH] [WinHelp]: fix for 5314
by Dmitry Timoshkov 21 Sep '08

21 Sep '08

From: "Eric Pouech" <eric.pouech(a)orange.fr> wrote: > +#include <ctype.h> ... > + if (!ch || !isalpha(ch)) break; Since that's apparently a Windows encoding shouldn't this be GetStringType() instead of isalpha()? -- Dmitry.

2 1

What to do when size of the struct differs on 32 and 64 bit?
by Vitaliy Margolen 21 Sep '08

21 Sep '08

While debugging some force-feedback issues ran into an interesting problem. The size of one struct from include/linux differs between 32-bit and 64-bit. That wouldn't be a major problem except that size is the part of the ioctl() request. Which results in EINVAL. In more details: input.h: #define EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect)) The simple test program: #include <linux/input.h> #include <stdio.h> int main(int argc, char * argv[]) { printf("sizeof(struct ff_effect) = %d EVIOCSFF=%#x\n", sizeof(struct ff_effect), EVIOCSFF); return 0; } $ gcc test_size.c -o test_size && ./test_size sizeof(struct ff_effect) = 48 EVIOCSFF=0x40304580 $ gcc -m32 test_size.c -o test_size32 && ./test_size32 sizeof(struct ff_effect) = 44 EVIOCSFF=0x402c4580 The question is what do we do about it? I'm sure there are might be more cases like that. Vitaliy

6 6

Re: WineD3D: fix UpdateSurface bug [with patch]
by Henri Verbeet 20 Sep '08

20 Sep '08

2008/9/20 Roderick Colenbrander <thunderbird2k(a)gmx.net>: > Hi, > > Fix a bug in UpdateSurface where we didn't take into account the offset into the memory buffer specified in the source rectangle. > What about the glCompressedTexImage2DARB() call a few lines up and the TRACE?

2 1

Re: msvcrt: scanf fix a typo
by James Hawkins 20 Sep '08

20 Sep '08

On Fri, Sep 19, 2008 at 4:39 PM, Austin English <austinenglish(a)gmail.com> wrote: > Found using -Werror (strangely, didn't occur on ubuntu, but does on > PC-BSD)...Must be the gcc version. > @@ -63,7 +63,7 @@ static void test_sscanf( void ) ok( sscanf("1233", "%p", &ptr) == 1, "sscanf failed\n" ); ok( ptr == (void *)0x1233,"sscanf reads %p instead of %x\n", ptr, 0x1233 ); - ok( sscanf("1234", "%P", &ptr) == 1, "sscanf failed\n" ); + ok( sscanf("1234", "%p", &ptr) == 1, "sscanf failed\n" ); ok( ptr == (void *)0x1234,"sscanf reads %p instead of %x\n", ptr, 0x1234 ); How do you figure that's a typo? The test right above it is exactly the same as what you've changed this one to. I didn't write the test, but I'm pretty sure the original author meant to test both cases. This is a good reason why tests should be commented, so the author's intent is well known. -- James Hawkins

5 6

WebKit vs Gecko and Wine
by Vijay Kiran Kamuju 20 Sep '08

20 Sep '08

Hi, I have a nice idea to discuss at wineconf this year. Is it possible to use webkit for mshtml and jscript implementations of wine? Have been hearing a lotta good reviews about performance of webkit and lotta other browsers adopting it. How much work would it be to support webkit as to provide an alternative for winegecko? Firstly is it feasible. Thanks, VJ --------------------------------------------------------------------------------------------------------------------- Zsa Zsa Gabor - "He taught me housekeeping; when I divorce I keep the house."

3 2

Re: PrintDlgEx [2/7]: Add basic dialog.
by Michael Stefaniuc 19 Sep '08

19 Sep '08

Hello Gal, there is no point in adding new resources in English to the other languages rc files. If a resource doesn't exist Win32 will automatically fail over to use the en_US version. Actually its even detrimental to add the new resources as: a.) http://pf128.krakow.sdi.tpnet.pl/wine-transl/ cannot show those resources as untranslated. b.) The copied English resources have a tendency to bit-rot. c.) The patch is smaller and offers the exact same functionality. You need to only amend existing resources in the language files that have that resource. To make it easy the Wine wrc supports the --verify-translation switch. Just take the wrc command that make is running in that directory and append --verify-translation to it. Do that before and after you applied your patch. If you see additional lines popping up that start with "DIFF" or "ERR" your patch breaks the translations and you'll have to check what resource you need to amend. Gal Topper wrote: > dlls/comdlg32/cdlg_Bg.rc | 38 +++++++ > dlls/comdlg32/cdlg_Cs.rc | 38 +++++++ > dlls/comdlg32/cdlg_Da.rc | 38 +++++++ > dlls/comdlg32/cdlg_De.rc | 38 +++++++ > dlls/comdlg32/cdlg_El.rc | 38 +++++++ > dlls/comdlg32/cdlg_En.rc | 38 +++++++ > dlls/comdlg32/cdlg_Eo.rc | 38 +++++++ > dlls/comdlg32/cdlg_Es.rc | 38 +++++++ > dlls/comdlg32/cdlg_Fi.rc | 38 +++++++ > dlls/comdlg32/cdlg_Fr.rc | 38 +++++++ > dlls/comdlg32/cdlg_It.rc | 38 +++++++ > dlls/comdlg32/cdlg_Ja.rc | 38 +++++++ > dlls/comdlg32/cdlg_Ko.rc | 38 +++++++ > dlls/comdlg32/cdlg_Nl.rc | 38 +++++++ > dlls/comdlg32/cdlg_No.rc | 38 +++++++ > dlls/comdlg32/cdlg_Pl.rc | 38 +++++++ > dlls/comdlg32/cdlg_Pt.rc | 85 +++++++++++++++ > dlls/comdlg32/cdlg_Ro.rc | 40 +++++++ > dlls/comdlg32/cdlg_Ru.rc | 38 +++++++ > dlls/comdlg32/cdlg_Si.rc | 38 +++++++ > dlls/comdlg32/cdlg_Sk.rc | 38 +++++++ > dlls/comdlg32/cdlg_Sv.rc | 38 +++++++ > dlls/comdlg32/cdlg_Th.rc | 38 +++++++ > dlls/comdlg32/cdlg_Tr.rc | 38 +++++++ > dlls/comdlg32/cdlg_Uk.rc | 38 +++++++ > dlls/comdlg32/cdlg_Zh.rc | 38 +++++++ > dlls/comdlg32/printdlg.c | 269 +++++++++++++++++++++++++++++++++++++++++++++- > dlls/comdlg32/printdlg.h | 20 ++++- > 28 files changed, 1323 insertions(+), 3 deletions(-) bye michael

3 3

Re: winex11.drv: Make wglShareLists() cope with previously selected destination context (try 3)
by Roderick Colenbrander 19 Sep '08

19 Sep '08

Hi, First of all note that glXDestroyContext only destroys a context after no of the other threads is using it (it is in the specs of glXDestroyContext). Second there are some more issues in wglShareLists which shouldn't get fixed in your patch but which I plan to fix at a later stage which you should take into account. Some BAD class of apps calls wglShareLists before making the source context current (so it isn't backed by a GLX context) while it has made the destination one current. In such case we need to perform a swap as right now such programs crash. MSDN clearly mentions that the hglrc2 parameter shouldn't contain any existing display lists, so this situation isn't allowed. This would mean wglShareLists(dest, source) is invalid and second that when perform a legal wglShareLists(source, dest) that dest can't have been current in any thread. Since wglShareLists is a tricky function which might require very ugly hacks I want to keep it as clean as possible. This means that you should write a small wine test case for the behavior of wglShareLists in the situation affected by your patch. Roderick > The current wglShareLists() will fail if the destination context has ever > been made current. This causes a crash in Homeworld 2, unless pbuffers are > disabled. This patch fixes the crash by deleting and recreating the > underlying OpenGL context, unless it is still current in some thread. > > Improved patch by: Moving the deletion of the old context into the > wine_tsx11_lock where it belongs; tracking whether a WGL context is current in > some thread so we don't deselect it out from under the app; adding an > explanatory comment; a more professional change entry ;) -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

3 4

Re: [PATCH 6/7] d3dx9/tests: Test D3DXCheckTextureRequirements.
by Henri Verbeet 19 Sep '08

19 Sep '08

2008/9/19 Philip Nilsson <pnilsson(a)nullref.se>: > This one could use some more work, but I think the tests will pass in > most cases (except in strange environments without support for common > formats). > The tests should pass everywhere. I think you should be testing for consistency between CheckDeviceFormat() and D3DXCheckTextureRequirements().

2 1

Re: [PATCH 7/7] d3dx9/tests: Test D3DXCreateTexture.
by Henri Verbeet 19 Sep '08

19 Sep '08

I think it would be a good idea to test the parameters (format, width, height, miplevels) of the created texture.

2 1

Re: [PATCH 3/7] d3dx9: Implement D3DXCheckTextureRequirements.
by Henri Verbeet 19 Sep '08

19 Sep '08

2008/9/19 Philip Nilsson <pnilsson(a)nullref.se>: > + hr = IDirect3DDevice9_GetDirect3D(device, &d3d9); > + if (hr != D3D_OK || !device) > + return D3DERR_INVALIDCALL; > + > + IDirect3D9_GetAdapterDisplayMode(d3d9, D3DADAPTER_DEFAULT, &d3ddm); > + > + /* TODO: Use something more advanced that looks more like what's in MSDN. */ > + hr = IDirect3D9_CheckDeviceFormat(d3d9, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, d3ddm.Format, usage, D3DRTYPE_TEXTURE, *format); You shouldn't guess the adapter, device type, etc., but use whatever the device was created with. IDirect3DDevice9_GetCreationParameters() should help there. > + if (hr != D3D_OK) { > + if (usage & D3DUSAGE_DEPTHSTENCIL) { > + switch (*format) { ... > + } > + IDirect3D9_Release(d3d9); > + } I'm not sure about the big switch statement there, but I do know that just changing the format isn't enough. There's no guarantee the new format will work, or if there is any format that will support that specific set of usage flags at all.

2 1

Re: [PATCH 4/7] d3dx9: Add a D3DXCreateTexture stub.
by Henri Verbeet 19 Sep '08

19 Sep '08

2008/9/19 Philip Nilsson <pnilsson(a)nullref.se>: > + if (ret != D3D_OK) > + return ret; > + > + return D3D_OK; This doesn't really make sense.

1 0

Re: PrintDlgEx [1/7]: Add common failure checks and a trace.
by Juan Lang 19 Sep '08

19 Sep '08

Hi Gal, + * This function is necessary in order to match the behaviour on + * Windows, which seems to do all these checks when PrintDlgEx + * is called. It is also necessary in order to replicate a bug in + * PrintDlgExA, where S_OK is returned for invalid DevMode or DevNames. A test case would be a lot nicer than a comment. --Juan

2 2

Re: PrintDlgEx [1/7]: Add common failure checks and a trace.
by Vitaly Lipatov 19 Sep '08

19 Sep '08

What about move printdlgex related code in standalone file printdlgex.c? Is it possible? I see printdlg.c too large already. В сообщении от 18 сентября 2008 Gal Topper написал(a): > Changes since last attempt: > 1) Added a comment to explain the rationale behind the CommonChecks > function. 2) Resources and header are no longer in separate patches. > Instead, they are added along with the code that requires them. > 3) Some unused elements are no longer added in this patch-set. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

RE: Drawprim.c patch
by Stefan Dösinger 18 Sep '08

18 Sep '08

It is getting better, but still not correct. Look at how the diffuse and specular colors are handled, and create a call table texcoord_funcs to handle the different types. > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Chris Ahrendt > Sent: Thursday, September 18, 2008 7:58 AM > To: wine-patches(a)winehq.org > Subject: Drawprim.c patch > > This is a redo of my drawprim patch > > > Chris

2 1

Taking advantage of debug libraries
by Markus Hitter 18 Sep '08

18 Sep '08

Hello all, now, as I get better and better on juggling with the various debugger options, I'm at a point where I'd like to get advantage of MS' C++ runtime debug libraries. Looking at MSDN, they recommend to turn a few switches in the IDE and ... but this won't work, as I can't re-link my binary. Looking at what my app does, it obviously looks for mfc70.dll and is satisfied with getting mfc80.dll. To a Unix guy like me this looks weird. All Visual C++ distributions I could have a look at come with mfc42* libraries, no matter how recent the IDE distro is. So I've put this into C:/windows/system and hoped for even more magic - but it didn't happen. Still segment names only in winedbg. My question is: is it possible to take advantage of the mfc42d.dll/ mfc42d.map/mfc42d.pdb file trio to get debug symbols in winedbg? Or perhaps even in generic gdb? If yes, where would I put these files or how would I load their tables into the debugger? Thanks, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/

2 1

Re: d3dx9: Include d3dx9effect.h
by Tony Wasserka 18 Sep '08

18 Sep '08

Hi, one very little thing: You could include d3dx9.h (from d3dx9effect.h) after the #define __D3DX9EFFECT_H__, as this reduces compile time slightly when included twice or more. No actual reason to resend though, just an advice for future. Best regards, Tony

1 0

Re: d3dx9: Implement D3DXMatrixAffineTransformation2D with tests
by Tony Wasserka 18 Sep '08

18 Sep '08

Hi, you forgot the WINAPI in front of the function declaration and implementation. Maybe you should add a set_mat(_11, _12, _13, ....) macro to make the exp_mat better to read and not that big in size, However, I think it's better to dynamically calculate the expected matrix rather than compare it to hard-coded values (I'm not sure about that one though, it's just what _I_ would do). It would at least make the whole thing easier be adopted to new tests (of the same function with different values). Best regards, Tony

1 0

Re: imm: Don't crash in ImmConfigureIME when dwMode is IME_CONFIG_REGISTERWORD and lpData is NULL (resend)
by Aric Stewart 18 Sep '08

18 Sep '08

Humm, according to MSDN: "If dwMode is set to IME_CONFIG_REGISTERWORD, this parameter must indicate a REGISTERWORD structure." If windows does not crash in this case, then maybe it would involve checking for the non-presence of the parameter and returning the correct error. So it looks like your fix is not quite correct. -aric Juan Lang wrote: > Hi, > anything wrong with this one? > --Juan > > > ------------------------------------------------------------------------ > >

2 1

Patchwatcher problems
by Andrew Fenn 18 Sep '08

18 Sep '08

Hi, I just submitted a patch to wine patches (Started implementing the xinput library for xbox 360 joystick support ) and I believe patch watcher failed for a few reasons. 1) Although it applied my patch it didn't build it as ./tools/make_makefiles isn't called so it isn't built? 2) Patch watcher seems to fail because of another patch, perhaps the latest known good build should be tested if the patch fails and then compared with the first failed attempt? Regards, Andrew

1 0

Re: PrintDlgEx [4/7]: Implement hDevMode and hDevNames on output.
by Juan Lang 18 Sep '08

18 Sep '08

Hi Gal, + WORD locks; + if ((locks = (GlobalFlags(lppd->hDevMode) & GMEM_LOCKCOUNT))) { + WARN("hDevMode has %d locks on it. Unlocking it now\n", locks); + while(locks--) { + GlobalUnlock(lppd->hDevMode); + TRACE("Now got %d locks\n", locks); This looks funny. The loop may have a race condition if someone else is locking/unlocking it. The following would be simpler, and more importantly, more likely to be correct: WORD locks; while ((locks = (GlobalFlags(lppd->hDevMode) & GMEM_LOCKCOUNT))) { GlobalUnlock(lppd->hDevMode); TRACE("Now got %d locks\n", locks); } The same comment applies to unlocking hDevNames. --Juan

1 0

Re: d3dx9: Add d3dx9effect.h
by Henri Verbeet 18 Sep '08

18 Sep '08

2008/9/18 David Adam <david.adam.cnrs(a)gmail.com>: > Hello, > > > + // Pool > > C++ comment is forbidden > 2008/9/18 Busquets Pérez Luis C. <luiscar2001(a)yahoo.es>: > + // Selecting and setting a technique ... > + // Using current technique ... > + // Managing D3D Device ... > + // Logging device calls ... > + // Parameter blocks ... > + // Cloning ... > + // Fast path for setting variables directly in ID3DXEffect Actually, you shouldn't copy those from the Microsoft header in the first place. > +DEFINE_GUID( IID_ID3DXEffect, > +0xb589b04a, 0x293d, 0x4516, 0xaf, 0xb, 0x3d, 0x7d, 0xbc, 0xf5, 0xac, 0x54); That's interesting though, my headers have "0xf6ceb4b3, 0x4e4c, 0x40dd, 0xb8, 0x83, 0x8d, 0x8d, 0xe5, 0xea, 0xc, 0xd5" as the GUID for IID_ID3DXEffect.

1 0

howto fix bug 13462
by Louis. Lenders 18 Sep '08

18 Sep '08

Hi, we've been discussing in bug 13462 howto fix that bug, but in short i think we lack knowledge of how this should properly be fixed, and Erich suggested to take this to wine-devel. I did some testing and this is a major bug, preventing the following apps from working: CDBurner XP, XML Notepad2007, Nasa WorldWind, FX_Composer(nvidia), Ninja Trader and probably a lot more .net applications. I fixed up a patch here http://bugs.winehq.org/attachment.cgi?id=15775, that lets the applications start fine, but i haven't got a clue if it's correct, and Erich said it probably isn't correct, so my question is: Does anyone of the developers (on ole32) have suggestions how to fix this bug properly? More info at http://bugs.winehq.org/show_bug.cgi?id=13462

3 4

Re: ntoskrnl: Implement server side of get_device
by Vitaliy Margolen 18 Sep '08

18 Sep '08

Peter Dons Tychsen wrote: > Implement server side of get_device to complete the > IoGetDeviceObjectPointer() function. > > /pedro My first question: what will you do with that pointer if that driver is loaded in the separate instance of ntoskrnl? Driver that calls IoGetDeviceObjectPointer will most likely try to dereference the pointer it got back. > +/* locate a device */ > +DECL_HANDLER(get_device) > +{ > + struct unicode_str name; > + get_req_unicode_str( &name ); > + > + /* lookup the device */ > + struct device *device = open_object_dir(NULL, &name, 0, &device_ops); > + if(!device) > + { > + return; > + } > + > + /* fill reply */ > + reply->handle = alloc_handle(current->process, device, req->access, 0);.... > + reply->user_ptr = device->user_ptr; > + You leaking reference to device here. Need release_object( device ); In your patch please include changes to server/protocol.def only and not any other automatically generated files. Make it a separate commit in your tree and just don't send it to wine-patches. Vitaliy

2 3

Re: user32: Stub for LockWorkStation (try 3)
by James Mckenzie 18 Sep '08

18 Sep '08

Paul: I'm glad you removed this 'feature' as it would not work at all with Wine on a Mac system. James Mckenzie -----Original Message----- >From: Paul Chitescu <paulc(a)voip.null.ro> >Sent: Sep 17, 2008 8:12 AM >To: Wine Patches <wine-patches(a)winehq.org> >Subject: user32: Stub for LockWorkStation (try 3) > >Changelog: > user32: Stub for LockWorkStation > >Please do not ask for an implementation based on xdg-screensaver as Alexandre >will not accept it. Sorry, Steven.

2 1

Re: d3dx9: Add d3dx9effect.h
by Henri Verbeet 17 Sep '08

17 Sep '08

2008/9/17 Busquets Pérez Luis C. <luiscar2001(a)yahoo.es>: > b0VIM 7.1....... > ÿeÑH..M.áL..root > ................ > ................ > ....localhost.lo > caldomain....... > ............/win > e-git/0001--modi > fied-include-d3d > x9.h.patch...... > ................ That's probably not what you meant to attach. Also, it's bad practice to work as root.

1 0

Re: [1/5] wined3d: Clarify a comment
by Henri Verbeet 17 Sep '08

17 Sep '08

Ignore this set, I missed an issue with volumes between the 2nd and 3rd patch.

1 0

wineserver assertion failure
by Dan Kegel 17 Sep '08

17 Sep '08

Hrm. Saw this after trying the 'nytimes' crash on Google Chrome with yesterday's wine: wineserver: object.c:277: release_object: Assertion `obj->refcount' failed. If it happens again, I'll report more...

2 1

Request for feedback: gdi32/tests antialiasing patch
by Glenn Wurster 17 Sep '08

17 Sep '08

Last Thursday I submitted a patch which was silently dropped. I'd be interested if someone could take a look at it and let me know what I'm missing plase. I've included the original patch e-mail for reference. The patch was tested on XP, 98, and Wine. I also ran it through valgrind and it passed patchwatcher without any errors. I've had the conformance test sitting around for a while and believe it's best put in the wine source tree (especially as a conformance test for the new DIB engine). It's a conformance test for a bug I fixed years ago in the Wine source tree: * http://www.winehq.org/pipermail/wine-cvs/2005-January/013584.html * http://www.winehq.org/pipermail/wine-cvs/2005-January/013623.html Thanks for any assistance anyone may be able to provide. Glenn. On Thu, Sep 11, 2008 at 02:59:46PM -0400, Glenn Wurster wrote: > > Changelog: > gdi32/tests: Add font antialiasing tests > > Add tests to ensure that antialiasing is not used even if requested > when we are operating in a palette drawing mode, and that antialiasing > is used when operating in a non-palette mode. > > Changes since attempt 1: > * Clear the bitmap before we write the text to it. > * Document in this e-mail tests performed. > > Tested on XP (sp2), 98, and Wine, also run through Valgrind (did this on > the initial patch as well but forgot to mention that in the e-mail). > > Glenn Wurster. > > --- > dlls/gdi32/tests/font.c | 163 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 163 insertions(+), 0 deletions(-) > diff --git a/dlls/gdi32/tests/font.c b/dlls/gdi32/tests/font.c > index 7d2c036..088d4e6 100644 > --- a/dlls/gdi32/tests/font.c > +++ b/dlls/gdi32/tests/font.c > @@ -2430,6 +2430,168 @@ static void test_orientation(void) > DeleteDC(hdc); > } > > +static void clear_bmp(HDC hdc, int width, int height, COLORREF colour) > +{ > + HBRUSH hbrush, hbrush_old; > + HPEN hpen, hpen_old; > + > + hbrush = CreateSolidBrush(colour); > + ok(hbrush != NULL, "CreateSolidBrush failed.\n"); > + > + hpen = CreatePen(PS_SOLID, 0, colour); > + ok(hpen != NULL, "CreatePen failed.\n"); > + > + hpen_old = SelectObject( hdc, hpen ); > + hbrush_old = SelectObject( hdc, hbrush ); > + ok(hpen_old != NULL, "SelectObject failed.\n"); > + ok(hbrush_old != NULL, "SelectObject failed.\n"); > + > + ok(Rectangle(hdc, 0, 0, width, height), "Rectangle failed.\n"); > + > + SelectObject(hdc, hbrush_old); > + DeleteObject(hbrush); > + SelectObject(hdc, hpen_old); > + DeleteObject(hpen); > +} > + > +static COLORREF check_bmp_colors(HDC hdc, COLORREF * colours, int colorCnt, int width, int height) > +{ > + COLORREF pixel; > + int x, y, z; > + for(y = 0; y < height; y++) > + { > + for(x = 0; x < width; x++) > + { > + pixel = GetPixel(hdc, x, y); > + for(z = 0; z < colorCnt; z++) > + { > + if(pixel == colours[z]) > + break; > + } > + if(z >= colorCnt) > + { > + return pixel; > + } > + } > + } > + return 0; > +} > + > +static void test_antialias(void) > +{ > + PALETTEENTRY paletteEntries[3] = { > + { 0x00, 0x00, 0x00, PC_NOCOLLAPSE }, > + { 0xFF, 0xFF, 0xFF, PC_NOCOLLAPSE }, > + { 0x44, 0x44, 0x44, PC_NOCOLLAPSE } > + }; > + HDC hdc; > + HFONT hfont, old_hfont; > + HPALETTE hpal, old_hpal; > + LOGPALETTE * lpal; > + HBITMAP hbmp, old_hbmp; > + BITMAPINFO * bmi; > + COLORREF colours[3]; > + int cntr; > + COLORREF pixel; > + > + hdc = CreateCompatibleDC(0); > + > + /* Create an antialiased font. We don't really care what the specific font is */ > + hfont = CreateFont(32, 0, 0, 0, FW_REGULAR, FALSE, FALSE, FALSE, ANSI_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, ANTIALIASED_QUALITY, DEFAULT_PITCH | FF_DONTCARE, NULL); > + old_hfont = SelectObject(hdc, hfont); > + ok(old_hfont != NULL, "SelectObject failed.\n"); > + > + /* Set up a palette */ > + lpal = (LOGPALETTE *)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(LOGPALETTE) + 3*sizeof(PALETTEENTRY)); > + lpal->palNumEntries = 3; > + lpal->palVersion = 0x0300; > + lpal->palPalEntry[0] = paletteEntries[0]; > + lpal->palPalEntry[1] = paletteEntries[1]; > + lpal->palPalEntry[2] = paletteEntries[2]; > + hpal = CreatePalette(lpal); > + HeapFree(GetProcessHeap(), 0, lpal); > + old_hpal = SelectPalette(hdc, hpal, FALSE); > + ok(old_hpal != NULL, "SelectPalette failed.\n"); > + > + /* Create an 8bit bitmap to draw into */ > + bmi = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(BITMAPINFO) + 3 * sizeof(RGBQUAD)); > + bmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER); > + bmi->bmiHeader.biWidth = 20; > + bmi->bmiHeader.biHeight = -20; > + bmi->bmiHeader.biPlanes = 1; > + bmi->bmiHeader.biBitCount = 8; > + bmi->bmiHeader.biCompression = BI_RGB; > + bmi->bmiHeader.biClrUsed = 3; > + for(cntr = 0; cntr < 3; cntr++) > + { > + bmi->bmiColors[cntr].rgbRed = paletteEntries[cntr].peRed; > + bmi->bmiColors[cntr].rgbGreen = paletteEntries[cntr].peGreen; > + bmi->bmiColors[cntr].rgbBlue = paletteEntries[cntr].peBlue; > + bmi->bmiColors[cntr].rgbReserved = 0; > + colours[cntr] = RGB(paletteEntries[cntr].peRed, paletteEntries[cntr].peGreen, paletteEntries[cntr].peBlue); > + } > + > + hbmp = CreateDIBSection(hdc, bmi, DIB_RGB_COLORS, 0, 0, 0); > + ok(hbmp != NULL, "error=%d\n", GetLastError()); > + old_hbmp = SelectObject(hdc, hbmp); > + ok(old_hbmp != NULL, "error=%d\n", GetLastError()); > + > + HeapFree(GetProcessHeap(), 0, bmi); > + > + /* Set up the text colours */ > + SetTextColor(hdc, RGB(0xFF, 0xFF, 0xFF)); > + SetBkColor(hdc, RGB(0, 0, 0)); > + SetBkMode(hdc, OPAQUE); > + > + /* Draw an 'O' offset to see if antialiasing was > + * used. Antialiasing should be restricted to colours in the > + * palette (if it is done at all). */ > + clear_bmp(hdc, 20, 20, RGB(0, 0, 0)); > + ok(ExtTextOut(hdc, 0, -4, 0, NULL, "O", 1, NULL), "ExtTextOut failed.\n"); > + pixel = check_bmp_colors(hdc, colours, 3, 20, 20); > + ok(pixel == 0, "Found invalid pixel: %x.\n", pixel); > + > + /* Cleanup the palette stuff */ > + SelectPalette(hdc, old_hpal, FALSE); > + DeleteObject(hpal); > + SelectObject(hdc, old_hbmp); > + DeleteObject(hbmp); > + > + /* Create an RGB bitmap to draw into */ > + bmi = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(BITMAPINFO)); > + bmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER); > + bmi->bmiHeader.biWidth = 20; > + bmi->bmiHeader.biHeight = -20; > + bmi->bmiHeader.biPlanes = 1; > + bmi->bmiHeader.biBitCount = 32; > + bmi->bmiHeader.biCompression = BI_RGB; > + bmi->bmiHeader.biClrUsed = 0; > + > + hbmp = CreateDIBSection(hdc, bmi, DIB_RGB_COLORS, 0, 0, 0); > + ok(hbmp != NULL, "error=%d\n", GetLastError()); > + old_hbmp = SelectObject(hdc, hbmp); > + ok(old_hbmp != NULL, "error=%d\n", GetLastError()); > + > + HeapFree(GetProcessHeap(), 0, bmi); > + > + /* Draw an 'O' offset to see if antialiasing was used. > + * Antialiasing should be used when we specify an antialiasing > + * font and use a RGB bitmap. */ > + clear_bmp(hdc, 20, 20, RGB(0, 0, 0)); > + ok(ExtTextOut(hdc, 0, -4, 0, NULL, "O", 1, NULL), "ExtTextOut failed.\n"); > + pixel = check_bmp_colors(hdc, colours, 2, 20, 20); > + ok(pixel != 0, "Antialiasing was not used.\n"); > + > + /* Free the bitmap */ > + SelectObject(hdc, old_hbmp); > + DeleteObject(hbmp); > + > + /* Free the rest of our memory */ > + SelectObject(hdc, old_hfont); > + DeleteObject(hfont); > + DeleteDC(hdc); > +} > + > START_TEST(font) > { > init(); > @@ -2449,6 +2611,7 @@ START_TEST(font) > test_GetFontUnicodeRanges(); > test_nonexistent_font(); > test_orientation(); > + test_antialias(); > > /* On Windows Arial has a lot of default charset aliases such as Arial Cyr, > * I'd like to avoid them in this test. >

1 0

Rejected patches needing review.
by Peter Dons Tychsen 17 Sep '08

17 Sep '08

Hello. I have a problem loading a specific proprietary driver. I traced the problem to two bugs in: - services - winedevice The two bugs caused the loading to fail. I created and tested two fixes to solve the problem, but both patches were silently rejected. Can some review them before i re-send them? I have looked them over several time, but i do not see a problem with them. The only "problem" is that there are no test cases for these programs, as there is no such place for such. Thanks, /pedro

4 5

Re: [PATCH] pass correct buffersize to LCMapStringW
by Dmitry Timoshkov 16 Sep '08

16 Sep '08

"Marcus Meissner" <marcus(a)jet.franken.de> wrote: > diff --git a/dlls/kernel32/tests/locale.c b/dlls/kernel32/tests/locale.c > index f792da2..a49953b 100644 > --- a/dlls/kernel32/tests/locale.c > +++ b/dlls/kernel32/tests/locale.c > @@ -1268,7 +1268,7 @@ static void test_LCMapStringW(void) > /* otherwise src == dst should fail */ > SetLastError(0xdeadbeef); > ret = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY | LCMAP_UPPERCASE, > - buf, 10, buf, sizeof(buf)); > + buf, 10, buf, sizeof(buf)/sizeof(WCHAR)); > ok(GetLastError() == ERROR_INVALID_FLAGS /* NT */ || > GetLastError() == ERROR_INVALID_PARAMETER /* Win9x */, > "unexpected error code %d\n", GetLastError()); > @@ -1276,40 +1276,40 @@ static void test_LCMapStringW(void) > > /* test whether '\0' is always appended */ > ret = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY, > - upper_case, -1, buf, sizeof(buf)); > + upper_case, -1, buf, sizeof(buf)/sizeof(WCHAR)); > ok(ret, "LCMapStringW must succeed\n"); > ret2 = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY, > - upper_case, lstrlenW(upper_case), buf2, sizeof(buf2)); > + upper_case, lstrlenW(upper_case), buf2, sizeof(buf2)/sizeof(WCHAR)); > ok(ret, "LCMapStringW must succeed\n"); > ok(ret == ret2, "lengths of sort keys must be equal\n"); > ok(!lstrcmpA(p_buf, p_buf2), "sort keys must be equal\n"); > > /* test LCMAP_SORTKEY | NORM_IGNORECASE */ > ret = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY | NORM_IGNORECASE, > - upper_case, -1, buf, sizeof(buf)); > + upper_case, -1, buf, sizeof(buf)/sizeof(WCHAR)); > ok(ret, "LCMapStringW must succeed\n"); > ret2 = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY, > - lower_case, -1, buf2, sizeof(buf2)); > + lower_case, -1, buf2, sizeof(buf2)/sizeof(WCHAR)); > ok(ret2, "LCMapStringW must succeed\n"); > ok(ret == ret2, "lengths of sort keys must be equal\n"); > ok(!lstrcmpA(p_buf, p_buf2), "sort keys must be equal\n"); > > /* test LCMAP_SORTKEY | NORM_IGNORENONSPACE */ > ret = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY | NORM_IGNORENONSPACE, > - lower_case, -1, buf, sizeof(buf)); > + lower_case, -1, buf, sizeof(buf)/sizeof(WCHAR)); > ok(ret, "LCMapStringW must succeed\n"); > ret2 = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY, > - lower_case, -1, buf2, sizeof(buf2)); > + lower_case, -1, buf2, sizeof(buf2)/sizeof(WCHAR)); > ok(ret2, "LCMapStringW must succeed\n"); > ok(ret == ret2, "lengths of sort keys must be equal\n"); > ok(!lstrcmpA(p_buf, p_buf2), "sort keys must be equal\n"); > > /* test LCMAP_SORTKEY | NORM_IGNORESYMBOLS */ > ret = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY | NORM_IGNORESYMBOLS, > - lower_case, -1, buf, sizeof(buf)); > + lower_case, -1, buf, sizeof(buf)/sizeof(WCHAR)); > ok(ret, "LCMapStringW must succeed\n"); > ret2 = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY, > - symbols_stripped, -1, buf2, sizeof(buf2)); > + symbols_stripped, -1, buf2, sizeof(buf2)/sizeof(WCHAR)); > ok(ret2, "LCMapStringW must succeed\n"); > ok(ret == ret2, "lengths of sort keys must be equal\n"); > ok(!lstrcmpA(p_buf, p_buf2), "sort keys must be equal\n"); LCMAP_SORTKEY takes the target buffer size in bytes in both A and W versions. > @@ -1332,7 +1332,7 @@ static void test_LCMapStringW(void) > > /* test srclen = 0 */ > SetLastError(0xdeadbeef); > - ret = LCMapStringW(LOCALE_USER_DEFAULT, 0, upper_case, 0, buf, sizeof(buf)); > + ret = LCMapStringW(LOCALE_USER_DEFAULT, 0, upper_case, 0, buf, sizeof(buf)/sizeof(WCHAR)); > ok(!ret, "LCMapStringW should fail with srclen = 0\n"); > ok(GetLastError() == ERROR_INVALID_PARAMETER, > "unexpected error code %d\n", GetLastError()); The size of the target buffer doesn't matter at all in this case, since the API is supposed to fail due to source length being 0. -- Dmitry.

5 8

Wineconf - final reminder!
by Jeremy White 16 Sep '08

16 Sep '08

Folks, Just 11 days until Wineconf. Come celebrate Wine 1.0! http://wiki.winehq.org/WineConf2008 I'll start up a thread for RSVPs and such on the wineconf mailing list. Cheers, Jeremy

1 0

Re: winemenubuilder: eliminate wineshelllink (try 5)
by Alexandre Julliard 16 Sep '08

16 Sep '08

"Damjan Jovanovic" <damjan.jov(a)gmail.com> writes: > + do > + { > + line = HeapAlloc(GetProcessHeap(), 0, size); > + if (!line) > + return NULL; > + ret = fgets(line, size, file); > + if (ret != NULL) > + { > + if (strlen(line) < size - 1) > + return line; > + size *= 2; > + } > + HeapFree(GetProcessHeap(), 0, line); > + } while (ret != NULL); This won't do what you want. > + char *line; > + while ((line = next_line(originalMenu)) != NULL) > + { > + if (strstr(line, "<Filename>")) > + { > + if (strstr(line, name)) > + found = TRUE; > + fprintf(tempfile, "%s", line); > + } strstr is not appropriate for comparing file names. Also you are leaking memory here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Fwd: Implementing d3dx9_36.dll.D3DXCreateTexture
by Andrew Fenn 16 Sep '08

16 Sep '08

D3DXCheckTextureRequirements has already been implemented and a patch was submitted here: http://www.winehq.org/pipermail/wine-patches/2008-April/053547.html Please check it out. On Tue, Sep 16, 2008 at 2:20 PM, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > > For basic operation just forwarding to the d3d9 CreateTexture call should work fine but note the following: > "Internally, D3DXCreateTexture uses D3DXCheckTextureRequirements to adjust the calling parameters. Therefore, calls to D3DXCreateTexture will often succeed where calls to IDirect3DDevice9::CreateTexture would fail." > > As a start I wouldn't add that behavior but add a comment that the function isn't complete and what is missing. I would also print a FIXME about it but only show it once in total (so use a static variable). > > Roderick > >> Hi list, >> >> I'm trying to get a DirectX model viewer[1] to run. Using wine 1.1.4 it >> is possible to lauch because d3dx9_36.dll exists but a method >> (CreateTexture) of it is stubbed out. I started looking for details on >> this and came up with this MSDN link[2]. Looking at the code I found >> that this method is already implemented in the core d3d9 library in >> dlls/d3d9/texture.c. From what I understand a forward to this function >> should be enough to get this method to work since the parameters seem to >> match (except the last parameter in the core d3d9 (HANDLE* >> pSharedHandle) does not exist in the MSDN definition). >> >> Can someone please comment if my thoughts are right here? >> >> Thanks, >> Christoph >> >> [1] http://www.teamxtcgames.com/3d_object_viewer.htm >> [2] http://msdn.microsoft.com/en-us/library/bb172800(VS.85).aspx >> >> > > -- > GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! > http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/61691… > > >

1 0

Implementing d3dx9_36.dll.D3DXCreateTexture
by Christoph Brill 16 Sep '08

16 Sep '08

Hi list, I'm trying to get a DirectX model viewer[1] to run. Using wine 1.1.4 it is possible to lauch because d3dx9_36.dll exists but a method (CreateTexture) of it is stubbed out. I started looking for details on this and came up with this MSDN link[2]. Looking at the code I found that this method is already implemented in the core d3d9 library in dlls/d3d9/texture.c. From what I understand a forward to this function should be enough to get this method to work since the parameters seem to match (except the last parameter in the core d3d9 (HANDLE* pSharedHandle) does not exist in the MSDN definition). Can someone please comment if my thoughts are right here? Thanks, Christoph [1] http://www.teamxtcgames.com/3d_object_viewer.htm [2] http://msdn.microsoft.com/en-us/library/bb172800(VS.85).aspx

2 1

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