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

Re: Executing wine over make segfaults.
by Lee Harr 07 Nov '06

07 Nov '06

># wine --version >Works! > >But: > >Makefile >--------- >test: > wine --version >--------- > >Then run: >#make test > >Wine will segfault! I am having the same problem. I use wine to run a compiler from a Makefile. A few months ago, it worked fine, but recently it stopped working. I even downgraded to versions that had worked before, but without success. I have a few older systems that rarely get updated and are working fine, so I was not too concerned about it, but when I saw that 0.9.24 worked, I thought I was back in business.... except it doesn't work from make. The system is gentoo linux (2.6.18-gentoo-r1) wine compiled like this: ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --sysconfdir=/etc/wine --without-curses --without-opengl --with-x --disable-trace --disable-debug --build=i686-pc-linux-gnu >Do you have any special kernel compile options in use? It's gentoo, so everything is custom compiled, but I try to keep it pretty vanilla. I don't think I have stack-protector on unless that is the default for gcc-4.1.1 I could try installing an older version of gcc or an older kernel and see if that helps. Any other ideas? Thanks for your time. _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

8 20

toolbar buttons bug
by Kirill K. Smirnov 07 Nov '06

07 Nov '06

Hi! Today, Nov 7 13:05:46 MSK 2006 I've build current wine git. Something evil happened to toolbar buttons - most of them are black. This bug appears in every application I use. Has anybody have the same problem? (If so, then regression testing awaits us :-() -- Kirill K. Smirnov

1 0

Re: Patch for opengl32.dll.so
by Roderick Colenbrander 07 Nov '06

07 Nov '06

> Roderick Colenbrander wrote : > >> On 11/1/06, Bertrand Coconnier <bcoconni(a)club-internet.fr> wrote: > >>> Hi, > >>> > >>> The last release of Wine 0.9.24 contains an error in the code of > >> opengl32.dll.so > >>> under X11 : Wine tries to get the address of "wglGetIntegerv" (line > 608 > >> of > >>> dlls/opengl32/wgl.c) before the extensions of WGL have actually been > >> loaded > >>> (i.e. before X11DRV_WineGL_LoadExtensions() is called). The reading of > >> the > >>> wglGetIntegerv address fails and afterwards, whenever > >> internal_glGetIntegerv() > >>> is called, wine_wgl.p_wglGetIntegerv is NULL and a Fatal Exception is > >> raised. > >> > >> > >> This is probably already fixed in the git tree. See the commit: > >> winex11.drv: Fixed the prototype of many OpenGL functions. > >> > >> Jesse > > > > Else if the problem still happens something strange is going as the > extensions are registered at x11drv startup. > > > > Roderick > > Yes, the problem still happens because the function process_attach() (line > 582 > of dlls/opengl32/wgl.c) is called before the x11drv startup. The comment > of > process_attach is very clear : "/* This is for brain-dead applications > that use > OpenGL functions before even creating a rendering context.... */". It is > clear > that process_attach is a workaround for *brain-dead* apps :) and among > other > things it gets the address of wglGetIntegerv. This operation used to > succeed as > long as GetProcAddress() was used but now since x11drv is needed to upload > the > wglGetIntegerv address there is some kind of race condition and the > operation > fails hence the bug. > > Bertrand. Compared to 0.9.23 I changed the way wglGetIntegerv is loaded before it was directly loaded using GetProcAddress from winex11.drv now it is still loaded from winex11.drv but then using wglGetProcAddress from gdi32. At wine startup (I'm not sure at which stage but I believe directly when you use gdi stuff or perhaps even earlier) winex11.drv is initialized and during this initialization my opengl code is initialized aswell. I wonder what causes the race as I haven't seen it happening for other users yet. I want to avoid a patch like yours as I plan to do similar things for some other functions. Perhaps something goes wrong in wglGetProcAddress itself. Try running wine using: WINEDEBUG=+wgl,+opengl wine wow.exe -opengl &> log. If it is correct you'll see some opengl information (gl version, loading of extensions) before stuff happens in opengl32.dll. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

6 10

Re: [PATCH 2/2] comctl32: Switch to a Nx4 tiling.
by Robert Reif 06 Nov '06

06 Nov '06

Mike McCormack wrote: > --- > This fixes bug #3573. The only functions left that depend on Nx1 are > ImageList_Read and ImageList_Write, and they need a good rewriting... This patch breaks http://angusj.com/sudoku/

1 0

re: oleaut32: variant - allow conversion of VT_DISPATCH into VT_BSTR in VarCat
by Dan Kegel 06 Nov '06

06 Nov '06

Alex wrote: > While reviewing a tax application, I found out that this app tries to > VarCat(VT_BSTR, VT_DISPATCH) and viceversa. By allowing this conversion, > the application proceeds normally until the next step. Please include a change to the conformance test to test this case. Also, if you have a minute, please file a bug report at http://bugs.winehq.org so we know what tax application it is, etc. Thanks! - Dan (the guy who asked Benjamin do all those VarCat fixes...) -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: [PATCH] Implement GetShellSecurityDescriptor and test for it
by Francois Gouget 06 Nov '06

06 Nov '06

On Mon, 6 Nov 2006, Andrey Turkin wrote: [...] > The patch also adds 2 structures definitions to include/shlwapi.h. > According to MSDN, one of these structures should be placed into > include/shlobj.h, The MSDN is wrong: the PSDK does not define any of SHELL_USER_SID, SHELL_USER_PERMISSION or GetShellSecurityDescriptor(). So they should be defined in a private shlwapi header, not in include/shlobj.h or include/shlwapi.h. > but I think it is bad idea to include shlobj.h from > shlwapi.h (at least at the moment). It would certainly be a bad idea since the PSDK's shlwapi.h header does not include shlobj.h. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

2 3

WineD3D: heap corruption in d3dfmt_convert_surface
by Markus Amsler 06 Nov '06

06 Nov '06

I have (finally!) found the heap corruption in bf1942: Small surfaces have a pitch of 4 and a width <4. This results in pitch*4 > outpitch in IWineD3DSurfaceImpl_LoadTexture:1844. Afterwards the heap gets corrupted in d3dfmt_convert_surface:1654. The attached patch fixes the problem. I'm quite sure this fix is ugly, Suggestions? Markus

2 1

Re: kernel32: Add basic OpenProcess test, make it pass under Wine
by Robert Shearman 06 Nov '06

06 Nov '06

Dmitry Timoshkov wrote: > Hello, > > Changelog: > kernel32: Add basic OpenProcess test, make it pass under Wine. > > @@ -1960,7 +1961,7 @@ NTSTATUS WINAPI NtFlushVirtualMemory( HA > NTSTATUS status = STATUS_SUCCESS; > void *addr = ROUND_ADDR( *addr_ptr, page_mask ); > > - if (!is_current_process( process )) > + if (!is_current_process( process, PROCESS_VM_OPERATION )) > { > ERR("Unsupported on other process\n"); > return STATUS_ACCESS_DENIED; > > Does this fix a real application or is it something that could just as easily be deferred until these remote operations are supported? -- Rob Shearman

2 1

WineD3D: heap corruption patch
by Markus Amsler 06 Nov '06

06 Nov '06

Oops, forgot to attach diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c index d0f44cf..45972c4 100644 --- a/dlls/wined3d/surface.c +++ b/dlls/wined3d/surface.c @@ -1841,8 +1841,7 @@ static HRESULT WINAPI IWineD3DSurfaceImp int height = This->glRect.bottom - This->glRect.top; /* Stick to the alignment for the converted surface too, makes it easier to load the surface */ - outpitch = width * bpp; - outpitch = (outpitch + 3) & ~3; + outpitch = pitch * 4; mem = HeapAlloc(GetProcessHeap(), 0, outpitch * height); if(!mem) {

1 0

Re: Cast-qual warning fix
by Dmitry Timoshkov 06 Nov '06

06 Nov '06

"Andrew Talbot" <Andrew.Talbot(a)talbotville.com> wrote: > -typedef void *MSIITERHANDLE; > +typedef void *MSIITERHANDLE; > +typedef const void *MSICITERHANDLE; Personally I don't like MSICITERHANDLE typedef at all. It' not obvious that 'C' in the name marks constness of the object. Using 'const' explicitly such as 'const MSIITERHANDLE *handle' is much more clear and readable IMO. -- Dmitry.

3 2