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

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

Oct. 10, 2006

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 Oct. 10, 2006

Oct. 10, 2006

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 Oct. 10, 2006

Oct. 10, 2006

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 Oct. 10, 2006

Oct. 10, 2006

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 Oct. 9, 2006

Oct. 9, 2006

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 Oct. 9, 2006

Oct. 9, 2006

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 Oct. 9, 2006

Oct. 9, 2006

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 Oct. 9, 2006

Oct. 9, 2006

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 Oct. 9, 2006

Oct. 9, 2006

> 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

Re: mscoree: Invoke installed win32 mono runtime or exec mono native for .NET executables (try 2)
by Stefan Dösinger Oct. 9, 2006

Oct. 9, 2006

Am Montag 09 Oktober 2006 17:52 schrieb Paul Chitescu: > 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 Do you have any idea how we can deal with other libraries, for example managed DirectX? Is there a way to implement them in mono using wine's DirectX DLLs? I have found a discussion on the mono list about this[1], and it seems that it will be difficult for them to use exported COM interfaces, and the other option is to implement it in Mono on OpenGL directly, which is a waste of effort in my opinion. [1] http://lists.ximian.com/pipermail/mono-list/2005-June/027315.html, and replies

1 0