October 2006 - Wine-devel - list.winehq.org

Re: [msxml3] Add IRunnableObject stub implementation
by Huw Davies 10 Oct '06

10 Oct '06

On Tue, Oct 10, 2006 at 04:45:40PM -0400, Vijay Kiran Kamuju wrote: > Add IRunnableObject stub implementation, It's not at all clear to me what this interface should do in this context. Could you at least add a test that shows that the domdoc object should expose IRunnableObject? Thanks, Huw.

2 1

Re: [PATCH 1/6] lz32/tests: Test more last errors set by LZOpenFile[AW].
by James Hawkins 10 Oct '06

10 Oct '06

On 10/10/06, Saulius Krasuckas <saulius.krasuckas(a)ieee.org> wrote: > @@ -148,6 +149,8 @@ static void test_LZOpenFileA_existing_co > test.szPathName, expected); > LZClose(file); > } else { /* Win9x */ > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, > + "GetLastError() returns %ld\n", GetLastError()); > ok(test.cBytes == 0xA5, > "LZOpenFileA set test.cBytes to %d\n", test.cBytes); > ok(test.nErrCode == ERROR_FILE_NOT_FOUND, > GetLastError returns a DWORD, so these formats need to be %d, not %ld. There is already a big effort to clean these up, so we don't need to introduce more. -- James Hawkins

3 2

client-side DIB copy?
by Damjan Jovanovic 10 Oct '06

10 Oct '06

Hi I'm trying to implement the "client-side DIB copy optimization" mentioned in dlls/winex11.drv/bitblt.c, but I'm having trouble. The patch (against wine-0.9.22) is attached. The one app I know that uses it, Heroes of might and magic 4, runs much faster with the patch, but the graphics come out wrong: mouse droppings, black blocks, pictures drawn in wrong places (over panels) etc. Is there something else I am supposed to be doing, like holding some lock, or doing something after I copy the pixels? I'd really appreciate any help. Damjan

1 0

Re: wined3d: CreateFakeGLContext should also work when we have a context [3rd try]
by Alexandre Julliard 10 Oct '06

10 Oct '06

Jan Zerebecki <jan.wine(a)zerebecki.de> writes: > +static void WineD3D_CreateFakeGLContext(void) { > + TRACE_(d3d_caps)("getting context...\n"); > + if(wined3d_fake_gl_context_ref > 0) goto ret; > + assert(0 == wined3d_fake_gl_context_ref); > + > + wined3d_fake_gl_context_foreign = TRUE; > + Display* display = WineD3D_GetDisplay(); > + XVisualInfo* visInfo = NULL; > + GLXContext glCtx = glXGetCurrentContext(); This isn't thread-safe. Also please avoid mixing declarations and code. > - gl_test = glXGetFBConfigAttrib(ctx->display, cfgs, GLX_RED_SIZE, &rb); > - gl_test = glXGetFBConfigAttrib(ctx->display, cfgs, GLX_GREEN_SIZE, &gb); > - gl_test = glXGetFBConfigAttrib(ctx->display, cfgs, GLX_BLUE_SIZE, &bb); > - gl_test = glXGetFBConfigAttrib(ctx->display, cfgs, GLX_ALPHA_SIZE, &ab); > - gl_test = glXGetFBConfigAttrib(ctx->display, cfgs, GLX_RENDER_TYPE, &type); > - gl_test = glXGetFBConfigAttrib(ctx->display, cfgs, GLX_BUFFER_SIZE, &buf_sz); > + gl_test = glXGetFBConfigAttrib(WineD3D_GetDisplay(), cfgs, GLX_RED_SIZE, &rb); > + gl_test = glXGetFBConfigAttrib(WineD3D_GetDisplay(), cfgs, GLX_GREEN_SIZE, &gb); > + gl_test = glXGetFBConfigAttrib(WineD3D_GetDisplay(), cfgs, GLX_BLUE_SIZE, &bb); > + gl_test = glXGetFBConfigAttrib(WineD3D_GetDisplay(), cfgs, GLX_ALPHA_SIZE, &ab); > + gl_test = glXGetFBConfigAttrib(WineD3D_GetDisplay(), cfgs, GLX_RENDER_TYPE, &type); > + gl_test = glXGetFBConfigAttrib(WineD3D_GetDisplay(), cfgs, GLX_BUFFER_SIZE, &buf_sz); This will be slow, you should retrieve the display only once. > + WineD3D_CreateFakeGLContext(); > + if(wined3d_fake_gl_context_ref > 0) > + cfgs = glXGetFBConfigs(WineD3D_GetDisplay(), DefaultScreen(WineD3D_GetDisplay()), &nCfgs); The ref count should be internal to the get/release functions, you shouldn't use it here. > +extern int wined3d_fake_gl_context_ref; > +extern BOOL wined3d_fake_gl_context_foreign; No reason to export these, they should be static. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: oleaut32: Add tmarshal conformance test
by Dan Kegel 10 Oct '06

10 Oct '06

On 10/9/06, Michal Okresa <michal.okresa(a)ifne.eu> wrote: > On Monday 09 October 2006 19:14, Dan Kegel wrote: ... > > I think it's great you're working on this. What were the bugs? > > Thanks for your comments. > > I discovered these two problems in Rob's patch which make test crash. > * Firstly function IKindaEnumWidget_Release(pKEW) was called twice in test > sequence: > > IKindaEnumWidget_Release(pKEW); > IStream_Seek(pStream, ullZero, STREAM_SEEK_SET, NULL); > hr = CoUnmarshalInterface(pStream, &IID_IKindaEnumWidget, (void **)&pKEW); > ok_ole_success(hr, CoUnmarshalInterface); > IStream_Release(pStream); > > hr = IKindaEnumWidget_Next(pKEW, &pWidget); /* pKEW !!! */ > ok_ole_success(hr, IKindaEnumWidget_Next); > > IKindaEnumWidget_Release(pKEW); > > As you can see, pKEW is used even though memory was released. > > * Second problem was in function: static IWidget *Widget_Create(void). > > ITypeLib_GetTypeInfoOfGuid failed with wine (but only in last test - > test_DispCallFunc) and hr pointer is NULL. Therefore > ITypeLib_Release(pTypeInfo) after IF {} block might not be called. > > hr = ITypeLib_GetTypeInfoOfGuid(pTypeLib, &IID_IWidget, &pTypeInfo); > ok_ole_success(hr, ITypeLib_GetTypeInfoOfGuid); > if (SUCCEEDED(hr)) > { > This->pDispatchUnknown = NULL; > hr = CreateStdDispatch((IUnknown *)&This->lpVtbl, This, pTypeInfo, > &This->pDispatchUnknown); > ok_ole_success(hr, CreateStdDispatch); > ITypeInfo_Release(pTypeInfo); > } > ITypeLib_Release(pTypeInfo); (hr is null) > > This problem was difficult to find because test crashed randomly (winedbg > excercise ;-) ) > > And finally I added few VariantClear() calls (but this isn't important) Thanks for the info... Dan H., could you have a quick look at Michal's patch? - Dan

2 1

Re: localspl/tests: One more Test for InitializePrintMonitor
by Detlef Riekenberg 09 Oct '06

09 Oct '06

On Do, 2006-10-05 at 00:07 +0200, Detlef Riekenberg wrote: > Changelog: > - localspl/tests: One more Test for InitializePrintMonitor > Any hint for my localspl - Patches would be nice. InitializePrintMonitor: http://www.winehq.org/pipermail/wine-patches/2006-October/031353.html Test: http://www.winehq.org/pipermail/wine-patches/2006-October/031268.html Thanks. -- By by ... Detlef

1 0

Re: mscoree: Invoke installed win32 mono runtime or exec mono native for .NET executables (try 3)
by Hans Leidekker 09 Oct '06

09 Oct '06

On Monday 09 October 2006 18:28, Paul Chitescu wrote: > This is the 3rd version of the patch which tries to load mono more robustly > and also dropped the WIN32_LEAN_AND_MEAN. It still fails: trace:mscoree:DllMain (0x7edf0000, 1, 0x1) trace:mscoree:_CorExeMain trace:mscoree:runMain Attempting to use: "MONOEMBED" trace:mscoree:monoKey Mono registry path: "Software\\Novell\\Mono\\1.1.17.2" trace:mscoree:MONO_CorExeMain Mono lib directory: "C:\\Program Files\\Mono-1.1.17.2\\bin" err:module:import_dll Library libglib-2.0-0.dll (which is needed by L"C:\\Program Files\\Mono-1.1.17.2\\bin\\mono-1.dll") not found err:module:import_dll Library libgmodule-2.0-0.dll (which is needed by L"C:\\Program Files\\Mono-1.1.17.2\\bin\\mono-1.dll") not found err:module:import_dll Library libgthread-2.0-0.dll (which is needed by L"C:\\Program Files\\Mono-1.1.17.2\\bin\\mono-1.dll") not found trace:mscoree:runMain Attempting to use: "/usr/bin/mono" You should remove the shlwapi import, it's not needed. And please don't mix tabs and spaces. -Hans

1 0

Re: mscoree: Invoke installed win32 mono runtime or exec mono native for .NET executables
by Hans Leidekker 09 Oct '06

09 Oct '06

Hi Paul, > Several alternatives can be provided in Registry, separated by commas. For > each an attempt to execute it (spawnvp with OVERLAY flag set). The > exception is the keyword MONOEMBED that will try to locate and dynamically > load an installed Win32 mono. I tried your patch with Win32 Mono-1.1.17.2 installed but the MONOEMBED option failed for me. I found out this is because mono-1.dll depends on a number of other dlls that can't be found in the search path. Maybe you could add the Mono dir to the search path? Or instead hand the command line over to mono.exe? Getting past that hurdle I get this Mono exception: ... System.ArgumentException: FontFamily wasn't found. -Hans

2 2

re: oleaut32: Add tmarshal conformance test
by Dan Kegel 09 Oct '06

09 Oct '06

James wrote: >On 10/6/06, Michal Okresa <michal.okresa at ifne.eu> wrote: >> --- >> dlls/oleaut32/tests/tmarshal.c | 1099 >> ++++++++++++++++++++++++++++++++ >> dlls/oleaut32/tests/tmarshal.idl | 159 +++++ >> dlls/oleaut32/tests/tmarshal.rc | 30 + >> dlls/oleaut32/tests/tmarshal_dispids.h | 34 + >> 4 files changed, 1322 insertions(+), 0 deletions(-) > >Um...are you sending this in for Rob Shearman? If so, you need to add >a changelog with his name in it. And how does this relate to the version that Dan Hipschman sent in: http://winehq.org/pipermail/wine-patches/2006-August/029511.html (and which didn't work on Alexandre's machine, http://winehq.org/pipermail/wine-devel/2006-August/050185.html )? - Dan

2 1

Re: dlls/winex11.drv/opengl.c : DEADLOCK not leaving critsection
by Roderick Colenbrander 09 Oct '06

09 Oct '06

> When wine fails initialiwing opengl, the critical sections stays blocked, > wich prevent any other graphical thread to be successfully launched > > by Nicolas Delcros, 2006/10/09 Hi, Thanks for your wine patch but there's already a similar patch in CVS/GIT. Next time make sure that you work on the CVS/GIT version of Wine as it might already contain a fix. Regards, Roderick Colenbrander -- GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl

1 0