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

winealsa: 6 Channel Audio

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Andrew Eikum wrote: > > A configuration option (in winecfg/control panel) [...] > My reaction to this is "urrrrrrrghhhhhhh". >Tucking stuff away in the registry makes it a pain to screw >up their config, which means they'll probably turn to submitting bug >reports with the default config first, which is exactly what I want. Interesting wish. Somehow understandable, however ... Currently I see the winecfg as the only viable solution to the issue that we (at least I) don't know how to get the best default parameters. E.g. dmix prefers 48000Hz but this is settable somewhere in /etc/alsa or /usr/share/alsa PA seems to use 44100 on my system (and I'm wondering whether PA may end up using dmix as back-end, involving some resampling from 44100 to 48000?!?) All of them will happily accept any rate and resample. I don't know how to get hw:0's preferred rate short of disabling resampling, which will cause compatibility trouble (perhaps open hw:0 twice, once without resampling to investigate the bare bones, then with resampling which is what Wine needs for its operations). >GetMixFormat(). For example, >it should really be a per-device (and therefore per-backend) setting. Huh? it's already dependent on This->pcm_handle, hence the backend. IMHO we need enumeration tests to verify that GetMixFormat exists for every mmdevapi device. Conceptually IMHO, GetMix is all about a mixer. I don't believe MS provides N mixers, rather than one for each of "Default Voice output channel" and "Multimedia output" and perhaps "Comm output" -- should these be different. That's 1-3. OTOH, it's possible that it supplies on-demand mixing services for every mmdevapi backend, e.g. the poor built-in speaker, on-board audio and distinct 5:1 PCI card. Can an app open any device in shared (=mixer) mode, even when it's not one of the default devices? It's quite logical that there's a control panel in Windows Vista-7. Their users must be able to define which is their default (preferred) voice, multimedia and comm output card, and possibly how their 5/7:1 speakers are positioned. Ideally, Wine should detect whether ALSA has a distinct (and working) "surround" or "5.1" output device, use that and detect (or map) its speaker configuration. >Apparently ALSA is capable of handling up to 10,000 channels The message means nothing more than that dmix will accept upto 10000 channels and map that somehow to the underlying device. Not unlike that systematic test performed by a German guy IIRC about channel mapping on MS, where 1-6 channels were also accepted and distributed somehow to the existing speakers. Regards, Jörg Höhle

Oct. 26, 2011

Re: D3DXCreatePolygon

by Frédéric Delanoy

On Tue, Oct 25, 2011 at 08:10, paulo lesgaz <jeremielapuree(a)yahoo.fr> wrote: > Hello, > any problem with my D3DXCreatePolygon patch? > Thanks in advance. > David Don't see it on wine-patches, or http://source.winehq.org/patches/ Did you subscribe to wine-patches? Also, avoid HTML mail on wine mailing lists BTW the name you sign your messages with (David) does not match the name in your email address, which is weird

Oct. 26, 2011

Re: Wine's configure script when cross-compiling

by Roger Cruz

Hi Dan, So far that autoconf script has been a nightmare. It doesn't include string.h (where strerror.h is defined) directly BUT I did include unistd.h in order to get autoconf to find getpagesize(). I'm building under the Android development which uses GCC for cross-compiling for ARM. I decided to continue making progress on my project by taking autoconf's output (config.h) and hand tweaking the #define HAVE_xxx functions that I know the cross-compile environment provide. I get a lot farther now but a new error arises, for which I have no clues yet on how to fix. make[1]: Entering directory `/development/rcruz/sandbox/wine-builds/winearm3/dlls/acledit' arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/acledit -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o main.o /home/rcruz/sandbox/wine-dev-branch/dlls/acledit/main.c /home/rcruz/sandbox/wine-builds/wine32-dev/tools/winegcc/winegcc -b arm-linux-androideabi -B/home/rcruz/sandbox/wine-builds/wine32-dev/tools/winebuild --sysroot=../.. -fasynchronous-unwind-tables -shared /home/rcruz/sandbox/wine-dev-branch/dlls/acledit/acledit.spec main.o -o acledit.dll.so ../../libs/port/libwine_port.a ../../dlls/winecrt0/libwinecrt0.a(dll_entry.o): In function `__wine_spec_dll_entry': /home/rcruz/sandbox/wine-dev-branch/dlls/winecrt0/dll_entry.c:42: undefined reference to `_fini' /home/rcruz/sandbox/wine-dev-branch/dlls/winecrt0/dll_entry.c:37: undefined reference to `_init' /home/rcruz/sandbox/tools/toolchain9/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld: acledit.dll.so: hidden symbol `_init' isn't defined /home/rcruz/sandbox/tools/toolchain9/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status winegcc: arm-linux-androideabi-gcc failed make[1]: *** [acledit.dll.so] Error 2 make[1]: Leaving directory `/development/rcruz/sandbox/wine-builds/winearm3/dlls/acledit' ________________________________ From: Dan Kegel <dank(a)kegel.com> To: wine-devel(a)winehq.org Cc: roger_r_cruz(a)yahoo.com Sent: Wednesday, October 26, 2011 12:49 AM Subject: re: Wine's configure script when cross-compiling Welcome to the wonderful world of autoconf! > The code that generates conftest.c does not provide for an argument to strerror. Why doesn't it? And how does the configure script succeed when compiling for x86? If I recall correctly: Because conftest.c doesn't include the .h file that declares strerror(), and C doesn't have typesafe linkage, checking for the presence of a function by linking to it with a totally bogus call with no arguments should work fine. It's not clear why the compiler is complaining - did it somehow see a .h file that declared strerror()? What compiler are you using?

Oct. 26, 2011

re: Wine's configure script when cross-compiling

by Dan Kegel

Welcome to the wonderful world of autoconf! > The code that generates conftest.c does not provide for an argument to strerror. Why doesn't it? And how does the configure script succeed when compiling for x86? If I recall correctly: Because conftest.c doesn't include the .h file that declares strerror(), and C doesn't have typesafe linkage, checking for the presence of a function by linking to it with a totally bogus call with no arguments should work fine. It's not clear why the compiler is complaining - did it somehow see a .h file that declared strerror()? What compiler are you using?

Oct. 25, 2011

Wine's configure script when cross-compiling

by Roger Cruz

I'm still attempting to cross-compile Wine to ARM and I'm running into many compile errors right off the bat. I have tracked these down to the lack of HAVE_xxx in the config.h file generated from configure script. Many of the functions being checked from this list fail when they are compiled by ac_fn_c_check_func () for ac_func in \ _finite \ _isnan \ _pclose \ _popen \ ... snprintf \ spawnvp \ statfs \ statvfs \ strcasecmp \ strdup \ strerror \ One example of a failure is strerror which does not compile because it is missing one argument conftest.c:165: error: too few arguments to function 'strerror' The code that generates conftest.c does not provide for an argument to strerror. Why doesn't it? And how does the configure script succeed when compiling for x86? int main () { return $2 (); ; return 0; } Thanks in advance Roger R. Cruz

Oct. 25, 2011

Re: Regression testing breakthrough

by Francois Gouget

On Tue, 25 Oct 2011, Damjan Jovanovic wrote: [...] > Now the next question is, how to get the binaries to run on any distro? Or > should I just compile on Ubuntu because most people run that (do they still, > after Unity?)? Compile on Debian Stable or even Debian OldStable, taking care to still make sure you have all the important dependencies, sometimes adding some backported packages. Typically you'd do this in a chroot. Then it will run on all relevant Linux distributions. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A black hole is just God dividing by zero.

Oct. 25, 2011

Re: [PATCH] kernel32: Output message to stderr in UTF-8

by Nicolas Le Cam

2011/10/25 Alex Henrie <alexhenrie24(a)gmail.com>: > Hello, > > Last week I submitted a patch to make kernel32 output an error message > in UTF-8 rather than the current codepage. This fixed a bug in which > the command "wine /." would produce a garbled error message in > languages other than English. However, thinking about this some more, > I'm not sure that my patch fixes the bug correctly. I made > WideCharToMultiByte use CP_UTF8 instead of CP_ACP, but reading more > about the codepage setting, I think I should have used either > CP_UNIXCP or CP_OEMCP. Could anyone help clarify which should be used? > > -Alex > See Dmitry response to your patch : http://article.gmane.org/gmane.comp.emulators.wine.devel/87295 -- Nicolas Le Cam

Oct. 25, 2011

Re: [PATCH] kernel32: Output message to stderr in UTF-8

by Alex Henrie

Hello, Last week I submitted a patch to make kernel32 output an error message in UTF-8 rather than the current codepage. This fixed a bug in which the command "wine /." would produce a garbled error message in languages other than English. However, thinking about this some more, I'm not sure that my patch fixes the bug correctly. I made WideCharToMultiByte use CP_UTF8 instead of CP_ACP, but reading more about the codepage setting, I think I should have used either CP_UNIXCP or CP_OEMCP. Could anyone help clarify which should be used? -Alex

Oct. 25, 2011

Re: Regression testing breakthrough

by Damjan Jovanovic

2011/10/18 André Hentschel <nerv(a)dawncrow.de> > Am 18.10.2011 10:45, schrieb Damjan Jovanovic: > > This tool compiled all 35000 or so commits from Wine 1.0 to around 4th > October 2011 in only 7 days, generating a Git repository of Wine binaries > that's only 26 gigabytes in size. Regression testing with binaries is a > pleasure: it takes only a few seconds :-) on each bisection. I bisected a 16 > step regression in just 20 minutes, and most of that time was spent running > the application and dealing with 2 X-server crashes. > > I already love it. > > > I haven't figured out how to make the binaries available to users. Few > users can clone a 26 gigabyte repository, and even fewer places can serve > that much to multiple users. Maybe Git can compress it further? The other > idea I had is that users should be able to regression test through a GUI > tool. Maybe the GUI tool can just download and run the +/- 122 MB binary > snapshots for specific commits, instead of having the entire binary > repository locally? > > tried compressing the .git directory. or maybe "git gc" can help > > Thank you, "git gc" reduces it from 26 GB to only 1.5 GB :-). tar.lzma on top of that doesn't help. Now the next question is, how to get the binaries to run on any distro? Or should I just compile on Ubuntu because most people run that (do they still, after Unity?)? Thank you Damjan

Oct. 25, 2011

re: [PATCH 1/3] widl: teach widl how to automatically create class factories (resend)

by Dan Kegel

Hi Bernhard, build fails here: widl.o: In function `write_dlldata': /home/bob/wineslave.dir/sandbox/slave/runtests-default/build/tools/widl/widl.c:423: undefined reference to `write_dlldata_list' widl.o: In function `main': /home/bob/wineslave.dir/sandbox/slave/runtests-default/build/tools/widl/widl.c:781: undefined reference to `write_dlldata_list' http://winehq.org:8010/builders/runtests-default/builds/106 Also, patch 2/3 doesn't apply: error: patch failed: Make.rules.in:20 error: Make.rules.in: patch does not apply http://winehq.org:8010/builders/runtests-default/builds/107

Oct. 25, 2011

Re: [PATCH 2/5] d3d8/tests: Add a small test for multisampled CopyRects().

by Francois Gouget

commit fd1afd24f4af20646ce0f3a7ac2064e8e49b1e7d Author: Henri Verbeet <hverbeet(a)codeweavers.com> Date: Wed Oct 19 22:03:11 2011 +0200 d3d8/tests: Add a small test for multisampled CopyRects(). This commit causes the d3d8:visual to crash on my desktop (Debian Testing, 9600GT, 285.05.09-1 proprietary driver): wine: Unhandled stack overflow at address 0x7e3ab8bf (thread 0009), starting debugger... err:seh:setup_exception_record stack overflow 1100 bytes in thread 0009 eip 7ef8952b esp 00240ee4 stack 0x240000-0x241000-0x340000 The call that causes the crash is: hr = IDirect3DDevice8_CopyRects(device, rt, NULL, 0, readback, NULL); The stack trace seems to point towards an out of hand recursion problem that eventually causes a stack overrun: Backtrace: =>0 0x7e3a7a32 d3dfmt_get_conv+0x12(surface=0x161728, need_alpha_ck=0x1, use_texturing=0x1, format=0x242074, convert=0x24210c) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:4372] in wined3d (0x00242018) 1 0x7e3b05ee surface_load_texture+0xcd(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5953] in wined3d (0x00242128) 2 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00242258) 3 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00242388) 4 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242498) 5 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x002425c8) 6 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x002426f8) 7 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242808) 8 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00242938) 9 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00242a68) 10 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242b78) 11 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00242ca8) 12 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00242dd8) 13 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242ee8) 14 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00243018) 15 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00243148) 16 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00243258) 17 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00243388) 18 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x002434b8) 19 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x002435c8) [...] -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

Oct. 25, 2011

D3DXCreatePolygon

by David Adam

Any problem with my D3DXCreatePolygon patch? Thanks in advance. David

Oct. 25, 2011

D3DXCreatePolygon

by paulo lesgaz

Hello, any problem with my D3DXCreatePolygon patch? Thanks in advance. David

Oct. 25, 2011

Re: riched20: do not return incorrect values from ME_CharFromPoint[Cursor]

by Alexandre Julliard

Thomas Faber <thfabba(a)gmx.de> writes: > it is not a workaround. It is the current riched20 code that relies on the bug > being present (hence why it asserts on Windows). > The patch makes it work with a _correctly working_ version of > GetTextExtentExPointW (and also with the current one). > You could see it as a prerequisite to fixing that bug (that is, to fixing it > without breaking richedit controls). Ah OK, it's fine then. Thanks. -- Alexandre Julliard julliard(a)winehq.org

Oct. 24, 2011

Re: riched20: do not return incorrect values from ME_CharFromPoint[Cursor]

by Thomas Faber

Hey, On 2011-10-24 20:03, Alexandre Julliard wrote: > Thomas Faber <thfabba(a)gmx.de> writes: > >> Windows's version of GetTextExtentExPointW, which is called in that function, >> returns a value of 1 in this case (Wine's does not, which would appear to be >> a bug), leading to the "i<len" assertion failure if there is no text in the >> control. >> The patch fixes riched20 to correctly handle either behavior by >> adding a fast path for cx <= 0 (the function obviously needs to return 0 in >> the cx == 0 case too, so it can skip the calculation). > > You should not be adding workarounds for Wine bugs, the bugs need to be > fixed instead. > it is not a workaround. It is the current riched20 code that relies on the bug being present (hence why it asserts on Windows). The patch makes it work with a _correctly working_ version of GetTextExtentExPointW (and also with the current one). You could see it as a prerequisite to fixing that bug (that is, to fixing it without breaking richedit controls). Regards, Tom

Oct. 24, 2011

Re: riched20: explicitly cast WPARAM to character types

by Thomas Faber

Hi Michael, On 2011-10-23 21:25, Michael Stefaniuc wrote: > On 10/22/2011 10:38 PM, Thomas Faber wrote: >> This makes the use of casts more consistent and shows the conversion >> from WPARAM to CHAR/WCHAR is intentional for WM_CHAR/EM_SETPASSWORDCHAR. >> Also fixes two MSVC warnings. > To make it consistent remove the WCHAR cast 3 lines above. > Casts are *not* there to show a conversion is intentional. They tell the > compiler to STFU and to the human reader they mean "*WARNING* doing > something odd here". So don't cry wolf when there's no wolf in sight. > > No clue anyway why MSVC even warns, integer to integer conversions are > allowed. If you still want to get rid of those warnings the fix would be > to change the type of charCode to WCHAR. To correctly unmarshal the > WCHAR out of the WPARAM when passing it to ME_Char() use LOWORD(). good point, that sounds like a more appropriate solution. I'll see to it when I find the time. Thanks. -Tom

Oct. 24, 2011

Re: riched20: do not return incorrect values from ME_CharFromPoint[Cursor]

by Alexandre Julliard

Thomas Faber <thfabba(a)gmx.de> writes: > Windows's version of GetTextExtentExPointW, which is called in that function, > returns a value of 1 in this case (Wine's does not, which would appear to be > a bug), leading to the "i<len" assertion failure if there is no text in the > control. > The patch fixes riched20 to correctly handle either behavior by > adding a fast path for cx <= 0 (the function obviously needs to return 0 in > the cx == 0 case too, so it can skip the calculation). You should not be adding workarounds for Wine bugs, the bugs need to be fixed instead. -- Alexandre Julliard julliard(a)winehq.org

Oct. 24, 2011

Re: [PATCH 4/5] wined3d: Refuse to create a D3D10 wined3d device if it is not supported by the GPU.

by Henri Verbeet

On 24 October 2011 18:58, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (wined3d->dxVersion >= 10 && (shader_caps.VertexShaderVersion < WINED3DVS_VERSION(4,0) > + || shader_caps.PixelShaderVersion < WINED3DPS_VERSION(4,0))) This should probably be handled in dxgi_device_init().

Oct. 24, 2011

Re: [PATCH 2/5] d3d9: Limit VS/PS reported version.

by Henri Verbeet

On 24 October 2011 18:58, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (pCaps->VertexShaderVersion > D3DVS_VERSION(3,0)) > + pCaps->VertexShaderVersion = D3DVS_VERSION(3,0); > + if (pCaps->PixelShaderVersion > D3DPS_VERSION(3,0)) > + pCaps->PixelShaderVersion = D3DPS_VERSION(3,0); > + This should probably go into filter_caps().

Oct. 24, 2011

Re: [PATCH 1/5] d3d8: Limit VS/PS reported version.

by Henri Verbeet

On 24 October 2011 18:58, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (pCaps->VertexShaderVersion > D3DVS_VERSION(1,1)) > + pCaps->VertexShaderVersion = D3DVS_VERSION(1,1); > + if (pCaps->PixelShaderVersion > D3DPS_VERSION(1,4)) > + pCaps->PixelShaderVersion = D3DPS_VERSION(1,4); > + fixup_caps() should already do this.

Oct. 24, 2011

Re: [PATCH 5/7] msxml3: Make positions returned by ISAXLocator compatible with msxml6

by Nikolay Sivov

On 10/24/2011 14:55, Piotr Caban wrote: > --- > dlls/msxml3/factory.c | 8 ++++- > dlls/msxml3/msxml_private.h | 1 + > dlls/msxml3/saxreader.c | 62 > +++++++++++++++++++++++++++++++++++++++--- > 3 files changed, 64 insertions(+), 7 deletions(-) > > > > static ClassFactory saxreadcf = { {&ClassFactoryVtbl }, SAXXMLReader_create }; > +static ClassFactory saxread6cf = { {&ClassFactoryVtbl }, SAXXMLReader6_create }; > static ClassFactory httpreqcf = { {&ClassFactoryVtbl }, XMLHTTPRequest_create }; Such version dependent behaviour is handled currently with additional argument of MSXML_VERSION enum type. It's better to do it the same way in SAX too, to be consistent.

Oct. 24, 2011

Re: [1/2] d3dx9: Implemented non-equal declaration support in CloneMesh.

by Matteo Bruni

2011/10/24 Michael Mc Donnell <michael(a)mcdonnell.dk>: > On Mon, Oct 24, 2011 at 9:13 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> Hi Michael, >> >> + for (i = 0; declaration1[i].Stream != 0xff; i++) >> + { >> + if (memcmp(&declaration1[i], &declaration2[i], sizeof(*declaration1))) >> >> Doesn't that loop need to stop at the first end marker of either >> declaration? I.e. may the first vertex declaration be longer than the >> second one? > > The first vertex declaration may be longer than the second one, e.g. > to make room for more vertex attributes. The loop actually still > breaks if the second declaration is shorter because it will have an > end marker and the first one doesn't. > > I must admit it is difficult to read. I guess It would be easier to > read the code if it first finds the size of each declaration and does > a full memcmp if they're equal: > > static BOOL declaration_equals(CONST D3DVERTEXELEMENT9 *declaration1, > CONST D3DVERTEXELEMENT9 *declaration2) > { > UINT size1, size2; > > /* Find the size of each declaration */ > for (size1 = 0; declaration1[size1].Stream != 0xff; size1++); > > for (size2 = 0; declaration2[size2].Stream != 0xff; size2++); > > /* If not same size then they are definately not equal */ > if (size1 != size2) > return FALSE; > > /* Check that all components are the same */ > if (memcmp(declaration1, declaration2, size1*sizeof(*declaration1)) == 0) > return TRUE; > > return FALSE; > } > > I'll update the patch and send it again. > You're right, sorry for the noise. I see that you have already resent the patches, that's fine anyway.

Oct. 24, 2011

Re: [1/2] d3dx9: Implemented non-equal declaration support in CloneMesh.

by Michael Mc Donnell

On Mon, Oct 24, 2011 at 9:13 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Hi Michael, > > + for (i = 0; declaration1[i].Stream != 0xff; i++) > + { > + if (memcmp(&declaration1[i], &declaration2[i], sizeof(*declaration1))) > > Doesn't that loop need to stop at the first end marker of either > declaration? I.e. may the first vertex declaration be longer than the > second one? The first vertex declaration may be longer than the second one, e.g. to make room for more vertex attributes. The loop actually still breaks if the second declaration is shorter because it will have an end marker and the first one doesn't. I must admit it is difficult to read. I guess It would be easier to read the code if it first finds the size of each declaration and does a full memcmp if they're equal: static BOOL declaration_equals(CONST D3DVERTEXELEMENT9 *declaration1, CONST D3DVERTEXELEMENT9 *declaration2) { UINT size1, size2; /* Find the size of each declaration */ for (size1 = 0; declaration1[size1].Stream != 0xff; size1++); for (size2 = 0; declaration2[size2].Stream != 0xff; size2++); /* If not same size then they are definately not equal */ if (size1 != size2) return FALSE; /* Check that all components are the same */ if (memcmp(declaration1, declaration2, size1*sizeof(*declaration1)) == 0) return TRUE; return FALSE; } I'll update the patch and send it again.

Oct. 24, 2011

Re: winealsa: 6 Channel Audio

by Andrew Eikum

On Mon, Oct 24, 2011 at 06:26:18AM -0700, Chris Robinson wrote: > On Monday, October 24, 2011 8:08:58 AM Andrew Eikum wrote: > > On Sun, Oct 23, 2011 at 05:57:04PM -0700, Chris Robinson wrote: > > > A configuration option (in > > > winecfg/control panel) would be needed to set it into a different mode. > > > Windows has something similar to this for its own audio device > > > configuration in the control panel. > > My reaction to this is "urrrrrrrghhhhhhh". I'd much rather tuck it > > away in a registry entry than put it in winecfg for everyone to mess > > with. I was surprised to see that option on my Win 7 VM, although the > > control is actually inactive. > > Personally, I don't think users should be asked to manually edit the registry > to enable 4-channel or 5.1 surround sound, to select 48khz playback, or to > enable 24- or 32-bit output. They're not uncommon settings, so many people may > want to use it, but not common enough to make them default. A control panel > applet would also provide a nice place to test the separate channels to make > sure they're mapping correctly. > To be frank, what I want to avoid is giving users a ton of options with which to screw up their audio config, promptly forget about changing those settings, and then having to sort out their bug reports ("Can you set this to X and that to Y and get yet another log, please?"). Tucking stuff away in the registry makes it a pain to screw up their config, which means they'll probably turn to submitting bug reports with the default config first, which is exactly what I want. There are other problems with overriding GetMixFormat(). For example, it should really be a per-device (and therefore per-backend) setting. Can you imagine the dialog for that? What I really want, and what I tried to do when making the drivers, is GetMixFormat() to report the format that most accurately represents the device. I want the format reported by GetMixFormat() to require as near to no resampling, no channel remapping, and no bit depth changes as possible on its path from the application to the hardware. Then IsFormatSupported() and Initialize() will deal with conversions, if need be. Unfortunately, it seems very difficult to get this information out of most of the backends, which is why we have this "10000 channels" nonsense. I'm unsure what the best solution to this problem is. I'm open to suggestions. Andrew

Oct. 24, 2011

Re: Patch resend etiquette

by Erich Hoover

2011/10/23 Frédéric Delanoy <frederic.delanoy(a)gmail.com> > > On Sat, Oct 22, 2011 at 19:49, Austin English <austinenglish(a)gmail.com> wrote: > > On Sat, Oct 22, 2011 at 10:48, Erich Hoover <ehoover(a)mines.edu> wrote: > >> How long should one wait to resend patches marked as "New" on the > >> patch list? It seems that once they've gone "far enough" down on the > >> list that there's no chance they'll be looked at. Thanks in advance > >> for your advice. > > > > As with a lot of things in Wine, there is no hard rule, but on irc > > it's been mentioned a few times to wait until the patch falls off of > > the list. > > > http://wiki.winehq.org/SubmittingPatches says > "If your patch isn't committed in a day or two, improve it (perhaps by > adding more tests) and resend, or ask on IRC/wine-devel for > suggestions." > ... I believe that that comment is from before the patch tracker became available. It doesn't look like there's even a link on that page to the tracker... It seems like that page should probably be updated with a link to the tracker and a comment about waiting for the patch to fall off the list. Erich Hoover ehoover(a)mines.edu

Oct. 24, 2011

Re: winealsa: 6 Channel Audio

by Chris Robinson

On Monday, October 24, 2011 8:08:58 AM Andrew Eikum wrote: > On Sun, Oct 23, 2011 at 05:57:04PM -0700, Chris Robinson wrote: > > A configuration option (in > > winecfg/control panel) would be needed to set it into a different mode. > > Windows has something similar to this for its own audio device > > configuration in the control panel. > My reaction to this is "urrrrrrrghhhhhhh". I'd much rather tuck it > away in a registry entry than put it in winecfg for everyone to mess > with. I was surprised to see that option on my Win 7 VM, although the > control is actually inactive. Personally, I don't think users should be asked to manually edit the registry to enable 4-channel or 5.1 surround sound, to select 48khz playback, or to enable 24- or 32-bit output. They're not uncommon settings, so many people may want to use it, but not common enough to make them default. A control panel applet would also provide a nice place to test the separate channels to make sure they're mapping correctly.

Oct. 24, 2011

Re: [1/2] d3dx9: Implemented non-equal declaration support in CloneMesh.

by Matteo Bruni

Hi Michael, + for (i = 0; declaration1[i].Stream != 0xff; i++) + { + if (memcmp(&declaration1[i], &declaration2[i], sizeof(*declaration1))) Doesn't that loop need to stop at the first end marker of either declaration? I.e. may the first vertex declaration be longer than the second one?

Oct. 24, 2011

Re: winealsa: 6 Channel Audio

by Andrew Eikum

On Sun, Oct 23, 2011 at 05:57:04PM -0700, Chris Robinson wrote: > On Sunday, October 23, 2011 8:28:45 PM Jonathan McCrohan wrote: > > Would someone with a better knowledge of Wine and/or ALSA be able to > > assist me in tracking down the source of this bug? > > Part of the problem is the way Wine attempts to "detect" a default format from > ALSA. ALSA doesn't report a default format, though, so Wine attempts to see > what it's capable of and reports that instead. Apparently ALSA is capable of > handling up to 10,000 channels, and Wine has no idea how to report that back > to the Windows app. > > IMO, the "fix" would be to make winealsa default to something sane, like > 44.1khz 16-bit stereo. > I agree, this is a better solution than trying to detect it from the backends. Looking at >2-channel audio setups is near the top of my TODO list; Scott Ritchie even asked me about it at WineConf this year. Reworking GetMixFormat() is probably going to be part of that. Jonathan: If you are confident with the ALSA API, I would be happy to review a patch that does this and/or fixes multichannel audio. If you aren't confident with ALSA and value your sanity, I would suggest you stay far, far away :) > A configuration option (in winecfg/control panel) would > be needed to set it into a different mode. Windows has something similar to > this for its own audio device configuration in the control panel. > My reaction to this is "urrrrrrrghhhhhhh". I'd much rather tuck it away in a registry entry than put it in winecfg for everyone to mess with. I was surprised to see that option on my Win 7 VM, although the control is actually inactive. > But, there's an additional complication. The order Windows expects for >4 > channels is different than what ALSA provides. For example, ALSA places the > front-center/lfe channels after the rear-left/right, while Windows places them > after front-left/right. So either Wine will need to tell ALSA to expect a > different order (I'm not sure if you can in an easy way), or Wine will have to > reorder the samples itself before writing to the device. > Yeah, remapping the channels in winealsa.drv is probably the solution, unfortunately. I'll know more once I start investigating the various backends' multichannel support. Andrew

Oct. 24, 2011

Re: vbscript: Fixed local variable count calculation

by Marvin

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=15088 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Oct. 24, 2011

Re: winealsa: 6 Channel Audio

by Chris Robinson

On Sunday, October 23, 2011 8:28:45 PM Jonathan McCrohan wrote: > Would someone with a better knowledge of Wine and/or ALSA be able to > assist me in tracking down the source of this bug? Hi. Part of the problem is the way Wine attempts to "detect" a default format from ALSA. ALSA doesn't report a default format, though, so Wine attempts to see what it's capable of and reports that instead. Apparently ALSA is capable of handling up to 10,000 channels, and Wine has no idea how to report that back to the Windows app. IMO, the "fix" would be to make winealsa default to something sane, like 44.1khz 16-bit stereo. A configuration option (in winecfg/control panel) would be needed to set it into a different mode. Windows has something similar to this for its own audio device configuration in the control panel. But, there's an additional complication. The order Windows expects for >4 channels is different than what ALSA provides. For example, ALSA places the front-center/lfe channels after the rear-left/right, while Windows places them after front-left/right. So either Wine will need to tell ALSA to expect a different order (I'm not sure if you can in an easy way), or Wine will have to reorder the samples itself before writing to the device.

Oct. 23, 2011

Re: winmm: Avoid casting return value of Heap(Re)Alloc calls.

by Dan Kegel

On Sun, Oct 23, 2011 at 3:18 PM, Austin English <austinenglish(a)gmail.com> wrote: > This has come up a few times before, and it's already been discussed, > -Werror will not go in by default. Well, yes, several times, but I wasn't sure if that was a "never under any circumstances", or if the objections could be picked off one by one. Evidently it's the former. But that's ok, that's what buildbot is for, and there aren't that many new wine developers stubbing their toes on this at any one time.

Oct. 23, 2011

Re: winmm: Avoid casting return value of Heap(Re)Alloc calls.

by Austin English

On Sun, Oct 23, 2011 at 08:43, Dan Kegel <dank(a)kegel.com> wrote: > Debugged version: > > --- a/configure.ac > +++ b/configure.ac > @@ -1715,6 +1715,20 @@ then > if test "x$enable_maintainer_mode" = "xyes" > then > WINE_TRY_CFLAGS([-Werror]) > + else > + dnl Enable -Werror when building from git on 32 bit x86 with a > known good version of gcc > + case $host_cpu in > + *i[[3456789]]86*) > + if test "x${GCC}" = "xyes" && test -d $srcdir/.git > + then > + gcc_version=`$CC -v 2>&1 | grep "gcc version" | sed 's/gcc > version //'` > + case $gcc_version in > + 4.[[3456]].*) > + WINE_TRY_CFLAGS([-Werror]) ;; > + esac > + fi > + ;; > + esac > fi > > dnl Check for ms_hook_prologue support > This has come up a few times before, and it's already been discussed, -Werror will not go in by default. -- -Austin

Oct. 23, 2011

Re: riched20: explicitly cast WPARAM to character types

by David Laight

On Sun, Oct 23, 2011 at 09:25:26PM +0200, Michael Stefaniuc wrote: > > No clue anyway why MSVC even warns, integer to integer conversions are > allowed. ... Generally better to turn off MSVC's over-pedantic warnings about integer conversions. Using casts for integer convertions can actually hide other issues (like accidentally casting a pointer type). David -- David Laight: david(a)l8s.co.uk

Oct. 23, 2011

winealsa: 6 Channel Audio

by Jonathan McCrohan

Hi, Using foobar2000 (Wine 1.3.31) to output 6 channel audio via WASAPI, I get an error in foobar2000, and the following Wine errors in the terminal: fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels However, when using a patched version of Wine with hardcoded support for 6 channel audio, foobar2000 6 channel audio works correctly (patch attached). While this works, it is just a hack and doesn't fix the underlying issue; the additional 9,994 audio channels. This also merely just changes the error message from 2s channel to 6 channels: fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 6 channels Would someone with a better knowledge of Wine and/or ALSA be able to assist me in tracking down the source of this bug? Thanks, Jonathan

Oct. 23, 2011

Re: riched20: explicitly cast WPARAM to character types

by Michael Stefaniuc

On 10/22/2011 10:38 PM, Thomas Faber wrote: > This makes the use of casts more consistent and shows the conversion > from WPARAM to CHAR/WCHAR is intentional for WM_CHAR/EM_SETPASSWORDCHAR. > Also fixes two MSVC warnings. To make it consistent remove the WCHAR cast 3 lines above. Casts are *not* there to show a conversion is intentional. They tell the compiler to STFU and to the human reader they mean "*WARNING* doing something odd here". So don't cry wolf when there's no wolf in sight. No clue anyway why MSVC even warns, integer to integer conversions are allowed. If you still want to get rid of those warnings the fix would be to change the type of charCode to WCHAR. To correctly unmarshal the WCHAR out of the WPARAM when passing it to ME_Char() use LOWORD(). bye michael

Oct. 23, 2011

Re: winmm: Avoid casting return value of Heap(Re)Alloc calls.

by Michael Stefaniuc

On 10/23/2011 02:41 PM, Dan Kegel wrote: > 2011/10/22 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: >> OK thx. Should probably restructure that section as well (and add >> -Werror to my CFLAGS) > > How would people feel if configure turned on -Werror > when it's safe to if building from git? Something like this: This isn't safe at all. The quality of the gcc's and libraries used vary. And newer gcc tend to add additional warnings, e.g. there are still warnings with gcc-4.6. What helps is to pass "-s" to make to suppress the normal make output. That way it is waaay easier to see warnings/errors. $ git am /tmp/winmm\:\ Avoid\ casting\ return\ value\ of\ Heap$Re$Alloc\ calls..eml $ make -j4 -s dlls/winmm/lolvldrv.c: In function ‘MMDRV_InitPerType’: dlls/winmm/lolvldrv.c:406:13: warning: pointer of type ‘void *’ used in arithmetic [-Wpointer-arith] dlls/winmm/lolvldrv.c:411:13: warning: pointer of type ‘void *’ used in arithmetic [-Wpointer-arith] Wine build complete. The normal make output is too noisy to be useful. bye michael > > --- a/configure.ac > +++ b/configure.ac > @@ -1715,6 +1715,16 @@ then > if test "x$enable_maintainer_mode" = "xyes" > then > WINE_TRY_CFLAGS([-Werror]) > + else > + dnl Enable -Werror when building from git on 32 bit x86 with gcc > + case $host_cpu in > + *i[[3456789]]86*) > + if test "x${GCC}" = "xyes" && test -d $srcdir/.git > + then > + WINE_TRY_CFLAGS([-Werror]) > + fi > + ;; > + esac > fi > > dnl Check for ms_hook_prologue support

Oct. 23, 2011

Re: [3/6] dinput: SetActionMap saving simple configurations to an .ini file

by Vitaliy Margolen

Few nit picks. On 10/22/2011 02:53 PM, Lucas Fialho Zawacki wrote: > +static void _write_private_profile_intW(const char *format, WCHAR* section, WCHAR* key, int value, WCHAR* file) > +{ > + WCHAR* value_str = heap_printfW(format, value); Here and everywhere else you not checking if memory allocation succeeded. > + WCHAR path[] = { > + '%','C','o','m','m','o','n','P','r','o','g','r','a','m','F','i','l','e','s','%','\\', > + 'D','i','r','e','c','t','X','\\', > + 'D','i','r','e','c','t','I','n','p','u','t','\\', > + 'U','s','e','r',' ','M','a','p','s','\0'}; Missing static const qualifiers. Also the above directory does not exists and you not explicitly creating it. > + guid_strA = debugstr_guid(&lpdiaf->guidActionMap); > + guid_size = MultiByteToWideChar(CP_ACP, 0, guid_strA, -1, NULL, 0); I'm not sure debug function is ok to be used in the regular code. Also, if need it as unicode why not print it as unicode from the beginning? > + IDirectInputDevice_GetDeviceInfo(&This->IDirectInputDevice8W_iface, &didevi); You should use IDirectInputDevice8W_from_impl() function instead of directly accessing internals. > + memcpy(username, find_data.cFileName, (end - find_data.cFileName + 1) * sizeof(WCHAR)); No checking for big enough buffer. Assuming that file names are in specified format. Also I'm not exactly sure why do you need a mapping user name anyway? Wine does not support multiple users. The user currently running Wine would be the one created all the files. All this seems to be redundant. Vitaliy.

Oct. 23, 2011

Re: Compilation error when cross-compiling Wine to ARM.

by Alexandre Julliard

Roger Cruz <roger_r_cruz(a)yahoo.com> writes: > I'm attempting to cross-compile Wine for ARM and during the > compilation of the first file, I get the following error about some > strings.h routines not being portable. I have tracked this down to > the redefinitions for these routines in include/port.h. Probably you should include stdlib.h from port.h. -- Alexandre Julliard julliard(a)winehq.org

Oct. 23, 2011

Re: Compilation error when cross-compiling Wine to ARM.

by Roger Cruz

Yes, exactly. So far so good with their toolchain except for this redefinition of routines. It looks like it needs some architecture specific implementations of these routines. Thanks Roger R. Cruz On Oct 23, 2011, at 12:07 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > Am 22.10.2011 20:07, schrieb Roger Cruz: >> I'm attempting to cross-compile Wine for ARM and during the compilation of the first file, I get the following error about some strings.h routines not being portable. I have tracked this down to the redefinitions for these routines in include/port.h. >> >> How do I get around this issue? Is there a certain #define that needs to be enabled to allow me to use the native strings.h without redefinition (namely this #define NO_LIBWINE_PORT). What is the purpose of having these redefined? Any insight would be most welcome. >> >> gcc -c -I/home/rcruz/sandbox/dev-branch/tools -I. -I/home/rcruz/sandbox/dev-branch/include -I../include -D__WINESRC__ -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o makedep.o /home/rcruz/sandbox/dev-branch/tools/makedep.c >> In file included from /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/stdlib.h:42, >> from /home/rcruz/sandbox/dev-branch/tools/makedep.c:29: >> /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/strings.h:49: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ffs_is_not_portable' >> /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/strings.h:52: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'strcasecmp_is_not_portable' >> /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/strings.h:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'strncasecmp_is_not_portable' >> > > After some discussion last month i'd guess you are trying to crosscompile wine to android. > In this special case the toolchain is a bit weird and you need to comment these 3 files out of the crosscompilers strings.h > I'll send you some more hacks i made in private. > > > -- > > Best Regards, André Hentschel > >

Oct. 23, 2011

Re: riched20: do not return incorrect values from ME_CharFromPoint[Cursor]

by Thomas Faber

Hi, On 2011-10-22 22:45, Thomas Faber wrote: > Windows's version of GetTextExtentExPointW, which is called in that function, > returns a value of 1 in this case (Wine's does not, which would appear to be > a bug), leading to the "i<len" assertion failure if there is no text in the > control. this description isn't 100% complete (the fix is correct nonetheless). With the help of the corresponding gdi32 tests [1], I can describe it better: The nAvailWidth in a zero-width richedit control will be -2 (as borders are subtracted by the format rect, resulting in an invalid rect, as previously demonstrated), which will be passed as max_extent to GetTextExtentExPointW. Wine's version would return 0 as expected, while Windows's would interpret this as a large unsigned number and return the length of the text (1 in my test case, mIRC). This eventually led to the i<len assertion failing, as i was set to len exactly. I hope this clears up any doubts. Wine's riched20 now works nicely as a replacement for its counterpart. :) Best regards and have a nice Sunday. Tom [1] http://www.winehq.org/pipermail/wine-patches/2011-October/108186.html

Oct. 23, 2011

Re: Compilation error when cross-compiling Wine to ARM.

by André Hentschel

Am 22.10.2011 20:07, schrieb Roger Cruz: > I'm attempting to cross-compile Wine for ARM and during the compilation of the first file, I get the following error about some strings.h routines not being portable. I have tracked this down to the redefinitions for these routines in include/port.h. > > How do I get around this issue? Is there a certain #define that needs to be enabled to allow me to use the native strings.h without redefinition (namely this #define NO_LIBWINE_PORT). What is the purpose of having these redefined? Any insight would be most welcome. > > gcc -c -I/home/rcruz/sandbox/dev-branch/tools -I. -I/home/rcruz/sandbox/dev-branch/include -I../include -D__WINESRC__ -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o makedep.o /home/rcruz/sandbox/dev-branch/tools/makedep.c > In file included from /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/stdlib.h:42, > from /home/rcruz/sandbox/dev-branch/tools/makedep.c:29: > /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/strings.h:49: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ffs_is_not_portable' > /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/strings.h:52: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'strcasecmp_is_not_portable' > /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/strings.h:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'strncasecmp_is_not_portable' > After some discussion last month i'd guess you are trying to crosscompile wine to android. In this special case the toolchain is a bit weird and you need to comment these 3 files out of the crosscompilers strings.h I'll send you some more hacks i made in private. -- Best Regards, André Hentschel

Oct. 23, 2011

Re: winmm: Avoid casting return value of Heap(Re)Alloc calls.

by Dan Kegel

Debugged version: --- a/configure.ac +++ b/configure.ac @@ -1715,6 +1715,20 @@ then if test "x$enable_maintainer_mode" = "xyes" then WINE_TRY_CFLAGS([-Werror]) + else + dnl Enable -Werror when building from git on 32 bit x86 with a known good version of gcc + case $host_cpu in + *i[[3456789]]86*) + if test "x${GCC}" = "xyes" && test -d $srcdir/.git + then + gcc_version=`$CC -v 2>&1 | grep "gcc version" | sed 's/gcc version //'` + case $gcc_version in + 4.[[3456]].*) + WINE_TRY_CFLAGS([-Werror]) ;; + esac + fi + ;; + esac fi dnl Check for ms_hook_prologue support

Oct. 23, 2011

Re: winmm: Avoid casting return value of Heap(Re)Alloc calls.

by Dan Kegel

2011/10/23 Jerome Leclanche <adys.wh(a)gmail.com>: >> How would people feel if configure turned on -Werror >> when it's safe to if building from git? Something like this... > > It's still unsafe, you're limited to a subset of gcc versions. That's not too hard to check for: --- a/configure.ac +++ b/configure.ac @@ -1715,6 +1715,19 @@ then if test "x$enable_maintainer_mode" = "xyes" then WINE_TRY_CFLAGS([-Werror]) + else + dnl Enable -Werror when building from git on 32 bit x86 with a known good version of gcc + case $host_cpu in + *i[[3456789]]86*) + if test "x${GCC}" = "xyes" && test -d $srcdir/.git + then + case `$(CC) -v 2>&1 | grep "gcc version" | sed 's/gcc version //' ` in + 4.[3456].*) + WINE_TRY_CFLAGS([-Werror]) ;; + esac + fi + ;; + esac fi dnl Check for ms_hook_prologue support > Not worth it. In which sense? Is it too hard to make it safe? If it safely cuts down on the number of times people have to resubmit patches, why not do it? - Dan

Oct. 23, 2011

Re: winmm: Avoid casting return value of Heap(Re)Alloc calls.

by Jerome Leclanche

2011/10/23 Dan Kegel <dank(a)kegel.com>: > 2011/10/22 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: >> OK thx. Should probably restructure that section as well (and add >> -Werror to my CFLAGS) > > How would people feel if configure turned on -Werror > when it's safe to if building from git? Something like this: > > --- a/configure.ac > +++ b/configure.ac > @@ -1715,6 +1715,16 @@ then > if test "x$enable_maintainer_mode" = "xyes" > then > WINE_TRY_CFLAGS([-Werror]) > + else > + dnl Enable -Werror when building from git on 32 bit x86 with gcc > + case $host_cpu in > + *i[[3456789]]86*) > + if test "x${GCC}" = "xyes" && test -d $srcdir/.git > + then > + WINE_TRY_CFLAGS([-Werror]) > + fi > + ;; > + esac > fi > > dnl Check for ms_hook_prologue support It's still unsafe, you're limited to a subset of gcc versions. Not worth it. JL

Oct. 23, 2011

Re: winmm: Avoid casting return value of Heap(Re)Alloc calls.

by Dan Kegel

2011/10/22 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > OK thx. Should probably restructure that section as well (and add > -Werror to my CFLAGS) How would people feel if configure turned on -Werror when it's safe to if building from git? Something like this: --- a/configure.ac +++ b/configure.ac @@ -1715,6 +1715,16 @@ then if test "x$enable_maintainer_mode" = "xyes" then WINE_TRY_CFLAGS([-Werror]) + else + dnl Enable -Werror when building from git on 32 bit x86 with gcc + case $host_cpu in + *i[[3456789]]86*) + if test "x${GCC}" = "xyes" && test -d $srcdir/.git + then + WINE_TRY_CFLAGS([-Werror]) + fi + ;; + esac fi dnl Check for ms_hook_prologue support

Oct. 23, 2011

Re: Patch resend etiquette

by Frédéric Delanoy

On Sat, Oct 22, 2011 at 19:49, Austin English <austinenglish(a)gmail.com> wrote: > On Sat, Oct 22, 2011 at 10:48, Erich Hoover <ehoover(a)mines.edu> wrote: >> How long should one wait to resend patches marked as "New" on the >> patch list? It seems that once they've gone "far enough" down on the >> list that there's no chance they'll be looked at. Thanks in advance >> for your advice. > > As with a lot of things in Wine, there is no hard rule, but on irc > it's been mentioned a few times to wait until the patch falls off of > the list. > http://wiki.winehq.org/SubmittingPatches says "If your patch isn't committed in a day or two, improve it (perhaps by adding more tests) and resend, or ask on IRC/wine-devel for suggestions." Might it be useful to add sthg like "If some other external changes would make your patch unapplicable, you may rebase/resend it with (resend) appended to the subject line"? Or should that be (try N+1) with (try N+1: rebase) comment in the "extended" patch subject?

Oct. 23, 2011

Re: winmm: Avoid casting return value of Heap(Re)Alloc calls.

by Frédéric Delanoy

2011/10/22 Dan Kegel <dank(a)kegel.com>: > Doesn't build here: > > ccache gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ > -D_WINMM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes > -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings > -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op > -I/usr/include/freetype2 -g -O0 -Werror -Wno-unused-but-set-variable > -Wno-unused-but-set-parameter -o lolvldrv.o lolvldrv.c > lolvldrv.c: In function 'MMDRV_InitPerType': > lolvldrv.c:406:13: error: pointer of type 'void *' used in arithmetic > [-Werror=pointer-arith] > lolvldrv.c:411:13: error: pointer of type 'void *' used in arithmetic > [-Werror=pointer-arith] > cc1: all warnings being treated as errors > make[1]: Leaving directory > `/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/winmm' > make[1]: *** [lolvldrv.o] Error 1 > make: *** [dlls/winmm] Error 2 Right. OK thx. Should probably restructure that section as well (and add -Werror to my CFLAGS)

Oct. 23, 2011

Re: 80245: riched20/tests: test format rect adaption to window size and behavior with zero-sized windows

by Thomas Faber

On 2011-10-23 00:10, Dan Kegel wrote: > Fails to build here... > On Oct 22, 2011 1:48 PM, <buildbot(a)kegel.com> wrote: > editor.c:6369:5: error: passing argument 4 of 'SendMessageA' makes integer > from pointer without a cast [-Werror] Dangit. And I thought running on testbot would ensure I didn't forget anything. Heh. *activates -Werror in his working copy* Thanks, Dan! Regards, Tom

Oct. 22, 2011

Re: 80245: riched20/tests: test format rect adaption to window size and behavior with zero-sized windows

by Dan Kegel

Fails to build here... On Oct 22, 2011 1:48 PM, <buildbot(a)kegel.com> wrote: This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. For more info about this message, see http://wiki.winehq.org/BuildBot The Buildbot has detected a failed build on builder runtests-default while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/898 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed shell_2 Errors: editor.c: In function 'test_format_rect': editor.c:6369:5: error: passing argument 4 of 'SendMessageA' makes integer from pointer without a cast [-Werror] make[1]: *** [editor.o] Error 1 make: *** [dlls/riched20/tests] Error 2 make: *** Waiting for unfinished jobs.... _______________________________________________ wine-tests-results mailing list wine-tests-results(a)winehq.org http://www.winehq.org/mailman/listinfo/wine-tests-results

Oct. 22, 2011

Compilation error when cross-compiling Wine to ARM.

by Roger Cruz

I'm attempting to cross-compile Wine for ARM and during the compilation of the first file, I get the following error about some strings.h routines not being portable. I have tracked this down to the redefinitions for these routines in include/port.h. How do I get around this issue? Is there a certain #define that needs to be enabled to allow me to use the native strings.h without redefinition (namely this #define NO_LIBWINE_PORT). What is the purpose of having these redefined? Any insight would be most welcome. gcc -c -I/home/rcruz/sandbox/dev-branch/tools -I. -I/home/rcruz/sandbox/dev-branch/include -I../include -D__WINESRC__ -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o makedep.o /home/rcruz/sandbox/dev-branch/tools/makedep.c In file included from /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/stdlib.h:42, from /home/rcruz/sandbox/dev-branch/tools/makedep.c:29: /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/strings.h:49: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ffs_is_not_portable' /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/strings.h:52: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'strcasecmp_is_not_portable' /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/strings.h:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'strncasecmp_is_not_portable' Regards, Roger R. Cruz

Oct. 22, 2011