May 2011 - Wine-Devel - list.winehq.org

Re: [1/2] explorer: initialize COM
by Alexandre Julliard May 13, 2011

May 13, 2011

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Changelog: > * explorer: initialize COM > > Needed for the upcoming DDE patch to be able to create LNK files. You should do that only when necessary, there are very few things that need that DDE support. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/5] wininet: Clean up closing connection notifications tests
by Marvin May 13, 2011

May 13, 2011

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=10918 Your paranoid android. === WVISTAADM (32 bit http) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

1 0

Wine at LinuxTag 2011 - Driving a pun to far :)
by Marcus Meissner May 13, 2011

May 13, 2011

Hi, I will be on LinuxTag 2011 tomorrow (Saturday) and together with Christian Boltz hold a lecture on Wine at 5pm. http://www.linuxtag.org/2011/de/program/freies-vortragsprogramm/popup/vortr… The talk will be on both beverage and the emulator, as Christian (also a openSUSE community member) is a real life Wine grower. The emulator part from me will be more on the light and fun side. :) (This also accounts that it is in the last slot in the conference program.) We did hold this talk at the openSUSE conference in Nuernberg already, including Wine tasting. Not sure if Christian has planned tasting this time ;) If someone wants to meet up on LT, just drop me a e-mail or just drop by the openSUSE booth tomorrow and query the folks where I am :) Ciao, Marcus

2 1

Curious parallel make issue with make_xftmpl
by Marcus Meissner May 13, 2011

May 13, 2011

Hi, on large parallel in-tree builds I get this error occasionaly: ... ../tools/widl/widl -I. -I. -I../include -I../include -h -o wine/winedxgi.h wine/winedxgi.idl ../tools/widl/widl -m64 -I. -I. -I../include -I../include -t -o stdole2.tlb stdole2.idl gcc -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 ../tools/make_xftmpl.c -o ../tools/make_xftmpl ../tools/widl/widl -I. -I. -I../include -I../include -h -o docobjectservice.h docobjectservice.idl ../tools/widl/widl -I. -I. -I../include -I../include -h -o exdisp.h exdisp.idl gcc -c -I. -I. -I../include -I../include -I/usr/include/freetype2 -D__WINESRC__ -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o make_ctests.o make_ctests.c ../tools/make_xftmpl.c:21:20: fatal error: config.h: No such file or directory compilation terminated. make[1]: *** [../tools/make_xftmpl] Error 1 make[1]: *** Waiting for unfinished jobs.... gcc -c -I. -I. -I../include -I../include -I/usr/include/freetype2 -D__WINESRC__ -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o sfnt2fnt.o sfnt2fnt.c LC_ALL=C sed -e 's,@PACKAGE_STRING\@,Wine 1.3.19,g' ./wine.inf.in >wine.inf || (rm -f wine.inf && false) sed -e 's,@bindir\@,/usr/bin,g' ./wineapploader.in >wineapploader || (rm -f wineapploader && false) LC_ALL=C sed -e 's,@bindir\@,/usr/bin,g' -e 's,@dlldir\@,/usr/lib64/wine,g' -e 's,@PACKAGE_STRING\@,Wine 1.3.19,g' winemaker.man.in >winemaker.man || (rm -f winemaker.man && false) LC_ALL=C sed -e 's,@bindir\@,/usr/bin,g' -e 's,@dlldir\@,/usr/lib64/wine,g' -e 's,@PACKAGE_STRING\@,Wine 1.3.19,g' winemaker.de.man.in >winemaker.de.man || (rm -f winemaker.de.man && false) LC_ALL=C sed -e 's,@bindir\@,/usr/bin,g' -e 's,@dlldir\@,/usr/lib64/wine,g' -e 's,@PACKAGE_STRING\@,Wine 1.3.19,g' winemaker.fr.man.in >winemaker.fr.man || (rm -f winemaker.fr.man && false) gcc -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o make_ctests make_ctests.o gcc -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o fnt2fon fnt2fon.o ../libs/port/libwine_port.a gcc -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o fnt2bdf fnt2bdf.o ../libs/port/libwine_port.a gcc -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o make_xftmpl make_xftmpl.o ../libs/port/libwine_port.a make[1]: Leaving directory `/usr/src/packages/BUILD/wine-1.3.19.20110512/include' make: *** [include] Error 2 I *think* the include/ directory has a make_xftmpl build rule which is not passing the correct -I include paths, especially as make_xftmpl itself is also building in parallel in tools/. Ciao, Marcus

1 0

Question about ddraw implemtation
by Ralph Little May 12, 2011

May 12, 2011

Hi, I have been looking into bug #9672 regarding a crash on startup of The Sims. Tracing through what is happening, the problem seems to be manifesting in the DirectDraw implementation. The Sims calls CreateSurface() with DDSD->dwFlags & DDSD_PIXELFORMAT set to state that a pixformat is specified in u4.ddpfPixelFormat, but no optional flags are set in the pixelformat u4.ddpfPixelFormat.dwFlags [DDPIXELFORMAT]. The function PixelFormat_DD2WineD3D uses this to determine the proper WINE3D pixformat implementation. It does not cope with what I presume is the default situation of no flags having been set, the value being 0. I'm thinking that if you provide 0 for u4.ddpfPixelFormat.dwFlags, you get some basic default, but I don't know what that would be. Certainly, The Sims seems to be providing zero for this parameter. Any ideas what is the proper behaviour in this circumstance? I presume the crash is the game's inability to handle the failure of the surface create gracefully. Here is the relevant trace fragment (with my bit of debug "pixelformat given, flags = 0" added): Cheers, Ralph ======================================= trace:ddraw:ddraw4_CreateSurface iface 0x139f0c, surface_desc 0x34f944, surface 0x34f9c0, outer_unknown (nil). trace:ddraw:CreateSurface ddraw 0x139f08, surface_desc 0x34f944, surface 0x34f9c0, outer_unknown (nil). trace:ddraw:CreateSurface (0x139f08) Requesting surface desc : trace:ddraw:DDRAW_dump_members - DDSD_CAPS : DDSCAPS_SYSTEMMEMORY DDSCAPS_ZBUFFER trace:ddraw:DDRAW_dump_members - DDSD_HEIGHT : 600 trace:ddraw:DDRAW_dump_members - DDSD_WIDTH : 800 trace:ddraw:DDRAW_dump_members - DDSD_PIXELFORMAT : ( ) warn:ddraw:CreateSurface pixelformat given, flags = 0 trace:ddraw:ddraw_create_surface ddraw 0x139f08, surface_desc 0x34f7ec, surface 0x34f8b4, level 0. trace:ddraw:ddraw_create_surface (0x139f08) Requesting surface desc : trace:ddraw:DDRAW_dump_members - DDSD_CAPS : DDSCAPS_SYSTEMMEMORY DDSCAPS_ZBUFFER trace:ddraw:DDRAW_dump_members - DDSD_HEIGHT : 600 trace:ddraw:DDRAW_dump_members - DDSD_WIDTH : 800 trace:ddraw:DDRAW_dump_members - DDSD_PIXELFORMAT : ( ) trace:ddraw:PixelFormat_DD2WineD3D Convert a DirectDraw Pixelformat to a WineD3D Pixelformat trace:ddraw:DDRAW_dump_pixelformat ( ) err:ddraw:PixelFormat_DD2WineD3D Unknown Pixelformat! (0) warn:ddraw:ddraw_surface_init Unsupported / unknown pixelformat. warn:ddraw:ddraw_create_surface Failed to initialize surface, hr 0x88760091. warn:ddraw:CreateSurface ddraw_create_surface failed, hr 0x88760091. err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0xfffffffff

1 0

Re: ddraw: Fix filtering of enumerated display modes (try 4)
by Marvin May 12, 2011

May 12, 2011

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=10886 Your paranoid android. === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: ddraw: Fix filtering of enumerated display modes (try 3)
by Stefan Dösinger May 12, 2011

May 12, 2011

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This patch looks OK to me Am 11.05.2011 um 10:03 schrieb Ričardas Barkauskas: > try 3: Non standard bit mask test added. More surface description and > pixel format flags tested and DDSD_REFRESHRATE filtering and appearance > in callback surface description fixed. It affects filtering even when > DDEDM_REFRESHRATES is not set. > > try 2: Removed pixel format printing. Fixed email address > > Ričardas Barkauskas > REalm > <0001-ddraw-Fix-filtering-of-enumerated-display-modes.txt> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNy5voAAoJEN0/YqbEcdMwDK8P/iRh2fXmfGB+DV6zgHd1QY+6 JBTDZdLpSRIhdeM6KI+CYxbdClOkg5IEw7HUVldc8N8WnGoO28oeaf+XlaDVTwIR 66PPzC6NI/Q/301Gx34aO17VNQpnUs8Q6ITQU5kmEzlCP1cL0Tt0VCQQt95RETbv zxs2IW26QCwoHEv7g9cO8MNoU3UYOFVdln6EONOvpNRZDuAxU+NChF5OPMUJsCmJ xbkNTkCdrwf6kyHbm1MQewIVcgmZu/8b+enhL6mDpHtwiVOgD8Blw9u7rvdjlZse h7qb9X4zbsgNUUpvC4B6M1cK1LAi5M5LEI5dyAPzkWFUNV2CDwyhagnaAxv4VHkg KcYH9rzUN4EAe9ctnMH633Q7NMo870KboZOOyThQdRaXRXosRGsaFQ6tHqkqbNlp u47OdATqZrTKlDWsAC9CNBV8+NsLat6wK6sDhLVKgRTJuL2gTcePmHS+hzQ5aIxA 8A+2avxZRGlzaBW7tC7hKt/jYV7NHemWzEZNn6mduNL/PysmT+43881AthlSLDhD aegYN6e1XECPnDfTNDP/XaGaObiUZgLb8MbmRzOTJDMSKt06Hgf+PSjIW9LW4w1j bYz1QABAV1Wmso1iYEYTh1vMEeXq9TRm0m1+w+CV/PEVsRNwz2XLsNzfCjLYcgMq zZDO1Seyq/e3PiCmf9hU =KEpe -----END PGP SIGNATURE-----

1 0

dsound: return success in IDirectSoundBufferImpl_AcquireResources
by Joerg-Cyril.Hoehle＠t-systems.com May 11, 2011

May 11, 2011

Austin English wrote: - FIXME("(%p,%08u,%u,%p): stub\n",This,dwFlags,dwEffectsCount,pdwResultCodes); + FIXME("(%p,%08u,%u,%p): stub, faking success!\n",This,dwFlags,dwEffectsCount,pdwResultCodes); This is superfluous :-) "stub" is generally synonym with faking success. One lesson about apps - I tend to forget it myself - is that often enough they don't check every result and choose an alternative control path when some call fails, so better return success even thought it's a lie. Several bugs were fixed by returning the success value that apps would get on native, instead of returning the value that would be consistent with the specification and implementation state in Wine, e.g. NOTSUPPORTED, ERR_NOTIMPLEMENTED etc. I don't like that, but it helps. Often enough, the stub must fill part of the output parameters to prevent a crash later on. This remembers me to look at bug #17893 (needs amstream stub) again. Regards, Jörg Höhle

2 1

winealsa.drv/midi.c: Adds the midi MTC Quarter Frame messages support.
by Joerg-Cyril.Hoehle＠t-systems.com May 11, 2011

May 11, 2011

Hi, well, I know little about MIDI and have no MIDI HW, yet what I read about the F1 code is that it is indeed a quarter time "tick" and takes 2 bytes, so the 2nd part of Stéphane Bacri's patch from last month looks good to me. The first half + toSend = ((ev->data.control.value & 0x7f) << 8) | MIDI_CMD_COMMON_MTC_QUARTER; looks ok too (by analogy with the surrounding code). One would argue that the existing shifts in midi.c would benefit from named constants too, http://source.winehq.org/source/dlls/winealsa.drv/midi.c#L365 MIDI_CMD_COMMON_SONG_SELECT 0xf3 MIDI_CMD_COMMON_SONG_POS 0xf2 http://www.alsa-project.org/alsa-doc/alsa-lib/group___m_i_d_i___commands.ht… Regards, Jörg Höhle

1 0

configure looking for prelink
by Claudio Fontana May 11, 2011

May 11, 2011

Hello all, I noticed that wine's configure script looks for prelink using AC_PATH_PROG(PRELINK, prelink, false, [/sbin /usr/sbin $PATH]) I'd suggest changing it to AC_PATH_PROG(PRELINK, prelink, false, [/sbin /usr/sbin /usr/local/sbin $PATH]) to cover the case where the prelink package is built from source and installed in the default prefix (/usr/local). Thanks, Claudio Fontana

1 0