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

va_list breakage introduced today

by Gerald Pfeifer

I believe the following patch commit 8268ed978389662c7b43212e008037cae3ce900e Author: Alexandre Julliard <julliard(a)winehq.org> Date: Mon Dec 28 22:19:31 2009 +0100 kernel32: Do not include 16-bit headers in 32-bit files. is causing gmake[2]: Entering directory `/usr/test/Wine/dlls/kernel32' /files/pfeifer/gcc/bin/gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_KERNEL32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wtype-limits -Wpointer-arith -I/usr/local/include -g -O2 -o module.o module.c In file included from module.c:36:0: ../../include/winbase.h:1560:84: error: expected declaration specifiers or '...' before 'va_list' ../../include/winbase.h:1561:85: error: expected declaration specifiers or '...' before 'va_list' In file included from module.c:37:0: ../../include/winternl.h:2223:81: error: expected declaration specifiers or '...' before 'va_list' ../../include/winternl.h:2389:58: error: expected declaration specifiers or '...' before 'va_list' ../../include/winternl.h:2390:75: error: expected declaration specifiers or '...' before 'va_list' over here on my FreeBSD 7.2 tester. Gerald

Dec. 30, 2009

Tango Icons (Almost) Ready to Go!!

by Joel Holdsworth

Hi All, I'm pleased to announce that after a lot of work lately I've pretty much completed the graphics for the icons for shell32, user32 and the programs all sizes and screen depths: http://www.airwebreathe.org.uk/wine-icon/ There are a few minor things left to do: * comctl32: Finish and submit - only idb_std_small.bmp needs to be upgraded. Only idb_std_small.bmp is 32-bit in XP, and Vista * comdlg32: Convert bitmaps to 8-bit. Maybe rework comdlg32 so that the graphics are stored as a icons not bitmaps for so that different colour depths can be handled elegantly. What does windows do? * credui: Test on a low bit-depth platform, and submit. * cryptui: Redo emblems on certwarning.bmp, certerror.bmp, and convert bitmaps into icons for so that different colour depths can be handled elegantly. * winecfg: new transparent bitmap won't work without xrender on a 32-bpp screen. Think again. * wine: image lists still strip the alpha channel. talk to thunderbird about 32-bit DDBs * control, dxdiag, iexplore, winecfg: These programs currently do not have an icon, and although my patches add the icon to the src dir, further patches will be needed to add the icon to the progam's resources, and display them in the app windows. These things are all relatively minor, and I think at this stage it would be good to merge as soon as possible. The only major issue that remains is that there are 3 icons from Gnome that need to be relicensed as LGPL for our use. I've e-mailed the gnome artists mailing list, so hopefully we'll hear back from them soon. Once this is done I'm suggesting we merge the icons for shell32, user32 and the programs. If you're interested you can try them right now at the public-beta-2 branch of my gitorious repo: http://gitorious.org/wine-tango/wine-tango/commits/public-beta-2 My final question is about what to do with my source artwork. The artwork has been collected from a variety of sources. Some is SVGs, some gimp .xcf.bz2s, and some plain PNGs. I guess these shouldn't go into the wine source repo, but does anyone have any bright ideas where these files *should* go? They'll need to be published in case the icons ever need to be changed in any way. Any thoughts? Best Regards Joel

Dec. 30, 2009

Re: [3/4] jscript: Fix various memory and reference count leaks.

by Jacek Caban

Hi Rob, Thanks for your work on jscript. Unfortunately fixing Valgrind on jscript is not going to be easy. Most of your fixes are good, except clear_global part and "jscript: Fix a circular reference caused by object and function objects being able to have properties that are objects and functions." patch. I've sent a test showing that Windows doesn't do that. To fix it properly we need to implement a garbage collector. I've designed it in the very early days of jscript, but I never had time to implement it. Thanks, Jacek

Dec. 30, 2009

Wine prefix creation status

by Erich Hoover

I recently installed the bundled Wine for Mac OS X for someone and noticed something that would be nice for "normal Wine." In the bundled Mac OS X version a progress dialog* is displayed when prefix creation is occurring, are there any plans to do something like this for Wine 1.2? Erich Hoover ehoover(a)mines.edu *Note that this dialog doesn't show "real" progress, but at least lets the user know something is happening.

Dec. 30, 2009

Re: CPPCheck Dec 29

by chris ahrendt

On 12/29/2009 11:17 PM, Alasdair Sinclair wrote: > > return size; ok will file a false positive... thanks chris

Dec. 30, 2009

Re: avifile tests

by Vitaliy Margolen

Julius Schwartzenberg wrote: > +static void init_test_struct(COMMON_AVI_HEADERS *cah) > +{ > + memcpy(&cah->mah, &defmah, sizeof(defmah)); > + memcpy(&cah->ash0, &defash0, sizeof(defash0)); > + memcpy(&cah->ash1, &defash1, sizeof(defash1)); > + memcpy(&cah->pcmwf, &defpcmwf, sizeof(defpcmwf)); > +} You don't need to use memcpy to copy structures. Simple assignment is enough. Eg: cah->mah = defmah; > +static void create_avi_file(const COMMON_AVI_HEADERS *cah) > +{ > + HANDLE hFile; > + DWORD written; > + > + hFile = CreateFile("small.avi", GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); For tests you should always specify full path. Here you probably want to get system's tmp directory. > +static void test_default_data(void) > +{ > > + res = AVIFileOpen(&pFile, "small.avi", OF_SHARE_DENY_WRITE, 0L); Same thing here. Vitaliy.

Dec. 30, 2009

Re: Removing WPARAM/LPARAM Casts

by Michael Stefaniuc

James, On 12/30/2009 02:07 AM, James McKenzie wrote: > Michael Stefaniuc wrote: >> On 12/28/2009 03:06 AM, James Mckenzie wrote: >>> I've noticed that Michael Stefuic (sp?) has removed quite a few >>> WPARAM/LPARAM casts when calling SendMessage() and was >>> wondering/inquiring if he was going do this to riched20/tests/editor.c >>> since I noticed he put in a change for riched20. >>> >>> Michael are you going to do so, or are you going to leave this to >>> others? >> All but one change in the riched20 patch where for >> riched20/tests/editor.c. > Michael: > > Thank you. I've been working on the EM_FORMATRANGE patch and would like > to make changes in the tests to see what happens and if the tests remain > valid for Wine and Windows. I don't have any patch pending for the riched20/tests for the moment. And even if I would don't bother about me; those patches are automatically generated and I can regenerate them at will. Also in case of a conflict Alexandre will prefer the non-janitorial patch. bye michael

Dec. 30, 2009

Re: [PATCH 2/2] user32/uitools: Fix FillRect behaviour for invalid brush passed

by Nikolay Sivov

On 12/30/2009 15:44, Alexandre Julliard wrote: > Names like misc.c should be avoided. Something like uitools.c would be > preferable, particularly since that's where the tested function resides > in user32. > Ok.

Dec. 30, 2009

Re: [PATCH 2/2] user32/uitools: Fix FillRect behaviour for invalid brush passed

by Alexandre Julliard

Nikolay Sivov <bunglehead(a)gmail.com> writes: > diff --git a/dlls/user32/tests/Makefile.in b/dlls/user32/tests/Makefile.in > index 102653f..4f4e812 100644 > --- a/dlls/user32/tests/Makefile.in > +++ b/dlls/user32/tests/Makefile.in > @@ -19,6 +19,7 @@ CTESTS = \ > input.c \ > listbox.c \ > menu.c \ > + misc.c \ > monitor.c \ > msg.c \ > resource.c \ Names like misc.c should be avoided. Something like uitools.c would be preferable, particularly since that's where the tested function resides in user32. -- Alexandre Julliard julliard(a)winehq.org

Dec. 30, 2009

Re: wined3d: Added further Nvidia Geforce 8xxx detection.

by Roderick Colenbrander

Since we group cards, there is no need to add a lot of extra PCI ids. On Wed, Dec 30, 2009 at 1:02 PM, Aaron Brazener <rnbrznr(a)googlemail.com> wrote: > The attached patch is to add the missing PCI device information for > the Nvidia 8xxx series of cards. > > > >

Dec. 30, 2009