- wine-devel - winehq.org

Re: [PATCH] oleaut32: Add tmarshal conformance test
by James Hawkins 06 Oct '06

06 Oct '06

On 10/6/06, Michal Okresa <michal.okresa(a)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(-) > > diff --git a/dlls/oleaut32/tests/tmarshal.c b/dlls/oleaut32/tests/tmarshal.c > new file mode 100644 > index 0000000..be22443 > --- /dev/null > +++ b/dlls/oleaut32/tests/tmarshal.c > @@ -0,0 +1,1099 @@ > +/* > + * Copyright (C) 2005-2006 Robert Shearman for CodeWeavers > + * Um...are you sending this in for Rob Shearman? If so, you need to add a changelog with his name in it. -- James Hawkins

1 0

Re: WineD3D: Add WINED3DUSAGE_OVERLAY
by Vitaliy Margolen 06 Oct '06

06 Oct '06

Stefan Dösinger wrote: > D3D9 does not have Overlay surfaces like ddraw does, so we need a > wined3d-private way to create ddraw overlays. I decided to add a new usage > flag outside of the flags defined by Direct3D and use it in wined3d. d3d8 and > d3d9 have to filter usage flags which are not valid in d3d8 and d3d9 to > prevent broken applications from accidentally passing WINED3DUSAGE_OVERLAY. > > D3D9 does not need overlays, because dynamic textures + drawing textured quads > can provide simmilar functionality. But it is hard to implement ddraw ovelays > using dynamic textures in ddraw.dll in an efficient way, so I decided to > implement overlays in the ddraw way in wined3d. > > > @@ -274,7 +274,7 @@ static HRESULT WINAPI IDirect3DDevice9I > > TRACE("(%p) : w(%d) h(%d) fmt(%d) surf@%p\n", This, Width, Height, Format, *ppSurface); > > - hrc = IWineD3DDevice_CreateSurface(This->WineD3DDevice, Width, Height, Format, Lockable, Discard, Level, &object->wineD3DSurface, Type, Usage, (WINED3DPOOL) Pool,MultiSample,MultisampleQuality,pSharedHandle,SURFACE_OPENGL,(IUnknown *)object); > + hrc = IWineD3DDevice_CreateSurface(This->WineD3DDevice, Width, Height, Format, Lockable, Discard, Level, &object->wineD3DSurface, Type, Usage & WINED3DUSAGE_MASK, (WINED3DPOOL) Pool,MultiSample,MultisampleQuality,pSharedHandle,SURFACE_OPENGL,(IUnknown *)object); > Should we split lines like this? It's doesn't fit even on my 1600x1200 display. > diff --git a/include/wine/wined3d_types.h b/include/wine/wined3d_types.h > index e70a814..278e7d7 100644 > --- a/include/wine/wined3d_types.h > +++ b/include/wine/wined3d_types.h > @@ -1053,6 +1053,7 @@ #define WINED3DUSAGE_DYNAMIC > #define WINED3DUSAGE_AUTOGENMIPMAP 0x00000400L > #define WINED3DUSAGE_DMAP 0x00004000L > #define WINED3DUSAGE_MASK 0x00004FFFL > +#define WINED3DUSAGE_OVERLAY 0x00010000L > I think it would be safer to make it 0x10000000L instead. Vitaliy

5 4

Adobe Photoshop idea
by Karsten Anderson 06 Oct '06

06 Oct '06

I know a lot of people really want newer versions of photoshop (CS, CS2) to work with wine, myself included, so I opened up a feature request on Adobe's Photoshop forum, first with the intent to lobby for a Linux version, but then had the idea that maybe it would be more realistic to get Photoshop to work in Linux via Wine, possibly via having some sort of collaboration between the two dev groups. A reply I got on their messageboard is actually from a dev, and I suggested to him that they work with the Wine devs on this, as it seems much more realistic and possible than a Linux port. So I'm sending this to you guys as a heads up that this might be a good opportunity to get in contact with the Adobe people about getting some ideas on getting Photoshop working in Wine. Here's the link to the thread: http://www.adobeforums.com/cgi-bin/webx/.3bc1d4af/7 maybe someone could reply and say Hi at least and say to Chris (that's the guy) that you'd be receptive to some input from Adobe on this. I can only see this as a win-win situation for everyone, Linux users for getting Photoshop working, and Adobe for the admiration of the Linux community and the possibility of new revenue that might be available to them via new sales of the software. Sorry to drop in from out of nowhere on this, but I thought the opportunity seemed to good to not say anything. So long and thanks for wine, it's awesome :) Karsten

30 59

Re: [WINED3D 1/6] Move D3DSIO structure into the WINED3D namespace.
by Alexandre Julliard 06 Oct '06

06 Oct '06

Ivan Gyurdiev <ivg231(a)gmail.com> writes: > Note: A new file was started for this purpose: wined3d_types.h. This > is _not_ the same as the one in the wine include folder - that one > should be for types which appear in the interface of wined3d, and must > therefore be exposed to other dlls. This one is private. I think the > dll interface should be strictly enforced, so private structures have > no place outside our folder. This will cause massive confusion. There is already a wined3d_private.h file, you should put that stuff in there. -- Alexandre Julliard julliard(a)winehq.org

4 5

Re: DDraw: Protect the ddraw object list
by Mike McCormack 06 Oct '06

06 Oct '06

Stefan Dösinger wrote: > @@ -851,6 +853,13 @@ DllMain(HINSTANCE hInstDLL, > + /* Initialize the ddraw object list critical section unconditionally > + * Even if the app doesn't use multithreaded ddraw objects it can still > + * use multiple ddraw objects in multiple threads > + * Well, initialize it only once > + */ > + if(counter == 0) InitializeCriticalSection(&listCrit); > + Isn't "counter" redundant? When DllMain is called, the loader lock is held. Furthermore, DllMain( ... DLL_PROCESS_ATTACH) is only called once per process, so counter should only ever be 1 after a DLL_PROCESS_ATTACH and 0 after a DETACH. Mike

2 1

Re: wined3d/BltFast
by Stefan Dösinger 06 Oct '06

06 Oct '06

Am Donnerstag 05 Oktober 2006 09:45 schrieb Christopher GAUTIER: > It was due to GL_REGISTER_COMBINERS_NV being glEnabled() before entering > IWineD3DSurfaceImpl_BltOverride. I believe it should be glDisabled() > temporarily while blitting. Yes, they should be disabled, good catch :-)

1 0

Re: msi [2/2]: Perform button control events in greatest to least order [RESEND]
by Mike McCormack 06 Oct '06

06 Oct '06

James Hawkins wrote: > Is there anything wrong with this patch? It fixes bug 6379. msdn is > not specific about which order the events in the ControlEvent table > are executed, greatest to least or vice versa. It might be better to store the results in a list instead of using recursion. Though recursion is a "neat" solution, it's possible to overrun the bounds of the stack on a big data set. Mike

1 0

Re: opengl32: Correctly size and position opengl child windows
by Aaron Slunt 06 Oct '06

06 Oct '06

Ulrich Czekalla wrote: > This patch override glViewport and glScissor to correctly position and size > opengl child windows. > > I've only tested this patch with Google Earth and Google Sketchup so I'd > like to get some feedback to see if this solves the problem for your > application. > > Roderick: I realize you're currently reworking opengl32 so let me know if > this conflicts with what you are doing. > > Thanks, > > /Ulrich > > --- > > dlls/opengl32/make_opengl | 15 +++++++ > dlls/opengl32/opengl_ext.h | 5 ++ > dlls/opengl32/opengl_norm.c | 10 ++--- > dlls/opengl32/wgl.c | 78 +++++++++++++++++++++++++++++++++++++ > dlls/winex11.drv/opengl.c | 72 ++++++++++++++++++++++++++++++++-- > dlls/winex11.drv/winex11.drv.spec | 1 > 6 files changed, 172 insertions(+), 9 deletions(-) > > 6b6a26ef714827017c5ae438b2f843766d711cb2 > diff --git a/dlls/opengl32/make_opengl b/dlls/opengl32/make_opengl > index 837b8d9..bfb0191 100755 > --- a/dlls/opengl32/make_opengl > +++ b/dlls/opengl32/make_opengl > @@ -266,6 +266,21 @@ sub GenerateThunk($$$$$) > if ( $func_ref->[0] eq "glGetIntegerv" ) { > $wine_func_ref_name = "internal_glGetIntegerv"; > } > + if ( $func_ref->[0] eq "glEnable" ) { > + $wine_func_ref_name = "internal_glEnable"; > + } > + if ( $func_ref->[0] eq "glIsEnable" ) { > + $wine_func_ref_name = "internal_glIsEnable"; > + } > + if ( $func_ref->[0] eq "glDisable" ) { > + $wine_func_ref_name = "internal_glDisable"; > + } > + if ( $func_ref->[0] eq "glScissorr" ) { > + $wine_func_ref_name = "internal_glScissorr"; > + } > + if ( $func_ref->[0] eq "glViewport" ) { > + $wine_func_ref_name = "internal_glViewport"; > + } > $ret = "$ret$prefix$wine_func_ref_name( $call_arg);\n"; > if ($thread_safe) { > $ret = "$ret LEAVE_GL();\n"; > diff --git a/dlls/opengl32/opengl_ext.h b/dlls/opengl32/opengl_ext.h > index a7fe233..b7263df 100644 > --- a/dlls/opengl32/opengl_ext.h > +++ b/dlls/opengl32/opengl_ext.h > @@ -75,5 +75,10 @@ extern const int extension_registry_size > > const GLubyte* internal_glGetString(GLenum name); > void internal_glGetIntegerv(GLenum pname, GLint* params); > +void internal_glDisable(GLenum cap); > +void internal_glEnable(GLenum cap); > +GLboolean internal_glIsEnabled(GLenum cap); > +void internal_glScissor(GLint x, GLint y, GLsizei width, GLsizei height); > +void internal_glViewport(GLint x, GLint y, GLsizei width, GLsizei height); > > #endif /* __DLLS_OPENGL32_OPENGL_EXT_H */ > diff --git a/dlls/opengl32/opengl_norm.c b/dlls/opengl32/opengl_norm.c > index 8374a86..047770f 100644 > --- a/dlls/opengl32/opengl_norm.c > +++ b/dlls/opengl32/opengl_norm.c > @@ -815,7 +815,7 @@ void WINAPI wine_glDepthRange( GLclampd > void WINAPI wine_glDisable( GLenum cap ) { > TRACE("(%d)\n", cap ); > ENTER_GL(); > - glDisable( cap ); > + internal_glDisable( cap ); > LEAVE_GL(); > } > > @@ -915,7 +915,7 @@ void WINAPI wine_glEdgeFlagv( GLboolean* > void WINAPI wine_glEnable( GLenum cap ) { > TRACE("(%d)\n", cap ); > ENTER_GL(); > - glEnable( cap ); > + internal_glEnable( cap ); > LEAVE_GL(); > } > > @@ -1772,7 +1772,7 @@ GLboolean WINAPI wine_glIsEnabled( GLenu > GLboolean ret_value; > TRACE("(%d)\n", cap ); > ENTER_GL(); > - ret_value = glIsEnabled( cap ); > + ret_value = internal_glIsEnabled( cap ); > LEAVE_GL(); > return ret_value; > } > @@ -2889,7 +2889,7 @@ void WINAPI wine_glScalef( GLfloat x, GL > void WINAPI wine_glScissor( GLint x, GLint y, GLsizei width, GLsizei height ) { > TRACE("(%d, %d, %d, %d)\n", x, y, width, height ); > ENTER_GL(); > - glScissor( x, y, width, height ); > + internal_glScissor( x, y, width, height ); > LEAVE_GL(); > } > > @@ -3759,6 +3759,6 @@ void WINAPI wine_glVertexPointer( GLint > void WINAPI wine_glViewport( GLint x, GLint y, GLsizei width, GLsizei height ) { > TRACE("(%d, %d, %d, %d)\n", x, y, width, height ); > ENTER_GL(); > - glViewport( x, y, width, height ); > + internal_glViewport( x, y, width, height ); > LEAVE_GL(); > } > diff --git a/dlls/opengl32/wgl.c b/dlls/opengl32/wgl.c > index 1c3973c..76785d7 100644 > --- a/dlls/opengl32/wgl.c > +++ b/dlls/opengl32/wgl.c > @@ -84,6 +84,7 @@ static Display *default_display; /* dis > static HMODULE opengl32_handle; > > static void* (*p_glXGetProcAddressARB)(const GLubyte *); > +static void (*p_SyncCurrentDrawable)(); > > static char internal_gl_disabled_extensions[512]; > static char* internal_gl_extensions = NULL; > @@ -95,6 +96,9 @@ typedef struct wine_glcontext { > GLXFBConfig fb_conf; > GLXContext ctx; > BOOL do_escape; > + RECT viewport; > + RECT scissor; > + BOOL scissor_enabled; > struct wine_glcontext *next; > struct wine_glcontext *prev; > } Wine_GLContext; > @@ -124,6 +128,7 @@ inline static Display *get_display( HDC > return display; > } > > + > /*********************************************************************** > * wglCreateLayerContext (OPENGL32.@) > */ > @@ -563,6 +568,72 @@ BOOL WINAPI wglUseFontOutlinesW(HDC hdc, > return wglUseFontOutlines_common(hdc, first, count, listBase, deviation, extrusion, format, lpgmf, TRUE); > } > > + > +void internal_glEnable(GLenum cap) > +{ > + if (cap == GL_SCISSOR_TEST) > + { > + Wine_GLContext *ctx = (Wine_GLContext *) NtCurrentTeb()->glContext; > + ctx->scissor_enabled = TRUE; > + } > + else > + { > + glEnable(cap); > + } > +} > + > +GLboolean internal_glIsEnabled(GLenum cap) > +{ > + GLboolean enabled; > + > + if (cap == GL_SCISSOR_TEST) > + { > + Wine_GLContext *ctx = (Wine_GLContext *) NtCurrentTeb()->glContext; > + enabled = ctx->scissor_enabled; > + } > + else > + { > + enabled = glIsEnabled(cap); > + } > + > + return enabled; > +} > + > +void internal_glDisable(GLenum cap) > +{ > + if (cap == GL_SCISSOR_TEST) > + { > + Wine_GLContext *ctx = (Wine_GLContext *) NtCurrentTeb()->glContext; > + ctx->scissor_enabled = FALSE; > + } > + else > + { > + glDisable(cap); > + } > +} > + > +void internal_glScissor( GLint x, GLint y, GLsizei width, GLsizei height ) > +{ > + Wine_GLContext *ctx = (Wine_GLContext *) NtCurrentTeb()->glContext; > + > + ctx->scissor.left = x; > + ctx->scissor.top = y; > + ctx->scissor.right = x + width; > + ctx->scissor.bottom = y + height; > + > + p_SyncCurrentDrawable(); > +} > + > +void internal_glViewport( GLint x, GLint y, GLsizei width, GLsizei height ) > +{ > + Wine_GLContext *ctx = (Wine_GLContext *) NtCurrentTeb()->glContext; > + ctx->viewport.left = x; > + ctx->viewport.top = y; > + ctx->viewport.right = x + width; > + ctx->viewport.bottom = y + height; > + p_SyncCurrentDrawable(); > +} > + > const GLubyte * internal_glGetString(GLenum name) { > const char* GL_Extensions = NULL; > > @@ -658,6 +729,13 @@ static BOOL process_attach(void) > /* Interal WGL function */ > wine_wgl.p_wglGetIntegerv = (void *)GetProcAddress(mod, "wglGetIntegerv"); > > + p_SyncCurrentDrawable = (void *)GetProcAddress(mod, "SyncCurrentDrawable"); > + if (!p_SyncCurrentDrawable) > + { > + ERR("Using incompatible version of winex11drv\n"); > + return FALSE; > + } > + > hdc = GetDC(0); > default_display = get_display( hdc ); > ReleaseDC( 0, hdc ); > diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c > index 64b1166..c8650a1 100644 > --- a/dlls/winex11.drv/opengl.c > +++ b/dlls/winex11.drv/opengl.c > @@ -74,6 +74,9 @@ typedef struct wine_glcontext { > GLXFBConfig fb_conf; > GLXContext ctx; > BOOL do_escape; > + RECT viewport; > + RECT scissor; > + BOOL scissor_enabled; > struct wine_glcontext *next; > struct wine_glcontext *prev; > } Wine_GLContext; > @@ -240,12 +243,15 @@ MAKE_FUNCPTR(glBitmap) > MAKE_FUNCPTR(glCopyTexSubImage1D) > MAKE_FUNCPTR(glCopyTexSubImage2D) > MAKE_FUNCPTR(glDrawBuffer) > +MAKE_FUNCPTR(glEnable) > MAKE_FUNCPTR(glEndList) > MAKE_FUNCPTR(glGetError) > MAKE_FUNCPTR(glGetIntegerv) > MAKE_FUNCPTR(glGetString) > MAKE_FUNCPTR(glNewList) > MAKE_FUNCPTR(glPixelStorei) > +MAKE_FUNCPTR(glScissor) > +MAKE_FUNCPTR(glViewport) > #undef MAKE_FUNCPTR > > BOOL X11DRV_WineGL_InitOpenglInfo() > @@ -363,15 +369,18 @@ LOAD_FUNCPTR(glXGetFBConfigs) > /* Standard OpenGL calls */ > LOAD_FUNCPTR(glBindTexture) > LOAD_FUNCPTR(glBitmap) > -LOAD_FUNCPTR(glEndList) > LOAD_FUNCPTR(glCopyTexSubImage1D) > LOAD_FUNCPTR(glCopyTexSubImage2D) > LOAD_FUNCPTR(glDrawBuffer) > +LOAD_FUNCPTR(glEnable) > +LOAD_FUNCPTR(glEndList) > LOAD_FUNCPTR(glGetError) > LOAD_FUNCPTR(glGetIntegerv) > LOAD_FUNCPTR(glGetString) > LOAD_FUNCPTR(glNewList) > LOAD_FUNCPTR(glPixelStorei) > +LOAD_FUNCPTR(glScissor) > +LOAD_FUNCPTR(glViewport) > #undef LOAD_FUNCPTR > > if(!X11DRV_WineGL_InitOpenglInfo()) { > @@ -1353,6 +1362,54 @@ PROC X11DRV_wglGetProcAddress(LPCSTR lps > return NULL; > } > > +/*********************************************************************** > + * X11DRV_SyncCurrentDrawable > + * > + * Adjust the current viewport and stencil in order to position > + * and size the current drawable correctly on the parent window. > + */ > +void X11DRV_SyncCurrentDrawable() > +{ > + RECT rc; > + RECT rootrc; > + HWND hwnd; > + HWND roothwnd; > + int width, height; > + int rheight; > + Wine_GLContext *ctx = (Wine_GLContext *) NtCurrentTeb()->glContext; > + > + if (ctx && (hwnd = WindowFromDC(ctx->hdc)) != 0) > + { > + roothwnd = GetAncestor(hwnd, GA_ROOT); > + > + if (roothwnd != hwnd) > + { > + GetClientRect(roothwnd, &rootrc); > + rheight = rootrc.bottom - rootrc.top; > + > + GetWindowRect(hwnd, &rc); > + width = rc.right - rc.left; > + height = rc.bottom - rc.top; > + > + MapWindowPoints(0, roothwnd, (LPPOINT)&rc, 2); > + > + pglViewport(rc.left + ctx->viewport.left, rheight - rc.bottom + ctx->viewport.top, > + ctx->viewport.right ? (ctx->viewport.right - ctx->viewport.left) : width, > + ctx->viewport.bottom ? (ctx->viewport.bottom - ctx->viewport.top) : height); > + > + pglEnable(GL_SCISSOR_TEST); > + > + if (ctx->scissor_enabled) > + pglScissor(rc.left + min(width, max(0, ctx->scissor.left)), > + rheight - rc.bottom + min(height, max(0, ctx->scissor.top)), > + min(width, max(0, ctx->scissor.right - ctx->scissor.left)), > + min(height, max(0, ctx->scissor.bottom - ctx->scissor.top))); > + else > + pglScissor(rc.left, rheight - rc.bottom, width, height); > + > + } > + } > +} > > /* OpenGL32 wglMakeCurrent */ > BOOL X11DRV_wglMakeCurrent(X11DRV_PDEVICE *physDev, HGLRC hglrc) { > @@ -1397,10 +1454,17 @@ BOOL X11DRV_wglMakeCurrent(X11DRV_PDEVIC > TRACE(" make current for dis %p, drawable %p, ctx %p\n", ctx->display, (void*) drawable, ctx->ctx); > ret = pglXMakeCurrent(ctx->display, drawable, ctx->ctx); > NtCurrentTeb()->glContext = ctx; > - if(ret && type == OBJ_MEMDC) > + if(ret) > { > - ctx->do_escape = TRUE; > - pglDrawBuffer(GL_FRONT_LEFT); > + if (type == OBJ_MEMDC) > + { > + ctx->do_escape = TRUE; > + pglDrawBuffer(GL_FRONT_LEFT); > + } > + else > + { > + X11DRV_SyncCurrentDrawable(); > + } > } > } > wine_tsx11_unlock(); > diff --git a/dlls/winex11.drv/winex11.drv.spec b/dlls/winex11.drv/winex11.drv.spec > index 4e4dcbf..62e3197 100644 > --- a/dlls/winex11.drv/winex11.drv.spec > +++ b/dlls/winex11.drv/winex11.drv.spec > @@ -139,3 +139,4 @@ > @ cdecl wglShareLists(long long) X11DRV_wglShareLists > @ cdecl wglUseFontBitmapsA(long long long long) X11DRV_wglUseFontBitmapsA > @ cdecl wglUseFontBitmapsW(long long long long) X11DRV_wglUseFontBitmapsW > +@ cdecl SyncCurrentDrawable() X11DRV_SyncCurrentDrawable > Unfortunately, this doesn't seem to fix Valve Hammer Editor. On top of that, hammer never spit out any errors to the console before, now the console is filled with: err:syslevel:_EnterSysLevel (0x7ed4a220, level 2): Holding 0x7ec3d9e0, level 3. Expect deadlock!

1 0

Re: dinput: Call missing LeaveCriticalSection in the error case (found by Smatch)
by Vitaliy Margolen 06 Oct '06

06 Oct '06

James Hawkins wrote: > Hi, > > Changelog: > * Call missing LeaveCriticalSection in the error case (found by Smatch). > > dlls/dinput/mouse.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > > ------------------------------------------------------------------------ > > diff --git a/dlls/dinput/mouse.c b/dlls/dinput/mouse.c > index aae5e9a..ea4b2c4 100644 > --- a/dlls/dinput/mouse.c > +++ b/dlls/dinput/mouse.c > @@ -703,7 +703,10 @@ static HRESULT WINAPI SysMouseAImpl_GetD > /* Check if we need to do a mouse warping */ > if (This->need_warp == WARP_NEEDED && (GetCurrentTime() - This->last_warped > 10)) { > if(!dinput_window_check(This)) > + { > + LeaveCriticalSection(&(This->crit)); > return DIERR_GENERIC; > + } > TRACE("Warping mouse to %ld - %ld\n", This->mapped_center.x, This->mapped_center.y); > SetCursorPos( This->mapped_center.x, This->mapped_center.y ); > This->last_warped = GetCurrentTime(); > > This patch will conflict with one of my patches that removes this code completely. Just a heads up. Vitaliy.

1 0

Re: [PATCH 4/5] lz32/tests: WinME sometimes returns short filenames.
by Dmitry Timoshkov 06 Oct '06

06 Oct '06

"Saulius Krasuckas" <saulius.krasuckas(a)ieee.org> wrote: > --- a/dlls/lz32/tests/lzexpand_main.c > +++ b/dlls/lz32/tests/lzexpand_main.c > @@ -356,6 +356,7 @@ static void test_LZOpenFileA(void) > INT file; > static char badfilename_[] = "badfilename_"; > char expected[MAX_PATH]; > + char short_expected[MAX_PATH]; > > SetLastError(0xfaceabee); > /* Check for nonexistent file. */ > @@ -401,9 +402,10 @@ static void test_LZOpenFileA(void) > "LZOpenFileA set test.cBytes to %d\n", test.cBytes); > ok(test.nErrCode == ERROR_SUCCESS, > "LZOpenFileA set test.nErrCode to %d\n", test.nErrCode); > - ok(lstrcmpA(test.szPathName, expected) == 0, > - "LZOpenFileA returned '%s', but was expected to return '%s'\n", > - test.szPathName, expected); > + ok(lstrcmpA(test.szPathName, expected) == 0 || > + lstrcmpA(test.szPathName, short_expected) == 0, /* Win9x */ > + "LZOpenFileA returned '%s', but was expected to return '%s' or '%s'\n", > + test.szPathName, expected, short_expected); > LZClose(file); short_expected is used without being initialized. -- Dmitry.

1 0

Re: wined3d/BltFast
by H. Verbeet 05 Oct '06

05 Oct '06

On 05/10/06, Christopher GAUTIER <krys(a)via.ecp.fr> wrote: > I've identified a bug in IWineD3DSurfaceImpl_BltOverride(). Some blits > used to emulate a fading effect would result in a non-fading, white > screen. > > It was due to GL_REGISTER_COMBINERS_NV being glEnabled() before entering > IWineD3DSurfaceImpl_BltOverride. I believe it should be glDisabled() > temporarily while blitting. > > Patch included. > > Changelog: > * dlls/wined3d/surface.c: > wined3d: Disable GL_REGISTER_COMBINERS_NV (if supported) in > IWineD3DSurfaceImpl_BltOverride > > -- I actualy ran into this issue the other day as well. Patch looks ok.

1 0

Re: Resend: shdocvw: Make sure BSTR is allocated before calling sink
by Robert Shearman 05 Oct '06

05 Oct '06

Cihan Altinay wrote: > This fixes bug 6054 and lets MSN Messenger 7 start up. > http://bugs.winehq.org/show_bug.cgi?id=6054 > > --- > dlls/shdocvw/dochost.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/shdocvw/dochost.c b/dlls/shdocvw/dochost.c > index 5bb40e0..8d78a49 100644 > --- a/dlls/shdocvw/dochost.c > +++ b/dlls/shdocvw/dochost.c > @@ -49,11 +49,12 @@ static void navigate_complete(DocHost *T > V_DISPATCH(params+1) = disp; > > V_VT(&url) = VT_BSTR; > - V_BSTR(&url) = This->url; > + V_BSTR(&url) = SysAllocString(This->url); > > call_sink(This->cps.wbe2, DISPID_NAVIGATECOMPLETE2, &dispparams); > call_sink(This->cps.wbe2, DISPID_DOCUMENTCOMPLETE, &dispparams); > > + SysFreeString(This->url); Please listen to the previous comments and free the correct memory here. -- Rob Shearman

1 0

Re: clusapi: [RESEND] Implements stub dll for clusapi
by Robert Shearman 05 Oct '06

05 Oct '06

Benjamin Arai wrote: > +@ stdcall -private DllMain(long long ptr) > There's no need to export DllMain. -- Rob Shearman

2 2

Re: netapi: Stub for DsGetDcNameA
by Vitaliy Margolen 05 Oct '06

05 Oct '06

Paul Chitescu wrote: > Changelog: Add stub implementation of DsGetDcNameA > > Note: I noticed MSDN listing DsGetDcName as taking 7 parameters (there's an > extra domain name as 3rd parameter) while wine versions have only 6 > parameters. Which is correct? > SDK is correct. And it has only 6. Vitaliy.

1 0

Re: [D3D9 1/8] Remove const qualifier on state_test data
by Alexandre Julliard 05 Oct '06

05 Oct '06

Ivan Gyurdiev <ivg231(a)gmail.com> writes: > Type: Cleanup > > Why: > The const qualifier is unnecessarily restrictive. > I intend to allocate and free such data on the heap in a future patch > (in addition to the current const data). I still don't see any reason for this. Please fix your code to not require that change by simply saving the pointer you are going to free somewhere else. -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: Make.rules.in: Add a new make variable "C_GEN_SRCS" for C files that need to be generated before makedep can be run on them.
by Alexandre Julliard 05 Oct '06

05 Oct '06

Robert Shearman <rob(a)codeweavers.com> writes: > This is useful for generated files such as *_i.c and *_p.c (when widl > can generate them). > diff --git a/Make.rules.in b/Make.rules.in > index 9e7ec07..68544dc 100644 > --- a/Make.rules.in > +++ b/Make.rules.in > @@ -8,6 +8,7 @@ # MODULE : name of the module bein > # > # Each individual makefile may define the following additional variables: > # C_SRCS : C sources for the module > +# C_GEN_SRCS : C sources that are generated for the module You shouldn't need that. IDL files will be listed as sources and make depend will be able to handle that properly, just like it handles idl headers already. -- Alexandre Julliard julliard(a)winehq.org

2 4

Compiling Wine on Ubuntu AMD64
by Ryan Walklin 05 Oct '06

05 Oct '06

Check this forum thread - http://www.ubuntuforums.org/showthread.php?t=167765 , the original post with my modifications on page 7 lets me build Wine with Freetype and OpenGL - WoW works really well. Good luck, feel free to email or post in the thread if you need any more help

1 0

Mem usage in Mac OSX
by Nick Burns 05 Oct '06

05 Oct '06

Im seeing some very odd behaviour in Mac OSX using wine -- and wondered if anyone could enlighten me When I run any application -- I see it start with ~4GB of VM then depending on the app -- it goes upwards of 5.7GB in VM usage (>4GB?) in Activity Monitor (usually because of texture loading or other context loading -- so this is seen in games where you start moving around a map and it starts loading textures into OGL/D3D(->OGL)) Usually when it gets this high -- bad things happen -- basically mallocs start to fail, and the app crashes. I personally dont like the app to crash -- i ha just started playing. So, lets say in GTAVC -- thats me in a heli going from Downtown -> New Haiti == crash. Thats only a few blocks worth of carnage. ---- So, I tested a coule theories -- 1 - Was it bad OGL calls? **No**, the glTexImage calls looked decent -- some even very small (128x128 compressed) 2 - Was it too many mallocs/calloc/reallocs? **No**, none of these were in the GB range... 3 - Finally I found out some very large mmaps/vm_allocates (2x256MB 2x512MB) taking a significant portion of the VM space away from any system libs. I tested this out a bit by printing the mmaps/vm_allocates that I was getting (found the huge 256/512 MB ones) So, in mmap.c:175 -- try_mmap_fixed I put in ' if(len>0x10000000) { printf("len very big -- 0x%08X\n",len); len=0x10000000; } ' to cap the mmaps that i was seeing Yes yes, I realize thats a HORRIBLE thing to do -- but its for the sake of testing and science! This 'cured' my problems in GTAVC -- I no longer crashed (But i would have given enough allocations... or time). My VM usage droped from an initial ~4gb -> ~3gb as I expected I was unable to track down these specific huge allocations... And would like some advice on this situation -- from the sages of Wine... ---- I would like to fix this the correct way I have no idea what happen on Linux in these cases.... - Nick

6 7

[SOLVED] Re: wined3d/CopyRects bug fix
by Christopher GAUTIER 05 Oct '06

05 Oct '06

On Fri, Sep 22, 2006, Stefan Dösinger wrote: > So the idea is to find out what the application does and fix the opengl > blitting code :-) After a debugging session, I found out that the cause of the graphical glitch is that the extension GL_REGISTER_COMBINERS_NV was enabled, and it breaks IWineD3DSurface_BltFast. As a conclusion, Stefan's patch should be applied (and mine too :) ), as they fixes graphical issues. I'll post both of them on wine-patch. Cheers, -- krys

1 0

Implementing sxs?
by Dan Kegel 05 Oct '06

05 Oct '06

http://bugs.winehq.org/show_bug.cgi?id=5276 and its ilk are becoming increasingly annoying. I marked two more bugs as being blocked by this just now. Presumably more semi-intelligent futzing with the stubs will get us by for a lot of apps, but I wonder: how soon are we going to have to really implement side-by-side assemblies?

2 1

Re: msi [3/12]: Assign the property to path if the property is empty
by Mike McCormack 05 Oct '06

05 Oct '06

James Hawkins wrote: > @@ -1456,6 +1456,9 @@ static void msi_dialog_update_pathedit( > prop = msi_dialog_dup_property( dialog, control->property, indirect ); > > path = msi_dup_property( dialog->package, prop ); > + if (!path) > + path = prop; > + > SetWindowTextW( control->hwnd, path ); > SendMessageW( control->hwnd, EM_SETSEL, 0, -1 ); Later on in that code block, it does: msi_free( path ); msi_free( prop ); If path and prop point to the same thing, then we'll try free and illegal pointer. Looks like it would be better to replace msi_dup_property() with another (new) macro function that understands this behavior, rather than changing the code similarly in 4 places. Mike

1 0

Re: KERNEL: honor additional DLL search paths under HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths
by Mike McCormack 05 Oct '06

05 Oct '06

Alex Villacís Lasso wrote: > Changelog: > * Check under HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\App > Paths\\EXENAME.EXE for > additional directory locations to search for DLLs. Fixes Dreamweaver MX > 6.0. This change is incorrect. The App Pathes key is checked by ShellExecute, not by CreateProcess. Try running "wine start exename.exe" Mike

3 5

Re: Wine 0.9.21 fails to run
by Ken Zalewski 04 Oct '06

04 Oct '06

Hi Nick, Thanks for the advice and patches. However, Wine still fails to run ANY programs at all. This is with both of the patches applied (the "ATI" patch and the "NVidia" patch). Moving back to 0.9.20 makes everything work again. My OpenGL library is from NVidia driver 8774 (the most recent), and x11 is 6.8.2. If there is anything you would like me to provide in order to diagnose this, let me know. Thanks. -kz Nick Law wrote: > Ken Zalewski wrote: >> I just upgraded from 0.9.20 to 0.9.21, and now nothing will run, >> including simple programs such as sol.exe and notepad.exe. >> >> The error message I'm receiving is: >> >> X Error of failed request: BadWindow (invalid Window parameter) >> Major opcode of failed request: 145 (NV-GLX) >> Minor opcode of failed request: 4 () >> Resource id in failed request: 0x242 >> Serial number of failed request: 19 >> Current serial number in output stream: 19 >> >> >> My system is a Slackware 10.2 system, running kernel 2.6.17.13, x11 >> 6.8.2, and NVidia driver 8774. >> >> I have seen some other postings on the Net about this, including >> postings in the Ubuntu forums (which means that this is not limited >> to Slackware). >> >> Downgrading to 0.9.20 gets everything working again. My guess, based >> on the "NV-GLX" message, is that something was changed in the OpenGL >> support between 0.9.20 and 0.9.21, and it has broken Wine. >> >> I'll be happy to help debug this. >> >> Sincerely, >> >> Ken Zalewski >> Slackware package maintainer >> Linuxpackages.net >> >> >> >> >> > That's correct, on the wow 1.12 AppDB page in the latest news section > you'll find two patches, the patch marked ATI ( or FBconfigregression > ) will fix the opengl & D3D problems. > > You can download and apply both irrespective of what graphics card you > have. > > Regards > Nick Law >

2 2

Re: wined3d: Report the correct number of available 4-component float vectors for GLSL
by Mirek 04 Oct '06

04 Oct '06

This patch caused regresion in Half-Life 2 Episode One, if i have "UseGLSL"="enabled" HalfLife 2 Episode One crash about 20 seconds after start and menu page is completly white! Only the second part (second gl_max /= 4;) is the bad one, with first part evrything works well. Mirek H. Verbeet napsal(a): > GL_MAX_VERTEX_UNIFORM_COMPONENTS_ARB and > GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB return the number of available > uniform components. A 4-component float vector need 4 uniform > components. > > Changelog: > - Report the correct number of available 4-component float vectors for > GLSL > > > ------------------------------------------------------------------------ > > --- > > dlls/wined3d/directx.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index fdde6ea..0e61c67 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -546,6 +546,7 @@ #undef USE_GL_FUNC > } else if (strcmp(ThisExtn, "GL_ARB_fragment_shader") == 0) { > gl_info->supported[ARB_FRAGMENT_SHADER] = TRUE; > glGetIntegerv(GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB, &gl_max); > + gl_max /= 4; > TRACE_(d3d_caps)(" FOUND: ARB_fragment_shader (GLSL) support - max float ps constants=%u\n", gl_max); > gl_info->ps_glsl_constantsF = gl_max; > } else if (strcmp(ThisExtn, "GL_ARB_imaging") == 0) { > @@ -618,6 +619,7 @@ #undef USE_GL_FUNC > } else if (strcmp(ThisExtn, "GL_ARB_vertex_shader") == 0) { > gl_info->supported[ARB_VERTEX_SHADER] = TRUE; > glGetIntegerv(GL_MAX_VERTEX_UNIFORM_COMPONENTS_ARB, &gl_max); > + gl_max /= 4; > TRACE_(d3d_caps)(" FOUND: ARB_vertex_shader (GLSL) support - max float vs constants=%u\n", gl_max); > gl_info->vs_glsl_constantsF = gl_max; > } else if (strcmp(ThisExtn, "GL_ARB_vertex_blend") == 0) { > > > ------------------------------------------------------------------------ > >

3 16

Re: oleaut32 1/2: [try 3] Implements function varformat:VarWeekdayName
by Alexandre Julliard 04 Oct '06

04 Oct '06

"Benjamin Arai" <me(a)benjaminarai.com> writes: > + if (fAbbrev) > + if (iFirstDay == 0) > + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + LOCALE_IFIRSTDAYOFWEEK - 1) % 7); > + else > + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 4) % 7); > + else > + if (iFirstDay == 0) > + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + LOCALE_IFIRSTDAYOFWEEK - 1) % 7); > + else > + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + iFirstDay + 4) % 7); This obviously can't work, LOCALE_IFIRSTDAYOFWEEK is a constant. -- Alexandre Julliard julliard(a)winehq.org

1 0

Register policy for WGL_ARB_render_texture
by Paweł Różański 04 Oct '06

04 Oct '06

Hi, On current git I see that "wglBindTexImageARB" isn't found on my system (when running nvidia demos). Quick look into dlls/winex11.drv/opengl.c reveals: if (glxRequireExtension("GLX_ATI_render_texture") || glxRequireExtension("GLX_ARB_render_texture")) register_extension(&WGL_ARB_render_texture); My glxinfo doesn't show GLX_ATI_render_texture nor GLX_ARB_render_texture - if i remove that if and force register_extension - all is working The card is GeForce 6200/AGP on opengl 2.0.2 NVIDIA 87.74. I would like only to point that buggy code - maybe someone will came with nice fix. http://bugs.winehq.org/show_bug.cgi?id=6329 take care, -- Paweł Różański

2 1

Re: [PATCH] add some more fake binaries
by Francois Gouget 04 Oct '06

04 Oct '06

On Tue, 3 Oct 2006, Marcus Meissner wrote: > Hi, > > Added dsound.dll and dsound.vxd and ddhelp.exe > to the fake dlls. > > These are checked for by "Curse of Monkey Island" > DirectX check. [...] > +11,,ddhelp.exe > 11,,ddraw.dll > +11,,dsound.dll > +11,,dsound.vxd [...] I think we should not add fake exes if we don't have the corresponding Winelib exe. I have seen it cause applications think that the exe is available and thus try to run it which fails (hence commit efafe08fc6a6d843e52069095947c70abeab867e). So here it seems to fix an application but it may just break many others. IMHO, it would be better to (also) add a stub. Fake dlls probably have the same issue but maybe not vxds. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

1 0

Re: [PATCH 1/3] Compile oleaut32 for win32 but not for win64
by Robert Shearman 04 Oct '06

04 Oct '06

Pavel Roskin wrote: > GLUT32FILES = glut32 > OPENGLFILES = opengl32 wined3d > XFILES = winex11.drv > -EXTRADIRS = @GLU32FILES@ @GLUT32FILES@ @OPENGLFILES@ @XFILES@ > +WIN32FILES = oleaut32 > +EXTRADIRS = @GLU32FILES@ @GLUT32FILES@ @OPENGLFILES@ @XFILES@ Why? -- Rob Shearman

2 1

Re: [TRY2 1/8] gdi32: Cleanup the update_font_info().
by Huw Davies 04 Oct '06

04 Oct '06

On Wed, Oct 04, 2006 at 11:26:49AM +0900, Byeong-Sik Jeon wrote: > Changelog: > Cleanup the updata_font_info(). > > +static void add_nls_font_to_registry( > + HKEY hkey, > + const char *value_name, > + const char *value_data, > + BOOL is_force) .... > + { > + RegSetValueExA(hkey, value_name, 0, REG_SZ, > + (const BYTE *)value_data, (DWORD)(strlen(value_data) + 1)); > + } You shouldn't need the DWORD cast here. > @@ -1546,6 +1528,7 @@ static void update_font_info(void) > + if(!matched_nls_font_list) > + { > + FIXME("there is no font defaults for lcid %04lx/ansi_cp %u", lcid, ansi_cp); > + return; > + } Could you add the missing \n in the FIXME and change the text to read "There are no..."? Thanks, Huw.

1 0

Re: [PATCH 1/3] Compile oleaut32 for win32 but not for win64
by James Hawkins 03 Oct '06

03 Oct '06

On 10/3/06, Pavel Roskin <proski(a)gnu.org> wrote: > From: Pavel Roskin <proski(a)gnu.org> > > Compile oleaut32 for win32 but not for win64 Does win64 not come with oleaut32? What I'm really asking is, why are you making this change? -- James Hawkins

2 4

Re: x11.drv: [2/2] Use internal cached cursor position for GetCursorPos.
by Mirek 03 Oct '06

03 Oct '06

Why was not accepted those patches? With those patches is mouse moving in some games perfetly smooth and correct (Tomb Raider Legend, GTA San Andreas, NFS Most Wanted). Mirek Vitaliy Margolen napsal(a): > ChangeLog: > winex11.drv: Use internal cached cursor position for GetCursorPos. > Query X directly only when cursor is outside process' windows. > > We need to use cached cursor position in GetCursorPos() because it should > return previous position inside hook handler. And get updated right after > hook chain is finished and we sent appropriate mouse messages. > > However we have a problem with synchronizing this cached cursor position > between processes. To solve that we can either share that information between > processes or query X the same we did before, if cursor is outside process' > windows. > > dlls/winex11.drv/event.c | 4 +-- > dlls/winex11.drv/mouse.c | 71 ++++++++++++++++++++++++++++++--------------- > dlls/winex11.drv/window.c | 2 + > dlls/winex11.drv/x11drv.h | 1 + > 4 files changed, 52 insertions(+), 26 deletions(-) > > > > ------------------------------------------------------------------------ > > b81f98baf1ba0321f413a0a0c3a5cf90b07fab8c > diff --git a/dlls/winex11.drv/event.c b/dlls/winex11.drv/event.c > index 210d816..bbd1a0c 100644 > --- a/dlls/winex11.drv/event.c > +++ b/dlls/winex11.drv/event.c > @@ -87,7 +87,7 @@ static struct event_handler handlers[MAX > { ButtonRelease, X11DRV_ButtonRelease }, > { MotionNotify, X11DRV_MotionNotify }, > { EnterNotify, X11DRV_EnterNotify }, > - /* LeaveNotify */ > + { LeaveNotify, X11DRV_LeaveNotify }, > { FocusIn, EVENT_FocusIn }, > { FocusOut, EVENT_FocusOut }, > { KeymapNotify, X11DRV_KeymapNotify }, > @@ -116,7 +116,7 @@ static struct event_handler handlers[MAX > { MappingNotify, X11DRV_MappingNotify }, > }; > > -static int nb_event_handlers = 18; /* change this if you add handlers above */ > +static int nb_event_handlers = 19; /* change this if you add handlers above */ > > > /* return the name of an X event */ > diff --git a/dlls/winex11.drv/mouse.c b/dlls/winex11.drv/mouse.c > index 14ffcc7..470b9f1 100644 > --- a/dlls/winex11.drv/mouse.c > +++ b/dlls/winex11.drv/mouse.c > @@ -70,6 +70,7 @@ static const UINT button_up_flags[NB_BUT > }; > > POINT cursor_pos; > +static int mouse_inside_wine; > > static CRITICAL_SECTION cursor_CritSection; > static CRITICAL_SECTION_DEBUG critsect_debug = > @@ -697,17 +698,29 @@ BOOL X11DRV_SetCursorPos( INT x, INT y ) > { > Display *display = thread_display(); > > - TRACE( "warping to (%d,%d)\n", x, y ); > + /* Cursor position hasn't changed at all or not yet. */ > + EnterCriticalSection(&cursor_CritSection); > + if (cursor_pos.x == x && cursor_pos.y == y) > + { > + LeaveCriticalSection(&cursor_CritSection); > > - wine_tsx11_lock(); > - XWarpPointer( display, root_window, root_window, 0, 0, 0, 0, x, y ); > - XFlush( display ); /* avoids bad mouse lag in games that do their own mouse warping */ > - wine_tsx11_unlock(); > + /* We still need to generate WM_MOUSEMOVE */ > + queue_raw_mouse_message( WM_MOUSEMOVE, NULL, x, y, 0, GetCurrentTime(), 0, 0 ); > + return TRUE; > + } > + LeaveCriticalSection(&cursor_CritSection); > + > + TRACE( "warping to (%d,%d)\n", x, y ); > > EnterCriticalSection( &cursor_CritSection ); > cursor_pos.x = x; > cursor_pos.y = y; > LeaveCriticalSection( &cursor_CritSection ); > + > + wine_tsx11_lock(); > + XWarpPointer( display, root_window, root_window, 0, 0, 0, 0, x, y ); > + XFlush( display ); /* avoids bad mouse lag in games that do their own mouse warping */ > + wine_tsx11_unlock(); > return TRUE; > } > > @@ -716,25 +729,28 @@ BOOL X11DRV_SetCursorPos( INT x, INT y ) > */ > BOOL X11DRV_GetCursorPos(LPPOINT pos) > { > - Display *display = thread_display(); > - Window root, child; > - int rootX, rootY, winX, winY; > - unsigned int xstate; > - BOOL res; > - > - wine_tsx11_lock(); > - res = XQueryPointer( display, root_window, &root, &child, > - &rootX, &rootY, &winX, &winY, &xstate ); > - wine_tsx11_unlock(); > - if (res) > + if (!mouse_inside_wine) > { > - update_key_state( xstate ); > - update_button_state( xstate ); > - TRACE("pointer at (%d,%d)\n", winX, winY ); > - EnterCriticalSection( &cursor_CritSection ); > - cursor_pos.x = winX; > - cursor_pos.y = winY; > - LeaveCriticalSection( &cursor_CritSection ); > + Display *display = thread_display(); > + Window root, child; > + int rootX, rootY, winX, winY; > + unsigned int xstate; > + Bool res; > + > + wine_tsx11_lock(); > + res = XQueryPointer( display, root_window, &root, &child, > + &rootX, &rootY, &winX, &winY, &xstate ); > + wine_tsx11_unlock(); > + if (res) > + { > + update_key_state( xstate ); > + update_button_state( xstate ); > + TRACE("pointer at (%d,%d)\n", winX, winY ); > + EnterCriticalSection( &cursor_CritSection ); > + cursor_pos.x = winX; > + cursor_pos.y = winY; > + LeaveCriticalSection( &cursor_CritSection ); > + } > } > EnterCriticalSection( &cursor_CritSection ); > *pos = cursor_pos; > @@ -838,6 +854,7 @@ void X11DRV_EnterNotify( HWND hwnd, XEve > > TRACE("hwnd %p, event->detail %d\n", hwnd, event->detail); > > + mouse_inside_wine = TRUE; > if (!hwnd) return; > if (event->detail == NotifyVirtual || event->detail == NotifyNonlinearVirtual) return; > > @@ -847,3 +864,11 @@ void X11DRV_EnterNotify( HWND hwnd, XEve > X11DRV_send_mouse_input( hwnd, MOUSEEVENTF_MOVE | MOUSEEVENTF_ABSOLUTE, > pt.x, pt.y, 0, EVENT_x11_time_to_win32_time(event->time), 0, 0 ); > } > + > +/*********************************************************************** > + * X11DRV_LeaveNotify > + */ > +void X11DRV_LeaveNotify( HWND hwnd, XEvent *xev ) > +{ > + mouse_inside_wine = FALSE; > +} > diff --git a/dlls/winex11.drv/window.c b/dlls/winex11.drv/window.c > index fe07ddf..17ecc1e 100644 > --- a/dlls/winex11.drv/window.c > +++ b/dlls/winex11.drv/window.c > @@ -758,7 +758,7 @@ static Window create_whole_window( Displ > attr.event_mask = (ExposureMask | PointerMotionMask | > ButtonPressMask | ButtonReleaseMask | EnterWindowMask | > KeyPressMask | KeyReleaseMask | StructureNotifyMask | > - FocusChangeMask | KeymapStateMask); > + FocusChangeMask | KeymapStateMask | LeaveWindowMask); > mask |= CWBitGravity | CWBackingStore | CWEventMask; > > wine_tsx11_lock(); > diff --git a/dlls/winex11.drv/x11drv.h b/dlls/winex11.drv/x11drv.h > index b5bec51..2e1423e 100644 > --- a/dlls/winex11.drv/x11drv.h > +++ b/dlls/winex11.drv/x11drv.h > @@ -611,6 +611,7 @@ extern void X11DRV_ButtonPress( HWND hwn > extern void X11DRV_ButtonRelease( HWND hwnd, XEvent *event ); > extern void X11DRV_MotionNotify( HWND hwnd, XEvent *event ); > extern void X11DRV_EnterNotify( HWND hwnd, XEvent *event ); > +extern void X11DRV_LeaveNotify( HWND hwnd, XEvent *event ); > extern void X11DRV_KeyEvent( HWND hwnd, XEvent *event ); > extern void X11DRV_KeymapNotify( HWND hwnd, XEvent *event ); > extern void X11DRV_Expose( HWND hwnd, XEvent *event ); > > > > ------------------------------------------------------------------------ > >

1 0

Re: [WINED3D 6/8] Stateblock support for dmap and vtf samplers
by H. Verbeet 03 Oct '06

03 Oct '06

On 03/10/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote: > + IWineD3DDevice_SetTexture(iface, D3DDMAPSAMPLER, NULL); I don't think wined3d should depend on d3d9 includes. There are currently a number of places in wined3d where we do use d3d9 constants, but at least for new code I don't think we should add dependencies on d3d9 includes.

5 9

Re: LOSTWAGES: Instructions for getting additional modules
by Mike McCormack 03 Oct '06

03 Oct '06

Detlef Riekenberg wrote: > When switching the Instructions for the Wine tree > from cvs to git, the Instructions for the > additional modules (docs, lostwages, ...) got lost. They're still available at the old link: http://www.winehq.org/site/cvs It would be nice to move the remaining modules to Git too, IMO. Mike

4 3

AMD64 compilation successful; still not working
by Alexander K. Seewald 03 Oct '06

03 Oct '06

Hi, I've managed to compile the current CVS version under AMD64, according to the WineOn64bit-Wiki for Debian. So far, so good. However, all tests fail and starting wine gives an error code of 2. --version gives no output. wine-kthread gives an error code of 139 (segmentation violation), wine-pthread seems to work. Debugging wine shows that the error appears when execve'ing (should have been somewhat obvious ;-) When debugging wine-kthread, I get the following error on the first line of code: 0x557721ba in __libc_pthread_init () from /emul/ia32-linux/lib/tls/libc.so.6 Interestingly, my libc.so.6 link points to libc-2.3.2.so. Hope that is ok... it is defined in the ia32-libc6 debian package from stable. :-> Might this have something to do with my 4GB of memory? I am open for suggestions... Best, Alex -- Dr. Alexander K. Seewald GE Money Bank, Analytics/CRM +43(664)1106886 ------------------------------------------------ Information wants to be free; Information also wants to be expensive (S.Brant) --------------- alex.seewald.at ----------------

2 3

Re: [crypt32] Win64 printf format warning fixes
by Paul Vriens 03 Oct '06

03 Oct '06

On Tue, 2006-10-03 at 11:18 +0200, Paul Vriens wrote: > Hi, > > leftover after Juan's patch. > > Changelog > Win64 printf format warning fixes > > Cheers, > Forget this one, Juan already sent in a patch (and it was applied). Cheers, Paul.

1 0

Re: [gdi32 1/6]: Cleanup the update_font_list().
by Huw Davies 03 Oct '06

03 Oct '06

On Tue, Oct 03, 2006 at 01:39:23PM +0900, Byeong-Sik Jeon wrote: > Cleanup the update_font_list(). I'm not convinced this is a cleanup, see below for comments. > +#define AddNlsFontToRegistry(hKey, ValueNameA, Data, bForce) do\ > + {\ > + DWORD reg_type;\ > + if(bForce == TRUE ||\ > + RegQueryValueExA(hKey, ValueNameA, 0, &reg_type, NULL, NULL) != ERROR_SUCCESS ||\ > + reg_type != REG_SZ)\ > + {\ > + RegSetValueExA(hKey, ValueNameA, 0, REG_SZ, (const BYTE *)Data, (DWORD)(strlen(Data) + 1));\ > + }\ > + } while(0) Please avoid macro abuse like this and use an inlined function instead. It's also nicer to call it something like add_nls_font_to_registry so that it's easier to read and doesn't look like a Windows API. > + RegCreateKeyExW(HKEY_LOCAL_MACHINE, > + is_win9x() ? win9x_font_reg_key : winnt_font_reg_key, > + 0, NULL, 0, KEY_ALL_ACCESS, NULL, &hkey, NULL); > + AddNlsFontToRegistry(hkey, "Courier" , matched_nls_font_list->courier, TRUE); > + AddNlsFontToRegistry(hkey, "MS Serif" , matched_nls_font_list->serif, TRUE); > + AddNlsFontToRegistry(hkey, "MS Sans Serif", matched_nls_font_list->sserif, TRUE); > + AddNlsFontToRegistry(hkey, "Small Fonts" , matched_nls_font_list->small, TRUE); > + RegCloseKey(hkey); Here you only create either the win9x key or the winnt key. I'd prefer that you created both like the old code did. Thanks, Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: [PATCH] added debugregisters testcase
by Dmitry Timoshkov 03 Oct '06

03 Oct '06

"Marcus Meissner" <marcus(a)jet.franken.de> wrote: >> exception.c:281: Test failed: failed to set debugregister 7 to 0x155, got >> 555 > > Interesting, it apparently changed the 0x155 from my code to > 0x555, turning a single byte watch into a 2 byte watch. Or perhaps > it did not use my code, but had something set there already. Looks like 0x400 is already set there, because changing 0x155 to 0x55 leads to the following: exception.c:281: Test failed: failed to set debugregister 7 to 0x55, got 455 -- Dmitry.

1 0

Re: [gdi32 5/6]: Use the [HKLM\...\GRE_Initialize] for languagedependent stock fonts.
by Dmitry Timoshkov 03 Oct '06

03 Oct '06

"Byeong-Sik Jeon" <wjsqudtlr(a)gmail.com> wrote: > diff --git a/dlls/gdi/gdiobj.c b/dlls/gdi/gdiobj.c > index 3d5450d..740504c 100644 > --- a/dlls/gdi/gdiobj.c > +++ b/dlls/gdi/gdiobj.c > +static LOGFONTW SystemFont = > +static LOGFONTW DeviceDefaultFont = > +static LOGFONTW SystemFixedFont = > +static LOGFONTW DefaultGuiFont = Any reason you don't make LOGFONTs above const? -- Dmitry.

1 0

Re: [PATCH] added debugregisters testcase
by Dmitry Timoshkov 03 Oct '06

03 Oct '06

"Marcus Meissner" <marcus(a)jet.franken.de> wrote: > + ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS; > + res = pNtGetContextThread(GetCurrentThread(), &ctx); > + ok (res == STATUS_SUCCESS,"NtGetContextThread failed with %lx", res); > + ok(ctx.Dr7 == 0x155,"failed to set debugregister 7 to 0x155"); This test fails for me under XP SP2 with all updates: exception.c:281: Test failed: failed to set debugregister 7 to 0x155, got 555 -- Dmitry.

1 0

Re: DDraw: Don't destroy complex attached surfaces even if explicitely requested as they will be liquidated anyway when the root is destroyed.
by Stefan Dösinger 03 Oct '06

03 Oct '06

Am Freitag 22 September 2006 16:55 schrieb Elie Morisse: > A new version of my refcounting patch, lighter and honoring Stefan Dösinger > proposal. Is there any reason why this patch wasn't applied? It looks ok to me, and it complies with the wording of the msdn(complex surfaces can only be destroyed by destroying the root). It might be good to have a test case, but how can we test if something has been destroyed?

1 0

Re: DDraw: Implement depth filling through blit. ( Resubmit )
by Stefan Dösinger 03 Oct '06

03 Oct '06

Am Freitag 22 September 2006 17:12 schrieb Elie Morisse: > Resubmit of my previous patch. Be aware that it is completing an older > Stefan Dosinger patch which hasn't been accepted, but can be applied > independently ( it'll be quite useless nevertheless.. ) I think you should replace the 4294967295.0 by something more meaningful like (float) DWORD_MAX, or how the constant is called.

1 0

RFC: dlls/user/tests/win.c fix
by Juan Lang 03 Oct '06

03 Oct '06

The attached patch (sorry, crappy mailer) fixes the win.c failure I was seeing. Is it correct? --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 7

Re: Request for Test: exception handling test
by Stefan Leichter 02 Oct '06

02 Oct '06

Am Thursday 01 January 1970 01:00 schrieb Marcus Meissner: > Hi, > > Can someone with ability to run the testsuite on Windows please test > the following new 2 testcases under Windows? > > They succeed in WINE now, but I wonder if they will work in Windows. > > Ciao, Marcus Hi, i don't get any new error on win2k. Attached is the logging of the modified test target. Bye Stefan

1 0

Scrambled VB Fonts improving.
by Joe Baker 02 Oct '06

02 Oct '06

2 1

Request for Test: exception handling test
by Marcus Meissner 02 Oct '06

02 Oct '06

Hi, Can someone with ability to run the testsuite on Windows please test the following new 2 testcases under Windows? They succeed in WINE now, but I wonder if they will work in Windows. Ciao, Marcus --- dlls/ntdll/tests/exception.c | 145 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 145 insertions(+), 0 deletions(-) ef86b7cd65ade45a1e1cd269bff378166d1ad677 diff --git a/dlls/ntdll/tests/exception.c b/dlls/ntdll/tests/exception.c index 1d00816..20ff896 100644 --- a/dlls/ntdll/tests/exception.c +++ b/dlls/ntdll/tests/exception.c @@ -24,6 +24,7 @@ #define _WIN32_WINNT 0x500 /* For NTSTATUS */ #endif +#include <stdio.h> #include "ntstatus.h" #define WIN32_NO_STATUS #include "windef.h" @@ -281,6 +282,148 @@ static void test_debug_regs(void) ok(ctx.Dr7 == 0x155,"failed to set debugregister 7 to 0x155"); } +/* test the single step exception behaviour */ +static int gotsinglesteps = 0; +static DWORD single_step_handler( EXCEPTION_RECORD *rec, EXCEPTION_REGISTRATION_RECORD *frame, + CONTEXT *context, EXCEPTION_REGISTRATION_RECORD **dispatcher ) +{ + gotsinglesteps++; + ok (!(context->EFlags & 0x100), "eflags has single stepping bit set\n"); + return ExceptionContinueExecution; +} + +static BYTE single_stepcode[] = { + 0x9c, /* pushf */ + 0x58, /* pop %eax */ + 0x0d,0,1,0,0, /* or $0x100,%eax */ + 0x50, /* push %eax */ + 0x9d, /* popf */ + 0x35,0,1,0,0, /* xor $0x100,%eax */ + 0x50, /* push %eax */ + 0x9d, /* popf */ + 0xc3 +}; + +static void test_single_step(void) +{ + struct { + EXCEPTION_REGISTRATION_RECORD frame; + } exc_frame; + void (*func)(void) = (void *)single_stepcode; + + pNtCurrentTeb = (void *)GetProcAddress( GetModuleHandleA("ntdll.dll"), "NtCurrentTeb" ); + if (!pNtCurrentTeb) { + trace( "NtCurrentTeb not found, skipping tests\n" ); + return; + } + exc_frame.frame.Handler = single_step_handler; + exc_frame.frame.Prev = pNtCurrentTeb()->Tib.ExceptionList; + pNtCurrentTeb()->Tib.ExceptionList = &exc_frame.frame; + func(); + ok(gotsinglesteps == 1, "expected 1 single step exceptions, got %d\n", gotsinglesteps); + pNtCurrentTeb()->Tib.ExceptionList = exc_frame.frame.Prev; +} + +/* Test the alignment check (AC) flag handling. */ +static BYTE align_check_code[] = { + 0x55, /* push %ebp */ + 0x89,0xe5, /* mov %esp,%ebp */ + 0x9c, /* pushf */ + 0x58, /* pop %eax */ + 0x0d,0,0,4,0, /* or $0x40000,%eax */ + 0x50, /* push %eax */ + 0x9d, /* popf */ + 0x8b,0x45,8, /* mov 0x8(%ebp),%eax */ + 0xc7,0x40,1,42,0,0,0, /* movl $42,0x1(%eax) */ + 0x9c, /* pushf */ + 0x58, /* pop %eax */ + 0x35,0,0,4,0, /* xor $0x40000,%eax */ + 0x50, /* push %eax */ + 0x9d, /* popf */ + 0x5d, /* pop %ebp */ + 0xc3, /* ret */ +}; + +static int gotalignfaults = 0; +static DWORD align_check_handler( EXCEPTION_RECORD *rec, EXCEPTION_REGISTRATION_RECORD *frame, + CONTEXT *context, EXCEPTION_REGISTRATION_RECORD **dispatcher ) +{ + ok (!(context->EFlags & 0x40000), "eflags has AC bit set\n"); + gotalignfaults++; + return ExceptionContinueExecution; +} + +/* Not working in Linux now. Causes problems with unrelated functions. + * have to fix them sometime :( + */ +#undef STACK_ALIGN_TEST + +#ifdef STACK_ALIGN_TEST +static BYTE align_check_code2[] = { + 0x55, /* pushl %ebp */ + 0x89,0xe5, /* movl %esp,%ebp */ + 0x9c, /* pushf */ + 0x58, /* pop %eax */ + 0x0d,0,0,4,0, /* or $0x40000,%eax */ + 0x50, /* push %eax */ + 0x9d, /* popf */ + 0x35,0,0,4,0, /* xor $0x40000,%eax */ + 0x83,0xec,2, /* sub $0x2,%esp */ + 0x50, /* push %eax - test fault on stack */ + 0x89,0xec, /* movl %ebp, %esp */ + 0x50, /* push %eax */ + 0x9d, /* popf */ + 0x5d, /* popl %ebp */ + 0xcb /* lret */ +}; + +static DWORD align_check_handler2( EXCEPTION_RECORD *rec, EXCEPTION_REGISTRATION_RECORD *frame, + CONTEXT *context, EXCEPTION_REGISTRATION_RECORD **dispatcher ) +{ + ok (!(context->EFlags & 0x40000), "eflags has AC bit set\n"); + if (context->Esp & 0x2) { + gotalignfaults++; + context->Esp+=2; + } + return ExceptionContinueExecution; +} +#endif + + +static void test_align_faults(void) +{ + int twoints[2]; + struct { + EXCEPTION_REGISTRATION_RECORD frame; + } exc_frame; + void (*func1)(int*) = (void *)align_check_code; +#ifdef STACK_ALIGN_TEST + void (*func2)(void) = (void *)align_check_code2; +#endif + + pNtCurrentTeb = (void *)GetProcAddress( GetModuleHandleA("ntdll.dll"), "NtCurrentTeb" ); + if (!pNtCurrentTeb) { + trace( "NtCurrentTeb not found, skipping tests\n" ); + return; + } + exc_frame.frame.Handler = align_check_handler; + exc_frame.frame.Prev = pNtCurrentTeb()->Tib.ExceptionList; + pNtCurrentTeb()->Tib.ExceptionList = &exc_frame.frame; + + gotalignfaults=0; + func1(twoints); + ok(gotalignfaults == 0, "got %d alignment faults, expected 0\n", gotalignfaults); + +#ifdef STACK_ALIGN_TEST + exc_frame.frame.Handler = align_check_handler2; + gotalignfaults=0; + func2(); + ok(gotalignfaults == 0, "got %d alignment faults, expected 0\n", gotalignfaults); +#endif + + pNtCurrentTeb()->Tib.ExceptionList = exc_frame.frame.Prev; +} + #endif /* __i386__ */ START_TEST(exception) @@ -288,5 +431,7 @@ START_TEST(exception) #ifdef __i386__ test_prot_fault(); test_debug_regs(); + test_single_step(); + test_align_faults(); #endif } -- 1.2.4

1 0

no backtrace with wine crashes
by James Hawkins 02 Oct '06

02 Oct '06

Hey guys, Since very recently, any time we get a crash in Wine, winedbg does not show a backtrace. This makes it significantly more difficult to debug the crash. Is anyone else experiencing this? I'll run a regression test as soon as I can. wine: Unhandled page fault on read access to 0x00000000 at address 0x7ebfeb70 (thread 0011), starting debugger... Modules: Cannot get info on module while no process is loaded Threads: process tid prio (all id:s are in hex) 00000013 00000021 0 00000020 0 0000001e 0 0000001b 0 00000019 0 00000018 0 00000017 0 00000016 0 00000014 0 00000010 (D) (null) 00000023 0 00000022 0 00000012 0 00000011 0 0000000a 0000000c 0 0000000b 0 -- James Hawkins

2 5

Implementation question for CryptSIPLoad
by Paul Vriens 02 Oct '06

02 Oct '06

Hi, In CryptSIPLoad I have to load the some internal crypt32 function pointers into a structure. Will the following work ? : pSipDispatch->pfGet = &CryptSIPGetSignedDataMsg; pSipDispatch->pfPut = &CryptSIPPutSignedDataMsg; pSipDispatch->pfCreate = &CryptSIPCreateIndirectData; pSipDispatch->pfVerify = &CryptSIPVerifyIndirectData; pSipDispatch->pfRemove = &CryptSIPRemoveSignedDataMsg; What happens if I have another dll loaded that has the same functions (wintrust, msisip ....)? Do I need to do an explicit LoadLibrary or GetModuleHandle? The tests I've already created (in current GIT) succeed with the above 'solution' but I just want to make sure there aren't any side-effects. Cheers, Paul.

1 0

RE: compiling wine for amd64 on ubuntu dapper 6.06
by Ge van Geldorp 02 Oct '06

02 Oct '06

> From: "Gerald Britton" <gerald.britton(a)gmail.com> > > 1. /configure can't find opengl, and produces these messages: > > configure: WARNING: Wine will be build without OpenGL or > Direct3D support > configure: WARNING: because something is wrong with the OpenGL setup: > configure: WARNING: No OpenGL library found on this system. I found the easiest way around this problem is to run configure using --without-opengl. I doubt OpenGL is very useful at the moment for 64-bit Wine anyway. Ge van Geldorp.

2 1

Re: wined3d - fix grammatical errors
by Stefan Dösinger 02 Oct '06

02 Oct '06

I think Alexandre wants 1 patch per mail ;-)

1 0

Re: Copy protection
by Tim Schmidt 02 Oct '06

02 Oct '06

On 10/2/06, James Courtier-Dutton <James(a)superbug.co.uk> wrote: > The easiest way round this is to simply recognise the executable with > the copy protection, and simply install a hook to catch the appropriate > file system or registry calls and divert them to a special handling > routine to satisfy the application. The difficulty would come from > actually implementing the "copy protection" part. I.e. Preventing the > wine user from copying the software. Since we're not getting cooperation from the copy protection software houses, I don't think that's a major goal of this work. We'd like _copy protected_ software to work with Wine, who cares if the _copy protection_ software actually works beyond allowing the program to run? --tim

1 0

Full A and W implementations for registry functions in shlwapi
by Paul Vriens 02 Oct '06

02 Oct '06

Hi, is there any reason that some of the registry functions in shlwapi have a full implementation for both the A and the W calls, instead of calling W from A? (other then nobody bothered). Is it worthwhile to be done? (Could be another janitorial task). Cheers, Paul.

1 0

building outside of source tree fails - making wrong makedep
by Michael [Plouj] Ploujnikov 02 Oct '06

02 Oct '06

My Wine source is in ~/apps/wine-git. I'm trying to build Wine inside ~/apps/build_dir. So, I do this: $ mkdir ~/apps/build_dir $ cd ~/apps/build_dir $ ../wine-git/configure --x-libraries=/emul/linux/x86/usr/lib/ LDFLAGS="-L/emul/linux/x86/usr/lib -L/emul/linux/x86/lib" --verbose &> config.output # config.output attached # Then I run make, and this is where it fails: $ make make[1]: Entering directory `/home/plouj/apps/build_dir/tools' ../tools/makedep -C../../wine-git/tools -S../../wine-git -T.. -I/usr/include/fre etype2 bin2res.c fnt2bdf.c fnt2fon.c make_ctests.c makedep.c relpath.c sfnt2fnt. c make[1]: ../tools/makedep: Command not found make[1]: [Makefile] Error 127 (ignored) make[1]: `../../wine-git/tools/makedep' is up to date. make[1]: Leaving directory `/home/plouj/apps/build_dir/tools' make[1]: Entering directory `/home/plouj/apps/build_dir/libs' make[2]: Entering directory `/home/plouj/apps/build_dir/libs/port' ../../tools/makedep -C../../../wine-git/libs/port -S../../../wine-git -T../.. f fs.c fstatvfs.c futimes.c getopt.c getopt1.c getpagesize.c gettid.c interlocked. c lstat.c memcpy_unaligned.c memmove.c mkstemps.c pread.c pwrite.c readlink.c si gsetjmp.c spawn.c statvfs.c strcasecmp.c strerror.c strncasecmp.c usleep.c .... What this looks like to me is make trying to build ../../wine-git/tools/makedep which already exists, but it's trying to use ../tools/makedep, which doesn't exist, to actually build other stuff. I am trying to build Wine on Gentoo AMD64. You can see that the configure command is already convoluted to achieve that. Wine _does_ build if I run make inside the source directory. It has been working fine since before 0.9.10. That is not what I'm doing here. I don't know anything about how make works and especially about how the Makefiles in Wine are setup so I would appreciate any help to track down this problem. It's been suggested that maybe this happens because my system is broken, but I don't want to come to that conclusion without any evidence. My goal is not to simply blame someone but to actually fix what is broken. -- () ASCII Ribbon Campaign /\ - against HTML mail & vCards

2 1

Re: gdi32: Improve get_nearest_charset().
by Huw Davies 02 Oct '06

02 Oct '06

On Mon, Oct 02, 2006 at 06:42:50AM +0900, Byeong-Sik Jeon wrote: > Use the font linking information at get_nearest_charset(). > MS-Windows do it(equal behavior). Looks good to me. Thanks, Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: wined3d - fix grammatical errors
by James Hawkins 02 Oct '06

02 Oct '06

On 10/1/06, EA Durbin <ead1234(a)hotmail.com> wrote: > > Please read up on the patch submission process [1]. Only one patch per email, and you need to include a changelog for each patch. Personally, I don't think the sentences in question need to be changed though. [1] http://winehq.org/site/sending_patches -- James Hawkins

2 2

-D_WIN64 breaks build
by Ivan Gyurdiev 01 Oct '06

01 Oct '06

utf8.h includes umachine.h umachine.h detects _WIN64 definition and includes pwin32.h pwin32.h defines U_EXPORT to __declspec(dllexport) ...later U_INTERNAL includes U_EXPORT in its definition so eventually it errors out: gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -D_WIN64 -o bidi.o bidi.c In file included from /usr/include/unicode/utf.h:222, from /usr/include/unicode/utypes.h:38, from /usr/include/unicode/ubidi.h:21, from bidi.c:27: /usr/include/unicode/utf8.h: In function ‘__declspec’: /usr/include/unicode/utf8.h:75: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘UChar32’ /usr/include/unicode/utf8.h:82: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘int32_t’ ...

1 1

a-10 cuba directdraw regression
by Matheus Izvekov 01 Oct '06

01 Oct '06

Hi, a-10 cuba used to work on older versions of wine, but now there are 2 regressions: when you are in the mission selection window and you start the game by clicking in fly mission button, this window keeps on top of the directdraw window, making the game unplayable. Changing resolution in the preferences window doesnt change the resolution per se, but the game draws in-game windows and fonts bigger, making everything look weird. What looks suspect is this: fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x16cfd0)->((nil),00000008) fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x16cfd0)->(0x10046,00000013) Ive read the description of this function, and those 2 errors seem related to that. you can download the demo (7mb) from: http://www.gamershell.com/download_8121.shtml It exhibits those 2 problems as well, exactly like the full game. Other than that, and directplay and joystick support, the game is 100% fine, and i hope by fixing that the game could go silver. Thank you.

2 3

Tribes2 OpenGL (wgl)
by Nick Burns 01 Oct '06

01 Oct '06

Whow 3 posts in a row... I am deving -- finally (ya in the AM on a sunday) -- too much real job work on the weekdays.... So, I have yet another problem... This time it is with WGL/OGL I know it is transition atm... But... I dont know why Tribes2 is so very mad at me Fullscreen tribes2 (in a virtual desktop) used to work before -- it would give me many different fullscreen modes. 640x480 -> 1680x1050 or so. Now... for some reason -- I can only use Tribes2 in windowed mode (in a virtual desktop) and if I choose fullscreen -- i see no possible choices (It sees no resolutions or bit depths for opengl fullscreen). -- Also now all objects are drawn with the wrong culling AFAICT. Tribes2 worked perfectly before -- Jul21st for example. On a side note -- Tribes2 d3d has never worked for me... (is this different on Linux?) Any ideas on either fullscreen ogl OR d3d? - Nick

1 0

RFC: Update Mac OSX stack patch
by Nick Burns 01 Oct '06

01 Oct '06

I recently found genpatch. Wow, wowey wow wow. Very sleek Used this line to gen the attached patch ./tools/genpatch -v -n winePatchMacOSXStackUpdate -c "Mac OSX stack update" -m "include/msvcrt/process.h tools/winegcc/winegcc.c" Anyway -- this patch is very simple and just extends the work that was done before to other places where stdcall and cdecl can be defined This makes sure they are all consistent and not misdefined (leading to runtime failures) And lastly -- any comments welcome... Ill try and follow this patch -- and at somepoint work on my openal patch (which did not go over too well last time.... poor openal -- there there I still like you) - Nick

1 0

todo_wine problems
by Jeff L 01 Oct '06

01 Oct '06

I am having trouble with getting todo_wine working. It seems to be ignored and the test is being executed on wine and failing as expected. Is there a trick to setting todo up? According to all the examples and the text this should work: todo_wine { ok(hr == S_OK, "ScriptStringOut Stub should return S_OK not %08lx\n", hr); } Jeff

4 3

Making cxtest.org more usable by linking it to app db and bugzilla
by Dan Kegel 01 Oct '06

01 Oct '06

It occurred to me that one problem with cxtest.org is that it's hard to browse the results of a particular application - and that it would be really cool if the app db and bugzilla had a filed called 'cxtest results' that linked to the cxtest results for the application in question. Naturally, this field would be empty for most apps, but gradually as we add more tests to cxtest, it would start to be quite useful.

2 1

Re: [PATCH] local fixes in ioctl for google video.
by Dmitry Timoshkov 30 Sep '06

30 Sep '06

"Marcus Meissner" <marcus(a)jet.franken.de> wrote: > @@ -2125,6 +2125,13 @@ INT WINAPI WSAIoctl(SOCKET s, > > switch( dwIoControlCode ) > { > + case 0x8004667E: > + FIXME("8004667E: stub!\n"); > + break; > + case 0x4004667f: /* FIONREAD */ > + FIXME("4004667f/FIONREAD: stub, returning 1!\n"); > + *(DWORD*)lpbOutBuffer = 1; > + break; 0x8004667e is FIONBIO (set or clear non-blocking I/O). -- Dmitry.

1 0

str{n}casecmp(): unrecognized identifier
by Andrew Talbot 30 Sep '06

30 Sep '06

Hi, It seems that, on my [x86_64] system, at least, string.h is not being included in the files where strcasecmp() or strncasecmp() is used (for example, in crypt32/oid.c), despite HAVE_STRCASECMP and HAVE_STRNCASECMP being defined as 1. I presume, because of the above defines, that just adding #include <string.h> ... in the affected files would not be a proper fix. I imagine it requires expert tweaking of the automake setup (or whatever) to ensure that this is done automatically (if it's not just a fault on my system), in which case I ask for suitable help, please. Thanks, -- Andy.

3 3

Re: [PATCH] Use correct headers for strcasecmp
by Mike McCormack 30 Sep '06

30 Sep '06

Marcus Meissner wrote: > We need to include string.h and also wine/port.h > to get strcasecmp on platforms where it is missing. In Win32 code, shouldn't we be using lstrcmpi instead? Mike

1 0

Re: [Bug 4995] Check for fontforge >= 20060406 as earlier versions fail to build our fonts with catastrophic results.
by Mike McCormack 30 Sep '06

30 Sep '06

Sam Dennis wrote: > +if PKG_CHECK_MINVER(fontforge, 20060406); then configure should check for features, not versions. This avoids problems with patched older versions or newer versions with features removed. To check for fontforge correctly, we need to check that it will generate a ttf file that works with Wine. The alternative is to fix up the sfd2ttf that somebody posted a month or two ago and use that so that we don't depend on fontforge. Mike

1 0

Yesterday's (6/28) Git (gdi32) updates break 64-bit compilation.
by Evil Jay 30 Sep '06

30 Sep '06

The updates in yesterday's Git tree have broken compilation under 64-bit. Previously, it was working. I entered a bugzilla entry for it (http://bugs.winehq.org/show_bug.cgi?id=6304), but thought I would mention it here too - since I think it's a pretty big deal and it doesn't seem that many of the developers here are working under 64-bit (and therefore wouldn't notice the issue). ------------------------ ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./gdi32.spec dispdib.spec.o gdi.exe.spec.o wing.spec.o bidi16.o dispdib.o env.o gdi16.o metafile16.o wing.o bidi.o bitblt.o bitmap.o brush.o clipping.o dc.o dib.o driver.o enhmetafile.o enhmfdrv/bitblt.o enhmfdrv/dc.o enhmfdrv/graphics.o enhmfdrv/init.o enhmfdrv/mapping.o enhmfdrv/objects.o font.o freetype.o gdi_main.o gdiobj.o icm.o mapping.o metafile.o mfdrv/bitblt.o mfdrv/dc.o mfdrv/graphics.o mfdrv/init.o mfdrv/mapping.o mfdrv/objects.o mfdrv/text.o painting.o palette.o path.o pen.o printdrv.o region.o version.res -o gdi32.dll.so -ladvapi32 -lkernel32 -lntdll /usr/lib/libsicuuc.a /usr/lib/libsicudata.a -lstdc++ -lgcc_s ../../libs/port/libwine_port.a -L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 ld: Relocatable linking with relocations from format elf64-x86-64 (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.n0hnjc.o) is not supported winebuild: ld -m elf_i386 -r failed with status 256 winegcc: ../../tools/winebuild/winebuild failed. make[2]: *** [gdi32.dll.so] Error 2 make[2]: Leaving directory `/data/install/wine/dlls/gdi' make[1]: *** [gdi] Error 2 make[1]: Leaving directory `/data/install/wine/dlls' make: *** [dlls] Error 2 -J

2 1

Re: [D3D9] Remove const qualifier on state_test data.
by Michael Stefaniuc 30 Sep '06

30 Sep '06

Ivan Gyurdiev wrote: > Type: Cleanup > > Why: > The const qualifier is unnecessarily restrictive. > I intend to allocate and free such data on the heap in a future patch. > Instead, const should be primarily used on function parameters. Question: do you realy have to use void pointers? Void pointers are compatible with every pointer type and thus will disable the type checking of the compiler. Also you do not need to to cast a rvalue to void * if the type of the lvalue is void *. bye michael > --- > dlls/d3d9/tests/stateblock.c | 40 ++++++++++++++++++++-------------------- > 1 files changed, 20 insertions(+), 20 deletions(-) > > diff --git a/dlls/d3d9/tests/stateblock.c b/dlls/d3d9/tests/stateblock.c > index 65a11e6..68b431a 100644 > --- a/dlls/d3d9/tests/stateblock.c > +++ b/dlls/d3d9/tests/stateblock.c > @@ -105,20 +105,20 @@ typedef struct state_test { > * as the default data, but a write can have side effects. > * The initial data is tested first, before any writes take place > * The default data can be tested after a write */ > - const void* initial_data; > + void* initial_data; > > /* The default data is the standard state to compare > * against, and restore to */ > - const void* default_data; > + void* default_data; > > /* The test data is the experiment data to try > * in - what we want to write > * out - what windows will actually write (not necessarily the same) */ > - const void* test_data_in; > - const void* test_data_out; > + void* test_data_in; > + void* test_data_out; > > /* The poison data is the data to preinitialize the return buffer to */ > - const void* poison_data; > + void* poison_data; > > /* Return buffer */ > void* return_data; > @@ -562,11 +562,11 @@ static void shader_constants_queue_test( > shader_constant_arg* arg = buffer; > shader_constant_data* return_data = (shader_constant_data*) (arg + 1); > > - test->test_data_in = &shader_constant_test_data; > - test->test_data_out = &shader_constant_test_data; > - test->default_data = &shader_constant_default_data; > - test->initial_data = &shader_constant_default_data; > - test->poison_data = &shader_constant_poison_data; > + test->test_data_in = (void*) &shader_constant_test_data; > + test->test_data_out = (void*) &shader_constant_test_data; > + test->default_data = (void*) &shader_constant_default_data; > + test->initial_data = (void*) &shader_constant_default_data; > + test->poison_data = (void*) &shader_constant_poison_data; > test->return_data = return_data; > test->data_size = sizeof(shader_constant_data); > test->set_handler = shader_constant_set_handler; > @@ -697,11 +697,11 @@ static void lights_queue_test( > light_arg* arg = buffer; > light_data* return_data = (light_data*) (arg + 1); > > - test->test_data_in = &light_test_data_in; > - test->test_data_out = &light_test_data_out; > - test->default_data = &light_default_data; > - test->initial_data = &light_initial_data; > - test->poison_data = &light_poison_data; > + test->test_data_in = (void*) &light_test_data_in; > + test->test_data_out = (void*) &light_test_data_out; > + test->default_data = (void*) &light_default_data; > + test->initial_data = (void*) &light_initial_data; > + test->poison_data = (void*) &light_poison_data; > test->return_data = return_data; > test->data_size = sizeof(light_data); > test->set_handler = light_set_handler; > @@ -856,11 +856,11 @@ static void transform_queue_test( > { > transform_data* return_data = buffer; > > - test->test_data_in = &transform_test_data; > - test->test_data_out = &transform_test_data; > - test->default_data = &transform_default_data; > - test->initial_data = &transform_default_data; > - test->poison_data = &transform_poison_data; > + test->test_data_in = (void*) &transform_test_data; > + test->test_data_out = (void*) &transform_test_data; > + test->default_data = (void*) &transform_default_data; > + test->initial_data = (void*) &transform_default_data; > + test->poison_data = (void*) &transform_poison_data; > test->return_data = return_data; > test->data_size = sizeof(transform_data); > test->set_handler = transform_set_handler; -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Re: [Bug 4995] Check for fontforge >= 20060406 as earlier versions fail to build our fonts with catastrophic results.
by Vitaliy Margolen 30 Sep '06

30 Sep '06

Sam Dennis wrote: > aclocal.m4 | 16 ++++++++++++++++ > configure.ac | 6 +++++- > 2 files changed, 21 insertions(+), 1 deletions(-) > You missing change log. Please don't forget to include it in the email body not just subject. Also your patch is not correct. It's been discussed on wine-devel that we should not restrict any one particular version of FontForge. Many distros come with old but good versions and this will add extra noise for no good reason. And it will not catch any new versions that are broken either... Vitaliy.

2 1

Vista applications that work & those that don't
by Nick Law 30 Sep '06

30 Sep '06

I thought this may be of interest... applications that work and those that don't in Vista RC1 It would be interesting on how this same list compares with wine 0.9.22 http://www.iexbeta.com/wiki/index.php/Windows_Vista_Software_Compatibility_… and the hardware compatibility list .. http://www.iexbeta.com/wiki/index.php/Windows_Vista_RC_1_Hardware_Compatibi… I don't believe Microsoft's official list has been made public yet, although they said they would sometime! Nick

1 0

Re: shdocvw(2/2): ignore VT_ERROR arguments to WebBrowser_Navigate2
by Michael Stefaniuc 29 Sep '06

29 Sep '06

Juan Lang wrote: > Combined with the first patch, I'm able to log in with Skype 2.6 beta. > > ChangeLog: ignore VT_ERROR arguments to WebBrowser_Navigate2 Ignoring VT_ERROR just masks a previous error. bye michael > Index: dlls/shdocvw/webbrowser.c > =================================================================== > RCS file: /home/wine/wine/dlls/shdocvw/webbrowser.c,v > retrieving revision 1.65 > diff -u -r1.65 webbrowser.c > --- dlls/shdocvw/webbrowser.c 25 Sep 2006 19:46:43 -0000 1.65 > +++ dlls/shdocvw/webbrowser.c 29 Sep 2006 00:55:46 -0000 > @@ -675,7 +675,7 @@ > if(V_VT(URL) != VT_BSTR) > return E_INVALIDARG; > > - if(PostData && V_VT(PostData) != VT_EMPTY) { > + if(PostData && V_VT(PostData) != VT_EMPTY && V_VT(PostData) != VT_ERROR) { > if(V_VT(PostData) != (VT_ARRAY | VT_UI1) > || V_ARRAY(PostData)->cDims != 1) { > WARN("Invalid PostData\n"); > @@ -686,7 +686,7 @@ > post_data_len = V_ARRAY(PostData)->rgsabound[0].cElements; > } > > - if(Headers && V_VT(Headers) != VT_EMPTY) { > + if(Headers && V_VT(Headers) != VT_EMPTY && V_VT(Headers) != VT_ERROR) { > if(V_VT(Headers) != VT_BSTR) > return E_INVALIDARG; > > > > ------------------------------------------------------------------------ > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

3 3

Re: [PATCH 0/4] Janitorial: Win64 printf format warning fixes
by Michael Stefaniuc 29 Sep '06

29 Sep '06

Michael Stefaniuc wrote: > For all the people wanting to help out with this janitorial task please > wait until Alexandre commits this patch series. After that i'll create a > page for this task on the Wine wiki and link it from > http://wiki.winehq.org/JanitorialProjects Ok, this janitorial task has now a Wiki page: http://wiki.winehq.org/Win64PrintfFormatWarnings This is a good opportunity for anybody that wants to start submitting patches for Wine and get accustomed to this process. > I will put in a download link for my perl script that can automaticly > fix around 20000 out of the remaining 25000 warnings. You realy do not > want to go manualy over 25k warnings. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Can't open DLL's without sudo
by Paul Wilkinson 29 Sep '06

29 Sep '06

I'm running wine v 0.9.20 under Fedora Core 5. I'm trying to get the Syncrosoft License Control Center to run under wine. for some reason it can only load MFC42.DLL and MSVCRT.DLL if I put 'sudo' on the command line: [paul@localhost LCC]$ wine LCC.exe err:module:import_dll Library MFC42.DLL (which is needed by L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe") not found err:module:import_dll Library MSVCRT.dll (which is needed by L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe") not found err:module:import_dll Library MSVCRT.dll (which is needed by L"C:\\windows\\system32\\MSVCP60.dll") not found err:module:import_dll Library MSVCP60.dll (which is needed by L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe" failed, status c0000135 [paul@localhost LCC]$ The NtOpenFile that tries to open the DLL (in loader.c) is returning c00000022 (ACCESS_DENIED). But the permissions for these DLL's are wide open. Any idea what's going on? - Paul

4 4

crypt32/sip: new test failures
by Marcus Meissner 29 Sep '06

29 Sep '06

Hi, ../../../tools/runtest -q -P wine -M crypt32.dll -T ../../.. -p crypt32_test.exe.so sip.c && touch sip.ok sip.c:176: Test failed: Expected CryptSIPRetrieveSubjectGuid to succeed sip.c:177: Test failed: Expected ERROR_SUCCESS, got 0x00000002 sip.c:179: Test failed: Expected ({c689aab8-8e78-11d0-8c47-00c04fc295ee}), got ({c689aab8-8e78-11d0-8c47-00c04fc295ee}). sip.c:187: Test failed: Expected CryptSIPRetrieveSubjectGuid to succeed sip.c:188: Test failed: Expected ERROR_SUCCESS, got 0x00000057 sip.c:190: Test failed: Expected ({c689aab8-8e78-11d0-8c47-00c04fc295ee}), got ({c689aab8-8e78-11d0-8c47-00c04fc295ee}). sip.c:199: Test failed: Expected CryptSIPRetrieveSubjectGuid to succeed sip.c:200: Test failed: Expected ERROR_SUCCESS, got 0x00000057 sip.c:202: Test failed: Expected ({c689aab8-8e78-11d0-8c47-00c04fc295ee}), got ({c689aab8-8e78-11d0-8c47-00c04fc295ee}). fixme:crypt:CryptSIPLoad ((null) 0 (nil)) stub! fixme:crypt:CryptSIPLoad ({7b845773-cc00-7ffd-0000-00003b933460} 0 (nil)) stub! fixme:crypt:CryptSIPLoad ({deadbeef-dead-beef-dead-beefdeadbeef} 0 0x33fda0) stub! fixme:crypt:CryptSIPLoad ({deadbeef-dead-beef-dead-beefdeadbeef} 0 0x33fda0) stub! fixme:crypt:CryptSIPLoad ({c689aaba-8e78-11d0-8c47-00c04fc295ee} 0 0x33fda0) stub! fixme:crypt:CryptSIPLoad ({c689aaba-8e78-11d0-8c47-00c04fc295ee} 0 0x33fda0) stub! fixme:crypt:CryptSIPLoad ({c689aaba-8e78-11d0-8c47-00c04fc295ee} 1 0x33fda0) stub! make[2]: *** [sip.ok] Fehler 9 I did run "wineprefixcreate" before (just in case). Ciao, Marcus

1 0

Re: wine-devel Digest, Vol 14, Issue 93
by Anton Litvinov 29 Sep '06

29 Sep '06

----- Original Message ----- From: <wine-devel-request(a)winehq.org> To: <wine-devel(a)winehq.org> Sent: Friday, September 29, 2006 8:58 PM Subject: wine-devel Digest, Vol 14, Issue 93 > Send wine-devel mailing list submissions to > wine-devel(a)winehq.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.winehq.org/mailman/listinfo/wine-devel > or, via email, send a message with subject or body 'help' to > wine-devel-request(a)winehq.org > > You can reach the person managing the list at > wine-devel-owner(a)winehq.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wine-devel digest..." > > > Today's Topics: > > 1. Re: Governance Ideas (Mike McCormack) > 2. Re: shdocvw(2/2): ignore VT_ERROR arguments to > WebBrowser_Navigate2 (Michael Stefaniuc) > 3. Re: make test failure (Michael Stefaniuc) > 4. Re: [D3D9] Remove const qualifier on state_test data. > (Michael Stefaniuc) > 5. compiling wine for amd64 on ubuntu dapper 6.06 (Gerald Britton) > 6. Re: make test failure (Vitaliy Margolen) > 7. Re: shdocvw(2/2): ignore VT_ERROR arguments to > WebBrowser_Navigate2 (Juan Lang) > 8. Re: USER32: Stub implementation of BlockInput (Juan Lang) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 29 Sep 2006 18:02:08 +0900 > From: Mike McCormack <mike(a)codeweavers.com> > Subject: Re: Governance Ideas > To: bobl(a)optushome.com.au > Cc: wine-devel(a)winehq.com, Alexandre Julliard <julliard(a)winehq.org> > Message-ID: <451CE110.5000708(a)codeweavers.com> > Content-Type: text/plain; charset=us-ascii; format=flowed > > > Robert Lunnon wrote: > > > "Community Focused Process" means what it says, develop a process which is > > centred on the community the project serves. This requires the project to > > answer some introspective questions > > > > 1. Who "owns" Wine, does wine belong to A.) Alexandre, or B) the community > > it serves. > > A) Alexandre is a benelovent dictator. He manages Wine with the > interests of "the community" in mind, as he sees them. > > > 1. Answer the questions about the "ownership" of wine and identify the > > community it serves. Determine the right of the community to be involved is > > setting wines direction IE The Bill of rights I mentioned before (for each > > community Developers VS Users etc). > > Your "bill of rights" is the Wine license, the LGPL. > > > 2. Alexandre documents the exact logic he uses to determine patch > > acceptability which becomes the patch acceptance policy in the interim. > > It's very likely impossible to write that down. If you don't agree with > me, please write down your proposal. > > > 3. The project develops a community process for establishing project direction > > and maintaining the patch acceptance policy which includes stakeholders > > elected from the "owners" IE communities with a stakeholding in wine > > NetBSD is a project that is (was?) run by committees: > > http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html > > If you want Wine to be run by a committee, how about creating your own > fork so you can run it as you see fit? > > Mike > > > > ------------------------------ > > Message: 2 > Date: Fri, 29 Sep 2006 10:57:26 +0200 > From: Michael Stefaniuc <mstefani(a)redhat.com> > Subject: Re: shdocvw(2/2): ignore VT_ERROR arguments to > WebBrowser_Navigate2 > To: juan_lang(a)yahoo.com > Cc: wine-devel(a)winehq.org > Message-ID: <451CDFF6.5060904(a)redhat.com> > Content-Type: text/plain; charset=UTF-8 > > Juan Lang wrote: > > Combined with the first patch, I'm able to log in with Skype 2.6 beta. > > > > ChangeLog: ignore VT_ERROR arguments to WebBrowser_Navigate2 > Ignoring VT_ERROR just masks a previous error. > > bye > michael > > > Index: dlls/shdocvw/webbrowser.c > > =================================================================== > > RCS file: /home/wine/wine/dlls/shdocvw/webbrowser.c,v > > retrieving revision 1.65 > > diff -u -r1.65 webbrowser.c > > --- dlls/shdocvw/webbrowser.c 25 Sep 2006 19:46:43 -0000 1.65 > > +++ dlls/shdocvw/webbrowser.c 29 Sep 2006 00:55:46 -0000 > > @@ -675,7 +675,7 @@ > > if(V_VT(URL) != VT_BSTR) > > return E_INVALIDARG; > > > > - if(PostData && V_VT(PostData) != VT_EMPTY) { > > + if(PostData && V_VT(PostData) != VT_EMPTY && V_VT(PostData) != VT_ERROR) { > > if(V_VT(PostData) != (VT_ARRAY | VT_UI1) > > || V_ARRAY(PostData)->cDims != 1) { > > WARN("Invalid PostData\n"); > > @@ -686,7 +686,7 @@ > > post_data_len = V_ARRAY(PostData)->rgsabound[0].cElements; > > } > > > > - if(Headers && V_VT(Headers) != VT_EMPTY) { > > + if(Headers && V_VT(Headers) != VT_EMPTY && V_VT(Headers) != VT_ERROR) { > > if(V_VT(Headers) != VT_BSTR) > > return E_INVALIDARG; > > > > > > > > ------------------------------------------------------------------------ > > > > > > > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Sr. Network Engineer Fax.: +49-711-96437-111 > Red Hat GmbH Email: mstefani(a)redhat.com > Hauptstaetterstr. 58 http://www.redhat.de/ > D-70178 Stuttgart > > > > ------------------------------ > > Message: 3 > Date: Fri, 29 Sep 2006 10:59:02 +0200 > From: Michael Stefaniuc <mstefani(a)redhat.com> > Subject: Re: make test failure > To: wine-devel(a)winehq.org > Message-ID: <451CE056.5000702(a)redhat.com> > Content-Type: text/plain; charset=UTF-8 > > James Hawkins wrote: > > On 9/28/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > > >> James Hawkins wrote: > >> > On 9/28/06, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > >> >> On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote: > >> >> > Hi, > >> >> > > >> >> > Running make test fails with: > >> >> > > >> >> > make[2]: Entering directory > >> `/usr/local/src/wine/dlls/comctl32/tests' > >> >> > ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p > >> >> > comctl32_test.exe.so tab.c && touch tab.ok > >> >> > tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >> [56,20] > >> >> > tab.c:208: Test failed: no icon, set size: Expected [42,20] got > >> [54,20] > >> >> > tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >> [56,20] > >> >> > tab.c:208: Test failed: no icon, set size: Expected [42,20] got > >> [54,20] > >> >> > tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >> [56,20] > >> >> > tab.c:184: Test failed: no icon, set size: Expected [54,20] got > >> [56,20] > >> >> > make[2]: *** [tab.ok] Error 6 > >> >> > > >> >> Succeeds over here. > >> >> > >> > > >> > I know, it succeeds on a lot of machines, but the point is that it > >> > shouldn't fail on any machine. > >> > > >> Please remove your ~/.wine dir and try again. It seems your metrics are > >> set different. Or your fonts are wrong. > >> > > > > The tests still fail with a clean .wine. > Yes, i used an empty .wine too. > > bye > michael > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Sr. Network Engineer Fax.: +49-711-96437-111 > Red Hat GmbH Email: mstefani(a)redhat.com > Hauptstaetterstr. 58 http://www.redhat.de/ > D-70178 Stuttgart > > > > ------------------------------ > > Message: 4 > Date: Fri, 29 Sep 2006 12:33:27 +0200 > From: Michael Stefaniuc <mstefani(a)redhat.com> > Subject: Re: [D3D9] Remove const qualifier on state_test data. > To: ivg231(a)gmail.com > Cc: wine-devel(a)winehq.org > Message-ID: <451CF677.1040305(a)redhat.com> > Content-Type: text/plain; charset=UTF-8 > > Ivan Gyurdiev wrote: > > Type: Cleanup > > > > Why: > > The const qualifier is unnecessarily restrictive. > > I intend to allocate and free such data on the heap in a future patch. > > Instead, const should be primarily used on function parameters. > Question: do you realy have to use void pointers? Void pointers are > compatible with every pointer type and thus will disable the type > checking of the compiler. Also you do not need to to cast a rvalue to > void * if the type of the lvalue is void *. > > bye > michael > > > --- > > dlls/d3d9/tests/stateblock.c | 40 ++++++++++++++++++++-------------------- > > 1 files changed, 20 insertions(+), 20 deletions(-) > > > > diff --git a/dlls/d3d9/tests/stateblock.c b/dlls/d3d9/tests/stateblock.c > > index 65a11e6..68b431a 100644 > > --- a/dlls/d3d9/tests/stateblock.c > > +++ b/dlls/d3d9/tests/stateblock.c > > @@ -105,20 +105,20 @@ typedef struct state_test { > > * as the default data, but a write can have side effects. > > * The initial data is tested first, before any writes take place > > * The default data can be tested after a write */ > > - const void* initial_data; > > + void* initial_data; > > > > /* The default data is the standard state to compare > > * against, and restore to */ > > - const void* default_data; > > + void* default_data; > > > > /* The test data is the experiment data to try > > * in - what we want to write > > * out - what windows will actually write (not necessarily the same) */ > > - const void* test_data_in; > > - const void* test_data_out; > > + void* test_data_in; > > + void* test_data_out; > > > > /* The poison data is the data to preinitialize the return buffer to */ > > - const void* poison_data; > > + void* poison_data; > > > > /* Return buffer */ > > void* return_data; > > @@ -562,11 +562,11 @@ static void shader_constants_queue_test( > > shader_constant_arg* arg = buffer; > > shader_constant_data* return_data = (shader_constant_data*) (arg + 1); > > > > - test->test_data_in = &shader_constant_test_data; > > - test->test_data_out = &shader_constant_test_data; > > - test->default_data = &shader_constant_default_data; > > - test->initial_data = &shader_constant_default_data; > > - test->poison_data = &shader_constant_poison_data; > > + test->test_data_in = (void*) &shader_constant_test_data; > > + test->test_data_out = (void*) &shader_constant_test_data; > > + test->default_data = (void*) &shader_constant_default_data; > > + test->initial_data = (void*) &shader_constant_default_data; > > + test->poison_data = (void*) &shader_constant_poison_data; > > test->return_data = return_data; > > test->data_size = sizeof(shader_constant_data); > > test->set_handler = shader_constant_set_handler; > > @@ -697,11 +697,11 @@ static void lights_queue_test( > > light_arg* arg = buffer; > > light_data* return_data = (light_data*) (arg + 1); > > > > - test->test_data_in = &light_test_data_in; > > - test->test_data_out = &light_test_data_out; > > - test->default_data = &light_default_data; > > - test->initial_data = &light_initial_data; > > - test->poison_data = &light_poison_data; > > + test->test_data_in = (void*) &light_test_data_in; > > + test->test_data_out = (void*) &light_test_data_out; > > + test->default_data = (void*) &light_default_data; > > + test->initial_data = (void*) &light_initial_data; > > + test->poison_data = (void*) &light_poison_data; > > test->return_data = return_data; > > test->data_size = sizeof(light_data); > > test->set_handler = light_set_handler; > > @@ -856,11 +856,11 @@ static void transform_queue_test( > > { > > transform_data* return_data = buffer; > > > > - test->test_data_in = &transform_test_data; > > - test->test_data_out = &transform_test_data; > > - test->default_data = &transform_default_data; > > - test->initial_data = &transform_default_data; > > - test->poison_data = &transform_poison_data; > > + test->test_data_in = (void*) &transform_test_data; > > + test->test_data_out = (void*) &transform_test_data; > > + test->default_data = (void*) &transform_default_data; > > + test->initial_data = (void*) &transform_default_data; > > + test->poison_data = (void*) &transform_poison_data; > > test->return_data = return_data; > > test->data_size = sizeof(transform_data); > > test->set_handler = transform_set_handler; > > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Sr. Network Engineer Fax.: +49-711-96437-111 > Red Hat GmbH Email: mstefani(a)redhat.com > Hauptstaetterstr. 58 http://www.redhat.de/ > D-70178 Stuttgart > > > > ------------------------------ > > Message: 5 > Date: Fri, 29 Sep 2006 09:06:48 -0400 > From: "Gerald Britton" <gerald.britton(a)gmail.com> > Subject: compiling wine for amd64 on ubuntu dapper 6.06 > To: wine-devel(a)winehq.org > Message-ID: > <5d1a32000609290606u56007017t6f8ace8de14bb0ab(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi -- I'm trying to get wine going on my ubuntu dapper installation on > an amd 64 box. I have followed the wiki instructions in > http://wiki.winehq.org/WineOn64bit for ubuntu and rechecked my work. > Two things go wrong: > > 1. /configure can't find opengl, and produces these messages: > > configure: WARNING: Wine will be build without OpenGL or Direct3D support > configure: WARNING: because something is wrong with the OpenGL setup: > configure: WARNING: No OpenGL library found on this system. > > 2. make depend works, but make all fails with this: > > LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc > --nostdinc -I. -I. -I../../include -I../../include > -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -foversion.res > version.rc > ../../tools/winegcc/winegcc -B../../tools/winebuild -shared > ./gdi32.spec dispdib.spec.o gdi.exe.spec.o wing.spec.o bidi16.o > dispdib.o env.o gdi16.o metafile16.o wing.o bidi.o bitblt.o bitmap.o > brush.o clipping.o dc.o dib.o driver.o enhmetafile.o enhmfdrv/bitblt.o > enhmfdrv/dc.o enhmfdrv/graphics.o enhmfdrv/init.o enhmfdrv/mapping.o > enhmfdrv/objects.o font.o freetype.o gdi_main.o gdiobj.o icm.o > mapping.o metafile.o mfdrv/bitblt.o mfdrv/dc.o mfdrv/graphics.o > mfdrv/init.o mfdrv/mapping.o mfdrv/objects.o mfdrv/text.o painting.o > palette.o path.o pen.o printdrv.o region.o version.res -o > gdi32.dll.so -ladvapi32 -lkernel32 -lntdll /usr/lib/libsicuuc.a > /usr/lib/libsicudata.a -lstdc++ -lgcc_s ../../libs/port/libwine_port.a > -L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 > ld: Relocatable linking with relocations from format elf64-x86-64 > (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.ArPHdq.o) > is not supported > winebuild: ld -m elf_i386 -r failed with status 256 > winegcc: ../../tools/winebuild/winebuild failed. > make[2]: *** [gdi32.dll.so] Error 2 > make[2]: Leaving directory `/tmp/wine-0.9.22/dlls/gdi' > make[1]: *** [gdi] Error 2 > make[1]: Leaving directory `/tmp/wine-0.9.22/dlls' > make: *** [dlls] Error 2 > > > > I'm not sure what to do now. Any feedback/suggestions would be appreciated. > > > > ------------------------------ > > Message: 6 > Date: Fri, 29 Sep 2006 07:36:58 -0600 > From: Vitaliy Margolen <wine-devel(a)kievinfo.com> > Subject: Re: make test failure > To: wine-devel(a)winehq.org > Message-ID: <451D217A.4060808(a)kievinfo.com> > Content-Type: text/plain; charset=UTF-8 > > Michael Stefaniuc wrote: > > James Hawkins wrote: > >> On 9/28/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > >> > >>> James Hawkins wrote: > >>>> On 9/28/06, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > >>>>> On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote: > >>>>>> Hi, > >>>>>> > >>>>>> Running make test fails with: > >>>>>> > >>>>>> make[2]: Entering directory > >>> `/usr/local/src/wine/dlls/comctl32/tests' > >>>>>> ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p > >>>>>> comctl32_test.exe.so tab.c && touch tab.ok > >>>>>> tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >>> [56,20] > >>>>>> tab.c:208: Test failed: no icon, set size: Expected [42,20] got > >>> [54,20] > >>>>>> tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >>> [56,20] > >>>>>> tab.c:208: Test failed: no icon, set size: Expected [42,20] got > >>> [54,20] > >>>>>> tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >>> [56,20] > >>>>>> tab.c:184: Test failed: no icon, set size: Expected [54,20] got > >>> [56,20] > >>>>>> make[2]: *** [tab.ok] Error 6 > >>>>>> > >>>>> Succeeds over here. > >>>>> > >>>> I know, it succeeds on a lot of machines, but the point is that it > >>>> shouldn't fail on any machine. > >>>> > >>> Please remove your ~/.wine dir and try again. It seems your metrics are > >>> set different. Or your fonts are wrong. > >>> > >> The tests still fail with a clean .wine. > > Yes, i used an empty .wine too. > > > And you guys have windows like "Arial" font? Any test that uses fonts > will not work if you don't have that font or it's not the same metrics > as the native one. > > Vitaliy. > > > > ------------------------------ > > Message: 7 > Date: Fri, 29 Sep 2006 08:36:46 -0700 (PDT) > From: Juan Lang <juan_lang(a)yahoo.com> > Subject: Re: shdocvw(2/2): ignore VT_ERROR arguments to > WebBrowser_Navigate2 > To: Michael Stefaniuc <mstefani(a)redhat.com> > Cc: wine-devel(a)winehq.org > Message-ID: <20060929153646.65850.qmail(a)web30008.mail.mud.yahoo.com> > Content-Type: text/plain; charset=iso-8859-1 > > > Ignoring VT_ERROR just masks a previous error. > > Hm.. are you sure? These are input arguments, not results. This isn't > the only app that gets further with this patch. See also bug 6166. > > I guess a test case is the only answer. > > --Juan > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > > ------------------------------ > > Message: 8 > Date: Fri, 29 Sep 2006 09:57:35 -0700 (PDT) > From: Juan Lang <juan_lang(a)yahoo.com> > Subject: Re: USER32: Stub implementation of BlockInput > To: Jason Green <jave27(a)gmail.com> > Cc: wine-devel(a)winehq.org > Message-ID: <20060929165735.77898.qmail(a)web30010.mail.mud.yahoo.com> > Content-Type: text/plain; charset=iso-8859-1 > > You forgot the patch.. > > --Juan > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > > ------------------------------ > > _______________________________________________ > wine-devel mailing list - wine-devel(a)winehq.org > http://www.winehq.org/mailman/listinfo/wine-devel > > > End of wine-devel Digest, Vol 14, Issue 93 > ******************************************

1 0

Re: make test failure #6
by Juan Lang 29 Sep '06

29 Sep '06

Hi James, > make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' > ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p > user32_test.exe.so sysparams.c && touch sysparams.ok > sysparams.c:1471: Test failed: wrong value in registry -1, expected 154 > sysparams.c:1474: Test failed: wrong value in registry -1, expected 0 > sysparams.c:1477: Test failed: wrong value in registry -1, expected 0 > sysparams.c:1480: Test failed: wrong value in registry -1, expected 8 > make[2]: *** [sysparams.ok] Error 4 This, like many other errors, disappears for me when I rerun make test. (I'm not too happy with the 'rerun make test' option, but I don't see people falling all over themselves up to fix the tests, either.) --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[rsaenh-test]: import&export of a plaintext public key + algID check
by Karsten Elfenbein 29 Sep '06

29 Sep '06

* test for importing a PlainPublicKey * test for the correct ALG_ID after the import * test for the correct PlainPublicKey after exporting the key again Karsten

1 0

make test failure (#7?)
by Juan Lang 29 Sep '06

29 Sep '06

After I run make test a bunch of times to get other failures to disappear, I get this: make[2]: Entering directory `/home/juan/src/wine-20050725/dlls/user/tests' ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so win.c && touch win.ok fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE win.c:2554: Test failed: message 000f available make[2]: *** [win.ok] Error 1 make[2]: Leaving directory `/home/juan/src/wine-20050725/dlls/user/tests' make[1]: *** [user/tests/__test__] Error 2 make[1]: Leaving directory `/home/juan/src/wine-20050725/dlls' make: *** [dlls/__test__] Error 2 --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: shdocvw: Make sure BSTR is allocated before calling sink
by Jacek Caban 29 Sep '06

29 Sep '06

Hi Cihan, Cihan Altinay wrote: > This fixes bug 6054 and let's MSN Messenger 7 start up. > http://bugs.winehq.org/show_bug.cgi?id=6054 > > --- > dlls/shdocvw/dochost.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/shdocvw/dochost.c b/dlls/shdocvw/dochost.c > index 5bb40e0..8d78a49 100644 > --- a/dlls/shdocvw/dochost.c > +++ b/dlls/shdocvw/dochost.c > @@ -49,11 +49,12 @@ static void navigate_complete(DocHost *T > V_DISPATCH(params+1) = disp; > > V_VT(&url) = VT_BSTR; > - V_BSTR(&url) = This->url; > + V_BSTR(&url) = SysAllocString(This->url); > > call_sink(This->cps.wbe2, DISPID_NAVIGATECOMPLETE2, &dispparams); > call_sink(This->cps.wbe2, DISPID_DOCUMENTCOMPLETE, &dispparams); > > + SysFreeString(This->url); You should free V_BSTR(&url) here, not This->url. Jacek

1 0

make test failure
by James Hawkins 29 Sep '06

29 Sep '06

Hi, Running make test fails with: make[2]: Entering directory `/usr/local/src/wine/dlls/comctl32/tests' ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so tab.c && touch tab.ok tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:184: Test failed: no icon, set size: Expected [54,20] got [56,20] make[2]: *** [tab.ok] Error 6 -- James Hawkins

4 8

Re: USER32: Stub implementation of BlockInput
by Juan Lang 29 Sep '06

29 Sep '06

You forgot the patch.. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Governance Ideas
by Robert Lunnon 29 Sep '06

29 Sep '06

Alexandre said ========================================= To be honest, I have no idea what it is that you are suggesting. All I see is phrases like "community focused process" or "acceptance policy" which frankly are just meaningless buzzwords. If you expect anything to happen, you'll need to make much more concrete suggestions, and provide examples to make us understand how what you are suggesting would work in practice, and how it would be different from what we are doing now. -- Alexandre Julliard julliard(a)winehq.org ========================================== To which I said I would respond soon - well here goes. From the outset I want to say that I am not going to redefine the wine project or make suggestions in the sense of a particular change. I want the communities of developers users and others to define that change. What I will do here is suggest ways in which we could organise to make a change as a collective. Firstly the buzzwords "Community Focused Process" means what it says, develop a process which is centred on the community the project serves. This requires the project to answer some introspective questions 1. Who "owns" Wine, does wine belong to A.) Alexandre, or B) the community it serves. 2 If the answer is B then which community. It may surprise some to realise that a project like this has many communities. We discovered this when setting up the OpenSolaris community process. Some obvious ones are "The Developer Community" and "The User Community" and "Developer + User" Community. There are other less obvious communities, eg the community of distribution maintainers who may be neither developer or user. If we decide that the community "Owns" Wine then it needs to be established whether the community has a right to direct wine's development. As the "Owner" I'd argue the community should have this right. Second Buzzword "Patch Acceptance Policy" means the rules by which a patch is deemed acceptable or not. At the moment this is pretty close to "It's acceptable if Alexandre commits it" This is OK in a community process as long as the community that wine serves supports this approach. I think the recent thread throws significant doubt on this. This particular patch acceptance policy is not Transparent, this is the key reason why dropped patches cause so much argument, why many developers leave the project and possibly why Wine doesn't get the major backing some projects do (EG Gnome, KDE Xorg) dealing with the wine project is risky business. Now what do I propose... 1. Answer the questions about the "ownership" of wine and identify the community it serves. Determine the right of the community to be involved is setting wines direction IE The Bill of rights I mentioned before (for each community Developers VS Users etc). 2. Alexandre documents the exact logic he uses to determine patch acceptability which becomes the patch acceptance policy in the interim. This should be done to the point that someone else could take over from Alexandre and achieve the same result. This opens the way to multiple maintainers as well as allowing Alexandre to take more holidays. 3. The project develops a community process for establishing project direction and maintaining the patch acceptance policy which includes stakeholders elected from the "owners" IE communities with a stakeholding in wine 4. A community process is run to A.) Establish the communities objective for wine - this will actually probably be reasonably argumentative, but that is exactly how it should be. If it's not there is probably something wrong. It was with OpenSolaris and governance was the greatest concern with that project too. B) review the Patch acceptance policy in line with the community objective. For example the policy may be adjusted to favour functionality improvements, or loosen gating on changes leading to solutions that wine critically needs or even establish a "must have" application. 5. A mechanism is created to independently review patches (appeal process) for acceptability IE Whether a patch meets the acceptance policy. Note that if a patch acceptable to the policy is rejected then the policy may need to change (Requiring a new community process to review that change) or an architectural decision needs to be taken. This is done by the architecture review board in the OpenSolaris process. Among other things when a patch is sent to appeal the owner of the patch is guaranteed an explanation of how the patch doesn't meet the acceptance policy. Now if we did all this we would * Have a picture of the needs of the community * Have a way to direct the project toward meeting that need * Have a way to demonstrate we intend to meet that need * Have a consistent review process for patches * Have a way to multistream patches * Have an open transparent, trusting and consistent environment in which to work * Have a way to change and grow * Open ways to allow business to confidently invest in Wine. Even if we ended up with exactly what we have now we will have improved transparency resulting in higher quality of work and less resentment of the process, improving developer retention rates and reducing disputes. Bob

6 5

make test failure #3
by James Hawkins 29 Sep '06

29 Sep '06

Hi, make[2]: Entering directory `/usr/local/src/wine/dlls/shell32/tests' ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfileop.c && touch shlfileop.ok shlfileop.c:168: Test failed: The requested file does not exist, ret=3 make[2]: *** [shlfileop.ok] Error 1 -- James Hawkins

2 1

make test failure #5
by James Hawkins 29 Sep '06

29 Sep '06

Hi, make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' msg.c:3700: Test failed: DrawMenuBar: the msg sequence is not complete: expected 0000 - actual 0021 msg.c:3727: Test failed: MsgWaitForMultipleObjects returned 0 fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet msg.c:6768: Test failed: WmEmpty: the msg sequence is not complete: expected 0000 - actual 0014 make[2]: *** [msg.ok] Error 3 -- James Hawkins

2 2

make test failure #2
by James Hawkins 28 Sep '06

28 Sep '06

Hi, This test passes on my machine, should it not? make[2]: Entering directory `/usr/local/src/wine/dlls/d3d9/tests' ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so surface.c && touch surface.ok fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x18cd10) : stub, simulating 64MB for now, returning 64MB left surface.c:131: Test succeeded inside todo block: Got pitch 12, expected 12 make[2]: *** [surface.ok] Error 1 -- James Hawkins

3 3

make test failure #6
by James Hawkins 28 Sep '06

28 Sep '06

Hi, This is with a clean .wine. make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so sysparams.c && touch sysparams.ok sysparams.c:1471: Test failed: wrong value in registry -1, expected 154 sysparams.c:1474: Test failed: wrong value in registry -1, expected 0 sysparams.c:1477: Test failed: wrong value in registry -1, expected 0 sysparams.c:1480: Test failed: wrong value in registry -1, expected 8 make[2]: *** [sysparams.ok] Error 4 -- James Hawkins

1 0

make test failure #4
by James Hawkins 28 Sep '06

28 Sep '06

Hi, make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[0]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[1]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[2]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[3]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) make[2]: *** [monitor.ok] Error 4 -- James Hawkins

1 0

Re: Route WGL font code through gdi32.dll
by Huw Davies 28 Sep '06

28 Sep '06

On Thu, Sep 28, 2006 at 08:20:51PM +0200, Roderick Colenbrander wrote: > Again as mentioned by Huw, the gdi32.spec file wasn't correct. > It should be correct this time. No. Your gdi32.spec was fine. It was the opengl32.spec that was wrong (hint: that's why I quoted that bit of the patch ;-). Your patch is for the wglUseFont*Bitmaps* functions and not the wglUseFont*Outlines* functions, so the only thing that should be changing is the former and not the latter. So in opengl32.spec you need to forward the wglUseFont*Bitmaps* functions to functions of the same name in gdi32. Huw.

2 1

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype (2nd attempt)
by Vitaliy Margolen 28 Sep '06

28 Sep '06

Thomas Weidenmueller wrote: > The parameter of RpcMgmtSetServerStackSize needs to be unsigned long, > not unsigned int. > > - Thomas > It's been discussed numerous times, you should avoid use of 'long' in Wine. On win64 sizeof(long) == 4. On Linux64 sizeof(long) == 8. Vitaliy.

1 1

Re: Patchwork (was Re: Governance revisited)
by Ge van Geldorp 28 Sep '06

28 Sep '06

> From: Vitaliy Margolen <wine-devel(a)kievinfo.com> > > So in a sense you will require some one to respond for any > incoming e-mail to wine-patches. And if no one does, > Alexandre don't get to see the status? Not sure I understand what you mean. If no-one responds to the patch on wine-devel the patch would remain queued and it would show up in Alexandres list. > What if he already > applied the patch? Now you slowing down what would have > worked just fine before. If the patch is already applied it would be marked as such in the database. When a message is sent to wine-devel after the fact, it won't get magically un-applied. > Ok now you making it dependant on an e-mail client. Yet > that's exactly what we are trying avoid with GIT. Actually, my preference would be to do patch management via a web-based interface. But that's just my preference, I assume a lot of other people prefer the mailinglist method. So let's try to support both. > Not really. You can't make some one to review something that > don't understand. Or if they are busy/on vacation/away from > PC/etc. I'm not trying to change the review process, it would remain as-is. The only addition would be a bot which could do some checks (e.g. does the patch apply cleanly?). But that bot could be introduced anyway, even if Patchwork isn't introduced, so I guess it's not an integral part of the proposed system. > So in the end you'll end up with either huge queue > that no one wants to touch. Or a "clean up" jobs that will > once in a while go and mark all patches as old and will > require authors to resubmit. How's that better then what we use now? If no-one touches a patch, it would end up on Alexandres plate. He could review the patch himself or ask a subsystem maintainer to review it. Again, that's not different from the current system. If the queue of patches waiting for commit grows without bounds, that's a clear indication that Alexandre is overloaded and the project should find ways to remove some of his workload. The same would happen without a patch management system, but perhaps it wouldn't be as visible, so I'm chalking this one up as an added benefit of a patch management system. The system would also be self-cleaning. If a patch has been in RFC status too long it would be deleted from the queue (with appropriate warning email to the author) http://www.winehq.org/pipermail/wine-devel/2006-September/051114.html > When people well send out right hacks and expect some one to > tell then what they really should do. Current system allows > to no waste any time on such craft. We seem to have fundamentally different views of the "peripheral" (non-core) Wine developers. You seem to view them as potentially bad guys, going out of their way to submit hacks and decrease the quality of Wine code as much as possible, people you'd rather see leave. I see people willing to donate their time to improve Wine. Sure, they make mistakes but at least they make an effort. > No, by requiring some one to respond you making them > responsible (at least until they respond). Of course > responses like "sucks" wouldn't be nice, so some one who does > understand the subject will have to spend their time to > understand the patch, write a review of the patch and send > it. I don't get your point here. Isn't the purpose of reviewing to actually review the patch? > And you want that ASAP! Which means whenever patch > arrives in wine-patches some one (most likely more then one > person) will stop everything they are doing, and start > writing a review? No, I don't want to change the review process. It can remain just as it is now. My objective is to improve Wine by maximizing the number of patches of acceptable quality. In my opinion, this can be done by: 1) assuring no patches get lost 2) assuring an author gets informed about why his patch is not acceptable in its current form so he can improve it. Ge van Geldorp.

4 6

Award for solving bug 6183
by Mirek 28 Sep '06

28 Sep '06

There is bug in wine, which prevents me to play NFS MW with sound (and even Call of Duty). I would like to offer some money for solving this bug. I dont know how much will be good and i can give you all info from my system to solve this (debug, system info). If you are interested in just reply on my email address. Thanks, Mirek

1 0

Re: Setupapi: add stubs [resend]
by Alexandre Julliard 28 Sep '06

28 Sep '06

Julien <julienc(a)psychologie-fr.org> writes: > +/*********************************************************************** > + * SetupDiDestroyClassImageList(SETUPAPI.@) > + */ > +BOOL WINAPI SetupDiDestroyClassImageList(PSP_CLASSIMAGELIST_DATA ClassImageListData) > +{ > + FIXME ("Stub %p\n", ClassImageListData); > + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return TRUE; > +} > + > +/*********************************************************************** > + * SetupDiGetClassImageList(SETUPAPI.@) > + */ > +BOOL WINAPI SetupDiGetClassImageList(PSP_CLASSIMAGELIST_DATA ClassImageListData) > +{ > + FIXME ("Stub %p\n", ClassImageListData); > + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return TRUE; > +} It makes no sense to set last error if you return success. And you really shouldn't return success unless you also store the right things in that data structure. -- Alexandre Julliard julliard(a)winehq.org

1 0

Award for solving bug 6183
by Mirek 28 Sep '06

28 Sep '06

There is bug in wine, which prevents me to play NFS MW with sound (and even Call of Duty). I would like to offer some money for solving this bug. I dont know how much will be good and i can give you all info from my system to solve this (debug, system info). If you are interested in just reply on my email address. Thanks, Mirek

1 0

Re: msi: Implement MsiDatabaseImport [try2]
by Alexandre Julliard 28 Sep '06

28 Sep '06

"James Hawkins" <truiken(a)gmail.com> writes: > +static LPWSTR msi_read_text_archive(LPCWSTR path) > { > - FIXME("%p %s %s\n", db, debugstr_w(folder), debugstr_w(file) ); > + HANDLE file; > + LPSTR data = NULL; > + DWORD read, size = 0; > + > + file = CreateFileW( path, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL ); > + if (file == INVALID_HANDLE_VALUE) > + return NULL; > + > + size = GetFileSize( file, NULL ); > + data = msi_alloc( size + 1 ); > + if (!data) > + return NULL; > + > + if (!ReadFile( file, data, size, &read, NULL )) > + return NULL; > + > + data[size] = '\0'; > + return strdupAtoW( data ); > +} You're leaking both the file and the ascii string. -- Alexandre Julliard julliard(a)winehq.org

1 0

Coverity coverage of Wine
by Paul Vriens 28 Sep '06

28 Sep '06

Hi, the latest run (with report) on the Coverity site seems to be from July 21st. It appears that the main page is updated though (not for the lines of code but for the errors fixed). Does anybody know more about the why? I've tried to contact Coverity for the last month and my last email (where I've requested a read-receipt, shame on me) was deleted without being read. Cheers, Paul.

2 5

Re: Route WGL font code through gdi32.dll
by Huw Davies 28 Sep '06

28 Sep '06

On Thu, Sep 28, 2006 at 08:01:00AM +0200, Roderick Colenbrander wrote: > As mentioned by Huw, I forgot to attach the gdi32.spec changes :( > This is (hopefully) a full patch. > > --- dlls/opengl32/opengl32.spec 2006-09-25 23:15:35.000000000 +0200 > +++ dlls/opengl32/opengl32.spec 2006-09-27 23:09:11.000000000 +0200 > @@ -396,5 +396,5 @@ > @ stdcall wglSwapLayerBuffers(long long) > @ stdcall wglUseFontBitmapsA(long long long long) > @ stdcall wglUseFontBitmapsW(long long long long) > -@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) > -@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) > +@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) gdi32.wglUseFontOutlinesA > +@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) gdi32.wglUseFontOutlinesW You're still forwarding the wrong set of UseFont functions here. Your patch moved wglUseFontBitmaps to gdi32, so you should forward those not wglUseFontOutlines. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: oleaut32 1/2: [RESEND 2] Implements function varformat:VarWeekdayName
by Alexandre Julliard 28 Sep '06

28 Sep '06

"Benjamin Arai" <me(a)benjaminarai.com> writes: > + if (fAbbrev) > + if (iFirstDay == 0) > + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 5) % 7); > + else > + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 4) % 7); > + else > + if (iFirstDay == 0) > + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + iFirstDay + 5) % 7); > + else > + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + iFirstDay + 4) % 7); iFirstDay == 0 is supposed to mean system default, but that is locale-dependent, you can't simply hardcode it. -- Alexandre Julliard julliard(a)winehq.org

1 0

wined3d base GLX requirement
by Ivan Gyurdiev 28 Sep '06

28 Sep '06

The current base GLX requirement for wined3d seems to be v1.3. It won't compile otherwise... I wrote a patch for pbuffers, which adds proper extension support for SGIX_PBUFFER and SGIX_FBCONFIG, but: - even with the patch there's additional offenders in directx.c that prevent a compile with glx < 1.3 [ more FBCONFIG dependencies ] - there's comments in the source saying ATI supports pbuffers, but only advertises GLX_VERSION_1_3, without the appropriate extensions. So - should GLX 1.3 be considered a base requirement for wined3d, or should I send patches to clean up pbuffer dependencies?

5 6

Linklint results for winehq
by Tom Wickline 28 Sep '06

28 Sep '06

Hello, I ran our linklint script on winehq and here's the results. I will try and fix as many errors as possible over the next couple weeks. Tom --- Processing ... writing files to linklint wrote 25 txt files wrote 23 html files wrote index file index.html found 1 default index found 476 cgi files found 3 html files found 17 image files found 208 other files found 3833 http links found 5 https links found 20 ftp links found 54 mailto links found 15 news links found 2 unknown links found 2658 named anchors ----- 766 ignored files ----- 3 actions skipped ----- 125 files skipped warn 3 warnings ERROR 1 missing image file ERROR 3 missing other files ERROR 99 missing named anchors Linklint found 705 files and checked 500 html files. There were 4 missing files. 13 files had broken links. 103 errors, 3 warnings. real 5m58.972s user 0m6.960s sys 0m0.320s checking 3833 urls ...

1 1

Re: [PATCH] Also show 24bit modes as supported, but still handle them like 32bit later
by Vitaliy Margolen 28 Sep '06

28 Sep '06

Christoph Frick wrote: > hi > > would someone please comment on that patch? this is a nearly unchanged > version of my previous attempt - but this time against current git. > > -static const unsigned int depths[] = {8, 16, 32}; > +static const unsigned int depths[] = {8, 16, 32, 24}; > +static const unsigned int nr_depths = sizeof(depths) / sizeof(depths[0]); > Can you make a test that demonstrates presence of 24-bit color depth on native? I have checked winnt40, win2k, winxp and none offering 24-bit. Also I seen some programs and games that will crash if you tell them that we really in 24-bit (as most X users are). Vitaliy.

1 0

Re: Problem with NtReadVirtualMemory and wine server connection
by Juan Lang 28 Sep '06

28 Sep '06

Hi Peter, I'm guessing the fact that no one has replied means that no one has a strong opinion, or no one feels qualified to answer, or that AJ would prefer to see a patch first. I'll give my opinion in the hope of stimulating discussion, as I think it's important. > 1. allocate a temporary buffer in NtReadVirtualMemory, read server > answer to this buffer, and then inside a try / catch block copy to > application memory This would be my preference, for two reasons: 1. This would allow the test to pass, that is, we could successfully return STATUS_ACCESS_VIOLATION in this case. 2. The server protocol appears to be robust enough, as it crashes the client, not the server. The problem is mapping the fault to an NTSTATUS, and recovering from it. The disadvantage may be that each server request would have to be checked whether it could fail in the same way. Any other opinions? --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

How hard is Uniscribe's ScriptLayout() to implement?
by Dan Kegel 27 Sep '06

27 Sep '06

See http://bugs.winehq.org/show_bug.cgi?id=5772 Quicktime 6.5.x, Eclipse 3.2, Word XP, and other apps crash because usp10.ScriptLayout() isn't implemented. How hard would it be to fix this? - Dan

2 4

Re: Route WGL font code through gdi32.dll
by Huw Davies 27 Sep '06

27 Sep '06

On Wed, Sep 27, 2006 at 11:34:35PM +0200, Roderick Colenbrander wrote: > Hi, > > This patch routes the WGL font code through gdi32.dll. The patch depends on the other routing patch which routed the WGL context code through gdi32.dll. > --- dlls/opengl32/opengl32.spec 2006-09-25 23:15:35.000000000 +0200 +++ dlls/opengl32/opengl32.spec 2006-09-27 23:09:11.000000000 +0200 @@ -396,5 +396,5 @@ @ stdcall wglSwapLayerBuffers(long long) @ stdcall wglUseFontBitmapsA(long long long long) @ stdcall wglUseFontBitmapsW(long long long long) -@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) -@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) +@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) gdi32.wglUseFontOutlinesA +@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) gdi32.wglUseFontOutlinesW You want to forward the wglUseFontBitmaps functions here since that's what the rest of your patch touches ;-) You also forgot to include the changes to gdi32.spec. Huw.

1 0

Re: Patchwork (was Re: Governance revisited)
by Ge van Geldorp 27 Sep '06

27 Sep '06

> From: Alexandre Julliard <julliard(a)winehq.org> > > If you expect > anything to happen, you'll need to make much more concrete > suggestions, and provide examples to make us understand how > what you are suggesting would work in practice Fair enough. Some disclaimers upfront: I'm basically thinking out loud, I have no idea what your typical workflow looks like. I'm also not restrained by any knowledge of emacs and what can be done in its plugins, macro's, user-defined commands or whatever they're called. But I know I could code the proposal below in e.g Perl or C, so I guess it should be possible in Lisp also. Who's going to code that is a different matter altogether, let's first see if we can think of a solution which would work. Let's assume a patch is submitted to wine-patches. A bot would receive it and store it in a database (Patchwork already seems to do a fine job on this). The bot could do some simple checks, like does it apply cleanly, no C++ comments, whatever automatic checks we can come up with. If one of the checks fails, the status would be set to RFC (Request For Change, I'm using the Patchwork statuses here) and the author would receive an automatic email explaining what's wrong, otherwise the status would be set to New. Note that this should save you some time, weeding out "obviously" wrong patches. On to your workflow. You'd issue a Meta-Ctrl-Shift-whatever emacs command. Behind the scenes, this would send a request to the webserver which would reply with a list of queued patches. This list could be sorted by a score. Authors who consistently submit good patches would get a higher score than, well, me. This score could be computed as the number of accepted patches minus the number of rejected patches. A patch already reviewed (and recommended) by a subsystem maintainer could get a real big score boost so it ends up near the top of the list. Patches which have been in the queue for a few days could get extra points. Patches with RFC status wouldn't be shown at all or get a very low score. Anyway, you end up with a list of patches on your screen with the least problematic near the top. This should help ensure that these get through pretty quickly. So you select a patch which is then retrieved from the server. It could be automatically applied, a build started, whatever suits you best. Comments made on it by other developers could be shown to you. After testing is complete, you issue a "decision" command. You can decide to accept the patch, that would send an "accept" message to the webserver and perhaps it could be comitted to your git repo. If the patch needs more work, you'll be prompted for a message. That message will be mailed to the author with a copy to win-devel and it will be sent to the webserver which will change the patch status to RFC. If you think the patch is beyond hope it can be rejected outright (again with a message to author and wine-devel). Or you can decide not to decide on it today and sleep on it for a night. Then the patch will just show up in the list of pending patches again tomorrow, with a little bit higher priority (since it has been in the queue longer). Back to the list of pending patches, repeat. > and how it would be different from what we are doing now. It would make sure the author always receives some kind of feedback (either from the bot, other developers or yourself) and would make sure patches don't get lost (patches are automatically entered into the system and only leave the system when the author withdraws them or when you make a final decision). Ge van Geldorp.

6 6

re: oleaut32 2/2: [RESEND] Conformance test for varformat:VarWeekdayName
by Dan Kegel 27 Sep '06

27 Sep '06

Alexandre wrote: > How will this test work in non-English locales? How about if it calls SetThreadLocale(LOCALE_INVARIANT)?

3 2

Re: start.exe: Implement /D option, add new wine specific feature allowing to specify the shell operation name (resend)
by James Hawkins 27 Sep '06

27 Sep '06

On 9/26/06, Paul Chitescu <paulc(a)voip.null.ro> wrote: > Changelog: start.exe: Implement /D option, add new wine specific feature > allowing to specify the shell operation name. > > The new /O[peration] command line option allows to specify a shell operation > other than "open". This is very valuable for testing or implementing actions > from shell scripts. > > It is also possible to pass a NULL operation by specifying the empty string > '' (or whatever looks like in your preferred shell). > > Examples: > wine start /d 'c:\' notepad.exe > wine start /o print README.txt > Only submit one fix per patch. Please read the WineHQ patch guidelines: http://winehq.org/site/sending_patches Why are you adding a new switch? This isn't provided by native start.exe, so we shouldn't add it. -- James Hawkins

2 2

Re: localspl: [1/3] Build the Importlib
by Alexandre Julliard 27 Sep '06

27 Sep '06

Detlef Riekenberg <wine.dev(a)web.de> writes: > We need the importlib for the tests It doesn't seem that we should have an importlib, there isn't one in the SDK either. The tests can always use GetProcAddress. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] Also show 24bit modes as supported, but still handle them like 32bit later
by Stefan Dösinger 27 Sep '06

27 Sep '06

Hi, > would someone please comment on that patch? this is a nearly unchanged > version of my previous attempt - but this time against current git. Not so sure about it. I am afraid I do not completely understand the color depth issue, but it appears to me that a patch like that rather hides the problem than fixing it. It is not possible to chance the depth on the fly on X11, so we may want a solution for all color depths.

1 0

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype
by Dmitry Timoshkov 27 Sep '06

27 Sep '06

"Thomas Weidenmueller" <wine-patches(a)reactsoft.com> wrote: > The parameter of RpcMgmtSetServerStackSize needs to be unsigned long, > not unsigned int. Then it should be changed to 'ULONG' or 'unsigned LONG' for compatibility with Win64. -- Dmitry.

2 2

Re: oleaut32 2/2: [RESEND] Conformance test for varformat:VarWeekdayName
by Alexandre Julliard 27 Sep '06

27 Sep '06

"Benjamin Arai" <me(a)benjaminarai.com> writes: > +void test_VarWeekdayName(void) > +{ > + WCHAR day_LongFormat[][10] = > + { > + {'S','u','n','d','a','y',0}, > + {'M','o','n','d','a','y',0}, > + {'T','u','e','s','d','a','y',0}, > + {'W','e','d','n','e','s','d','a','y',0}, > + {'T','h','u','r','s','d','a','y',0}, > + {'F','r','i','d','a','y',0}, > + {'S','a','t','u','r','d','a','y',0} > + }; How will this test work in non-English locales? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: clusapi: Implements stub dll for clusapi
by Alexandre Julliard 27 Sep '06

27 Sep '06

"Benjamin Arai" <me(a)benjaminarai.com> writes: > Fixes bug http://bugs.winehq.org/show_bug.cgi?id=6265 > > The application for bug 6265 checks if clusapi.dll exists and attempts > to call clusapi:GetNodeClusterState from it. This patch adds a stub > implementation for the DLL clusapi and GetNodeClusterState. You need to add a DLL_WINE_PREATTACH handler when adding a stub dll. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wintrust.h: add missing defines
by Paul Vriens 27 Sep '06

27 Sep '06

On Tue, 2006-09-26 at 22:08 -0700, Juan Lang wrote: > #define WTD_UI_ALL 1 > #define WTD_UI_NONE 2 > @@ -115,6 +118,42 @@ > DWORD dwUIContext; > } WINTRUST_DATA, *PWINTRUST_DATA; > > +#define WTD_UI_ALL 1 > +#define WTD_UI_NONE 2 > +#define WTD_UI_NOBAD 3 > +#define WTD_UI_NOGOOD 4 > + > +#define WTD_REVOKE_NONE 0 > +#define WTD_REVOKE_WHOLECHAIN 1 > + > +#define WTD_CHOICE_FILE 1 > +#define WTD_CHOICE_CATALOG 2 > +#define WTD_CHOICE_BLOB 3 > +#define WTD_CHOICE_SIGNER 4 > +#define WTD_CHOICE_CERT 5 Hi Juan, these ones you've added are already in (see also first line in the excerpt from your email). Cheers, Paul.

2 1

Re: H. Verbeet : wined3d: Add support for native NPOT textures.
by Frank Richter 27 Sep '06

27 Sep '06

On 27.09.2006 10:46, Alexandre Julliard wrote: > @@ -765,6 +768,12 @@ #undef USE_GL_FUNC > > gl_info->max_sampler_stages = max(gl_info->max_samplers, gl_info->max_texture_stages); > > + /* We can only use NP2_NATIVE when the hardware supports it. */ > + if (wined3d_settings.nonpower2_mode == NP2_NATIVE && !gl_info->supported[ARB_TEXTURE_NON_POWER_OF_TWO]) { > + WARN_(d3d_caps)("GL_ARB_texture_non_power_of_two not supported, falling back to NP2_NONE NPOT mode.\n"); > + wined3d_settings.nonpower2_mode = NP2_NONE; > + } > + FYI, ATI r300+ hardware has some limited support for NP2 textures - that is, 2D textures without mipmaps and repeat mode CLAMP. But since that does not fulfill the ARB_tnpot requirements this extension isn't published. Still, maybe you can exploit that feature somehow... -f.r.

1 0

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype
by Michael Stefaniuc 27 Sep '06

27 Sep '06

Thomas Weidenmueller wrote: > The parameter of RpcMgmtSetServerStackSize needs to be unsigned long, > not unsigned int. Won't work on Win64. long is 32bits on Win32 and Win64. On Linux64 long is 64bits. bye michael > ------------------------------------------------------------------------ > > Index: dlls/rpcrt4/rpc_server.c > =================================================================== > RCS file: /home/wine/wine/dlls/rpcrt4/rpc_server.c,v > retrieving revision 1.58 > diff -u -r1.58 rpc_server.c > --- dlls/rpcrt4/rpc_server.c 30 Jun 2006 19:16:38 -0000 1.58 > +++ dlls/rpcrt4/rpc_server.c 27 Sep 2006 12:38:00 -0000 > @@ -1008,7 +1008,7 @@ > /*********************************************************************** > * RpcMgmtSetServerStackSize (RPCRT4.@) > */ > -RPC_STATUS WINAPI RpcMgmtSetServerStackSize(unsigned int ThreadStackSize) > +RPC_STATUS WINAPI RpcMgmtSetServerStackSize(unsigned long ThreadStackSize) > { > FIXME("(0x%x): stub\n", ThreadStackSize); > return RPC_S_OK; -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype
by Paul Vriens 27 Sep '06

27 Sep '06

On Wed, 2006-09-27 at 14:40 +0200, Thomas Weidenmueller wrote: > FIXME("(0x%x): stub\n", ThreadStackSize); Shouldn't that be (0x%lx) then ? Cheers, Paul.

1 0

some wineconference pictures
by Marcus Meissner 27 Sep '06

27 Sep '06

Hi, Some Wine conference pictures from David and myself: http://gallery.kuschelt.net/main.php?g2_view=core.ShowItem&g2_itemId=100617 Ciao, Marcus

2 1

Governance revisited
by Robert Lunnon 27 Sep '06

27 Sep '06

I note the recent flamefest, where some of this list seared yet another contributor (Roland Kaeser) Since this particular very old, very shrivelled chestnut. is one of my personal favourites (thanks to Colin Wright for the chestnut thing...). I'd like to repeat my observations about this. Feel free to flame away since I have donned my asbestos suit and have long since decided my viewpoint. The problem is that code gets rejected that is *** NOT *** Hacky because there is a, single point of review - a single opinion of what constitutes a hack, and no appeal process. For example I once submitted code to implement cpu.c using the x86 cpuid instruction directly on all x86 platforms. This was NO hack. But the code was rejected. This code replaces the OS specific code for several x86 cases with generic code. The way I see it this code removes hacks (since I consider any OS specific code fragment a hack). This just shows that opinions differ about what a hack is. This code now sits in my patch-kit, never to see the light of day on wine-hq, but happily runs in every copy of wine for Solaris for the last 4 years with ZERO issues. No hacks should not be an objective, by my definition wine already has more hacks than just about any other open source package out there. Linuxisms continue to contaminate wine every month (I can vouch for it). What we need is management, balance between function and beauty delivered by peer review. Necessary functional hacks should be allowed unless they have severe side-effects. Even application specific work-arounds can be permitted if the work around adds significant functionality per the objectives of the project, the scope of the work-around is suitably confined, and assuming the code can be maintained over time. Wine needs process... The issue is not code, It's governance. Governance to establish balance, balance between beauty and function. Bob

24 55

re: shlwapi: Resupply array sizes stripped by function interface
by Dan Kegel 27 Sep '06

27 Sep '06

Andrew Talbot wrote: >A formal parameter declared as an array is treated as a pointer; any size >specifier is ignored. So here, sizeof decimal_buffer, for example, would >equate to the size of a pointer to WCHAR, not to that of an array of eight >WCHARs. Why are you doing this? - Dan

3 8

re: start.exe: New feature allowing to specify the shell operation name
by Dan Kegel 27 Sep '06

27 Sep '06

>The new /O[peration] command line option allows to specify a shell >operation other than "open". > This is very valuable for testing or implementing actions from shell scripts. Hmm. I don't see that option in the Win XP documentation: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en… There's already one clash (/l) between wine's start and Windows'. I hesitate to say that adding another extension is a good idea. I'd feel better if the help mentioned that this is a Wine-specific extension. - Dan

2 2

Re: Governance revisited
by jimtabor 26 Sep '06

26 Sep '06

Hi, Dmitry Timoshkov wrote: > > > How many projects have you ever participated in? Every developers' > mailing list > of an open source I personally participated in *doesn't guarantee* not > only patch > acceptance, but even a reply with explanations why the patch has been > silently > dropped, and it doesn't matter how many maintainers a project has. Why > do you > request that from Wine, and particularly from Alexandre? > > Alexandre is not a robot, he is a human. Please take that into account. Sounds like he need more help. > > It's a metter of the fact, that if you can't cope with other people's > requirements, > you can't work in a team. > Every Wine developer needs to read this, http://www.codeweavers.com/services/ and http://www.codeweavers.com/services/wine . It is your job to provide support for this product, I spend money and I need help, where do I go? Are you going to piss me off by telling me to shut up and put up with the poor support from this mailing list? This project needs a course in technical sales support. Good idea for the next WineConf! Remember you represent CodeWeavers, start acting like it. 8^D, James

6 7

Re: cabinet: Fix NULL pointer dereference (Coverity)
by James Hawkins 26 Sep '06

26 Sep '06

On 9/26/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > Changelog: > cabinet: Fix NULL pointer dereference (Coverity). > > diff -urN a/dlls/cabinet/fci.c b/dlls/cabinet/fci.c > --- a/dlls/cabinet/fci.c 2006-09-12 23:59:28.000000000 +0100 > +++ b/dlls/cabinet/fci.c 2006-09-26 18:27:03.000000000 +0100 > @@ -176,18 +176,22 @@ > if ((!perf) || (!pfnalloc) || (!pfnfree) || (!pfnopen) || (!pfnread) || > (!pfnwrite) || (!pfnclose) || (!pfnseek) || (!pfndelete) || > (!pfnfcigtf) || (!pccab)) { > - perf->erfOper = FCIERR_NONE; > - perf->erfType = ERROR_BAD_ARGUMENTS; > - perf->fError = TRUE; > + if (perf) { > + perf->erfOper = FCIERR_NONE; > + perf->erfType = ERROR_BAD_ARGUMENTS; > + perf->fError = TRUE; > + } > > SetLastError(ERROR_BAD_ARGUMENTS); > return NULL; > } > > if (!((hfci = ((HFCI) (*pfnalloc)(sizeof(FCI_Int)))))) { > - perf->erfOper = FCIERR_ALLOC_FAIL; > - perf->erfType = ERROR_NOT_ENOUGH_MEMORY; > - perf->fError = TRUE; > + if (perf) { > + perf->erfOper = FCIERR_ALLOC_FAIL; > + perf->erfType = ERROR_NOT_ENOUGH_MEMORY; > + perf->fError = TRUE; > + } > > SetLastError(ERROR_NOT_ENOUGH_MEMORY); > return NULL; > This last check is pointless. If perf is NULL, we bail out and return NULL a few lines up. Also, please add a test showing that native does not crash if a NULL perf is sent in. It's weird, but we need to be consistent with native, as some apps depend on such a crash. -- James Hawkins

2 1

Re: Alexandre Julliard : explorer: Work around the latest HAL binary compatibility breakage.
by Marcus Meissner 26 Sep '06

26 Sep '06

On Tue, Sep 26, 2006 at 03:04:47PM -0500, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 9ae4e8d98efc952918bcdae86b2f640c4b062a3b > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=9ae4e8d98efc952918bcdae… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Tue Sep 26 20:29:15 2006 +0200 > > explorer: Work around the latest HAL binary compatibility breakage. > - if (!(dbus_handle = wine_dlopen(SONAME_LIBDBUS_1, RTLD_NOW, error, sizeof(error)))) goto failed; > - if (!(hal_handle = wine_dlopen(SONAME_LIBHAL, RTLD_NOW, error, sizeof(error)))) goto failed; > + /* Load libhal with RTLD_GLOBAL so that the dbus symbols are available. > + * We can't load libdbus directly since libhal may have been built against a > + * different version but with the same soname. Binary compatibility is for wimps. */ Yet another Redhat stumbling block ;) But they warn in pretty large letters: cat /usr/lib/pkgconfig/hal.pc ... Cflags: -DDBUS_API_SUBJECT_TO_CHANGE -I${includedir}/hal ... #ifndef DBUS_API_SUBJECT_TO_CHANGE #error "Please define DBUS_API_SUBJECT_TO_CHANGE to acknowledge your understanding that D-BUS hasn't reached 1 .0 and is subject to protocol and API churn. See the README for a full explanation." #endif ciao, Marcus

1 0

WineD3D: glBlend* fixes
by Roland Scheidegger 26 Sep '06

26 Sep '06

> Roderick, Mesa calls the extension "GL_EXT_blend_minmax", and so does > the spec. I don't know what exactly uses the min_max form. Is this a > typo? Apart from the blend_minmax typo, it appears to be me this patch has some other problems. >> This patch changes the detection extension detection for >> glBlendColor/glBlendEquation. The function glBlendColor is part of >> OpenGL 1.1 and is supported on all OpenGL implementations. No, it's not. Calls to it are ONLY legal on opengl up to 1.3 if either ARB_imaging or EXT_blend_color are supported (the spec says "Blend Color is an imaging subset feature, and is only allowed when the imaging subset is supported"). It is however part of OpenGL 1.4. So, a really correct detection would be to check for ogl version 1.4, EXT_blend_color, ARB_imaging. Maybe the check for ARB_imaging could be omitted, but it is possible there are drivers out there which only announce support for ARB_imaging but not EXT_blend_color, according to www.delphi3d.net there are indeed some tnt2's out there which claim support for ARB_imaging but not EXT_blend_color - if I'd have to guess I'd suspect the call to glBlendColor results in a sw fallback. >> Further glBlendEquation is part of GL_ARB_imaging aswell. For the >> same reason GL_ARB_imaging can't be used to detect glBlendEquation. >> This call isn't supported on all OpenGL implementations. Luckily it >> is part of 'GL_EXT_blend_min_max' so that is used now. This is not quite so simple. If OGL 1.4 is supported, or the version is lower but ARB_imaging itself is supported, all the blend function stuff from ARB_imaging is ok. If only either EXT_blend_minmax or EXT_blend_subtract is supported, then glBlendEquation is supported, but only different modes are valid (FUNC_ADD, MIN, MAX for EXT_blend_minmax, FUNC_ADD, FUNC_SUBTRACT, FUNC_REVERSE_SUBTRACT for EXT_blend_subtract). But if all you care is that glBlendEquation is available, you should probably detect ogl 1.4, and EXT_blend_subtract (some cards only support EXT_blend_subtract but not EXT_blend_minmax), but really for correctness EXT_blend_minmax and ARB_imaging should be checked too. Roland (not subscribed to wine-devel - include me in cc for answers)

4 8

Using gdb
by Craig Keogh 26 Sep '06

26 Sep '06

Hi, I am trying to use gdb for debugging. I run the command: winedbg --gdb sol.exe I then get the following output: WineDbg starting on pid 0xa fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for wine-pthread fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for libwine.so.1 fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for ntdll<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for kernel32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for msvcrt<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for advapi32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for gdi32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for user32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for cards<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for shell32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for shlwapi<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for ole32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for rpcrt4<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for iphlpapi<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for comctl32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for winex11<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for imm32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for uxtheme<elf> 0x7eecaf5a start_process+0xde in kernel32: movl %edi,0x0(%esp) I don't end up with a gdb prompt. It is just stuck there. I am following: http://www.winehq.com/site/docs/winedev-guide/dbg-others I compiled wine (from GIT) using gcc v4.0.3, I am using gdb v6.4-debian. Running without gdb ('winedbg sol.exe') works fine. Thanks in advance,

2 2

Problem with NtReadVirtualMemory and wine server connection
by Peter Oberndorfer 26 Sep '06

26 Sep '06

Hi, throught a problem in winedbg i found out that NtReadVirtualMemory has a problem, when reading into a invalid local buffer. it uses wine_server_set_reply( req, buffer, size ); to read the data supplied by the server directly into application memory of unknown state. when the read call hits bad(non present/readonly ) memory it returns EFAULT and the client dies with "wine client error:<process id>: read: Bad address" i see 3 ways to deal with this problem 1. allocate a temporary buffer in NtReadVirtualMemory, read server answer to this buffer, and then inside a try / catch block copy to application memory 2. change server protocol so it is not as sensitive when read returns EFAULT (i do not really like this idea) 3. just fix the bug in winedbg and wait until a real world app needs this behavior. (of course i will send a patch for windbg even if one of the other ways is choosen) Any ideas? Greetings Peter PS: attached a testcase for NtReadVirtualMemory(testcase itself not tested on windows, but tests were) the test should probably also live in its own file, but i didn't want to create a almost empty file

1 0

Re: msi [1/5]: Implement MsiDatabaseImport
by Alexandre Julliard 26 Sep '06

26 Sep '06

"James Hawkins" <truiken(a)gmail.com> writes: > +static const WCHAR insert_fmts[][100] = > +{ > + {'I','N','S','E','R','T',' ','I','N','T','O',' ','`','%','s','`',' ','(',' ',0}, > + {'`','%','s','`',',',' ',0}, > + {' ',')',' ','V','A','L','U','E','S',' ','(',' ',0}, > + {'\'','%','s','\'',',',' ',0}, > + {'%','s',',',' ',0}, > + {' ',')',0}, > +}; It would be cleaner to use separate variables for the separate strings, there's no reason this needs to be an array. It would avoid wasting a lot of space, and make it more explicit what the strings mean, unlike something like insert_fmts[3]. Also since all you do is copy strings, it may be even cleaner to avoid sprintf and simply strcat the strings and the separators. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: D3D9: Add a pitch test for a 1x1 texture
by H. Verbeet 26 Sep '06

26 Sep '06

On 26/09/06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > To verify that the 32 bit alignment is true for 1x1 textures too. > >+ /* test is deactivated until out np2 support doesn't report the full power of 2 pitch to the app */ >+ todo_wine ok(lockedRect.Pitch == 4, "Got pitch %d, expected 4\n", lockedRect.Pitch); Shouldn't the test be about alignment, rather than the exact size? I that case the power-of-two stuff shouldn't matter either, as long as it's properly aligned. I do have an initial patch for native NPOT support, but it will (of course) only work on cards that support the relevant extension.

2 3

Re: [D3D9] Update state test framework
by Alexandre Julliard 26 Sep '06

26 Sep '06

Ivan Gyurdiev <ivg231(a)gmail.com> writes: > Changelog: > ========== > 1) Abandon central memory allocation, and the tracking that involves. > Write a setup() and teardown() handler for each test, and use heap > allocation. > > 2) Make the main test function configure test arguments. > Replace get/set arguments with a single test_arg. > > 3) Remove some const qualifiers on test data. > Const qualifiers should go on function parameters instead. When you find yourself writing a Changelog like this, it's a clear sign that it should be 3 separate patches. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: user: test and fix SwitchToThisWindow [3rd try]
by Alexandre Julliard 26 Sep '06

26 Sep '06

Jan Zerebecki <jan.wine(a)zerebecki.de> writes: > diff --git a/dlls/user/winpos.c b/dlls/user/winpos.c > index 6bc9056..e78f484 100644 > --- a/dlls/user/winpos.c > +++ b/dlls/user/winpos.c > @@ -152,7 +152,20 @@ UINT WINAPI ArrangeIconicWindows( HWND p > */ > void WINAPI SwitchToThisWindow( HWND hwnd, BOOL restore ) > { > - ShowWindow( hwnd, restore ? SW_RESTORE : SW_SHOWMINIMIZED ); > + HWND hwndOld = GetForegroundWindow(); > + SetActiveWindow( hwnd ); > + SetForegroundWindow( hwnd ); > + if ( restore ) > + { > + if ( IsIconic( hwnd ) ) > + ShowWindow( hwnd, SW_RESTORE ); > + } > + else > + { > + if ( !( GetWindowLongW( hwndOld, GWL_EXSTYLE ) & WS_EX_TOPMOST ) ) > + SetWindowPos( hwndOld, HWND_BOTTOM, 0, 0, 0, 0, > + SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE ); > + } That HWND_BOTTOM thing looks very wrong, SwitchToThisWindow is supposed to move things to the front. Most likely your test case is flawed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Tips for vim users
by n0dalus 26 Sep '06

26 Sep '06

Hi, Recently I learned a way to have vim automatically change settings when I'm editing wine source code: At the bottom of my ~/.vimrc (create it if it doesn't exist): if !exists("loaded_vimrc_autocmd") let loaded_vimrc_autocmd=1 autocmd BufNewFile,BufRead /data/wine/* set expandtab tabstop=8 softtabstop=4 endif In my case my wine tree is in /data/wine, so replace this with the first part of the path to your wine tree. Using the same syntax you can also put custom settings for other projects you might work on. This is helpful for me since I usually like to indent using tabs and a 4 space tab width, but now I can edit most of wine's code without having to worry about fixing my indents all the time. If anyone is interested, I've also got another Vim tip on the wiki (from last year), to automate the creation of wide character arrays: http://wiki.winehq.org/Character_arrays_in_Vim If any other vim users have tips that help out with wine coding, I'd love to hear them! Maybe we can make a page on the wiki for them. n0dalus.

2 4

Re: Governance revisited (Wineconf report)
by Ge van Geldorp 26 Sep '06

26 Sep '06

> From: Kai Blin > > Now, getting back to the patch submission process, you're talking about a > patch management system. How would that look like, in your opinion. We were > discussing a couple of ideas, but in the end figured that most of those would > slow down the submission speed of patches that are accepted. > > Our idea was to have patches be recieved by the subsytem maintainers, and > Alexandre would only apply patches he got from those guys. We voted that one > down. > > Now I would be interested in your idea for such a system. I figure that > writing an emacs frontend won't be too troublesome if it's reasonably > designed, so let's ignore that for now. A patch management system isn't exactly a new idea. It came up last year, during the same type of discussion we're having now (and it will probably come up next year when we have the same discussion again). See e.g. http://www.winehq.org/pipermail/wine-devel/2005-September/039837.html and note this sentence: "However, it became clear that the requirements were fairly substantial (the tight emacs integration became our first clue :-/), and that project got back burnered." The users of such a patch management system would fall into 3 categories: Developers/patch submitters, subsystem maintainers and Alexandre. I can take a guess at what subsystem maintainers and Alexandre would want from such a system, but of course I can only really speak as a patch submitter. My primary requirements would be to be able to: - Submit a patch - Specify a subsystem - Keep track of its progress - Resubmit after receiving feedback - Get an overview of patches in the queue - Apply a queued patch to my working copy - Provide feedback to others - Withdraw a patch In addition to the patch submitter requirements, subsystem maintainers would probably like to be able to: - Get an overview of patches relevant to their subsystem - Recommend a patch for inclusion In addition to all of the above, I guess Alexandre would need to be able to: - Get an overview of recommended patches - Commit a patch - Reject a patch - All from within emacs Moving on to implementation, I see a set of database tables giving a patch the following attributes: - Submitter - Short description - Status (Queued, Waiting for developer, Recommended, Withdrawn, Committed, Rejected) - Subsystem - Patch text (multiple versions, to allow resubmits and still keep a history) - Comments Some status changes are restricted (e.g. only a subsystem maintainer would be able to recommend a patch). Everyone would be able to submit a patch, which would initially have Queued status. When feedback is provided, the feedback provider (anyone) could change the status to Waiting for developer. If a patch is in "Waiting for developer" status too long (say a month) it could be automatically rejected. When "Waiting", the submitter could provide a new version or respond with a comment, setting the status back to Queued again. Or he could decide to Withdraw the patch. When a patch makes it into the tree it will gain the most holy of all statuses, Committed. I envision manually Rejecting a patch to be a pretty rare case, normally feedback would be provided and the Waiting status would be set. Uncommittable patches would then exit the system via the automatic clean up (in "Waiting" too long) or via a Withdraw. The heart of the system would be a couple of web pages. However, not everyone likes web pages and the current system with mailing lists does have its strong points too. So, there could be a two-way gateway between the web system and the mailing lists. If a patch is submitted via the web, it could be sent out via wine-patches too. If a patch comes in via wine-patches, it could be added to the database automatically (when that doesn't succeed a notification is sent to the author). Same for comments, they could be fed from the web page to wine-devel. If there is genuine interest to make this work I could put up a few mock webpages to get a better idea of how it would work. Gé van Geldorp.

6 6

Re: Governance revisited
by jimtabor 26 Sep '06

26 Sep '06

James Hawkins wrote: > On 9/25/06, jimtabor <jimtabor(a)users.sourceforge.net> wrote: > >> >> Every Wine developer needs to read this, >> http://www.codeweavers.com/services/ and >> http://www.codeweavers.com/services/wine . >> > > I'm a Wine developer, and I don't work for codeweavers. Why should I > read that? > You don't need to. >> It is your job to provide support for this product, I spend money and I >> need help, where do >> I go? >> > > It is not my job to provide support for this product. Even if you're > referring to Dmitry and everyone else that works at Codeweavers, > you're still wrong. This is the wine-devel mailing list, and has > nothing to do with Codeweavers. You confuse Crossover Office and Wine > as being the same product/project. Just because they work at > Codeweavers, can they not also work on Wine and not have affiliation > with Codeweavers? Of course they can, as can anyone else who has a > real job outside of Wine. > NO! You are WRONG, sir! ~and I quote from http://www.codeweavers.com/services/ "Since 1999, CodeWeavers has been hiring the very best Wine developers. Chief among these is Alexandre Julliard <http://www.codeweavers.com/about/people/alexandre/>, the long-time maintainer of the Wine Project itself. In addition to Alexandre's prodigious talents, we have consistently hired the very best Wine resources, recruiting them literally worldwide." Wine is CO as is CO is Wine! Wine is the heart of CO with out it CW would not have a product. They get paid for working on Wine to support CO. Don't you see that?! > First, he doesn't represent Codeweavers on the wine-devel mailing > list. Second, there's nothing unprofessional about his actions. > Missed my point! If his address has "name(a)codewreavers.com", than yes, that person does represent that organization. This project is NOT LINUX or X11, it is a paid for add on to it. I pay good money for support and I expect to get it. It is shocking to most FOSS code writers that maybe this is a real, truly, paid for project. "No! It can not be! I contribute to someones profit? NOOoooooooo~~~!". Thanks, James

3 2

Re: Governance revisited
by jimtabor 26 Sep '06

26 Sep '06

Wow, just like that! James Hawkins wrote: >> It is shocking to most FOSS code writers that maybe this is a real, >> truly, paid for project. "No! It can not be! I contribute to someones >> profit? NOOoooooooo~~~!". > The above is a famous quote I read from Linux Journal magazine. > > I am well aware that Codeweavers funds most of Wine development, and I > appreciate every bit of support coming from them, but this project > would continue even without their support. > > -- > James Hawkins > >> NO! You are WRONG, sir! >> NOOoooooooo~~~! > > > P.S. You should really calm down. It's hard to take you seriously > when you act immature. > I am calm, lol! immature? just a little! 8^D So, after reading this ML for years and assessing. Seriously, If I was a contractor representative researching code weavers ability to support their product, the last thing I would expect from any of their developers would be the lack of customer support and poor attitude on IRC. At lest if one of my employees does go out and join wine IRC, I would hope they will not get kicked or banned for asking to many questions. Understanding this, has made my mind up and forced to stop linux migration due to the lack of support and maturity of wine and code weavers. We do have contracts with Red Hat, SCO, Solaris, Raytheon,,,,, Oh the shock of that, yes we are considering the use of wine for moving away from Microsoft windows. Wine was the stop gap in our mission to provide both Linux and Window applications in a real time environment. That M$ update thingy is a ass kicker on real time systems, that must operate 24/7. Having said that,,,, sorry I can't authorize any contracts with code weavers. Sorry, you just never know sometime, James

1 0

make test failing in shell32
by Kai Blin 25 Sep '06

25 Sep '06

Hi folks, running make test repeatedly in a new wine prefix finally gives this error: make[2]: Entering directory `/home/nowhere/dev/wine/wine-build/dlls/shell32/tests' ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfileop.c && touch shlfileop.ok shlfileop.c:168: Test failed: The requested file does not exist, ret=3 I've attached the +shell trace bzip2ed, the uncompressed trace is 2.2 megs. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

Re: [RPCRT4] support for RPC TCP servers
by Robert Shearman 25 Sep '06

25 Sep '06

Damjan Jovanovic wrote: > Changelog: > * Makes RPCRT4 use Winsock2 instead of native sockets (needed for > event object support) > * Adds support for TCP (ncacn_ip_tcp protocol) servers I appreciate your attempt at solving this hard problem, but I don't believe this is the right approach. Using winsock2 instead of Unix sockets adds overhead in terms of wineserver calls and extra processing time to mangle arguments, which we shouldn't need. The reasoning for this is that at some point I want to use Unix domain sockets for the ncalrpc provider, so it should be as fast as possible. More detailed comments inline: > > --- a/include/ws2tcpip.h 2006-08-28 20:35:33.000000000 +0200 > +++ b/include/ws2tcpip.h 2006-09-16 08:55:45.000000000 +0200 > @@ -137,6 +137,8 @@ > #define WS_IFF_MULTICAST 0x00000010 /* multicast is supported */ > #endif /* USE_WS_PREFIX */ > > +#define INET_ADDRSTRLEN 16 > + > #ifndef USE_WS_PREFIX > #define IP_OPTIONS 1 > #define IP_HDRINCL 2 > This change looks good. Please submit it separately. > +static const char *gai_strerror(int errcode) > +{ > + switch (errcode) > + { > + case EAI_AGAIN: return "Temporary failure in name resolution"; > + case EAI_BADFLAGS: return "Bad value for ai_flags"; > + case EAI_FAIL: return "Non-recoverable failure in name resolution"; > + case EAI_FAMILY: return "ai_family not supported"; > + case EAI_MEMORY: return "Memory allocation failure"; > + case EAI_NONAME: return "Name or service not known"; > + case EAI_SERVICE: return "Servname not supported for ai_socktype"; > + case EAI_SOCKTYPE: return "ai_socktype not supported"; > + } > + return "Unknown error"; > +} > + > +static const char *inet_ntop(int af, const void *src, char *dst, int cnt) > +{ > + if (af == AF_INET) > + { > + unsigned int addr = * (unsigned int*) src; > + if (cnt < INET_ADDRSTRLEN) > + return NULL; > + snprintf(dst, cnt, "%u.%u.%u.%u", (addr >> 24) & 0xFF, > + (addr >> 16) & 0xFF, (addr >> 8) & 0xFF, addr & 0xFF); > + return dst; > + } > + else > + return NULL; > +} > + > These should obviously not be here. I believe gai_strerror is implemented as a macro in one of the winsock header files. I think inet_ntop should be implemented in ws2_32.dll. > @@ -506,51 +516,115 @@ > continue; > } > > - if (0>connect(sock, ai_cur->ai_addr, ai_cur->ai_addrlen)) > + if (Connection->server) > { > - WARN("connect() failed\n"); > - close(sock); > - continue; > + BOOL success = FALSE; > + if (bind(sock, ai_cur->ai_addr, ai_cur->ai_addrlen) == 0) > + { > + if (listen(sock, 5) == 0) > + { > + if ((tcpc->event = WSACreateEvent()) != NULL) > + { > + if (WSAEventSelect(sock, tcpc->event, FD_ACCEPT) == 0) > + success = TRUE; > + else > + WARN("WSAEventSelect() failed\n"); > Using WSAEVENTs is an interesting approach, but I'd rather see Unix sockets being used with a thread that select's on the socket and sets a Win32 event instead. Also, I think this amount of nesting is confusing and could be avoided. > > static int rpcrt4_conn_tcp_read(RpcConnection *Connection, > void *buffer, unsigned int count) > { > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; > - int r = recv(tcpc->sock, buffer, count, MSG_WAITALL); > - TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); > - return r; > + int rtotal = 0; > + int r = 0; > + do > + { > + r = recv(tcpc->sock, buffer, count, 0); > + if (r > 0) > + rtotal += r; > + else > + break; > + } while (rtotal < count); > + if (r < 0) > + rtotal = r; > + TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, rtotal); > + return rtotal; > } > Hmmm. Is the MSG_WAITALL flag not supported in winsock? I think that should be fixed there. > > static int rpcrt4_conn_tcp_write(RpcConnection *Connection, > const void *buffer, unsigned int count) > { > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; > - int r = write(tcpc->sock, buffer, count); > + int r = send(tcpc->sock, buffer, count, 0); > TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); > return r; > } > This is a good change. Please submit this as a separate fix. Thanks, -- Rob Shearman

3 3

Re: [RPCRT4] support for RPC TCP servers
by Robert Shearman 25 Sep '06

25 Sep '06

Damjan Jovanovic wrote: > On 9/22/06, Robert Shearman <rob(a)codeweavers.com> wrote: >> Using WSAEVENTs is an interesting approach, but I'd rather see Unix >> sockets being used with a thread that select's on the socket and sets a >> Win32 event instead. Also, I think this amount of nesting is confusing >> and could be avoided. > > Are you working on that approach, or am I free to try it? No, I am not working on that so you are free to try it. (You would be free to try it anyway, since your implementation might be better than an implementation I was working on.) > >> > >> > static int rpcrt4_conn_tcp_read(RpcConnection *Connection, >> > void *buffer, unsigned int count) >> > { >> > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; >> > - int r = recv(tcpc->sock, buffer, count, MSG_WAITALL); >> > - TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); >> > - return r; >> > + int rtotal = 0; >> > + int r = 0; >> > + do >> > + { >> > + r = recv(tcpc->sock, buffer, count, 0); >> > + if (r > 0) >> > + rtotal += r; >> > + else >> > + break; >> > + } while (rtotal < count); >> > + if (r < 0) >> > + rtotal = r; >> > + TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, rtotal); >> > + return rtotal; >> > } >> > >> >> Hmmm. Is the MSG_WAITALL flag not supported in winsock? I think that >> should be fixed there. > > It isn't supported in the native winsock either. You think too highly > of winsock - remeber it was made by Microsoft ;-). Both MSDN and dlls/ws2_32/socket.c suggest that it is supported, although only in non-blocking mode. Is that the problem? > >> > >> > static int rpcrt4_conn_tcp_write(RpcConnection *Connection, >> > const void *buffer, unsigned int >> count) >> > { >> > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; >> > - int r = write(tcpc->sock, buffer, count); >> > + int r = send(tcpc->sock, buffer, count, 0); >> > TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); >> > return r; >> > } >> > >> >> This is a good change. Please submit this as a separate fix. > > But if we use UNIX sockets, it shouldn't matter? Correct. This won't make any difference either way, so we should use send. -- Rob Shearman

1 0

Re: kernel32: Remove unwanted null terminator
by Alexandre Julliard 25 Sep '06

25 Sep '06

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > Changelog: > kernel32: Remove unwanted null terminator. There's no null terminator since the array size is specified explicitly. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: dmime: Dangling references fix
by Alexandre Julliard 25 Sep '06

25 Sep '06

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > Changelog: > dmime: Dangling references fix. The right way is to use wine_dbg_sprintf("%s") to allocate a copy of the buffer to return. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine translations statistics
by Mikołaj Zalewski 25 Sep '06

25 Sep '06

To check what needs to be translated I have played a bit with wrc --verify-translation and made some HTML from it's results. As this might interest other translators I've put the statistics at http://pf128.krakow.sdi.tpnet.pl/wine-transl/ . Mikolaj Zalewski

6 7

Re: wined3d: fix typo in ResourceReleased
by Stefan Dösinger 25 Sep '06

25 Sep '06

Hi, > if (This->stateBlock != NULL ) { > if ((IWineD3DResource *)This->stateBlock->streamSource[streamNumber] == resource) { > TRACE("Vertex buffer released whlst bound to a state block > stream %d\n", streamNumber); > TRACE("Vertex buffer released while bound to a state block stream %d\n", streamNumber); > This->stateBlock->streamSource[streamNumber] = 0; > } > } This is not your code, but this is wrong, even if the msdn says otherwise. Once I had a hacky test for testing this stuff. What my test did was: 1) Create a Vertex buffer 2) check device refcount: increased 3) Bind to a stream 4) check the vb refcount: unchanged(still 1) 5) release the vb(release returns 0) 6) check the device refcount: decreased 7) GetStreamSource: returns old vertex buffer 8) Check device refcount: increased 9) check vb refcount: 1 It seems that the stream source is not uset if the buffer is released. And it seems that ms implements holding the reference to the device in VertexBuffer::AddRef if(oldref == 0) IDirect3DDevice9_AddRef(This->device) or something like that, simmilar to our release. CreateVertexBuffer seems to init the ref to 0 and call VertexBuffer::AddRef. To be sure I did tested the following too: 1) Create VB 2) Check device refcount: increased 3) Release vb. Device refcount decremented 4) AddRef the just destroyed vb: Device refcount increased I didn't submit the test because it doesn't contain anything really new, and the GetStreamSource which returns the released buffer works just by chance. Any ideas to that? I agreed with Vitaly that this isn't crucial behavior as any app depending on that would randomly break on windows. Or is there some COM magic behind this, which keeps objects from beeing destroyed? Stefan

1 0

Re: Governance revisited
by Ge van Geldorp 25 Sep '06

25 Sep '06

> From: Steven Edwards <winehacker(a)gmail.com> > > Which is why we want to have the ambassadors project to help > new people in to wine. The thinking goes that if we have some > people to help hold the hands of new developers and the > developers that are defacto maintainers of a certain section > of code will respond to patches as they seem them, this will > free julliard from having to answer every single patch with a > reply. You can have ambassadors and subsystem maintainers all you want, but in the end it's still going to be Alexandre who decides if a patch goes in. That means the end-responsibility of informing developers why a patch was rejected needs to be with Alexandre. If an ambassador or subsystem maintainer already explained it, fine, no need to create double work for Alexandre, but if noone responded I'd still expect Alexandre to send a notification. Just for the record, my own policy on patch submission (and I really hope to get back to working on Wine and submitting patches Real Soon Now :-)) is to submit a patch once. If I get feedback I'll try to improve and resubmit, but if it goes the black hole route I'm not going to beg for an explanation. If the Wine community can't be bothered to provide feedback I can't be bothered to resubmit. After all, I've already scratched my itch, the bug is already fixed in my tree, it's the communities loss, not mine. Ge van Geldorp

2 1

Last update to git 5 days ago?
by Paul Vriens 25 Sep '06

25 Sep '06

Hi, is Alexandre on a holiday again? Or is this to recuperate from WineConf? Cheers, Paul

1 0

Whither msxml?
by Dan Kegel 25 Sep '06

25 Sep '06

For the past two years, I've helped UCLA's cs130 by pointing them at an area of Wine that needs improvement and helping them get patches submitted. For Winter 2007, I'm considering having them focus on msxml3. So I'm starting to look at bugzilla (see my previous message) and dig up demo apps and articles that might help us understand where wine's msxml needs to go. Man, oh, man are there a lot of pages about msxml out there. If anyone has tips on sore spots with Wine's msxml, please let me know. A few random notes: MSDN on msxml: http://windowssdk.msdn.microsoft.com/en-us/library/ms763742.aspx I see the spec file for msxml3 has a bunch of stubbed ordinals. Anyone know what they are? Can Wine handle the "msxml3 jumpstart" demo app from year 2000 yet? http://msdn.microsoft.com/library/en-us/dnmsxml/html/sax2jumpstart.asp Or the "msxsl.exe" wrapper app? http://www.microsoft.com/downloads/details.aspx?familyid=2fb55371-c94e-4373… "Programming The SAX2 3.0 Using MSXML" (examples in vb6) http://xml.sys-con.com/read/40210.htm "MSXML, It's Not Just for VB Programmers Anymore" (examples in perl) http://www.perl.com/pub/a/2001/04/17/msxml.html "Python & XML" http://safari.oreilly.com/0596001282 Here's a page that seems to show how to use msxsl and explains differences between msxml3 and msxml4: http://www.perfectxml.com/articles/xml/XSLTInMSXML.asp msxml3 examples: http://www.perfectxml.com/articles/xml/msxml30.asp "A C++ Template Wrapper for the XML SAX API" http://www.ddj.com/showArticle.jhtml?articleID=184401778 etc. etc. - Dan

3 2

An MSVCRT_fgetc bug
by Tobias Ringström 25 Sep '06

25 Sep '06

There's a bug in MSVCRT_fgetc in 0.9.21 (likely introduced in 0.9.19) in that it sometimes sign extends the byte read from the file. The following program illustrates the problem: #include <stdio.h> int main() { FILE *f = fopen("tmp.bin", "w+"); fputc(0xe0, f); fputc(0xe0, f); rewind(f); printf("0x%08x\n", fgetc(f)); printf("0x%08x\n", fgetc(f)); fclose(f); return 0; } The output is: 0x000000e0 0xffffffe0 (should be 0x000000e0 too) The bug is likely this line: http://source.winehq.org/source/dlls/msvcrt/file.c#L2134 That line is now i = file->_ptr++; but should be i = *(unsigned char*)(file->_ptr++); I don't have a build environment for Wine, and it felt like overkill to set one up for this little bug, so I've not been able to verify my hypothesis. I hope that's acceptable. /Tobias

2 1

Re: LOSTWAGES: WWN 292 & 320 updates
by Tom Wickline 25 Sep '06

25 Sep '06

On 9/23/06, Mirek <thunder.m(a)email.cz> wrote: > > > > Also Wine reports 64MB of video memory not 16MB > > I think there shuld be option in winecfg to set this, because it is not easy to > find how anyone can do that. http://wiki.winehq.org/UsefulRegistryKeys Tom

1 1

Re: Governance revisited (Wineconf report)
by Ge van Geldorp 25 Sep '06

25 Sep '06

> From: Kai Blin <kai.blin(a)gmail.com> > > On Saturday 23 September 2006 10:32, Scott Ritchie wrote: > > Frankly, all we really need is for Alexandre to write a 10-second > > reply to wine-devel for each patch he rejects. > > On WineConf, we decided against this. That would still slow > down the overall patch submission speed. Consider you have a > patch that's just fine, but before you sent that, I sent in > ten patches with C++ style comments. Alexandre would now have > to reply to ten patches with "No C++ style comments" before > processing your patch. Everybody reading wine-patches > could point out what was wrong with my patches. You must be kidding. Even in your somewhat convoluted example, it would be fine to receive just a single notification "No C++ style comments" and I really wouldn't care if the notification came from Alexandre or from someone else on wine-patches. The reality is that a lot of patches (I haven't kept a precise count, but I estimate about a third of my own patches) are dropped silently, without any feedback at all. I have absolutely no problem with a strict patch acceptance policy, designed to keep the Wine quality high. Alexandre is amazingly smart and when he tells me why a certain patch was rejected I'll usually agree with him and even if I don't agree, I have enough confidence in him to accept his judgement. But having your patches dropped silently is pretty annoying. The usual response from the core Wine developers is "well, just resubmit". I fail to see how this helps Alexandres productivity (or my own for that matter). If patches weren't dropped silently the sequence of events would be: 1) Submit patch 2) Alexandre looks at patch 3) Alexandre writes 10-second rejection reply With the resubmit: 1) Submit patch 2) Alexandre looks at patch 3) Wait a week 4) Resubmit patch 5) Alexandre looks at patch again 6) Alexandre writes 10-second rejection reply Seems to me this incurs extra work for Alexandre (number 5). The patch processes isn't very transparant. For example, I submitted a patch on 20 June 2006 to dlls/kernel/heap.c (www.winehq.org seems to be unreachable for me at the moment so I can't give a URL to the message) to fix a problem with the heap on Win64. This patch was silently dropped. On July 21 a change very similar to what I submitted was committed but not attributed to me. Now, either the commit was not based on my patch (in which case someone else spent another 2-3 days (it was one of those problems where a chain of out-of-buffer memory writes take place and you have to work your way up the chain to find the root cause) on tracking down an already known problem for which a fix was already available) or it was based on my patch (in which case my patch shouldn't have been dropped and I should have been given credit). Like I said before, I have a lot of respect for Alexandres technical abilities. But when I read comments in the Wineconf report about git: "Developers might not like it, but Alexandre does so it's a success" (did I mention I dislike git also???) and the inability of the Wine community to set up a patch management system (so patches won't disappear into the big void) because Alexandre refuses to use it if it won't work in Emacs I'm starting to wonder if people realise that the developers don't work for Alexandre. He's a great Benovelent Dictator on technical issues, but in my opinion only a Dictator on patch process management. Ge van Geldorp.

2 1

Governance revisited
by Steven Edwards 25 Sep '06

25 Sep '06

---------- Forwarded message ---------- From: Steven Edwards <winehacker(a)gmail.com> Date: Sep 25, 2006 1:27 AM Subject: Re: Governance revisited To: Troy Rollo <wine(a)troy.rollo.name> On 9/25/06, Troy Rollo <wine(a)troy.rollo.name> wrote: > The present system turns people off even before you've had time to learn > whether they are capable or not. Which is why we want to have the ambassadors project to help new people in to wine. The thinking goes that if we have some people to help hold the hands of new developers and the developers that are defacto maintainers of a certain section of code will respond to patches as they seem them, this will free julliard from having to answer every single patch with a reply. Now in the case of Ge where he was patching core functions of ntdll,kernel32,wineserver,etc I guess it would still fall to julliard to reply personally but in the case of other modules the experts in that area should take a step up and monitor wine-patches and say what patch X.Y.Zsucks and julliard most likely will not merge it. -- 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 -- 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

2 1

my dsound/winealsa hacks
by Tomas Carnecky 24 Sep '06

24 Sep '06

My ultimate goal was to solve the dsound underruns which were so horrible that I had to disable sound in World of Warcraft. While I managed to get the sound working flawlessly (really... I never heard such clear sound under wine) in WoW, it required WoW-specific hacks so my patch will never make it (in its current form) into the official git tree, but maybe someone can use some of my ideas to improve dsound/winealsa. The basic idea is to let alsa mix the sound instead of the infamous dsound mixer. The advantage is that if the hardware supports mixing, there is very little overhead, if not, there's still dmix which can do that, but dsound doesn't need to care how it's done, it's entirely up to alsa. Now to the actual implementation, it's pretty straight-forward: I 'forced' CreateSoundBuffer to create a hardware buffer (right now it creates a hw buffer only for the primary buffer) and changed the winealsa driver to support that. Because winealsa driver opens only one 'connection' (snd_pcm_t) to the soundcar (allowing only one buffer per device), I simply opened a new 'connection' for each buffer and configured the hardware for 44100Hz/U16LE/stereo (that's what WoW expects). Up to this point it was easy. One of the big problems was that WoW requests a 16kb buffer, but alsa is unable to allocate a buffer with this exact size, and it caused problems if I passed the alsa buffer to WoW (so WoW could write directly to it). I had to allocate a separate buffer, keep track of the play/write positions in both buffers and copy the data from one to the other. I'm fairly sure this all could be done in a WoW-independent way, eg. configure the hardware as the application requests it (by passing LPCDSBUFFERDESC to the low-level driver etc) and keeping track of the read/write positions could also be done in a better way. There are a free questions that should be answered before someone can go on and make a 'proper' implementation. I simply bypassed the primary buffer, it doesn't exist since the data from the secondary buffers are written directly to the soundcard. If it should be possible to read the data from the primary buffer then we should forget this all and look for another solution. I believe that it's not possible (it's not possible to write to the primary buffer and the API doesn't differentiate between reads and writes), but someone should test that under windows. (this is only one question but I'm sure you'll come up with more ;) ) Here is the complete patch, I also changed the IDirectSound interface and a lot unrelated code, so the patch is a bit big :-/ There also are a few memory leaks, I didn't bother freeing the memory etc. http://dbservice.com/ftpdir/tom/dsound-alsa.patch tom

6 10

Call for Installer Bugs...
by Dan Kegel 24 Sep '06

24 Sep '06

Lots of progress has been made in fixing installer bugs lately, but there are probably many such bugs hiding in plain view still. It would be very helpful if people could look for bugs which: a) appear to be MSI or setupapi related, and b) occur in freely downloadable executables (e.g. trial versions) c) aren't already in bugzilla (see http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-msi&keywords… for list) and file reports as appropriate at http://bugs.winehq.org. Thanks! - Dan

4 3

RFC: wine ASIO driver available for testing
by Robert Reif 24 Sep '06

24 Sep '06

I just uploaded a simple wine ASIO driver to http://bugs.winehq.org/show_bug.cgi?id=2161 for testing and feedback. Please look at it and give me feedback. Playback works. Recording is untested due to lack of software. Full duplex doesn't work for me but I'm not sure if it's a software issue or a problem with my hardware and OS setup. The software is a long way from being ready for submission so any feedback or help would be appreciated.

4 4

Re: LOSTWAGES: WWN 292 & 320 updates
by H. Verbeet 24 Sep '06

24 Sep '06

On 23/09/06, Mirek <thunder.m(a)email.cz> wrote: > > I also changed what benchmarks I had running at this years WineConf > > 3DMark2000, 3DMark2001SE and 3DMark2003... I have 3DMark2006 running > > and its beautiful, well beauty is in the eye of the beholder > > All of the test run in all three of the benchmarks to completion and > > there is only two test out of all test that have minor problems, and > > Henri has one of the test fixed in his tree. > > Can you post how i can get sources from his tree? The 3th and 4th 3DMark03 tests should pretty much work with current git, actually. The 4th test has some minor issues, afaik because of the wrong sampler types being bound. If there are other issues, those are separate bugs, and should probably be reported on bugzilla.

1 0

Server instability warning
by Jeremy White 24 Sep '06

24 Sep '06

Hi Folks, The server crashed early yesterday evening, and again sometime over the night. It's a new server - and in fact, I think it's the new 'new' server - seems like it always takes a while to get a server stabilized). Jeremy Newman is coming back from England today, and I prefer to leave these sort of repairs to him, otherwise he grouses at me (rightly, I might add :-/). So it's back up now, but I'm not sure for how long that will be true. Sorry for the hassle; if it gets worse this afternoon before Jer gets back, I may break down and start dissecting it. Cheers, Jeremy

1 0

ALSA implementation
by Aaron Slunt 24 Sep '06

24 Sep '06

Hi, I talked on #winehq in irc about how horribly alsa is implemented right now. I was told that winmm would need a complete re-write and the dsound needs some changes as well. My question is: anybody here who's familiar with all of the changes that need to be made to get alsa working properly? Thanks.

9 21

Re: Governance revisited (Wineconf report)
by J. Wesley Cleveland 24 Sep '06

24 Sep '06

> From: Kai Blin <kai.blin(a)gmail.com> > On Saturday 23 September 2006 10:32, Scott Ritchie wrote: > > Frankly, all we really need is for Alexandre to write a 10-second reply > > to wine-devel for each patch he rejects. > > On WineConf, we decided against this. That would still slow down the overall > patch submission speed. Consider you have a patch that's just fine, but > before you sent that, I sent in ten patches with C++ style comments. > Alexandre would now have to reply to ten patches with "No C++ style comments" > before processing your patch. Everybody reading wine-patches could point out > what was wrong with my patches. How about emacs macros that would send "Patch rejected" or "Patch under consideration" to wine-patches or wine-devel ? This would get rid of the feeling that patches are dropping into a black hole while only costing Alexandre a fraction of a second per patch.

1 0

Re: Minimize window via style change
by Dmitry Timoshkov 23 Sep '06

23 Sep '06

"Sebastian Reichelt" <SebastianR(a)gmx.de> wrote: > + if (winpos->flags & SWP_FRAMECHANGED) > + { > + DWORD style = GetWindowLongW( winpos->hwnd, GWL_STYLE ); > + X11DRV_set_iconic_state( winpos->hwnd ); > + if (style & WS_MINIMIZE) > + return TRUE; > + } > + > if (!SWP_DoWinPosChanging( winpos, &newWindowRect, &newClientRect )) return FALSE; > > /* Fix redundant flags */ X11DRV_set_iconic_state() call should be moved under the 'if' case. Next, you can't really avoid calling SWP_DoWinPosChanging and probably sending WM_WINDOWPOSCHANGED. This behaviour needs a good test case. -- Dmitry.

1 0

compiling wine for amd64
by Gerald Britton 23 Sep '06

23 Sep '06

Hi -- I'm running ubuntu dapper on amd64. I want to compile wine but am hitting problems. I got the dependencies just fine, but the compile died. Here's what I get: $ sudo apt-get -y --build source wine Reading package lists... Done Building dependency tree... Done Skipping the already downloaded file 'wine_0.9.21~winehq0~ubuntu~6.06-1.dsc' Skipping the already downloaded file 'wine_0.9.21~winehq0~ubuntu~6.06.orig.tar.gz' Skipping the already downloaded file 'wine_0.9.21~winehq0~ubuntu~6.06-1.diff.gz' Need to get 0B of source archives. Skipping unpack of already unpacked source in wine-0.9.21~winehq0~ubuntu~6.06 dpkg-buildpackage: source package is wine dpkg-buildpackage: source version is 0.9.21~winehq0~ubuntu~6.06-1 dpkg-buildpackage: source changed by Scott Ritchie <scott(a)open-vote.org> dpkg-buildpackage: host architecture amd64 debian/rules clean dh_testdir dh_testroot rm -f build-stamp # Add here commands to clean up after the build process. /usr/bin/make distclean make[1]: Entering directory `/home/jerryb/wine-0.9.21~winehq0~ubuntu~6.06' make[1]: *** No rule to make target `distclean'. Stop. make[1]: Leaving directory `/home/jerryb/wine-0.9.21~winehq0~ubuntu~6.06' make: [clean] Error 2 (ignored) #-/usr/bin/make -C documentation clean cp -f /usr/share/misc/config.sub config.sub cp -f /usr/share/misc/config.guess config.guess dh_clean debian/rules build dh_testdir # Add here commands to configure the package. CFLAGS="-Wall -g -O2" ./configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/usr --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking whether make sets $(MAKE)... yes checking for x86_64-linux-gnu-gcc... gcc -m32 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make: *** [config.status] Error 77 Build command 'cd wine-0.9.21~winehq0~ubuntu~6.06 && dpkg-buildpackage -b -uc' failed. E: Child process failed I attached the config.log. What must I do to complete the compiles?

4 7

Re: wined3d/CopyRects bug fix
by Stefan Dösinger 22 Sep '06

22 Sep '06

Am Montag 18 September 2006 10:12 schrieb Christopher GAUTIER: > Hello there, > > I've identified a bug in IWineD3DDeviceImpl_CopyRects. When CopyRects() > is called to copy the source entirely into the destination surface, and > that the sizes matches, a plain memcpy() is done. However, this assumes > that the surfaces have the same pitch, and this is not always the case. Welcome to Wine :-) IWineD3DDevice::CopyRects is a subset of IWineD3DSurface::BltFast(from DirectDraw), and I thought some time ago I sent a patch which makes CopyRects call BltFast. This patch apparently wasn't applied, and I did a google search for it and couldn't find it either. Looks like I moved it to /dev/null accidentally. We should call BltFast to avoid duplicating code. BltFast is also able to handle corner cases like bad rectangles. Can you test the attached patch? I have no game which uses CopyRects, so I can't test my patch. This is just a quick per-msdn implementation. Thanks, Stefan

2 1

Re: DDraw: Don't destroy complex attached surfaces even if explicitely requested as they will be liquidated anyway when the root is destroyed.
by Michael Stefaniuc 22 Sep '06

22 Sep '06

Elie Morisse wrote: > A new version of my refcounting patch, lighter and honoring Stefan Dösinger proposal. You forgot to attach the patch. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: msi: update target file paths on MsiSetTargetPath (for TARGETDIR)
by James Hawkins 22 Sep '06

22 Sep '06

On 9/21/06, Andrey Turkin <pancha(a)mail.nnov.ru> wrote: > MsiSetTargetPath can be used to change target path for directory after > CostFinalize, and all affected file paths must be recalculated. James > Hawkins sent a patch to make Wine's MSI engine do it for most cases; > this patch fixes one remaining "corner" case with TARGETDIR, and adds > test for it. > > ChangeLog: > > msi: Don't treat TargetDir specifically in resolve_folder > > > diff -aur wine-0.9.21/dlls/msi/helpers.c wine-0.9.21-my/dlls/msi/helpers.c > --- wine-0.9.21/dlls/msi/helpers.c 2006-09-13 23:10:25.000000000 +0400 > +++ wine-0.9.21-my/dlls/msi/helpers.c 2006-09-22 04:26:42.000000000 +0400 > @@ -216,29 +216,13 @@ > if (!name) > return NULL; > > - /* special resolving for Target and Source root dir */ > - if (strcmpW(name,cszTargetDir)==0 || strcmpW(name,cszSourceDir)==0) > + /* special resolving for Source root dir */ > + if ( strcmpW(name,cszSourceDir)==0) > { > - if (!source) > - { > - LPWSTR check_path; > - check_path = msi_dup_property( package, cszTargetDir ); > - if (!check_path) > - { > - check_path = msi_dup_property( package, cszRootDrive ); > - if (set_prop) > - MSI_SetPropertyW(package,cszTargetDir,check_path); > - } > - > - /* correct misbuilt target dir */ > - path = build_directory_name(2, check_path, NULL); > - clean_spaces_from_path( path ); > - if (strcmpiW(path,check_path)!=0) > - MSI_SetPropertyW(package,cszTargetDir,path); > - msi_free(check_path); > - } > - else > + if (source) > path = get_source_root( package ); > + else > + path = NULL; > if (folder) > *folder = get_loaded_folder( package, name ); > return path; > @@ -251,6 +235,11 @@ > if (folder) > *folder = f; > > + if (strcmpW(name, cszTargetDir)==0 && !f->ResolvedTarget && !f->Property) > + { > + f->Property = msi_dup_property( package, cszRootDrive ); > + } > + > if (!source && f->ResolvedTarget) > { > path = strdupW( f->ResolvedTarget ); > This fix is incorrect. What happens now when we call resolve_folder(package, "TARGETDIR", FALSE, TRUE, folder)? Your changelog says "Don't treat TargetDir specifically in resolve_folder" yet you're treating it specifically right here, but without the functionality that's still needed. Please resend the tests with todo_wine around failing tests. > > +#define ADD_SLASH(x) do { char *t; if (x[0]) {t=x+strlen(x)-1;if(t[0] != '\\' ) {t[1] ='\\';t[2] ='\0';}}} while (0) > + This is a really bad macro. Please use PathAddBackslash. -- James Hawkins

1 0

Re: WineD3D: glBlend* fixes
by Jesse Allen 21 Sep '06

21 Sep '06

On 9/21/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > > This patch changes the detection extension detection for glBlendColor/glBlendEquation. The function glBlendColor is part of OpenGL 1.1 and is supported on all OpenGL implementations. Officially it is part of the GL_ARB_imaging extension but not all vendors fully implement it and that's why only Nvidia and 3dlabs advertise it. This causes glBlendColor not to work on other implementations. So in case of GL 1.1, the detection is dropped. > > Further glBlendEquation is part of GL_ARB_imaging aswell. For the same reason GL_ARB_imaging can't be used to detect glBlendEquation. This call isn't supported on all OpenGL implementations. Luckily it is part of 'GL_EXT_blend_min_max' so that is used now. > Roderick, Mesa calls the extension "GL_EXT_blend_minmax", and so does the spec. I don't know what exactly uses the min_max form. Is this a typo? http://www.opengl.org/registry/specs/EXT/blend_minmax.txt http://www.google.com/search?hl=en&lr=&q=GL_EXT_blend_min_max&btnG=Search Also, the TRACE call in device.c:4513 needs a \n added too ;) Jesse

1 0

Re: Status of dlls that you maintain
by Jeff Latimer 21 Sep '06

21 Sep '06

Tom Wickline wrote: > On 9/21/06, Jeff L <lats(a)yless4u.com.au> wrote: > >> >> BTW, the WWN #292 looks to be out of date as those functions are now >> implemented. > > > Hmm, Brian Vincent does the WWN and I just link the WWN articles to > the status > pages.. > Tom > Brian, I have successfully run Notes 7 on wine and the problems mentioned in WWN #292 have been fixed. Jeff Latimer

1 0

Re: [c2man] remove hardcoded extension (try#2)
by Alexandre Julliard 21 Sep '06

21 Sep '06

"Vijay Kiran Kamuju" <infyquest(a)gmail.com> writes: > my $uc_dll_name = uc $dll_name; > + > + if (($dll_ext ne 'ds') && ($dll_ext ne 'acm') && ($dll_ext ne 'drv') > + ($dll_ext ne 'exe') && ($dll_ext ne 'ocx') && ($dll_ext ne 'vxd')) > + { > + $dll_ext='dll'; > + } You are still hardcoding things, there's really no reason to do that. -- Alexandre Julliard julliard(a)winehq.org

3 4

ATI and GL_ARB_Imaging support
by Kapila De Silva 21 Sep '06

21 Sep '06

Hi all, I noticed, that wine checks for GL_ARB_imaging, before performing operations like glBlendColor, glBlendEquation etc. However it appears that the ATI drivers do not support this extension, though they do support the blending operations. I posted about this on the Rage3d linux driver boards, and the response seems to suggest that it would be better to check for the individual operations rather than the GL_ARB_imaging extension. See bottom of http://rage3d.com/board/showthread.php?t=33814685 What do you guys think? Kap.

2 1

Re: msi [6/7]: Translate the INSTALLSTATE_UNKNOWN index into the INSTALLSTATE_ABSENT image index
by Juan Lang 21 Sep '06

21 Sep '06

Hiya James, - TRACE("Feature %s -> %d %d %d\n", debugstr_w(feature->Title), + printf("Feature %s -> %d %d %d\n", debugstr_w(feature->Title), I don't think you meant that to slip in. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Text Layout Summit
by Daniel Glassey 21 Sep '06

21 Sep '06

Hi folks, There is going to be a Text Layout Summit during the Boston Gnome Summit http://live.gnome.org/Boston2006/TextLayout We are going to discuss things related to text layout. Hopefully we will discuss a uniscribe compatible API that could be used by wine and mono SWF since afaik neither has uniscribe support. It would be great if someone from wine and mono could be there. If that wouldn't be possible we would appreciate your input on what you would need. Regards, Daniel P.S. OK to CC me on replies as I'm not subscribed to either list.

2 1

Re: gdi32: GetTextExtentPoint and GetTextExtentExPoint behavedifferently if there's a \n in the string.
by Dmitry Timoshkov 21 Sep '06

21 Sep '06

"Huw Davies" <huw(a)codeweavers.com> wrote: > - ok(sz1.cx == sz2.cx && sz1.cy == sz2.cy, > - "results from GetTextExtentExPointW and GetTextExtentPointW differ\n"); > + ok(sz1.cy == sz2.cy, > + "cy from GetTextExtentExPointW (%ld) and GetTextExtentPointW (%ld) differ\n", sz1.cy, sz2.cy); > +todo_wine { > + /* The \n in the string is apparently handled differently in GetTextExtentPoint and GetTextExtentExPoint */ > + ok(sz1.cx != sz2.cx, > + "cx from GetTextExtentExPointW (%ld) and GetTextExtentPointW (%ld) are the same\n", sz1.cx, sz2.cx); > + } This test fails for me (i.e. sz1.cx == sz2.cx) under XP (SP2+all the latest fixes). -- Dmitry.

2 3

Re: X11DRV: wgl move font code [resubmit]
by Roderick Colenbrander 20 Sep '06

20 Sep '06

This time with a patch. > Hi, > > This is a resubmit of the previous font moving patch against the latest > cvs/git version. The old version didn't apply anymore to winex11.drv. For the > rest the patch is the same. > > Regards, > Roderick Colenbrander > -- > Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! > Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer > -- NEU: GMX DSL Sofort-Start-Set - blitzschnell ins Internet! Echte DSL-Flatrate ab 0,- Euro* http://www.gmx.net/de/go/dsl

1 0

Re: X11DRV: wgl move font code [resubmit]
by James Hawkins 20 Sep '06

20 Sep '06

On 9/20/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > > This is a resubmit of the previous font moving patch against the latest cvs/git version. The old version didn't apply anymore to winex11.drv. For the rest the patch is the same. > You forgot to attach the patch. -- James Hawkins

1 0

EnumServicesStatusA - Typical return structure contents with a working internet LAN connection
by Nick Law 20 Sep '06

20 Sep '06

I'm trying to get an application running that accesses the Internet, but fails with the message, no Internet connection present. The internet connection is fine, as proved by the fact I can run firefox & wow under wine. I've disassembled the applications exe and examined wine's fixme errors when the application runs and it seems to do the following.... It calls InternetGetConnectedState to determine whether there is a modem or LAN connection. Wine returns the fact there is a LAN connection. It then calls EnumServicesStatusA with a type=30 & state=1, in order to get a list of running services, now what I think it's doing is expecting to see a service that provides the internet connection, because wine doesn't actually return a list of services the application then decides there's no internet connection. What I want to do is provide a return structure that does at least contain the service name & state (internet related) that the application is expecting to see. Does anybody know what service that could be, (specifically it's actual name) or even better provide a typical return structure that is returned by windows when a application calls EnumServicesStatusA so I can construct the structure this app is expecting to see. I've never written anything under MS windows otherwise I would write a small application myself that calls EnumServicesStatus & figure it out myself. In fact maybe I will have to get myself a copy of visual C++ so I can do these tests. Regards Nick Law PS I'm new to this debugging without access to the applications source code, so any hints & tricks would be appreciated. It looks like I may have to learn Intels assembler instruction set as well!, which I don't mind. The last time I wrote an assembly language program was 25 years ago on a PerkinElmer 3220 mini computer! So this should be fun.

2 1

msi/iTunes and questions
by Paul Vriens 20 Sep '06

20 Sep '06

Hi, just for fun I've tried to install iTunes 7 on a fresh .wine. According to the AppDB this fails (one should first install QuickTime). While going through some traces I saw something the apparently needs this fix, but I'm no MSI-guy: diff --git a/dlls/msi/custom.c b/dlls/msi/custom.c index dad67a2..7b862fe 100644 --- a/dlls/msi/custom.c +++ b/dlls/msi/custom.c @@ -703,8 +703,8 @@ static UINT HANDLE_CustomType19(MSIPACKA static const WCHAR query[] = { 'S','E','L','E','C','T',' ','`','M','e','s','s','a','g','e','`',' ', 'F','R','O','M',' ','`','E','r','r','o','r','`',' ', - 'W','H','E','R','E',' ','`','E','r','r','o','r','`',' ','=',' ', - '%','s',0 + 'W','H','E','R','E',' ','`','E','r','r','o','r','`',' ','=',' ','\'', + '%','s','\'',0 }; MSIRECORD *row = 0; LPWSTR deformated = NULL; The single-quotes should be needed as the SQL statement in the trace showed: trace:msi:MSI_DatabaseOpenViewW L"SELECT `Message` FROM `Error` WHERE `Error` = The installlation of QuickTime did not complete successfully. iTunes requires QuickTime." 0x6669a498 and a bit further: err:msidb:WHERE_VerifyCondition Couldn't find column L"The" This is just one of many issues with this installation. Does the fix look OK? Should this be sent? If it has to be accompanied with tests then please use the above fix at will, as I don't have the time (nor the msi-skills to look into that). Cheers, Paul.

3 2

Re: oleaut32 1/2: Implements function variant:VarImp
by Alexandre Julliard 20 Sep '06

20 Sep '06

"Benjamin Arai" <me(a)benjaminarai.com> writes: > + case VT_I1: if (V_I1(left) == -1) resvt = VT_NULL; break; > + case VT_UI1: if (V_UI1(left) == 0xff) resvt = VT_NULL; break; > + case VT_I2: if (V_I2(left) == -1) resvt = VT_NULL; break; > + case VT_UI2: if (V_UI2(left) == 0xffff) resvt = VT_NULL; break; > + case VT_INT: if (V_INT(left) == -1) resvt = VT_NULL; break; > + case VT_UINT: if (V_UINT(left) == 0xffffffff) resvt = VT_NULL; break; > + case VT_I4: if (V_I4(left) == -1) resvt = VT_NULL; break; > + case VT_UI4: if (V_UI4(left) == 0xffffffff) resvt = VT_NULL; break; > + case VT_I8: if (V_I8(left) == -1) resvt = VT_NULL; break; > + case VT_UI8: if (V_UI8(left) == 0xffffffff) resvt = VT_NULL; break; Shouldn't the last one be something like ~(ULONGLONG)0 instead of 0xffffffff? -- Alexandre Julliard julliard(a)winehq.org

2 2

EnumServicesStatusA - Typical return structure contents with a working internet LAN connection
by Nick Law 20 Sep '06

20 Sep '06

I'm trying to get an application running that accesses the Internet, but fails with the message, no Internet connection present. The internet connection is fine, as proved by the fact I can run firefox & wow under wine. I've disassembled the applications exe and examined wine's fixme errors when the application runs and it seems to do the following.... It calls InternetGetConnectedState to determine whether there is a modem or LAN connection. Wine returns the fact there is a LAN connection. It then calls EnumServicesStatusA with a type=30 & state=1, in order to get a list of running services, now what I think it's doing is expecting to see a service that provides the internet connection, because wine doesn't actually return a list of services the application then decides there's no internet connection. What I want to do is provide a return structure that does at least contain the service name & state (internet related) that the application is expecting to see. Does anybody know what service that could be, (specifically it's actual name) or even better provide a typical return structure that is returned by windows when a application calls EnumServicesStatusA so I can construct the structure this app is expecting to see. I've never written anything under MS windows otherwise I would write a small application myself that calls EnumServicesStatus & figure it out myself. In fact maybe I will have to get myself a copy of visual C++ so I can do these tests. Regards Nick Law PS I'm new to this debugging without access to the applications source code, so any hints & tricks would be appreciated. It looks like I may have to learn Intels assembler instruction set as well!, which I don't mind. The last time I wrote an assembly language program was 25 years ago on a PerkinElmer 3220 mini computer! So this should be fun. -- Regards Nick Law Mobile: 07736 022165 Email: nick.law(a)mic-nucmed.co.uk Medical Imaging Consultancy Ltd (M.I.C) Sales and Service of ADAC and IS2 Products http://www.mic-nucmed.co.uk

2 2

Re: Implement GetKerningPairs for TrueType fonts, take 4
by Huw Davies 20 Sep '06

20 Sep '06

On Thu, Sep 21, 2006 at 12:18:51AM +0900, Dmitry Timoshkov wrote: > this version of the patch incorporates another Huw's suggestion > in eliminating redundant local variable and simplifying the code. Thanks Dmitry, Looks good to me. -- Huw Davies huw(a)codeweavers.com

1 0

Recovering a patch accidentally removed by git reset
by Jeff L 20 Sep '06

20 Sep '06

How do you get a patch back that you have managed to remove completely from your system with a git reset HEAD^ git reset git checkout patchname ? git fetch does not seem to refresh the patch from the repository. I was going fairly well with git then stuffed this up. Jeff

4 4

Re: Implement GetKerningPairs for TrueType fonts, take 3
by Huw Davies 20 Sep '06

20 Sep '06

On Wed, Sep 20, 2006 at 03:22:02PM +0900, Dmitry Timoshkov wrote: > Changelog: > Implement GetKerningPairs for TrueType fonts. Hi Dmitry, Looks good, apart from one small nitpick below. I still think it would be nice to add the tests that you have to the test suite, even if it's just something that checks the first few pairs of Arial at some fixed font height. .... > +static DWORD parse_format0_kern_subtable(GdiFont font, > + const struct TT_format0_kern_subtable *tt_f0_ks, > + const USHORT *glyph_to_char, > + KERNINGPAIR *kern_pair, DWORD cPairs) > +{ .... > + kern_pairs_copied = 0; > + > + for (i = 0; i < nPairs; i++) > + { > + kern_pair->wFirst = glyph_to_char[GET_BE_WORD(tt_kern_pair[i].left)]; > + kern_pair->wSecond = glyph_to_char[GET_BE_WORD(tt_kern_pair[i].right)]; > + kern_pair->iKernAmount = MulDiv((short)GET_BE_WORD(tt_kern_pair[i].value), font->ppem, font->ft_face->units_per_EM); > + > + TRACE("left %u right %u value %d\n", > + kern_pair->wFirst, kern_pair->wSecond, kern_pair->iKernAmount); > + > + kern_pair++; > + kern_pairs_copied++; > + if (!--cPairs) break; > + } Seems to me that if you set nPairs = min(cPairs, nPairs) at the start of the loop, then you can eliminate the break and get rid of the kern_pairs_copied variable that basically mirrors i. Thanks, Huw. -- Huw Davies huw(a)codeweavers.com

1 0

make test failure
by Ivan Leo Puoti 20 Sep '06

20 Sep '06

Here is a make test failure I'm getting on my laptop (for those of you who were not at wineconf, make test should, in theory, work everywhere) ../../../../wine/tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so ../../../../wine/dlls/gdi/tests/font.c && touch font.ok font.c:276: Test failed: Courier(13): tm.tmAscent 10 != 11 font.c:277: Test failed: Courier(13): tm.tmDescent 3 != 2 make[2]: *** [font.ok] Error 2 make[2]: Leaving directory `/home/ivan/build/dlls/gdi/tests' make[1]: *** [gdi/tests/__test__] Error 2 make[1]: Leaving directory `/home/ivan/build/dlls' make: *** [dlls/__test__] Error 2

8 7

RegisterHotKey/UnregisterHotKey implementation...success?
by Aaron Slunt 20 Sep '06

20 Sep '06

http://www.winehq.com/pipermail/wine-devel/2006-May/047460.html The above link I looked at, and I saw this person was apparently crashing with the patch when trying to register a hotkey twice (that's how I interpreted it). Anyways, I looked at the patch, and cleaned it up so it applies to the current git tree. Anyways, it seems that I simply cannot reproduce the crash he was talking about. I binded F1 in HLSS (Half-Life Sound Selector), and opened another copy of HLSS. It simply would not allow me to register the key again. So I closed the second copy of HLSS and opened Ventrilo. I attempted to bind F1, and again it simply would not allow it. And let me make this clear, not once did I crash with this patch. HLSS works (fundamentally, not perfectly) when using it with Counter-strike (the hotkey works, there are window management problems though which have nothing to do with this) and I just never crashed with it. I'm attaching the patch for others to test if they could, and to see if a crash can be reproduced. But to me it looks like the work Robert Reif and Vincent Povirk is a huge success.* *

2 2

COM
by Joe McCay 20 Sep '06

20 Sep '06

A recent article in a Linux magazine talking about winelib mentioned using __attribute__((com_interface)). I thought that attribute was no longer valid in gcc. The reason I am asking is because I am trying to do COM development using mingw, C++, & (hopefully) WIDL. I thought the 3.x and higher version of gcc supported -fvtable-thunks by default making it binary compatible with windows COM. Does anyone know if this is really true? jmccay

1 0

Problem with a Turbolog4.exe application under wine
by James Courtier-Dutton 19 Sep '06

19 Sep '06

Hi, A demo version of Turbolog4 can be downloaded from: http://www.turbolog.de/ The program installs ok, but fails to run correctly. It asks for a License key, one should be able to press cancel and bypass it into demo mode where a window is displayed for entering log records. Can anyone help be diagnose why it fails. James

2 1

Something's wrong with my GIT tree
by Aaron Slunt 19 Sep '06

19 Sep '06

http://pastebin.ca/176787 I've had this for several days, and git fetch tells me everything's up to date. Is this a known issue? How do I get rid of this? ./configure --x-libraries=/emul/linux/x86/usr/lib/ LDFLAGS="-L/emul/linux/x86/usr/lib -L/emul/linux/x86/lib" && make depend && make That configure has always worked for me, and it gets through make depend, it's just failing on make with that error message.

2 1

Error in GDI (StretchBlt) - proper fix?
by David Gümbel 19 Sep '06

19 Sep '06

Hello everybody, I am debugging an application and got up to the point where I have reason to believe that the StretchBlt function in GDI is part of the problem. A backtrace of the exception I always run into looks like this: err:syslevel:_CheckNotSysLevel Holding lock 0x7ecd0820 level 3 wine: Unhandled exception 0x80000003 at address 0x0000:0x7ee96b34 (thread 0011), starting debugger... WineDbg starting on pid 0x10 err:syslevel:_CheckNotSysLevel Holding lock 0x7ecd0820 level 3 0x7ee96b35 _CheckNotSysLevel+0x3d in kernel32: addl $36,%esp Wine-dbg>bt Backtrace: =>1 0x7ee96b35 _CheckNotSysLevel+0x3d in kernel32 (0x7ee96b35) 2 0x7ec84c81 GDI_CheckNotLock+0x20 in gdi32 (0x7ec84c81) 3 0x7ec628e8 DeleteDC+0x26 in gdi32 (0x7ec628e8) 4 0x7ec6420b GetDIBits+0x1fd in gdi32 (0x7ec6420b) 5 0x7ec6c282 in gdi32 (+0x2c282) (0x7ec6c282) 6 0x7ec5bfee StretchBlt+0xca in gdi32 (0x7ec5bfee) 7 0x0042a3aa in bav (+0x2a3aa) (0x0042a3aa) 8 0x00425460 in bav (+0x25460) (0x00425460) 9 0x005d1304 in bav (+0x1d1304) (0x005d1304) 10 0x005e4f5d in bav (+0x1e4f5d) (0x005e4f5d) 11 0x0066f10b in bav (+0x26f10b) (0x0066f10b) 12 0x00681f8b in bav (+0x281f8b) (0x00681f8b) 13 0x7ee7ff5f in kernel32 (+0x4ff5f) (0x7ee7ff5f) 14 0xb7e9d387 wine_switch_to_stack+0x17 in libwine.so.1 (0xb7e9d387) When looking at StretchBlt's source code, I see a comment saying that there is a race condition in this function[1]. If I'm not mistaken, this problem has been reported in january as bug #4284, causing trouble (a deadlock) with MS PowerPoint[2]. Walt Ogburn suggested in january that commenting out #define STRETCH_VIA_DIB in dlls/gdi/mfdrv/bitblt.c could work around the problem[3]. Does anybody have any idea on how a proper fix for that function might approximately look like? Thanks, David [1] http://source.winehq.org/source/dlls/gdi/bitblt.c#L139 [2] http://bugs.winehq.com/show_bug.cgi?id=4284 [3] http://www.winehq.org/pipermail/wine-devel/2006-January/044040.html

1 0

Re: Fix a memory leak, fix a typo in the comment, add a trace
by Huw Davies 19 Sep '06

19 Sep '06

On Tue, Sep 19, 2006 at 11:44:52AM +0900, Dmitry Timoshkov wrote: > please apply after "Implement GetKerningPairs for TrueType fonts". > > Changelog: > - fix a memory leak > - fix a typo in the comment > - add a trace about skipped a not supported kerning table format Hi Dmitry, Wouldn't it be nicer to simply resend the first patch again with these fixes applied? Thanks, Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: [WINED3D] Pbuffer/ActiveRender cleanup #2
by H. Verbeet 19 Sep '06

19 Sep '06

On 17/09/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote: > @@ -156,6 +160,7 @@ typedef struct wined3d_settings_s { > BOOL glslRequested; > int vs_selected_mode; > int ps_selected_mode; > + int offscreen_selected_mode; > /* nonpower 2 function */ > int nonpower2_mode; > int rendertargetlock_mode; When you change wined3d_settings, you should make sure that you update the defaults in wined3d_main.c as well. I know those are currently mismatched, but I've got a patch to clean it up. I'm currently waiting for Alexandre to apply/reject some of the wined3d patches sent over the past couple days before sending it (and some other patches). I'm not sure if using wined3d_settings is really the right place to store things that don't have a corresponding registry key, but it seems like the best place for now. To clarify what OFFSCREEN_NONE does, it renders to the backbuffer for the current context, rather than using a separate context, and copies it to a texture when done. That's also why, depending on the primitive drawing order, you sometimes see the offscreen surface in the lower left corner of the screen.

2 3

My Wineconf 2006 trip report
by Marcus Meissner 19 Sep '06

19 Sep '06

Hi folks, I had to write it up for my dear colleagues anyway, so here my notes... Feel free to reuse as you like. Attendance was around 35 people, all developers. Location was the university campus of Reading, a lecture hall in the Agriculture Department. The conference was organized by CodeWeavers, but sponsored by mostly 2 donors of each 1000 (?) US$ to the Wine project, one private person and a Poker website (strange enough). Around 10 - 15 developers were CodeWeavers employees, the other were volunteer developers. 1. Keynote by Alexandre Julliard (CW) Alexandre Julliard, our resident dictator and lone committer held the keynote. - The beta (0.9.*) works out fine. The 2 month code freeze before Beta has helped, and bugs got nicely pruned. The bugzilla stat char showed a nice increase in reported and also in fixed bugs. - Wine 1.0 plans Code Freeze perhaps later this year, for several months, then 1.0 release early next year. - Post 1.0 Unclear. Likely will have a stable and a feature branch. - GIT GIT is working out nicely. Number of monthly (?) commits grew from 400 at the turnover point to around 700 now. Reasons: * More smaller and confined patches (also thanks to GIT allowing incremental local commits). * GIT patch submission is in one defined patch format. Earlier patches were occcasionaly generated from subdirectories, misformatted, hand edited or similar. GIT changes this to one defined format, making his work easier. * "Developers might not like it, but I do". - Goals for 1.0 * Better Game Support (DirectX). This is pretty much heavy work in progress currently. * Regressiontests, Documentation are fine as-is. * Copy Protection support for Games etc. Necessary to run lots of games. However this is not a release stopper. - LOC still increasing, around 1.800.000 now. - COM (Component Object Model) report by Rob Shearman (CW) Rob (and others) spent most of last year enhancing and fixing the COM, OLE and RPCRT parts of WINE and summarized it. The out of process COM used by InstallShield has seen lots of changes and is working much better now. Work on remote COM was necessary for Outlook which talks COM via RPC over TCP sockets with the Outlook server. - GIT Tutorial by Mike McCormack (CW) Not WINE specific, so no details. - cxtest by Martin Pilka (CW) cxtest is the ongoing developed GUI testing kit from Codeweavers. Basic idea is that it can generate keypresses, mouseclicks and similar things and then captures images at various intervals and compares them with previous runs. Needs review of problems, but has definitely spotted some already. - Google's use of WINE by Dan Kegel (Google) 2 major Windows applications that wanted a Linux port. - Picasa Requirement: _No_ Windows binary code change. Hired Codeweavers as company to fix issues: - lots of bugfixes - IWebBrowser implementation - File change notification (implemented with inotify) - Video Codec handling fixes (both in MSVIDEO and DSHOW) - However: Needed to disable CD Burning Module of Picasa. Works on almost all distros nicely. - Google Earth WINE has OpenGL-in-Window problems, otherwise this might have been a WINE job too likely. The Loki Installer guy (Brad something?) did the port on-site (this 1 person did the port). Exposes lots of OpenGL / GFX card related related problems. -> But received more press and recognition. No other Windows applications of Google need to be ported currently. (Google Desktop would be one, but it requires integration into native browsers, so it is too Windows specific.) Dan also oversees 4 Google interns working on Wine. - CrossOver on Mac by Andrew Bogott (CW) Beta on MacOS/X (Intel) of CrossOver Office available. Andrew demoed MS Excel, including installation of it. GUI toolkit is in TCL + Coco (? graphical Mac scripting language) Use X11 graphics driver, Quartz driver is currently being considered. Caused stability problems with Mac Kernel. Caused stability problems with Mac X Server. Is slower than on Linux due to lack of some fast methods we use on Linux (I guess something like threading, futexes or so. -Marcus) - Governance breakout session The point sometimes comes up whether to replace Alexandre. The present developers did not agree, so there was not much discussion. We evaluated _why_ they want it: - They want low quality hacks into the tree to make apps work. This is a no go, you need to fix it right. - They get no reply on their submission _why_ it was rejected. True reason, we discussed a bit how to improve. - A bot welcoming new patch posters? - checks for most common problem, // comments - people actively taking care of areas and responding to people - Alexandre waiting for comments from those responsibles on difficult patches - Branch Maintainership post 1.0 ... Briefly touched, but we will see when we get there. - Packaging breakout session Its unclear (to me at least) what is wanted ;) Paul Millar wants nightly regression tests (cxtest runs with downloaded binaries?) Some want nightly builds. Some want .spec files in a central repository. Marcus is trying to bring up RPM builds for SUSE, Mandriva 2006.0, Fedora Core 4 and 5 on the openSUSE buildservice. Debian to come. Ciao, Marcus

2 2

Wine 0.9.21 fails to run
by Ken Zalewski 19 Sep '06

19 Sep '06

I just upgraded from 0.9.20 to 0.9.21, and now nothing will run, including simple programs such as sol.exe and notepad.exe. The error message I'm receiving is: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 145 (NV-GLX) Minor opcode of failed request: 4 () Resource id in failed request: 0x242 Serial number of failed request: 19 Current serial number in output stream: 19 My system is a Slackware 10.2 system, running kernel 2.6.17.13, x11 6.8.2, and NVidia driver 8774. I have seen some other postings on the Net about this, including postings in the Ubuntu forums (which means that this is not limited to Slackware). Downgrading to 0.9.20 gets everything working again. My guess, based on the "NV-GLX" message, is that something was changed in the OpenGL support between 0.9.20 and 0.9.21, and it has broken Wine. I'll be happy to help debug this. Sincerely, Ken Zalewski Slackware package maintainer Linuxpackages.net

2 1

wine conf group photo
by EA Durbin 18 Sep '06

18 Sep '06

The link on the winehq.org page for the photo is returning 404 not found.

2 1

Re: winex11.drv: cleanup better in X11DRV_WineGL_InitOpenglInfo
by Jesse Allen 18 Sep '06

18 Sep '06

On 9/17/06, Phil Costin <philcostin(a)hotmail.com> wrote: > Roderick Colenbrander wrote: > > > The problem is that I'm not sure (and I think it is Alexandre his issue > > aswell) whether this patch is a workaround or a real fix. I think that > > wined3d created a GLX context in lets say thread '1' and that it wants to > > create lets say another one in a different thread. If this is the case it > > could happen that for the new thread the x11drv visual needs to be > > 'rechosen'. This causes the 'info' code to be called again. Because this > > code creates a context we mess up the already active context. > > > > Your patch indeed fixes that by storing the current GLX context and > > restoring it later on. Perhaps there's a nicer way to prevent this issue > > to happen at all. > > > > In any case I think it might be nicer to use glXGetCurrentContext in case > > there's already some GLX context around. So in that case don't create a > > new context and don't kill it at the end. This would already be cleaner. > > > > Roderick > > > > > > > >> I don't know myself either. I was just going to wait. I want to add a > >> little more to say about it. > >> > >> It's funny that the patch was only meant to affect the opengl/wgl code > >> and the crashing apps are all d3d ones. However winex11 will now > >> change the context on it's own when doing the opengl query and not set > >> it back. What I noticed a couple weeks ago and now is that winex11 > >> does usually gets inited twice, therefore it will change the current > >> context twice. One at the start of the program, and another later on > >> -- maybe on creation of a window or something. By that time wined3d is > >> probably inited too, and making glXMakeCurrent calls too since it's > >> based on opengl. So perhaps winex11 is causing wined3d to trip up at > >> some point by changing the context. So if InitOpenglInfo just sets > >> things back, then wined3d won't go boom. > >> > >> >>From comments in wined3d, I can tell there isn't any "context > >> manager". So what wined3d does at most is very simple management of > >> contextes. We probably need a manager to coordinate things like this > >> better between the two libraries. But that will likely be a bigger > >> patch and to do so... I don't know, we need a fix for all the broken > >> d3d apps now. > >> > >> Jesse > >> > > > > > At the moment, this patch fixes regressions so if we don't have the code in > there at all, many games do not work. > > It may not be the ideal solution but is it not better for now to fix the > regression and think about a proper solution separately without breaking > applications by not having the patch applied? > > Regards, > Phil > > > > Phil, Roderick, I'm going to look at what I can do to improve the patch and gather more information on the handling of contextes. I just haven't had time yet. And Roderick, I'll discuss with you the newer patch when I'm ready so to see if you agree with it. I do lean towards agreeing with Phil on that this is simply needed and more than a workaround. I've already been asked many times if the patch has gotten in and that is why I posted to wine-patches so quickly; your patch broke alot of D3D apps for alot of people... The d3d9 stateblock test is the best clue. Jesse

2 2

Visual C++ does not seem to have snprinft
by Jeff L 18 Sep '06

18 Sep '06

When compiling dlls/gdi/tests/metafile.c on line 1357 I get a warning C4013: "snprintf" is undefined. Looking around, it seems that snprinft is in fact _snprintf in Visual C++. I have found a define #if !defined(HAVE_SNPRINTF) && defined(HAVE__SNPRINTF) #define snprintf _snprintf #endif in wine/port.h but it requires config.h and they don't appear in my Visual C++ system. What is the best way to address this problem? It seems to be fairly common but I have not found an example in a test. Jeff Latimer

6 5

Re: If there is no space for strings GetOutlineTextMetricsA should not indicate that they present
by Paul Vriens 18 Sep '06

18 Sep '06

On Mon, 2006-09-18 at 19:00 +0900, Dmitry Timoshkov wrote: > Hello, > > this patch prevents my test application from crashing by dereferencing > memory beyond allocated memory block. > > Changelog: > If there is no space for strings GetOutlineTextMetricsA should not > indicate that they present. > > --- cvs/hq/wine/dlls/gdi/font.c 2006-08-15 14:51:46.000000000 +0900 > +++ wine/dlls/gdi/font.c 2006-09-18 18:38:57.000000000 +0900 > @@ -1483,6 +1483,20 @@ UINT WINAPI GetOutlineTextMetricsA( > if(output != lpOTM) { > memcpy(lpOTM, output, cbData); > HeapFree(GetProcessHeap(), 0, output); > + > + /* check if the string offsets really fit into the provided size */ > + /* FIXME: should we check string length as well? */ > + if ((UINT_PTR)lpOTM->otmpFamilyName >= lpOTM->otmSize) > + lpOTM->otmpFamilyName = 0; /* doesn't fit */ > + > + if ((UINT_PTR)lpOTM->otmpFaceName >= lpOTM->otmSize) > + lpOTM->otmpFaceName = 0; /* doesn't fit */ > + > + if ((UINT_PTR)lpOTM->otmpStyleName >= lpOTM->otmSize) > + lpOTM->otmpStyleName = 0; /* doesn't fit */ > + > + if ((UINT_PTR)lpOTM->otmpFullName >= lpOTM->otmSize) > + lpOTM->otmpFullName = 0; /* doesn't fit */ > } > > end: this one also fixes an issue I was looking into this morning: Try to create a key via regedit with the name {44444444-4444-4444-44444444} and press enter. Cheers and thanks, Paul.

1 0

Wine directx and xinerama
by Roland Kaeser 17 Sep '06

17 Sep '06

Hello all I just regognized that I get serious trouble trying to run apps on a xinerama screen (Matrox Parhelia) with Triple display configuration (http://www.matrox.com/graphics/workstation/cre_pro/products/pseries/p750.cfm / 01:00.0 VGA compatible controller: Matrox Graphics, Inc. Millenium P650/P750 (rev 02)). Running the same apps (such as Railroad Tycoon) on a "normal" machine with intel 945G (VGA compatible controller: Intel Corporation 945G/GZ Express Integrated Graphics Controller (rev 02)) its works fine. But running RT3 on my Matrox card makes it crashing or just bringing a error message, even when I configured a virtual desktop (1024x768). Does somebody has a idea about this behaviour? Thanks Roland

3 2

Will Wine run with Linspire 5?
by Ctm007 17 Sep '06

17 Sep '06

Will Wine run with Linspire 5? Carl Martin ctm007(a)houston.rr.com

1 0

Re: secur32: Add a warning if ntlm_auth is not found or in a wrongversion.
by Dmitry Timoshkov 17 Sep '06

17 Sep '06

"Kai Blin" <kai.blin(a)gmail.com> wrote: > + else > + { > + WARN("ntlm_auth not found, or in an outdated version.\n" \ > + "Make sure you are using ntlm_auth =< 3.x and it is in your path.\n"); > + } If the message is supposed to be user visible (otherwise why to bother with wording?) it would be better to use either FIXME or MESSAGE. Also "=<" is not really understandable in this context. Did you mean that a version 3.x or better is required (then >= 3.x), or <= 3.x (then the word "outdated" is misleading)? -- Dmitry.

2 1

How to report code errors?
by Andrew Talbot 16 Sep '06

16 Sep '06

How should one report minor code errors that don't necessarily produce known bad behaviour? To give a concrete example, in msacm32:driver.c acmDriverPriority(), formal parameter dwPriority is of type DWORD, which is unsigned, but it contains a line that reads: if (dwPriority < 0) dwPriority = -1; ... which can never happen. Bugzilla seems inappropriate, so does wine-devel. If Coverity has abandoned us, would it be worth having a web/wiki page for posting any such code anomalies, so that the knowledgable might consider fixing them? Thanks, -- Andy.

3 4

Already Error while installing MS Office 2003
by Roland Kaeser 16 Sep '06

16 Sep '06

Hello Just tried to test install office 2003 on wine 0.9.21. But getting already errors. I read in C't (german it magazine) that office 2003 works on codeweavers. Can somebody declare me this? Does codeweavers voluntary not provide the corrections to wine to sell their product? Looks very strange to me. Roland Debug Output while installing office (breaks down when it trieds to start installation of the files (after setup configuration and serial number request) --------------------------------------------------------------------------------------------------------- fixme:imm:ImmDisableIME (-1): stub fixme:advapi:CheckTokenMembership ((nil) 0x190388 0x346d3c) stub! err:ole:CoUninitialize Mismatched CoUninitialize err:ole:CoUninitialize Mismatched CoUninitialize fixme:advapi:CheckTokenMembership ((nil) 0x1ad6f8 0x7d3683b8) stub! err:msidb:WHERE_VerifyCondition Couldn't find column L"Lock" fixme:msi:msi_unimplemented_action_stub MigrateFeatureStates -> 67 ignored L"Upgrade" table values err:msidb:WHERE_VerifyCondition Couldn't find column L"Lock" err:msi:msi_dialog_set_font No font entry for L"52" err:msi:msi_dialog_set_font No font entry for L"9" err:msi:msi_dialog_set_font No font entry for L"52" fixme:msi:ControlEvent_SpawnWaitDialog Doing Nothing fixme:msi:ControlEvent_SpawnWaitDialog Doing Nothing err:msi:msi_dialog_set_font No font entry for L"100" err:heap:HEAP_ValidateInUseArena Heap 0x110000: in-use arena 0x1ed990 next block has PREV_FREE flag fixme:msi:msi_unimplemented_action_stub MigrateFeatureStates -> 67 ignored L"Upgrade" table values err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\1031\\OFREADME.HTM") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\1031\\OFREADME.HTM") fixme:msi:ACTION_HandleStandardAction unhandled standard action L"SetODBCFolders" fixme:msi:deformat_component component key L"HTM_Editor_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"HTM_Editor_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"Core_IDE_Resource_DLLs_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"Core_IDE_Resource_DLLs_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"Core_IDE_Cmd_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"Core_IDE_Cmd_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"VS_SCC_Core_TeamCore_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"VS_SCC_Core_TeamCore_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"CSS_Package_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"CSS_Package_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"_VS_Debugging_SDM2_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"_VS_Debugging_SDM2_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"_VS_Debugging_VSDebug_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"_VS_Debugging_VSDebug_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"WbBrwsrPckgRsrcDLLDEUX86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"WbBrwsrPckgRsrcDLLDEUX86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"URL_Font_Color_Picker_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"URL_Font_Color_Picker_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\CSSPKGUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\CSSPKGUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\HTMEDUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\HTMEDUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\htmdlgsUI.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\htmdlgsUI.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\vsdebugui.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\vsdebugui.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\MSDBGUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\MSDBGUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\MSENVUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\MSENVUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\vsbrowseUI.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\vsbrowseUI.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\VisualStudioTeamCoreUI.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\VisualStudioTeamCoreUI.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\CMDDEFUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\CMDDEFUI.DLL") err:msi:ITERATE_Actions Execution halted, action L"SKURED" returned 1603 err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1603 fixme:msi:msi_dialog_set_control_condition Unhandled action L"Default" fixme:msi:msi_dialog_set_control_condition Unhandled action L"Default"

10 14

Re: winex11.drv: cleanup better in X11DRV_WineGL_InitOpenglInfo
by Jesse Allen 16 Sep '06

16 Sep '06

On 9/14/06, Phil Costin <philcostin(a)hotmail.com> wrote: > This patch fixes many games for me, what is the reason it was not applied? > > Regards > Phil Costin > > I don't know myself either. I was just going to wait. I want to add a little more to say about it. It's funny that the patch was only meant to affect the opengl/wgl code and the crashing apps are all d3d ones. However winex11 will now change the context on it's own when doing the opengl query and not set it back. What I noticed a couple weeks ago and now is that winex11 does usually gets inited twice, therefore it will change the current context twice. One at the start of the program, and another later on -- maybe on creation of a window or something. By that time wined3d is probably inited too, and making glXMakeCurrent calls too since it's based on opengl. So perhaps winex11 is causing wined3d to trip up at some point by changing the context. So if InitOpenglInfo just sets things back, then wined3d won't go boom. >From comments in wined3d, I can tell there isn't any "context manager". So what wined3d does at most is very simple management of contextes. We probably need a manager to coordinate things like this better between the two libraries. But that will likely be a bigger patch and to do so... I don't know, we need a fix for all the broken d3d apps now. Jesse

2 1

Re: X11DRV: fix fbconfig regression
by Roderick Colenbrander 16 Sep '06

16 Sep '06

Ati doesn't advertise GLX_SGIX_fbconfig. They only advertise a GLX client version of 1.3. Because the Xserver only supports 1.2, the reported version is also 1.2 (only the client version number is 1.3, the rest not). Roderick > Roderick Colenbrander wrote: > > The issue is that ATI's drivers don't advertise GLX_SGIX_fbconfig (which > really all opengl drivers do) but on the other hand they advertise GLX > client version 1.3 which promoted GLX_SGIX_fbconfig to core functionality. So > ATI doesn't advertise GLX_SGIX_fbconfig but it is available because their > libs are 1.3. They only ship the 1.3 functions so not the SGIX ones. > > > > So, ATI correctly advertises what they support, I don't see any reason > to have workarounds there. > > tom -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

1 0

configure error
by Tijl Coosemans 16 Sep '06

16 Sep '06

I get the following error running configure on FreeBSD: config.status: creating Makefile sed: 14: ./confstathEGAkR/subs-4.sed: unescaped newline inside substitute pattern There's one of those for every Makefile. The problem is with the following lines in configure.ac where I had to add '\\' to every line to work around the problem. Is this a FreeBSD only thing? AC_SUBST(DEPENDENCIES,"### Dependencies:\\ \\ .INIT: Makefile\\ .BEGIN: Makefile\\ Makefile: dummy\\ -\$(MAKEDEP) -C\$(SRCDIR) -S\$(TOPSRCDIR) -T\$(TOPOBJDIR) \$(EXTRAINCL) \$(DEPEND_SRCS)\\ \\ \$(ALL_OBJS): \$(IDL_SRCS:.idl=.h)\\ \$(LEX_SRCS:.l=.yy.o): \$(LEX_SRCS:.l=.yy.c)\\ \$(BISON_SRCS:.y=.tab.o): \$(BISON_SRCS:.y=.tab.c)")

2 1

Re: X11DRV: fix fbconfig regression
by Roderick Colenbrander 16 Sep '06

16 Sep '06

> Roderick Colenbrander wrote: > > There's this check: > > if ((!WineGLInfo.glxDirect && !strcmp("1.2", > WineGLInfo.glxServerVersion)) || > > (WineGLInfo.glxDirect && !strcmp("1.2", > WineGLInfo.glxClientVersion))) > > > This is not the correct way of loading opengl functions or deciding > whether they are available or not. According to the > GLX_ARB_get_proc_address spec, we need to check _only_ > glXQueryExtensionsString() and glXQueryVersion() and it's not correct to > make assumptions based on server/client versions or extension strings. > > This patch removes all the client/server code and replaces it with the > correct checks. The patch fixes the code in has_opengl() (and also > replaces one wine_dlsym() with pglXGetProcAddressARB()) as well as the > helper function glxRequireExtension() and fixes the code that decices > whether pbuffers are available. Pbuffers are part of GLX 1.3, so if the > GLX version is 1.3 we _have_ pbuffers, no need to check for the > GLX_SGIX_pbuffers extension anymore (&& -> ||) > > If this patch works with ATI drivers, I don't know, but that's certainly > the correct way of querying functions. I'm aware of the GLX version / extension issues. The check is more or less a workaround for buggy drivers like ATI's :( I'm against workarounds but in this case without it, there won't be any OpenGL support on ATI's drivers as GLX_SGIX_fbconfig is a requirement for wine. (I have submitted a bugreport) BTW I had the same stuff in opengl32. The issue is that ATI's drivers don't advertise GLX_SGIX_fbconfig (which really all opengl drivers do) but on the other hand they advertise GLX client version 1.3 which promoted GLX_SGIX_fbconfig to core functionality. So ATI doesn't advertise GLX_SGIX_fbconfig but it is available because their libs are 1.3. They only ship the 1.3 functions so not the SGIX ones. When direct rendering is enabled we look at the GLX client version :( This only works for fbconfig stuff and not for other things like pbuffers (it does work on ATI cards but not on Mesa). I hope this clears it up, Roderick -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

1 0

Re: Already Error while installing MS Office 2003
by jimtabor 16 Sep '06

16 Sep '06

Hi! > Hello > > >Codeweavers version of Wine has changes that Alexandre deems > >unacceptable for the "clean" WineHQ tree. > > If this is that way, it would be real a horror. Why are code patches > which allows a huge major app (key application) to run on linux > "unacceptable" (From point of view of the MS users). Do we here make > trench warfares? Or are there quality conceivabilities which are > completely unrealistic? Shouldn't we not see the major goal of wine? > To run windows apps on linux? Not to have a few lines code a bit > better quality etc. I think we don't have the choice to reject code. > Be very very thankful for each line which is checked in!! I think some > responsible persons are to deep in the code. They are looking just > into the code but can't see the benefit of the code for the wine > project itself. Why don't just accept the code? There is enough time > later to make it more "beautiful" or correct it to a better quality. > But for the moment, some of the code directly allows important apps to > work. > > Roland > > > I checked the Codeweavers version of Wine, there are a lot of "Codeweaver "HACK HACK HACK" Alerts" everywhere in key dlls. I compared it with 0.9.16 since the Codeweavers wine VERSION stated it. Amazing! James > >----- Ursprüngliche Mail ---- > >Von: Jim White <jim(a)pagesmiths.com> > >An: Roland Kaeser <roli8200(a)yahoo.de> > >CC: wine-devel(a)winehq.com > >Gesendet: Freitag, den 15. September 2006, 19:41:45 Uhr > >Betreff: Re: Already Error while installing MS Office 2003 > > > >Roland Kaeser wrote: > > > >> Just tried to test install office 2003 on wine 0.9.21. But getting > >> already errors. I read in C't (german it magazine) that office 2003 > >> works on codeweavers. Can somebody declare me this? Does codeweavers > >> voluntary not provide the corrections to wine to sell their product? > >> Looks very strange to me. > >> ... > > > >Codeweavers version of Wine has changes that Alexandre deems > >unacceptable for the "clean" WineHQ tree. > > > >The Codeweavers Wine source is here: > > > >http://www.codeweavers.com/products/source/ > > > >Jim > > >------------------------------------------------------------------------ >

1 0

[OT] Wine reveals bug in Microsoft Installer
by Segin 16 Sep '06

16 Sep '06

I was recently just feeding random crap to Wine, in an attempt to "stress-test" Wine, for a lack of better words. I fed it the Microsoft Platform SDK Installer, and it revealed a bug in the program, probably related to translation. Image URI: http://segin.no-ip.org/wtf.png -- The real problem with C++ for kernel modules is: the language just sucks. -- Linus Torvalds

1 0

Re: X11DRV: fix fbconfig regression
by Tomas carnecky 16 Sep '06

16 Sep '06

Roderick Colenbrander wrote: > There's this check: > if ((!WineGLInfo.glxDirect && !strcmp("1.2", WineGLInfo.glxServerVersion)) || > (WineGLInfo.glxDirect && !strcmp("1.2", WineGLInfo.glxClientVersion))) This is not the correct way of loading opengl functions or deciding whether they are available or not. According to the GLX_ARB_get_proc_address spec, we need to check _only_ glXQueryExtensionsString() and glXQueryVersion() and it's not correct to make assumptions based on server/client versions or extension strings. This patch removes all the client/server code and replaces it with the correct checks. The patch fixes the code in has_opengl() (and also replaces one wine_dlsym() with pglXGetProcAddressARB()) as well as the helper function glxRequireExtension() and fixes the code that decices whether pbuffers are available. Pbuffers are part of GLX 1.3, so if the GLX version is 1.3 we _have_ pbuffers, no need to check for the GLX_SGIX_pbuffers extension anymore (&& -> ||) If this patch works with ATI drivers, I don't know, but that's certainly the correct way of querying functions. tom

1 1

Note and patch about strange UDP packets
by Florian Echtler 15 Sep '06

15 Sep '06

Hi everybody, we are using a certain tracking software from Advanced Realtime Tracking. This is a windows software, but we decided yesterday that it would be more flexible to be able to use it under Linux, too, so I gave it a try with Wine. As this software communicates with customized (expensive) cameras via UDP, I noted a strange bug in the Wine debug channel "winsock": the software was sending UDP packets to IP _254_.255.255.255 (note the first octet). After some experimentation, I noticed that while Windows just sends this as a broadcast packet, Linux rejects this address, because the corresponding RFC states that the network 240.0.0.0/4 is reserved and should not be used. I therefore build a small patch which checks for these strange adresses and replaces them by broadcast adresses. This enabled our software to work. However, the question now is whether it makes sense to include this patch into Wine? On the one hand, it increases the similarity between Wine's behaviour and Windows's, OTOH it decreases Wine's RFC compliance.. Comments? Thanks, Yours, Florian

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