December 2005 - Wine-Devel - list.winehq.org

Re: Problems generating c++ project since wine 0.9.3

by Sergio

Vincent Béron wrote: >> Is there something that I am misisng when generating this project? Or is >> this a known issue? > > Known problem (caused then fixed by me). > The fix was committed after 0.9.3, and is the patch available from > http://source.winehq.org/git/?p=wine.git;a=commitdiff_plain;h=fe987b3035817… > > Vincent Thank you, the patch solved the problem.

Dec. 14, 2005

Re: Can't install mdac at all now

by Dan Kegel

On 12/13/05, Raphael <fenix(a)club-internet.fr> wrote: > Hi Dan, > my patch haven't been commited so it doesn't work I think you misunderstand. There's been a regression. Things are worse than before, even with your patch not applied before or after; your patch was to unpack the cabs, but they don't even get copied now, let alone unpacked. > Markus is working on a better implementation Any ETA? I guess I'll stop worrying, if he's going to get that area working, he'll fix this regression anyway. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 14, 2005

Re: question regarding FindWindow

by Rob Shearman

Marcus Meissner wrote: >Hi, > >While debugging Google Earth I see hangs in FindWindow... > >Apparently the > if (GetWindowTextW( list[i], buffer, len + 1 ) && !strcmpiW( buffer, title )) break; >call hangs on the server... But how is this possible? > >+win,+server snippet: > >trace:win:RedrawWindow 0x10020 whole window flags: RDW_INVALIDATE RDW_ERASE >0009: redraw_window( window=0x10020, flags=00000005, region={} ) >0009: redraw_window() = 0 >trace:win:RedrawWindow 0x10020 whole window flags: RDW_INVALIDATE RDW_ERASE >0009: redraw_window( window=0x10020, flags=00000005, region={} ) >0009: redraw_window() = 0 >0009: get_window_children( parent=0x10020, atom=0000, tid=0000 ) >0009: get_window_children() = 0 { count=3, children={0x10026,0x10024,0x10022} } >fixme:win:WIN_FindWindow before getwindowtext >fixme:win:WIN_FindWindow after getwindowtext >fixme:win:WIN_FindWindow before getwindowtext >0009: send_message( id=0010, type=1, flags=0, win=0x10024, msg=0000000d, wparam=00000023, lparam=55937970, x=0, y=0, time=000010a4, info=00 >000000, timeout=0, callback=(nil), data={} ) >0009: send_message() = 0 >0009: get_msg_queue( ) >0009: get_msg_queue() = 0 { handle=0x148 } >0009: set_queue_mask( wake_mask=00008040, changed_mask=00008040, skip_wait=1 ) >0009: set_queue_mask() = 0 { wake_bits=00000000, changed_bits=00000000 } >0009: select( flags=4, cookie=0x55c1f6f8, signal=(nil), timeout=0, handles={0x148,0x80} ) >0009: select() = PENDING >*hang* > >What debug to enable and what to look at? > > Look at why the message loop for 0x10024 doesn't process the message. This may be one of the things that Windows handles in the server rather than sending messages to each window. Rob

Dec. 14, 2005

Re: WLDAP32: link to the reentrant version of libldap

by Robert Reif

Hans Leidekker wrote: >The configure check somehow needs -lpthread on Fedora based systems but >Wine's build system links wldap32 to libldap_r without it just fine. > >Adding -lphtread to the configure check doesn't seem to cause any trouble >on my Debian based Ubuntu either (where it isn't needed). I suspect it's >a problem with the (newer) autoconf tools in Fedora. > > -Hans > >Changelog > Link to the reentrant version of libldap. > > >------------------------------------------------------------------------ > >f891a05d34c03c99b3476dea041cca3f9e06cc09 >diff --git a/configure.ac b/configure.ac >index a834d40..4b9a0f2 100644 >--- a/configure.ac >+++ b/configure.ac >@@ -542,15 +542,20 @@ then > fi > > dnl **** Check for OpenLDAP *** >+saved_libs="$LIBS" >+LIBS="$LIBS $LIBPTHREAD" >+ > AC_SUBST(LDAPLIBS,"") > if test "$ac_cv_header_ldap_h" = "yes" -a "$ac_cv_header_lber_h" = "yes" > then >- AC_CHECK_LIB(ldap, ldap_initialize, >+ AC_CHECK_LIB(ldap_r, ldap_initialize, > [AC_CHECK_LIB(lber, ber_init, > [AC_DEFINE(HAVE_LDAP, 1, [Define if you have the OpenLDAP development environment]) >- LDAPLIBS="-lldap -llber"])]) >+ LDAPLIBS="-lldap_r -llber"])]) > fi > >+LIBS="$saved_libs" >+ > dnl **** Check for FreeType 2 **** > AC_SUBST(FREETYPELIBS,"") > AC_SUBST(FREETYPEINCL,"") > > >------------------------------------------------------------------------ > > > This patch breaks builds on RH9 and appears to be responsible for the build breakage on http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php

Dec. 14, 2005

Regression in Wine on FreeBSD (DVD Shrink)

by Travis Poppe

Hello All, Lately I've been trying to track down a problem that prevents DVD Shrink 3.2 from starting on FreeBSD in any version of Wine built on/after 04-20-2005 (including the recent beta releases). Any version built prior to this works fine. I've tracked the problem down to the changes made to x11drv/dib.c (and associated) on 04-20-2005. I'm not fluent in C; I merely found the problem through trial and error. If I copy the x11drv/dib.c (and ntdll/, so the old dib.c will work) from 04-18-2005 in place of the one introduced on the 20th, the problem disappears and DVD Shrink fires right up. Changing dib.c (and dib.c only) back to the 20th snapshot re-introduces the problem, and DVD Shrink hangs again. As I don't understand the code, I don't know how to detect where the problem really lies, as the dib.c changes may only be indirectly responsible. I am very willing to test for or aid anyone who wouldn't mind helping with this problem, however. I have already contacted the author of the changes (dib.c and associated) and he suggested I try this list. If anyone would like to glance at the differences between the two files I've mentioned above, I have posted a diff here: http://lickwid.net/~tlp/dib.c.diff --- are the old and working changes +++ are the new and broken changes Any help would be greatly appreciated. Thanks, -- Travis Poppe IRC: tlp @ irc.freenode.net

Dec. 14, 2005

Re: Can't install mdac at all now

by Raphael

On Tuesday 13 December 2005 08:39, Dan Kegel wrote: > Bug 3636 is worse now. > http://bugs.winehq.org/show_bug.cgi?id=3636 > A few weeks ago, after mdac installer finished, > I could go and unpack the installed cabs by hand. > Now the installer aborts before it even copies the cabs. > Bleah. > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv Hi Dan, my patch haven't been commited so it doesn't work Markus is working on a better implementation Regards, Raphael

Dec. 14, 2005

Re: Wine: DirectDraw over Direct3D

by Raphael

On Tuesday 13 December 2005 09:28, Stefan Dösinger wrote: > Am Dienstag, 13. Dezember 2005 04:25 schrieb Aric Cyr: > > What is slow with ATI cards? It seems that you should only need basic 3D > > acceleration to do what you propose. Is fglrx missing something that > > would be required for 2D rendering? > > Texture upload is very slow. glReadPixels, glWritePixels and friends take > ages. That means that blt, Lock, and Unlock is really slow. > There is some hope at least: Xine and Mplayer can play videos over OpenGL > really fast, maybe we can find out how they do it. for glReadPixels, glWritePixels you can use the frame buffer object extension (or/with pbuffers) :) Keep your Good work > Stefan Regards, Raphael

Dec. 14, 2005

Re: Problems generating c++ project since wine 0.9.3

by Vincent Béron

Le dim 11/12/2005 à 19:43, Sergio a écrit : > Hi all, > > I've been having problems trying to compile one c++ project since latest > wine version (0.9.3). This project compiled and worked fine with previous > versions. > > The error messages look like: > /usr/include/wine/windows/unknwn.h:26: error: expected unqualified-id before > ‘{’ token > ... > /usr/include/wine/windows/objidl.h:66: error: expected unqualified-id before > ‘:’ token > ... > /usr/include/wine/windows/oaidl.h:553: error: expected unqualified-id before > ‘:’ token > ... > /usr/include/wine/windows/propidl.h:287: error: expected unqualified-id > before ‘:’ token > ... > /usr/include/wine/windows/oleidl.h:46: error: expected unqualified-id before > ‘:’ token > ... > > Is there something that I am misisng when generating this project? Or is > this a known issue? Known problem (caused then fixed by me). The fix was committed after 0.9.3, and is the patch available from http://source.winehq.org/git/?p=wine.git;a=commitdiff_plain;h=fe987b3035817… Vincent

Dec. 13, 2005

question regarding FindWindow

by Marcus Meissner

Hi, While debugging Google Earth I see hangs in FindWindow... Apparently the if (GetWindowTextW( list[i], buffer, len + 1 ) && !strcmpiW( buffer, title )) break; call hangs on the server... But how is this possible? +win,+server snippet: trace:win:RedrawWindow 0x10020 whole window flags: RDW_INVALIDATE RDW_ERASE 0009: redraw_window( window=0x10020, flags=00000005, region={} ) 0009: redraw_window() = 0 trace:win:RedrawWindow 0x10020 whole window flags: RDW_INVALIDATE RDW_ERASE 0009: redraw_window( window=0x10020, flags=00000005, region={} ) 0009: redraw_window() = 0 0009: get_window_children( parent=0x10020, atom=0000, tid=0000 ) 0009: get_window_children() = 0 { count=3, children={0x10026,0x10024,0x10022} } fixme:win:WIN_FindWindow before getwindowtext fixme:win:WIN_FindWindow after getwindowtext fixme:win:WIN_FindWindow before getwindowtext 0009: send_message( id=0010, type=1, flags=0, win=0x10024, msg=0000000d, wparam=00000023, lparam=55937970, x=0, y=0, time=000010a4, info=00 000000, timeout=0, callback=(nil), data={} ) 0009: send_message() = 0 0009: get_msg_queue( ) 0009: get_msg_queue() = 0 { handle=0x148 } 0009: set_queue_mask( wake_mask=00008040, changed_mask=00008040, skip_wait=1 ) 0009: set_queue_mask() = 0 { wake_bits=00000000, changed_bits=00000000 } 0009: select( flags=4, cookie=0x55c1f6f8, signal=(nil), timeout=0, handles={0x148,0x80} ) 0009: select() = PENDING *hang* What debug to enable and what to look at? Ciao, Marcus

Dec. 13, 2005

Re: PATCH: handle NULL XImage in GetBitmapBits

by Marcus Meissner

On Tue, Dec 13, 2005 at 07:13:00PM +0100, Willie Sippel wrote: > Am Dienstag, 13. Dezember 2005 11:42 schrieb Alexandre Julliard: > > Marcus Meissner <marcus(a)jet.franken.de> writes: > > > Changelog: > > > In GetBitmapBits() handle the correct bitmap information > > > when a DIB is used. > > > > I think for a DIB we want to copy the bits directly, like we already > > do in SetBitmapBits. Does this work for you? > > > All three patches (yours and the two by Marcus) fix bug 4034... ;-) Can also confirm that it fixes the issue. Ciao, Marcus

Dec. 13, 2005