September 2006 - Wine-devel

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