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

Re: [PATCH 2/5] wined3d: Create the DIB section for DDSCAPS_OWNDC surfaces on initialization.

by Stefan Dösinger

On Monday 31 October 2011 21:06:09 Henri Verbeet wrote: > Probably in general. The way GetDC is supposed to work is probably by > asking the graphics driver to create a DC on top of the existing > memory or texture, instead of the DIB section hacks we do in wined3d. In the days of the old ddraw code we used to have a Wine-specific export in gdi32 that did that, but I don't think adding that back 1:1 is a good solution. We could allocate surface memory in ddraw and copy between that and the memory wined3d's map() returns for some or all surfaces. This would deal with cases where an app(Some Windows Media Player 9 visualization plugins specifically) use SetSurfaceDesc to set lpSurface and then call GetDC, and we could get rid of SFLAG_USERPTR in wined3d. It would also be more reliable for the backbuffer than hoping the memory returned by glMapBuffer remains valid. Alternatively we could make the dibsection a separate location, but that wouldn't deal with apps that want the backbuffer memory to stay the same. > and since > OWNDC implies the application wants to keep the DC around anyway, we > might as well set it up at surface initialization. This is probably correct, but do you have docs for OWNDC, besides of the name and very short description in msdn/sdk? I don't think IE8 sets OWNDC here, this is most likely our ddrawex.dll. And the main reason I've set it there is because it kinda-sorta sounds like what the ddrawex DDSCAPS_VIDEOMEMORY | DDSCAPS_SYSTEMMEM hack is doing, not because I had any in-depth information what OWNDC does, so I'd be wary about reading too much into it.

Oct. 31, 2011

Re: [4/4] wined3d: YUY2 and UYVY are block based

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=15193 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Oct. 31, 2011

Re: [3/4] d3d9/tests: Test partial block locks

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=15192 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Oct. 31, 2011

Re: ddraw/tests: Move some surface attachment tests from refcount to dsurface and enhance them.

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=15183 Your paranoid android. === W2KPROSP4 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === WXPPROSP3 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W2K3R2SESP2 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === WVISTAADM (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W2K8SE (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W7PRO (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W7PROX64 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === TEST64_W7SP1 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W7PROX64 (64 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === TEST64_W7SP1 (64 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a

Oct. 31, 2011

Re: [3/4] d3d9/tests: Test partial block locks

by Henri Verbeet

On 31 October 2011 20:03, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + case D3DPOOL_SCRATCH: > + case D3DPOOL_SYSTEMMEM: > + hr = IDirect3DDevice9_CreateOffscreenPlainSurface(device, 128, 128, formats[i].fmt, > + D3DPOOL_SCRATCH, &surface, 0); That doesn't really test D3DPOOL_SYSTEMMEM.

Oct. 31, 2011

Re: [4/4] wined3d: YUY2 and UYVY are block based

by Henri Verbeet

On 31 October 2011 20:17, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > {WINED3DFMT_ATI2N, GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI, GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI, 0, > GL_LUMINANCE_ALPHA, GL_UNSIGNED_BYTE, 0, > - WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING | WINED3DFMT_FLAG_FILTERING, > + WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING | WINED3DFMT_FLAG_FILTERING | WINED3DFMT_FLAG_COMPRESSED, > GL_COMPRESSED_RED_GREEN_RGTC2 is also compressed.

Oct. 31, 2011

Re: [PATCH 2/5] wined3d: Create the DIB section for DDSCAPS_OWNDC surfaces on initialization.

by Henri Verbeet

On 31 October 2011 20:38, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > You would get the same effect by calling GetDC and ReleaseDC from ddraw or > ddrawex without another usage flag. Yes, but I don't think that would be an improvement. >> + /* Similar to lockable rendertargets above, creating the DIB section >> + * during surface initialization prevents the sysmem pointer from >> changing + * after a wined3d_surface_getdc() call. */ > Is this a property of DDSCAPS_OWNDC, or sysmem surfaces in general? I'd expect > that this applies to sysmem surfaces in general. Probably in general. The way GetDC is supposed to work is probably by asking the graphics driver to create a DC on top of the existing memory or texture, instead of the DIB section hacks we do in wined3d. However, without much more invasive changes to the way wined3d interacts with winex11 that's just not going to happen, and since OWNDC implies the application wants to keep the DC around anyway, we might as well set it up at surface initialization.

Oct. 31, 2011

Re: [PATCH 2/5] wined3d: Create the DIB section for DDSCAPS_OWNDC surfaces on initialization.

by Stefan Dösinger

On Monday 31 October 2011 19:48:12 Henri Verbeet wrote: > --- > dlls/ddraw/surface.c | 3 +++ > dlls/wined3d/surface.c | 11 +++++++++++ > include/wine/wined3d.h | 1 + > 3 files changed, 15 insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c > index 3860959..567d086 100644 > --- a/dlls/ddraw/surface.c > +++ b/dlls/ddraw/surface.c > @@ -5273,6 +5273,9 @@ HRESULT ddraw_surface_init(IDirectDrawSurfaceImpl > *surface, IDirectDrawImpl *ddr if (desc->ddsCaps.dwCaps & DDSCAPS_ZBUFFER) > usage |= WINED3DUSAGE_DEPTHSTENCIL; > > + if (desc->ddsCaps.dwCaps & DDSCAPS_OWNDC) > + usage |= WINED3DUSAGE_OWNDC; You would get the same effect by calling GetDC and ReleaseDC from ddraw or ddrawex without another usage flag. Probably ddrawex should do that since it sets DDSCAPS_OWNDC, assuming that IE 8 still uses ddrawex. > + /* Similar to lockable rendertargets above, creating the DIB section > + * during surface initialization prevents the sysmem pointer from > changing + * after a wined3d_surface_getdc() call. */ Is this a property of DDSCAPS_OWNDC, or sysmem surfaces in general? I'd expect that this applies to sysmem surfaces in general. Otoh we don't really want to create a DIB section for every sysmem surface, especially with bug 5535 in mind.

Oct. 31, 2011

Re: [PATCH 4/5] wined3d: Make the buffer parameter to buffer_is_dirty() const.

by Henri Verbeet

On 31 October 2011 19:56, Josh Juran <josh(a)iswifter.net> wrote: > Looks like you lost an 'inline'. Was that intentional? > Yes.

Oct. 31, 2011

Re: [PATCH 4/5] wined3d: Make the buffer parameter to buffer_is_dirty() const.

by Josh Juran

On Oct 31, 2011, at 11:48 AM, Henri Verbeet wrote: > --- > dlls/wined3d/buffer.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/wined3d/buffer.c b/dlls/wined3d/buffer.c > index 45518cc..69c110a 100644 > --- a/dlls/wined3d/buffer.c > +++ b/dlls/wined3d/buffer.c > @@ -76,9 +76,9 @@ static inline void buffer_clear_dirty_areas(struct wined3d_buffer *This) > This->modified_areas = 0; > } > > -static inline BOOL buffer_is_dirty(struct wined3d_buffer *This) > +static BOOL buffer_is_dirty(const struct wined3d_buffer *buffer) > { > - return !!This->modified_areas; > + return !!buffer->modified_areas; > } > > static inline BOOL buffer_is_fully_dirty(struct wined3d_buffer *This) > -- Looks like you lost an 'inline'. Was that intentional? Josh

Oct. 31, 2011

Re: 80199: shdocvw: add a stub for InstallReg_RunDLL

by Austin English

On Thu, Oct 20, 2011 at 15:55, Dan Kegel <dank(a)kegel.com> wrote: > Fails to build here? > > On Thu, Oct 20, 2011 at 3:51 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/803 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) >> BUILD FAILED: failed shell_2 >> >> Errors: >> shdocvw_main.c: In function 'InstallReg_RunDLL': >> shdocvw_main.c:547:159: error: format '%p' expects a matching 'void *' argument [-Werror=format] >> shdocvw_main.c:547:159: error: format '%p' expects a matching 'void *' argument [-Werror=format] >> make[1]: *** [shdocvw_main.o] Error 1 >> make: *** [dlls/shdocvw] Error 2 >> make: *** Waiting for unfinished jobs.... Resent, thanks. -- -Austin

Oct. 31, 2011

Re: [PATCH 2/5] ddraw: Implement copy_mipmap_chain() on top of wined3d_surface_blt().

by Henri Verbeet

On 31 October 2011 15:04, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Sunday 30 October 2011 18:06:33 Henri Verbeet wrote: >> + if (FAILED(hr = >> wined3d_surface_blt(dest_level->wined3d_surface, &dst_rect, >> + src_level->wined3d_surface, &src_rect, 0, NULL, >> WINED3DTEXF_POINT))) > Wouldn't wined3d_device_update_surface be a better match? No, the patch actually removes that code.

Oct. 31, 2011

Re: [PATCH 2/5] ddraw: Implement copy_mipmap_chain() on top of wined3d_surface_blt().

by Stefan Dösinger

On Sunday 30 October 2011 18:06:33 Henri Verbeet wrote: > + if (FAILED(hr = > wined3d_surface_blt(dest_level->wined3d_surface, &dst_rect, > + src_level->wined3d_surface, &src_rect, 0, NULL, > WINED3DTEXF_POINT))) Wouldn't wined3d_device_update_surface be a better match? IDirect3DDevice7::Load could probably be handled by wined3d_device_update_texture if it wasn't for color keys/palettes.

Oct. 31, 2011

RFC: Make X11 window rect empty for WS_EX_TRANSPARENT windows

by Octavian Voicu

Hi, Attached patch fixes http://bugs.winehq.org/show_bug.cgi?id=28678. The root problem is that X11 windows cannot be made transparent (allowing other windows to draw over them). My approach I to make the X11 window with WS_EX_TRANSPARENT extended style have an empty region. Obviously, this is very hacky and except for very particular cases (like the bug I'm trying to fix) it won't work at all, so this patch is more like a proof-of-concept than a fix. For example, window decorations aren't drawn and not even the window can paint itself. This becomes kind of a recursive question -- how to draw the contents of the window-less window? Can this approach ever work? Any comments or suggestions are welcome. Octavian

Oct. 30, 2011

d3dx9_36: Simplify the computation of a 2-adic valuation

by David Adam

Hello, please discard this patch. It is logically wrong. David

Oct. 29, 2011

Re: cmd: Avoid mixing signed and unsigned type in conditional expression

by Frédéric Delanoy

2011/10/27 Michael Stefaniuc <mstefani(a)redhat.com>: > On 10/27/2011 02:09 PM, Frédéric Delanoy wrote: >> On Thu, Oct 27, 2011 at 08:38, Eric Pouech <eric.pouech(a)orange.fr> wrote: >>> why do we check for ptr being null or not, when we deref ptr one line above? >> >>>> if (*ptr == '\n') ptr++; >>>> - WCMD_output_asis_len(message, (ptr) ? ptr - message : >>>> strlenW(message), handle); >>>> + WCMD_output_asis_len(message, (ptr) ? (DWORD)(ptr - message) : >>>> strlenW(message), handle); >>>> if (ptr) { >>>> numChars = 0; >>>> if (++line_count >= max_height - 1) { >> >> It's dereferenced but incremented afterwards, so might be null after that line > Only if ptr wraps around ;) Yeah right. Don't know where I saw a * before the ptr in (ptr)...

Oct. 28, 2011

Re: [PATCH 1/2] include: Add a few defines to winscard.h (try 2)

by Bruno Jesus

2011/10/28 André Hentschel <nerv(a)dawncrow.de>: > Am 28.10.2011 19:42, schrieb Bruno Jesus: > ... > btw: if there is no dependencies than you don't need numbered patchsets Agreed. Sorry again. Best wishes, Bruno

Oct. 28, 2011

Re: [PATCH 1/2] include: Add a few defines to winscard.h (try 2)

by André Hentschel

Am 28.10.2011 19:42, schrieb Bruno Jesus: > On Fri, Oct 28, 2011 at 15:01, Alexandre Julliard <julliard(a)winehq.org> wrote: >> Bruno Jesus <00cpxxx(a)gmail.com> writes: >> >>> +/* Max ATR size defined by ISO-7816 */ >>> +#define MAX_ATR_SIZE 33 >> >> I don't see that one in my PSDK, where does it come from? > > My bad, apologies. I copied it from Vincent Hardy patch series but in > fact the variable should be name SCARD_ATR_LENGTH and should be in > winsmcrd.h. I'm still not using these defines yet so if possible I > would like the [2/2] to be commited if no mistakes are found in it, btw: if there is no dependencies than you don't need numbered patchsets -- Best Regards, André Hentschel

Oct. 28, 2011

Re: [PATCH 1/2] include: Add a few defines to winscard.h (try 2)

by Bruno Jesus

On Fri, Oct 28, 2011 at 15:01, Alexandre Julliard <julliard(a)winehq.org> wrote: > Bruno Jesus <00cpxxx(a)gmail.com> writes: > >> +/* Max ATR size defined by ISO-7816 */ >> +#define MAX_ATR_SIZE 33 > > I don't see that one in my PSDK, where does it come from? My bad, apologies. I copied it from Vincent Hardy patch series but in fact the variable should be name SCARD_ATR_LENGTH and should be in winsmcrd.h. I'm still not using these defines yet so if possible I would like the [2/2] to be commited if no mistakes are found in it, I'll resend this one later. Best wishes, Bruno

Oct. 28, 2011

Re: [PATCH 1/2] include: Add a few defines to winscard.h (try 2)

by Alexandre Julliard

Bruno Jesus <00cpxxx(a)gmail.com> writes: > +/* Max ATR size defined by ISO-7816 */ > +#define MAX_ATR_SIZE 33 I don't see that one in my PSDK, where does it come from? -- Alexandre Julliard julliard(a)winehq.org

Oct. 28, 2011

kernel32: Update English resource

by Ken Sharp

I suspect this is the wrong way to update the US English resource for an .mc file. Could anyone comment? Thanks

Oct. 28, 2011

Re: basic_ifstream implementation

by Frédéric Delanoy

On Fri, Oct 28, 2011 at 01:30, Josh Juran <josh(a)iswifter.net> wrote: > I appreciate your (and others') willingness to provide feedback. Unfortunately, my job in this case is to make certain apps work (by hack or by crack) and move on. What you could do is add/update the AppDB entry for this program, and link to your bug (hence patch). Frédéric

Oct. 28, 2011

Re: Antw.: signal_arc.c failing to cross-compile

by Roger Cruz

Thanks Andre, I realize that I'm breaking some new ground here and I don't mind doing the legwork. I just like to first post to make sure someone hasn't already tried this and found a solution before I spend too much time on it. It looks like you have been trying to cross-compile for Android as well. I'm guessing you must have hit this missing header file as well? Regards, Roger R. Cruz On Oct 28, 2011, at 3:05 AM, "André Hentschel" <nerv(a)dawncrow.de> wrote: > Thats not a problem of cross compiling to ARM, but of android. Android is not Linux, not fully. Maybe i can find a solution, but only maybe. BTW all the problems you will find are Android specific. > > Gesendet mit meinem HTC > > ----- Reply message ----- > Von: "Roger Cruz" <roger_r_cruz(a)yahoo.com> > An: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> > Betreff: signal_arc.c failing to cross-compile > Datum: Fr., Okt. 28, 2011 06:46 > > > Hi Andre et al, > > Wondering if any of you know how to get around this? The compiler is barfing at the lack of ucontext_t when doing a typedef of SIGCONTEXT. > > Thanks in advance, > > Roger R. Cruz > > arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/ntdll -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -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 signal_arm.o /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SIGCONTEXT' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: warning: type defaults to 'int' in declaration of 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: error: expected ';', ',' or ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:149: error: expected declaration specifiers or '...' before 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'restore_context': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: 'sigcontext' undeclared (first use in this function) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: (Each undeclared identifier is reported only once > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: for each function it appears in.) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: At top level: > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: warning: type defaults to 'int' in declaration of 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: error: expected ';', ',' or ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: warning: type defaults to 'int' in declaration of 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: error: expected ';', ',' or ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:364: error: expected ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'segv_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'SIGCONTEXT' undeclared (first use in this function) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'context' undeclared (first use in this function) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:545: warning: ISO C90 forbids mixed declarations and code > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:556: warning: implicit declaration of function 'setup_exception_record' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'trap_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:608: warning: implicit declaration of function 'save_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:615: error: too many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'fpe_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:629: warning: implicit declaration of function 'save_fpu' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:683: error: too many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:684: warning: implicit declaration of function 'restore_fpu' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'int_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:708: error: too many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'abrt_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:732: error: too many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'usr1_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:758: error: too many arguments to function 'restore_context' > make[1]: *** [signal_arm.o] Error 1

Oct. 28, 2011

Re: ntdll: Make the VirtualProtect tests pass under Wine. Resend.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Updated to current git. > --- > dlls/kernel32/tests/virtual.c | 16 ---------------- > dlls/ntdll/virtual.c | 3 +++ > 2 files changed, 3 insertions(+), 16 deletions(-) This completely breaks Wine here. There are several places where we use WRITECOPY for protections, they would have to be fixed first. -- Alexandre Julliard julliard(a)winehq.org

Oct. 28, 2011

Re: signal_arc.c failing to cross-compile

by Paul Chitescu

Hi! Android is hopeless, its C library (bionic) is a very trimmed down and bug ridden version of the BSD library. The Android devel team is not willing to fix any bugs unless they affect native Android applications or Dalvik. In particular the .so loader and related initialization is broken. dlopen() doesn't properly call initializers, dlclose() doesn't work at all. Unless a proper C library is installed on the target systems (and a matching cross-toolchain used for compiling) there are no chances wine will run on Android. Many of the libraries required for Wine will not work properly with bionic even if they may compile. Paul On Friday 28 October 2011 07:46:26 am Roger Cruz wrote: > Hi Andre et al, > > Wondering if any of you know how to get around this? The compiler is > barfing at the lack of ucontext_t when doing a typedef of SIGCONTEXT. > > Thanks in advance, > > Roger R. Cruz > > > arm-linux-androideabi-gcc -c > -I/home/rcruz/sandbox/wine-dev-branch/dlls/ntdll -I. > -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include > -D__WINESRC__ -D_NTSYSTEM_ -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 signal_arm.o > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:69: error: > expected '=', ',', ';', 'asm' or '__attribute__' before 'SIGCONTEXT' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: warning: > type defaults to 'int' in declaration of 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: error: > expected ';', ',' or ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:149: error: > expected declaration specifiers or '...' before 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function > 'restore_context': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: > 'sigcontext' undeclared (first use in this function) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: > (Each undeclared identifier is reported only once > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: for > each function it appears in.) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: At top level: > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: warning: > type defaults to 'int' in declaration of 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: error: > expected ';', ',' or ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: warning: > type defaults to 'int' in declaration of 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: error: > expected ';', ',' or ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:364: error: > expected ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function > 'segv_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: > 'SIGCONTEXT' undeclared (first use in this function) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: > 'context' undeclared (first use in this function) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:545: warning: > ISO C90 forbids mixed declarations and code > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:556: warning: > implicit declaration of function 'setup_exception_record' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function > 'trap_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:608: warning: > implicit declaration of function 'save_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:615: error: too > many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function > 'fpe_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:629: warning: > implicit declaration of function 'save_fpu' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:683: error: too > many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:684: warning: > implicit declaration of function 'restore_fpu' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function > 'int_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:708: error: too > many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function > 'abrt_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:732: error: too > many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function > 'usr1_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:758: error: too > many arguments to function 'restore_context' make[1]: *** [signal_arm.o] > Error 1

Oct. 28, 2011

Antw.: signal_arc.c failing to cross-compile

by André Hentschel

Thats not a problem of cross compiling to ARM, but of android. Android is not Linux, not fully. Maybe i can find a solution, but only maybe. BTW all the problems you will find are Android specific. Gesendet mit meinem HTC ----- Reply message ----- Von: "Roger Cruz" <roger_r_cruz(a)yahoo.com> An: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> Betreff: signal_arc.c failing to cross-compile Datum: Fr., Okt. 28, 2011 06:46 Hi Andre et al, Wondering if any of you know how to get around this? The compiler is barfing at the lack of ucontext_t when doing a typedef of SIGCONTEXT. Thanks in advance, Roger R. Cruz arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/ntdll -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -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 signal_arm.o /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SIGCONTEXT' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:149: error: expected declaration specifiers or '...' before 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'restore_context': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: 'sigcontext' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: (Each undeclared identifier is reported only once /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: for each function it appears in.) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: At top level: /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:364: error: expected ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'segv_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'SIGCONTEXT' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'context' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:545: warning: ISO C90 forbids mixed declarations and code /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:556: warning: implicit declaration of function 'setup_exception_record' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'trap_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:608: warning: implicit declaration of function 'save_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:615: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'fpe_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:629: warning: implicit declaration of function 'save_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:683: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:684: warning: implicit declaration of function 'restore_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'int_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:708: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'abrt_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:732: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'usr1_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:758: error: too many arguments to function 'restore_context' make[1]: *** [signal_arm.o] Error 1

Oct. 28, 2011

signal_arc.c failing to cross-compile

by Roger Cruz

Hi Andre et al, Wondering if any of you know how to get around this? The compiler is barfing at the lack of ucontext_t when doing a typedef of SIGCONTEXT. Thanks in advance, Roger R. Cruz arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/ntdll -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -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 signal_arm.o /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SIGCONTEXT' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:149: error: expected declaration specifiers or '...' before 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'restore_context': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: 'sigcontext' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: (Each undeclared identifier is reported only once /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: for each function it appears in.) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: At top level: /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:364: error: expected ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'segv_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'SIGCONTEXT' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'context' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:545: warning: ISO C90 forbids mixed declarations and code /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:556: warning: implicit declaration of function 'setup_exception_record' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'trap_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:608: warning: implicit declaration of function 'save_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:615: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'fpe_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:629: warning: implicit declaration of function 'save_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:683: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:684: warning: implicit declaration of function 'restore_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'int_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:708: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'abrt_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:732: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'usr1_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:758: error: too many arguments to function 'restore_context' make[1]: *** [signal_arm.o] Error 1

Oct. 28, 2011

Re: basic_ifstream implementation

by Josh Juran

On Oct 27, 2011, at 12:35 AM, Piotr Caban wrote: > On 10/27/11 2:01 AM, Josh Juran wrote: >> On Oct 26, 2011, at 11:59 AM, Josh Juran wrote: >> >>> I'm ready to begin work on a basic_ifstream implementation for Wine, which is needed for the game Vampire Secrets among others. > In order to implement it correctly lots of functions/classes needs to be implemented first. I've started stubbing some of them but there's still lots to be done. >>> Well, it turns out that the game creates an ifstream for its intro movie and then uses a completely different mechanism to read from it. Defining a (nearly) empty constructor and destructor for basic_ifstream<char> was sufficient to make things work. > It may happen because of inlining some functions. I don't understand this explanation. Most games don't have this issue. It looks like the developer was originally using ifstream to read the file and then switched to something else, but forgot to remove the ifstream object definition. > The game may also use created streams later. Possible in theory, but unlikely. > It's not good to add an incomplete structure. We'll end having lots of bugs that will need to be debugged to find where the problem is. Especially adding uninitialized vtable pointer is not a good idea. I agree that this patch should not go into Wine as is. > I think it should be implemented by adding all fstream class dependencies first. Thanks to it it will be possible to create a complete basic_ifstream_char structure. I appreciate your (and others') willingness to provide feedback. Unfortunately, my job in this case is to make certain apps work (by hack or by crack) and move on. Josh

Oct. 27, 2011

Re: cmd: Avoid mixing signed and unsigned type in conditional expression

by Michael Stefaniuc

On 10/27/2011 02:09 PM, Frédéric Delanoy wrote: > On Thu, Oct 27, 2011 at 08:38, Eric Pouech <eric.pouech(a)orange.fr> wrote: >> why do we check for ptr being null or not, when we deref ptr one line above? > >>> if (*ptr == '\n') ptr++; >>> - WCMD_output_asis_len(message, (ptr) ? ptr - message : >>> strlenW(message), handle); >>> + WCMD_output_asis_len(message, (ptr) ? (DWORD)(ptr - message) : >>> strlenW(message), handle); >>> if (ptr) { >>> numChars = 0; >>> if (++line_count >= max_height - 1) { > > It's dereferenced but incremented afterwards, so might be null after that line Only if ptr wraps around ;) bye michael

Oct. 27, 2011

Re: cmd: Avoid mixing signed and unsigned type in conditional expression

by Frédéric Delanoy

2011/10/27 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > On Thu, Oct 27, 2011 at 08:38, Eric Pouech <eric.pouech(a)orange.fr> wrote: >> why do we check for ptr being null or not, when we deref ptr one line above? > >>> if (*ptr == '\n') ptr++; >>> - WCMD_output_asis_len(message, (ptr) ? ptr - message : >>> strlenW(message), handle); >>> + WCMD_output_asis_len(message, (ptr) ? (DWORD)(ptr - message) : >>> strlenW(message), handle); >>> if (ptr) { >>> numChars = 0; >>> if (++line_count >= max_height - 1) { > > It's dereferenced but incremented afterwards, so might be null after that line Of course if (*ptr != '\n') the check is unnecessary. I guess the original author simply wanted to merge both cases. Might need some reorganization, but that's probably outside of the scope of this patch

Oct. 27, 2011

Re: cmd: Avoid mixing signed and unsigned type in conditional expression

by Frédéric Delanoy

On Thu, Oct 27, 2011 at 08:38, Eric Pouech <eric.pouech(a)orange.fr> wrote: > why do we check for ptr being null or not, when we deref ptr one line above? >> if (*ptr == '\n') ptr++; >> - WCMD_output_asis_len(message, (ptr) ? ptr - message : >> strlenW(message), handle); >> + WCMD_output_asis_len(message, (ptr) ? (DWORD)(ptr - message) : >> strlenW(message), handle); >> if (ptr) { >> numChars = 0; >> if (++line_count >= max_height - 1) { It's dereferenced but incremented afterwards, so might be null after that line

Oct. 27, 2011

Re: basic_ifstream implementation

by Piotr Caban

On 10/27/11 2:01 AM, Josh Juran wrote: > On Oct 26, 2011, at 11:59 AM, Josh Juran wrote: > >> I'm ready to begin work on a basic_ifstream implementation for Wine, which is needed for the game Vampire Secrets among others. In order to implement it correctly lots of functions/classes needs to be implemented first. I've started stubbing some of them but there's still lots to be done. >> Well, it turns out that the game creates an ifstream for its intro movie and then uses a completely different mechanism to read from it. Defining a (nearly) empty constructor and destructor for basic_ifstream<char> was sufficient to make things work. It may happen because of inlining some functions. The game may also use created streams later. >> +static const vtable_ptr basic_ifstream_char_vtable; >> + >> +typedef struct _basic_ifstream_char >> +{ >> + const vtable_ptr *vtable; >> + >> + int filler[ 140 / sizeof (int) - sizeof (const vtable_ptr*) ]; >> +} >> +basic_ifstream_char; It's not good to add an incomplete structure. We'll end having lots of bugs that will need to be debugged to find where the problem is. Especially adding uninitialized vtable pointer is not a good idea. I think it should be implemented by adding all fstream class dependencies first. Thanks to it it will be possible to create a complete basic_ifstream_char structure. >> +basic_ifstream_char* __thiscall basic_ifstream_char_ctor(basic_ifstream_char *this, const char *path, int mode, int prot) >> +@ thiscall -arch=win32 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAE(a)PBDHH@Z(ptr long long) basic_ifstream_char_ctor Arguments in spec file are different then in ios.c. Cheers, Piotr

Oct. 27, 2011

Re: cmd: Avoid mixing signed and unsigned type in conditional expression

by Eric Pouech

why do we check for ptr being null or not, when we deref ptr one line above ? something's wrong in the code logic A+ Le 27 octobre 2011 04:53, Frédéric Delanoy <frederic.delanoy(a)gmail.com> a écrit : > --- > programs/cmd/wcmdmain.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/programs/cmd/wcmdmain.c b/programs/cmd/wcmdmain.c > index 56aa85f..1bcc598 100644 > --- a/programs/cmd/wcmdmain.c > +++ b/programs/cmd/wcmdmain.c > @@ -278,7 +278,7 @@ static void WCMD_output_asis_handle (DWORD std_handle, > const WCHAR *message) { > ptr++; > }; > if (*ptr == '\n') ptr++; > - WCMD_output_asis_len(message, (ptr) ? ptr - message : > strlenW(message), handle); > + WCMD_output_asis_len(message, (ptr) ? (DWORD)(ptr - message) : > strlenW(message), handle); > if (ptr) { > numChars = 0; > if (++line_count >= max_height - 1) { > -- > 1.7.7.1 > > > > -- -- Eric Pouech

Oct. 27, 2011

Re: basic_ifstream implementation

by Octavian Voicu

On Thu, Oct 27, 2011 at 2:01 AM, Josh Juran <josh(a)iswifter.net> wrote: > @ stub -arch=win64 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAA(a)PEBDHH@Z > @ stub -arch=win64 ??_D?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAAXXZ You forgot to update the win64 stubs in the spec file. Octavian

Oct. 27, 2011

Re: basic_ifstream implementation

by Josh Juran

On Oct 26, 2011, at 11:59 AM, Josh Juran wrote: > I'm ready to begin work on a basic_ifstream implementation for Wine, which is needed for the game Vampire Secrets among others. > > http://bugs.winehq.org/show_bug.cgi?id=28612 > > First I'd like to check that Piotr isn't already working on this. If not, I'm open to any advice on how to proceed. My plan is to create fstream.c, and use string.c as a guide. Well, it turns out that the game creates an ifstream for its intro movie and then uses a completely different mechanism to read from it. Defining a (nearly) empty constructor and destructor for basic_ifstream<char> was sufficient to make things work. The good news is that this ticket can be resolved if the patch attached to it and included below (or one like it) is applied. The bad news is that I won't be providing an actual implementation or otherwise working on this any further. Josh diff --git a/dlls/msvcp90/ios.c b/dlls/msvcp90/ios.c index 84dfb17..4290469 100644 --- a/dlls/msvcp90/ios.c +++ b/dlls/msvcp90/ios.c @@ -1727,3 +1727,35 @@ basic_ostream_char* __thiscall basic_ostream_char_write(basic_ostream_char *this FIXME("(%p %s %lu) stub\n", this, debugstr_a(str), count); return NULL; } + +static const vtable_ptr basic_ifstream_char_vtable; + +typedef struct _basic_ifstream_char +{ + const vtable_ptr *vtable; + + int filler[ 140 / sizeof (int) - sizeof (const vtable_ptr*) ]; +} +basic_ifstream_char; + +/* ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAE(a)PBDHH@Z */ +/* ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAA(a)PEBDHH@Z */ +DEFINE_THISCALL_WRAPPER(basic_ifstream_char_ctor, 16) +basic_ifstream_char* __thiscall basic_ifstream_char_ctor(basic_ifstream_char *this, const char *path, int mode, int prot) +{ + FIXME("(%p, %s, %d, %d) stub\n", this, path, mode, prot); + + this->vtable = &basic_ifstream_char_vtable; + + return this; +} + +/* ??_D?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAEXXZ */ +/* ??_D?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAAXXZ */ +DEFINE_THISCALL_WRAPPER(basic_ifstream_char_vbase_dtor, 4) +basic_ifstream_char* __thiscall basic_ifstream_char_vbase_dtor(basic_ifstream_char *this) +{ + FIXME("(%p) stub\n", this); + + return this; +} diff --git a/dlls/msvcp90/msvcp90.spec b/dlls/msvcp90/msvcp90.spec index 33d5619..f43a669 100644 --- a/dlls/msvcp90/msvcp90.spec +++ b/dlls/msvcp90/msvcp90.spec @@ -590,7 +590,7 @@ @ stub -arch=win64 ??0?$basic_fstream(a)_WU?$char_traits(a)_W@std@@@std@@QEAA(a)XZ @ stub -arch=win32 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAE(a)PAU_iobuf@@@Z @ stub -arch=win64 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAA(a)PEAU_iobuf@@@Z -@ stub -arch=win32 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAE(a)PBDHH@Z +@ thiscall -arch=win32 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAE(a)PBDHH@Z(ptr long long) basic_ifstream_char_ctor @ stub -arch=win64 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAA(a)PEBDHH@Z @ stub -arch=win32 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAE(a)PBGHH@Z @ stub -arch=win64 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAA(a)PEBGHH@Z @@ -1907,7 +1907,7 @@ @ stub -arch=win64 ??_D?$basic_fstream(a)GU?$char_traits(a)G@std@@@std@@QEAAXXZ @ stub -arch=win32 ??_D?$basic_fstream(a)_WU?$char_traits(a)_W@std@@@std@@QAEXXZ @ stub -arch=win64 ??_D?$basic_fstream(a)_WU?$char_traits(a)_W@std@@@std@@QEAAXXZ -@ stub -arch=win32 ??_D?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAEXXZ +@ thiscall -arch=win32 ??_D?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAEXXZ(ptr) basic_ifstream_char_vbase_dtor @ stub -arch=win64 ??_D?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAAXXZ @ stub -arch=win32 ??_D?$basic_ifstream(a)GU?$char_traits(a)G@std@@@std@@QAEXXZ @ stub -arch=win64 ??_D?$basic_ifstream(a)GU?$char_traits(a)G@std@@@std@@QEAAXXZ

Oct. 27, 2011

basic_ifstream implementation

by Josh Juran

I'm ready to begin work on a basic_ifstream implementation for Wine, which is needed for the game Vampire Secrets among others. http://bugs.winehq.org/show_bug.cgi?id=28612 First I'd like to check that Piotr isn't already working on this. If not, I'm open to any advice on how to proceed. My plan is to create fstream.c, and use string.c as a guide. Josh

Oct. 26, 2011

Re: winscard/tests: Add the tests file

by Bruno Jesus

On Wed, Oct 26, 2011 at 11:38, Marvin <testbot(a)testbot.winehq.org> wrote: > === W2KPROSP4 (32 bit winscard) === > winscard.c:53: Test failed: SCardIsValidContext expected SCARD_E_INVALID_HANDLE, received 00000006 > winscard.c:64: Test failed: SCardReleaseContext expected SCARD_E_INVALID_HANDLE, received 00000006 > It looks like Win2000 didn't have the SCARD_E_INVALID_HANDLE and instead return the win error INVALID_HANDLE (error 6). If possible and if no one finds any problem with the patch I would ask for it to be commited as is because I'll fix this in a newer patch using broken. Best wishes, Bruno

Oct. 26, 2011

Re: winscard/tests: Add the tests file

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=15123 Your paranoid android. === W2KPROSP4 (32 bit winscard) === winscard.c:53: Test failed: SCardIsValidContext expected SCARD_E_INVALID_HANDLE, received 00000006 winscard.c:64: Test failed: SCardReleaseContext expected SCARD_E_INVALID_HANDLE, received 00000006

Oct. 26, 2011

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

by Dan Kegel

On Wed, Oct 26, 2011 at 4:48 AM, Bernhard Loos <bernhardloos(a)googlemail.com> wrote: > This means tools/widl/Makefile wasn't regenerated. > But the changes to Makefile.in are there, so it's a problem with your system. Hmm. Thanks, I'll have a look. - Dan

Oct. 26, 2011

Re: [PATCH 2/2] d3dx9/test: Fix typo.

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=15120 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Oct. 26, 2011

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

by Bernhard Loos

On Tue, Oct 25, 2011 at 6:11 PM, Dan Kegel <dank(a)kegel.com> wrote: > 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' This means tools/widl/Makefile wasn't regenerated. But the changes to Makefile.in are there, so it's a problem with your system. > 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 > Sorry, forgot to rebase yesterday.

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Kai Tietz

2011/10/26 Dmitry Timoshkov <dmitry(a)baikal.ru>: > Chris Robinson <chris.kcat(a)gmail.com> wrote: > >> For Wine it doesn't really matter, since we can't use C++. For mingw-w64, >> however, it could be a big problem if it's not properly typed as a long. >> Overloads and template types would silently use 'int' where it should be using >> 'long', and you wouldn't necessarily know until you see odd behavior in the >> app. > > What kind of odd behaviour? Both int and long are 32-bit in win32 and win64. > > -- > Dmitry. See as example for C++: #include <stdio.h> void foo (int i) { printf ("int i == %d\n", i); } void foo (long i) { printf ("long i == %ld\n", i); } int main () { foo (1); foo (1L); return 0; } if you compile this program and execute it, then you will see the following output: $ ./tst.exe int i == 1 long i == 1 C++ has the ability to have for same function name different implementation for different argument types. Means, argument types getting part of function's signature. So you might see the cause what is different about suffixed/non-suffixed values for C++. Regards, Kai

Oct. 26, 2011

Re: [PATCH 1/2] d3dx9: Improve argument check in D3DXFindShaderComment().

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=15119 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Dmitry Timoshkov

Chris Robinson <chris.kcat(a)gmail.com> wrote: > For Wine it doesn't really matter, since we can't use C++. For mingw-w64, > however, it could be a big problem if it's not properly typed as a long. > Overloads and template types would silently use 'int' where it should be using > 'long', and you wouldn't necessarily know until you see odd behavior in the > app. What kind of odd behaviour? Both int and long are 32-bit in win32 and win64. -- Dmitry.

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Chris Robinson

On Wednesday, October 26, 2011 12:35:28 PM Michael Stefaniuc wrote: > Chris Robinson wrote: > > imagine some C++ function overrides tripping up with the int/long > > difference. > If you use the Wine headers this should actually fix it as it brings the > numeric constants in line with the types as LONG == int in Wine. For Wine it doesn't really matter, since we can't use C++. For mingw-w64, however, it could be a big problem if it's not properly typed as a long. Overloads and template types would silently use 'int' where it should be using 'long', and you wouldn't necessarily know until you see odd behavior in the app.

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Michael Stefaniuc

Chris Robinson wrote: > On Wednesday, October 26, 2011 12:17:22 PM Michael Stefaniuc wrote: >> Hello Jacek! >> >> Jacek Caban wrote: >>> mingw-w64 project imports some of our headers, including most of d3d >>> headers. They would probably prefer to keep them with 'l' modifier since >>> that's the right thing to do. Given that it's mostly harmless for Wine, >>> could we please consider not changing it? >> Well ... the the dinput.h was a real change were Wine was affected. >> But the change should be mostly harmless for mingw-w64 as long == int on >> Win32 and Win64. > > The compiler does still complain about types even if the type is the same > size. Such as when using printf formatting (%x = int, #lx = long; GCC > complains if the type doesn't match, even if it's the same size). Also I could Right, one of the reasons we do this change for Wine. > imagine some C++ function overrides tripping up with the int/long difference. If you use the Wine headers this should actually fix it as it brings the numeric constants in line with the types as LONG == int in Wine. bye michael

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Chris Robinson

On Wednesday, October 26, 2011 12:17:22 PM Michael Stefaniuc wrote: > Hello Jacek! > > Jacek Caban wrote: > > mingw-w64 project imports some of our headers, including most of d3d > > headers. They would probably prefer to keep them with 'l' modifier since > > that's the right thing to do. Given that it's mostly harmless for Wine, > > could we please consider not changing it? > > Well ... the the dinput.h was a real change were Wine was affected. > But the change should be mostly harmless for mingw-w64 as long == int on > Win32 and Win64. The compiler does still complain about types even if the type is the same size. Such as when using printf formatting (%x = int, #lx = long; GCC complains if the type doesn't match, even if it's the same size). Also I could imagine some C++ function overrides tripping up with the int/long difference.

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Kai Tietz

2011/10/26 Michael Stefaniuc <mstefani(a)redhat.com>: > Hello Jacek! > > Jacek Caban wrote: >> On 10/26/11 00:30, Michael Stefaniuc wrote: >>> --- >>> include/d3d9caps.h | 182 >>> ++++++++++++++++++++++++++-------------------------- >>> 1 files changed, 91 insertions(+), 91 deletions(-) >>> >>> diff --git a/include/d3d9caps.h b/include/d3d9caps.h >>> index 8ed6598..64dba21 100644 >>> --- a/include/d3d9caps.h >>> +++ b/include/d3d9caps.h >>> @@ -29,13 +29,13 @@ >>> #define D3DCURSORCAPS_LOWRES 2 >>> >>> >>> -#define D3DDEVCAPS2_STREAMOFFSET 0x00000001L >>> -#define D3DDEVCAPS2_DMAPNPATCH 0x00000002L >>> -#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004L >>> -#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008L >>> -#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010L >>> -#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020L >>> -#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040L >>> +#define D3DDEVCAPS2_STREAMOFFSET 0x00000001 >>> +#define D3DDEVCAPS2_DMAPNPATCH 0x00000002 >>> +#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004 >>> +#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008 >>> +#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010 >>> +#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020 >>> +#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040 >>> >> >> mingw-w64 project imports some of our headers, including most of d3d >> headers. They would probably prefer to keep them with 'l' modifier since >> that's the right thing to do. Given that it's mostly harmless for Wine, >> could we please consider not changing it? > Well ... the the dinput.h was a real change were Wine was affected. > But the change should be mostly harmless for mingw-w64 as long == int on > Win32 and Win64. > > Anyway this is a hit job from Alexandre so you'll have to convince him. > > bye > michael Hi Michael, 2011/10/26 Jacek Caban <jacek(a)codeweavers.com>: > Hi Michael, > > On 10/26/11 00:30, Michael Stefaniuc wrote: >> >> --- >> include/d3d9caps.h | 182 >> ++++++++++++++++++++++++++-------------------------- >> 1 files changed, 91 insertions(+), 91 deletions(-) >> >> diff --git a/include/d3d9caps.h b/include/d3d9caps.h >> index 8ed6598..64dba21 100644 >> --- a/include/d3d9caps.h >> +++ b/include/d3d9caps.h >> @@ -29,13 +29,13 @@ >> #define D3DCURSORCAPS_LOWRES 2 >> >> >> -#define D3DDEVCAPS2_STREAMOFFSET 0x00000001L >> -#define D3DDEVCAPS2_DMAPNPATCH 0x00000002L >> -#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004L >> -#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008L >> -#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010L >> -#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020L >> -#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040L >> +#define D3DDEVCAPS2_STREAMOFFSET 0x00000001 >> +#define D3DDEVCAPS2_DMAPNPATCH 0x00000002 >> +#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004 >> +#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008 >> +#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010 >> +#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020 >> +#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040 >> > > mingw-w64 project imports some of our headers, including most of d3d > headers. They would probably prefer to keep them with 'l' modifier since > that's the right thing to do. Given that it's mostly harmless for Wine, > could we please consider not changing it? > > Thanks, > Jacek As Jacek mentioned already, it would be for our use of Wine direct-x SDK a big flaw to have constants here not proper suffixed with L. Especially in use for C++ this would cause big pain for 32-bit and 64-bit native Windows compilation. I am not sure about this, but I assume that Wine might have an interest to be able to use platform-headers and optional SDKs also with a cross-compiler targeting for Windows native. I would suggest to use here a helper-macro, which does on demand the required L-suffix. Something like in global configure headers: #ifdef __SIZEOF_LONG <= 32 #define MSABI_LONG(VAL) VAL ## L #else #define MSABI_LONG(VAL) VAL #endif And then using in platform/sdk headers ... #define XYZ MSABI_LONG(0x1234) ... instead. Regards, Kai

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Michael Stefaniuc

Hello Jacek! Jacek Caban wrote: > On 10/26/11 00:30, Michael Stefaniuc wrote: >> --- >> include/d3d9caps.h | 182 >> ++++++++++++++++++++++++++-------------------------- >> 1 files changed, 91 insertions(+), 91 deletions(-) >> >> diff --git a/include/d3d9caps.h b/include/d3d9caps.h >> index 8ed6598..64dba21 100644 >> --- a/include/d3d9caps.h >> +++ b/include/d3d9caps.h >> @@ -29,13 +29,13 @@ >> #define D3DCURSORCAPS_LOWRES 2 >> >> >> -#define D3DDEVCAPS2_STREAMOFFSET 0x00000001L >> -#define D3DDEVCAPS2_DMAPNPATCH 0x00000002L >> -#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004L >> -#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008L >> -#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010L >> -#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020L >> -#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040L >> +#define D3DDEVCAPS2_STREAMOFFSET 0x00000001 >> +#define D3DDEVCAPS2_DMAPNPATCH 0x00000002 >> +#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004 >> +#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008 >> +#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010 >> +#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020 >> +#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040 >> > > mingw-w64 project imports some of our headers, including most of d3d > headers. They would probably prefer to keep them with 'l' modifier since > that's the right thing to do. Given that it's mostly harmless for Wine, > could we please consider not changing it? Well ... the the dinput.h was a real change were Wine was affected. But the change should be mostly harmless for mingw-w64 as long == int on Win32 and Win64. Anyway this is a hit job from Alexandre so you'll have to convince him. bye michael

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Jacek Caban

Hi Michael, On 10/26/11 00:30, Michael Stefaniuc wrote: > --- > include/d3d9caps.h | 182 ++++++++++++++++++++++++++-------------------------- > 1 files changed, 91 insertions(+), 91 deletions(-) > > diff --git a/include/d3d9caps.h b/include/d3d9caps.h > index 8ed6598..64dba21 100644 > --- a/include/d3d9caps.h > +++ b/include/d3d9caps.h > @@ -29,13 +29,13 @@ > #define D3DCURSORCAPS_LOWRES 2 > > > -#define D3DDEVCAPS2_STREAMOFFSET 0x00000001L > -#define D3DDEVCAPS2_DMAPNPATCH 0x00000002L > -#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004L > -#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008L > -#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010L > -#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020L > -#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040L > +#define D3DDEVCAPS2_STREAMOFFSET 0x00000001 > +#define D3DDEVCAPS2_DMAPNPATCH 0x00000002 > +#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004 > +#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008 > +#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010 > +#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020 > +#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040 > mingw-w64 project imports some of our headers, including most of d3d headers. They would probably prefer to keep them with 'l' modifier since that's the right thing to do. Given that it's mostly harmless for Wine, could we please consider not changing it? Thanks, Jacek

Oct. 26, 2011

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. 26, 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. 26, 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. 24, 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

Re: Patch resend etiquette

by Austin English

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. -- -Austin

Oct. 22, 2011

Re: msctf: increase buffer to have room for full key

by Austin English

On Fri, Oct 21, 2011 at 20:26, Aric Stewart <aric(a)codeweavers.com> wrote: > > found by Dan Kegel with Valgrind. > Fixes bug 25826 And Clang :). -- -Austin

Oct. 22, 2011

Patch resend etiquette

by Erich Hoover

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. Erich Hoover ehoover(a)mines.edu

Oct. 22, 2011

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

by Dan Kegel

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 http://buildbot.kegel.com/builders/runtests-default/builds/874

Oct. 22, 2011

Re: [PATCH 1/5] wined3d: Move the cursor in wined3d_device_set_cursor_position().

by Henri Verbeet

On 21 October 2011 17:12, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Does this address Alexandre's need for a software cursor, or is this > unrelated? > It's related, but software cursors are still somewhat broken.

Oct. 21, 2011

Re: [PATCH 1/5] wined3d: Move the cursor in wined3d_device_set_cursor_position().

by Stefan Dösinger

Hi, Does this address Alexandre's need for a software cursor, or is this unrelated? In the tests I recommend to test a bigger cursor in addition to the 32x32 cursor to see what happens in situations where Windows falls back to a software cursor. Stefan On Thursday 20 October 2011 12:42:55 Henri Verbeet wrote: > --- > dlls/wined3d/device.c | 8 +++++++- > 1 files changed, 7 insertions(+), 1 deletions(-) > > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index 67e50b5..6f43715 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -5251,10 +5251,16 @@ void CDECL > wined3d_device_set_cursor_position(struct wined3d_device *device, > device->xScreenSpace = x_screen_space; > device->yScreenSpace = y_screen_space; > > - /* switch to the software cursor if position diverges from the > hardware one */ if (device->hardwareCursor) > { > POINT pt; > + > + GetCursorPos( &pt ); > + if (x_screen_space == pt.x && y_screen_space == pt.y) > + return; > + SetCursorPos( x_screen_space, y_screen_space ); > + > + /* Switch to the software cursor if position diverges from the > hardware one. */ GetCursorPos( &pt ); > if (x_screen_space != pt.x || y_screen_space != pt.y) > {

Oct. 21, 2011

Re: [PATCH 2/2] vbscript: Added remaining week day constants implementations

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=15047 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. 21, 2011

Re: [PATCH 1/2] vbscript: Added vbSunday constant implementation

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=15046 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. 21, 2011

Re: dpnet/tests: Avoid casting return value of HeapAlloc calls

by Michael Stefaniuc

Frédéric Delanoy wrote: > On Fri, Oct 21, 2011 at 02:13, Marvin <testbot(a)testbot.winehq.org> wrote: >> 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=15042 >> >> Your paranoid android. >> >> >> === WNT4WSSP6 (32 bit peer) === >> peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 >> peer: unhandled exception c0000005 at 004013BF >> >> === W2KPROSP4 (32 bit peer) === >> peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 >> peer: unhandled exception c0000005 at 004013BF > > This also happens when you send a comment-only patch to testbot. Flaky test? Nope. There is no dpnet dll on those boxes. winetest.exe skips those but the WTB doesn't. http://test.winehq.org/data/bbbee31c38cde112cfcc7417872416bf34955367/nt4_wt… "dpnet missing" bye michael

Oct. 21, 2011

Re: 80186: [PATCH 2/2] dinput: Restore checks for DirectX 3 buffer size.

by Michael Stefaniuc

Vitaliy Margolen wrote: > On 10/20/2011 06:18 PM, Dan Kegel wrote: >> On Thu, Oct 20, 2011 at 5:15 PM, Vitaliy Margolen >> <wine-devel(a)kievinfo.com> wrote: >>>>> device.c:117: Test failed: GetDeviceData() should have failed: >>>>> 80040207 >>>>> device.c:120: Test failed: GetDeviceData() should have failed: >>>>> 80040207 >>>>> make: *** [device.ok] Error 8 >>> >>> Could be because of definition problems. Here's what I get compiling >>> wine64: >>> ../../../../wine.git/dlls/dinput/tests/device.c:117:5: warning: >>> comparison >>> is always false due to limited range of data type >>> ../../../../wine.git/dlls/dinput/tests/device.c:120:5: warning: >>> comparison >>> is always false due to limited range of data type >>> >>> HRESULT defined as "typedef LONG HRESULT;". But error code defined as: >>> #define DIERR_NOTBUFFERED 0x80040207L >>> >>> Not sure what to do here. Test passed on all win64 bit platforms >>> according >>> to test bot. So unless we want to redefine all LONG constants in PSDK >>> (and >>> remove that last L) I'd say ignore this. >> >> How can we ignore it? Once we check it in, the 64 bit build will >> start failing its tests :-( > > So you saying we should modify all long error constants in PSDK? I'm not > sure what else can be done. Yes, that's the right way. I got that as a janitorial task from Alexandre during the last WineConf. One commit is in already http://source.winehq.org/git/wine.git/?a=commit;h=0324fc57469f402102b677c4e… While the search and replace is trivial it uncovers interesting challenges and opportunities in the Wine code... That's why I'm not done yet with this task. bye michael

Oct. 21, 2011

Re: 80186: [PATCH 2/2] dinput: Restore checks for DirectX 3 buffer size.

by Vitaliy Margolen

On 10/20/2011 06:26 PM, Vitaliy Margolen wrote: > On 10/20/2011 06:18 PM, Dan Kegel wrote: >> On Thu, Oct 20, 2011 at 5:15 PM, Vitaliy Margolen >> <wine-devel(a)kievinfo.com> wrote: >>>>> device.c:117: Test failed: GetDeviceData() should have failed: 80040207 >>>>> device.c:120: Test failed: GetDeviceData() should have failed: 80040207 >>>>> make: *** [device.ok] Error 8 >>> >>> Could be because of definition problems. Here's what I get compiling wine64: >>> ../../../../wine.git/dlls/dinput/tests/device.c:117:5: warning: comparison >>> is always false due to limited range of data type >>> ../../../../wine.git/dlls/dinput/tests/device.c:120:5: warning: comparison >>> is always false due to limited range of data type >>> >>> HRESULT defined as "typedef LONG HRESULT;". But error code defined as: >>> #define DIERR_NOTBUFFERED 0x80040207L >>> >>> Not sure what to do here. Test passed on all win64 bit platforms according >>> to test bot. So unless we want to redefine all LONG constants in PSDK (and >>> remove that last L) I'd say ignore this. >> >> How can we ignore it? Once we check it in, the 64 bit build will >> start failing its tests :-( > > So you saying we should modify all long error constants in PSDK? I'm not > sure what else can be done. > Ok, casting error code to HRESULT seemed to work. Vitaliy.

Oct. 21, 2011

Re: 80186: [PATCH 2/2] dinput: Restore checks for DirectX 3 buffer size.

by Vitaliy Margolen

On 10/20/2011 06:18 PM, Dan Kegel wrote: > On Thu, Oct 20, 2011 at 5:15 PM, Vitaliy Margolen > <wine-devel(a)kievinfo.com> wrote: >>>> device.c:117: Test failed: GetDeviceData() should have failed: 80040207 >>>> device.c:120: Test failed: GetDeviceData() should have failed: 80040207 >>>> make: *** [device.ok] Error 8 >> >> Could be because of definition problems. Here's what I get compiling wine64: >> ../../../../wine.git/dlls/dinput/tests/device.c:117:5: warning: comparison >> is always false due to limited range of data type >> ../../../../wine.git/dlls/dinput/tests/device.c:120:5: warning: comparison >> is always false due to limited range of data type >> >> HRESULT defined as "typedef LONG HRESULT;". But error code defined as: >> #define DIERR_NOTBUFFERED 0x80040207L >> >> Not sure what to do here. Test passed on all win64 bit platforms according >> to test bot. So unless we want to redefine all LONG constants in PSDK (and >> remove that last L) I'd say ignore this. > > How can we ignore it? Once we check it in, the 64 bit build will > start failing its tests :-( So you saying we should modify all long error constants in PSDK? I'm not sure what else can be done. Vitaliy.

Oct. 21, 2011

Re: dpnet/tests: Avoid casting return value of HeapAlloc calls

by Frédéric Delanoy

On Fri, Oct 21, 2011 at 02:13, Marvin <testbot(a)testbot.winehq.org> wrote: > 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=15042 > > Your paranoid android. > > > === WNT4WSSP6 (32 bit peer) === > peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 > peer: unhandled exception c0000005 at 004013BF > > === W2KPROSP4 (32 bit peer) === > peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 > peer: unhandled exception c0000005 at 004013BF This also happens when you send a comment-only patch to testbot. Flaky test?

Oct. 21, 2011

Re: 80186: [PATCH 2/2] dinput: Restore checks for DirectX 3 buffer size.

by Dan Kegel

On Thu, Oct 20, 2011 at 5:15 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: >>> device.c:117: Test failed: GetDeviceData() should have failed: 80040207 >>> device.c:120: Test failed: GetDeviceData() should have failed: 80040207 >>> make: *** [device.ok] Error 8 > > Could be because of definition problems. Here's what I get compiling wine64: > ../../../../wine.git/dlls/dinput/tests/device.c:117:5: warning: comparison > is always false due to limited range of data type > ../../../../wine.git/dlls/dinput/tests/device.c:120:5: warning: comparison > is always false due to limited range of data type > > HRESULT defined as "typedef LONG HRESULT;". But error code defined as: > #define DIERR_NOTBUFFERED 0x80040207L > > Not sure what to do here. Test passed on all win64 bit platforms according > to test bot. So unless we want to redefine all LONG constants in PSDK (and > remove that last L) I'd say ignore this. How can we ignore it? Once we check it in, the 64 bit build will start failing its tests :-( - Dan

Oct. 21, 2011

Re: 80186: [PATCH 2/2] dinput: Restore checks for DirectX 3 buffer size.

by Vitaliy Margolen

Could be because of definition problems. Here's what I get compiling wine64: ../../../../wine.git/dlls/dinput/tests/device.c:117:5: warning: comparison is always false due to limited range of data type ../../../../wine.git/dlls/dinput/tests/device.c:120:5: warning: comparison is always false due to limited range of data type HRESULT defined as "typedef LONG HRESULT;". But error code defined as: #define DIERR_NOTBUFFERED 0x80040207L Not sure what to do here. Test passed on all win64 bit platforms according to test bot. So unless we want to redefine all LONG constants in PSDK (and remove that last L) I'd say ignore this. Vitaliy. On 10/20/2011 09:46 AM, Dan Kegel wrote: > Hi Vitaliy, > could you check on win64? I had a test failure there with your patch. > - Dan > > On Thu, Oct 20, 2011 at 7:49 AM,<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-x86_64 while building Wine. >> Full details are available at: http://buildbot.kegel.com/builders/runtests-default-x86_64/builds/769 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) >> BUILD FAILED: failed shell_3 >> >> Errors: >> alarum: failed command was ../../../wine dinput_test.exe.so device.c >> device.c:117: Test failed: GetDeviceData() should have failed: 80040207 >> device.c:120: Test failed: GetDeviceData() should have failed: 80040207 >> device.c:117: Test failed: GetDeviceData() should have failed: 80040207 >> device.c:120: Test failed: GetDeviceData() should have failed: 80040207 >> device.c:117: Test failed: GetDeviceData() should have failed: 80040207 >> device.c:120: Test failed: GetDeviceData() should have failed: 80040207 >> device.c:117: Test failed: GetDeviceData() should have failed: 80040207 >> device.c:120: Test failed: GetDeviceData() should have failed: 80040207 >> make: *** [device.ok] Error 8 >> >> > >

Oct. 21, 2011

Re: dpnet/tests: Avoid casting return value of HeapAlloc calls

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=15042 Your paranoid android. === WNT4WSSP6 (32 bit peer) === peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 peer: unhandled exception c0000005 at 004013BF === W2KPROSP4 (32 bit peer) === peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 peer: unhandled exception c0000005 at 004013BF

Oct. 21, 2011

Re: Anyone wants to ban spammer on forum

by Evil Jay

On 10/20/2011 02:34 PM, L. Rahyen wrote: > If such a system will be used, I will volunteer too. By the way, I > like this idea because I think it can prevent all or almost all spam > (most spammers never post "intelligent posts"). It would definitely be an improvement. I moderate in some other tech forums and only *rarely* have I seen a bot programmed to post a few generic ("me too" and such) posts before it started spewing the spam.

Oct. 20, 2011

Re: 80200: wininet: add a stub for ShowClientAuthCerts

by Dan Kegel

Fails to build here? On Thu, Oct 20, 2011 at 3:52 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/804 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > internet.c: In function 'ShowClientAuthCerts': > internet.c:4391:159: error: format '%p' expects a matching 'void *' argument [-Werror=format] > make[1]: *** [internet.o] Error 1 > make: *** [dlls/wininet] Error 2 > make: *** Waiting for unfinished jobs.... > >

Oct. 20, 2011

Re: 80199: shdocvw: add a stub for InstallReg_RunDLL

by Dan Kegel

Fails to build here? On Thu, Oct 20, 2011 at 3:51 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/803 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > shdocvw_main.c: In function 'InstallReg_RunDLL': > shdocvw_main.c:547:159: error: format '%p' expects a matching 'void *' argument [-Werror=format] > shdocvw_main.c:547:159: error: format '%p' expects a matching 'void *' argument [-Werror=format] > make[1]: *** [shdocvw_main.o] Error 1 > make: *** [dlls/shdocvw] Error 2 > make: *** Waiting for unfinished jobs.... > >

Oct. 20, 2011

Re: Anyone wants to ban spammer on forum

by L. Rahyen

On 2011-10-20 (October, Thursday) 19:17:56 Jerome Leclanche wrote: > On Thu, Oct 20, 2011 at 8:07 PM, Josh Juran <josh(a)iswifter.net> wrote: > > Quarantine new users' posts until approved by a human moderator. After a > > few intelligent posts, grant the user unmoderated posting privilege. > > The Boost mailing list does this. > I think that's a great system, but you'll need volunteers :) I can > volunteer for that matter, but I won't exactly spend a lot of time on > it. If such a system will be used, I will volunteer too. By the way, I like this idea because I think it can prevent all or almost all spam (most spammers never post "intelligent posts").

Oct. 20, 2011

Re: Anyone wants to ban spammer on forum

by Ken Sharp

Here here On 20/10/11 8:17 PM, Jerome Leclanche wrote: > I think that's a great system, but you'll need volunteers :) I can > volunteer for that matter, but I won't exactly spend a lot of time on > it. > > JL > > On Thu, Oct 20, 2011 at 8:07 PM, Josh Juran<josh(a)iswifter.net> wrote: >> On Oct 20, 2011, at 11:58 AM, Jerome Leclanche wrote: >> >>> I don't subscribe to websites that have annoying captchas either way; >>> and many people are like that. Bot authors have proved they can beat >>> any system; and captchas (recaptcha especially) has proved itself as >>> one of the most effective and unintrusive free captcha systems. >> >> Quarantine new users' posts until approved by a human moderator. After a few intelligent posts, grant the user unmoderated posting privilege. The Boost mailing list does this. >> >> Josh >> >> >> >

Oct. 20, 2011

Re: Anyone wants to ban spammer on forum

by Jerome Leclanche

I think that's a great system, but you'll need volunteers :) I can volunteer for that matter, but I won't exactly spend a lot of time on it. JL On Thu, Oct 20, 2011 at 8:07 PM, Josh Juran <josh(a)iswifter.net> wrote: > On Oct 20, 2011, at 11:58 AM, Jerome Leclanche wrote: > >> I don't subscribe to websites that have annoying captchas either way; >> and many people are like that. Bot authors have proved they can beat >> any system; and captchas (recaptcha especially) has proved itself as >> one of the most effective and unintrusive free captcha systems. > > Quarantine new users' posts until approved by a human moderator. After a few intelligent posts, grant the user unmoderated posting privilege. The Boost mailing list does this. > > Josh > > >

Oct. 20, 2011

Re: Anyone wants to ban spammer on forum

by Josh Juran

On Oct 20, 2011, at 11:58 AM, Jerome Leclanche wrote: > I don't subscribe to websites that have annoying captchas either way; > and many people are like that. Bot authors have proved they can beat > any system; and captchas (recaptcha especially) has proved itself as > one of the most effective and unintrusive free captcha systems. Quarantine new users' posts until approved by a human moderator. After a few intelligent posts, grant the user unmoderated posting privilege. The Boost mailing list does this. Josh

Oct. 20, 2011

Re: Anyone wants to ban spammer on forum

by Jerome Leclanche

I don't subscribe to websites that have annoying captchas either way; and many people are like that. Bot authors have proved they can beat any system; and captchas (recaptcha especially) has proved itself as one of the most effective and unintrusive free captcha systems. JL On Thu, Oct 20, 2011 at 7:54 PM, Ken Sharp <kennybobs(a)o2.co.uk> wrote: > Isn't the system for creating new accounts only? If it's just to post > messages then anything will be annoying. > > On 20/10/11 7:48 PM, Jerome Leclanche wrote: >> >> Unless you want to implement a captcha system, any system is going to >> annoy the users. Bots can be programmed to answer those fields pretty >> easily; if a spammer wants to get around it, they will :) >> >> JL >> >> On Thu, Oct 20, 2011 at 7:24 PM, Ken Sharp<kennybobs(a)o2.co.uk> wrote: >>> >>> >>> On 20/10/11 4:13 PM, Bruno Jesus wrote: >>>> >>>> On Thu, Oct 20, 2011 at 11:48, Jeremy Newman<jnewman(a)codeweavers.com> >>>> wrote: >>>>> >>>>> I will take suggestions on other questions that regular users can >>>>> answer >>>>> easily, but would stump (for a bit anyway) a bot, or bot author. >>>> >>>> Why not the good and old random math questions inside an image? For >>>> example 2 + 4 = ... >>>> >>>> >>> >>> A bot should be able to figure that out too, unless the answer is also a >>> picture. >>> >>> Maybe A+B = ? The answer being AB. >>> >>> Don't know if any of this is possible with the software, however. >>> >>> >>> >>> >> >

Oct. 20, 2011

Re: Anyone wants to ban spammer on forum

by Ken Sharp

Isn't the system for creating new accounts only? If it's just to post messages then anything will be annoying. On 20/10/11 7:48 PM, Jerome Leclanche wrote: > Unless you want to implement a captcha system, any system is going to > annoy the users. Bots can be programmed to answer those fields pretty > easily; if a spammer wants to get around it, they will :) > > JL > > On Thu, Oct 20, 2011 at 7:24 PM, Ken Sharp<kennybobs(a)o2.co.uk> wrote: >> >> >> On 20/10/11 4:13 PM, Bruno Jesus wrote: >>> >>> On Thu, Oct 20, 2011 at 11:48, Jeremy Newman<jnewman(a)codeweavers.com> >>> wrote: >>>> >>>> I will take suggestions on other questions that regular users can answer >>>> easily, but would stump (for a bit anyway) a bot, or bot author. >>> >>> Why not the good and old random math questions inside an image? For >>> example 2 + 4 = ... >>> >>> >> >> A bot should be able to figure that out too, unless the answer is also a >> picture. >> >> Maybe A+B = ? The answer being AB. >> >> Don't know if any of this is possible with the software, however. >> >> >> >> >

Oct. 20, 2011

Re: Anyone wants to ban spammer on forum

by Jerome Leclanche

Unless you want to implement a captcha system, any system is going to annoy the users. Bots can be programmed to answer those fields pretty easily; if a spammer wants to get around it, they will :) JL On Thu, Oct 20, 2011 at 7:24 PM, Ken Sharp <kennybobs(a)o2.co.uk> wrote: > > > On 20/10/11 4:13 PM, Bruno Jesus wrote: >> >> On Thu, Oct 20, 2011 at 11:48, Jeremy Newman<jnewman(a)codeweavers.com> >> wrote: >>> >>> I will take suggestions on other questions that regular users can answer >>> easily, but would stump (for a bit anyway) a bot, or bot author. >> >> Why not the good and old random math questions inside an image? For >> example 2 + 4 = ... >> >> > > A bot should be able to figure that out too, unless the answer is also a > picture. > > Maybe A+B = ? The answer being AB. > > Don't know if any of this is possible with the software, however. > > > >

Oct. 20, 2011

Re: Anyone wants to ban spammer on forum

by Ken Sharp

On 20/10/11 4:13 PM, Bruno Jesus wrote: > On Thu, Oct 20, 2011 at 11:48, Jeremy Newman<jnewman(a)codeweavers.com> wrote: >> I will take suggestions on other questions that regular users can answer >> easily, but would stump (for a bit anyway) a bot, or bot author. > Why not the good and old random math questions inside an image? For > example 2 + 4 = ... > > A bot should be able to figure that out too, unless the answer is also a picture. Maybe A+B = ? The answer being AB. Don't know if any of this is possible with the software, however.

Oct. 20, 2011

Re: 80186: [PATCH 2/2] dinput: Restore checks for DirectX 3 buffer size.

by Dan Kegel

Hi Vitaliy, could you check on win64? I had a test failure there with your patch. - Dan On Thu, Oct 20, 2011 at 7:49 AM, <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-x86_64 while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default-x86_64/builds/769 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine dinput_test.exe.so device.c > device.c:117: Test failed: GetDeviceData() should have failed: 80040207 > device.c:120: Test failed: GetDeviceData() should have failed: 80040207 > device.c:117: Test failed: GetDeviceData() should have failed: 80040207 > device.c:120: Test failed: GetDeviceData() should have failed: 80040207 > device.c:117: Test failed: GetDeviceData() should have failed: 80040207 > device.c:120: Test failed: GetDeviceData() should have failed: 80040207 > device.c:117: Test failed: GetDeviceData() should have failed: 80040207 > device.c:120: Test failed: GetDeviceData() should have failed: 80040207 > make: *** [device.ok] Error 8 > >

Oct. 20, 2011

Re: Anyone wants to ban spammer on forum

by Bruno Jesus

On Thu, Oct 20, 2011 at 11:48, Jeremy Newman <jnewman(a)codeweavers.com> wrote: > I will take suggestions on other questions that regular users can answer > easily, but would stump (for a bit anyway) a bot, or bot author. Why not the good and old random math questions inside an image? For example 2 + 4 = ...

Oct. 20, 2011

Re: Anyone wants to ban spammer on forum

by Jeremy Newman

On 10/19/2011 08:03 PM, Vitaliy Margolen wrote: >> The new question is: >> What operating system does Wine run applications from? >> >> Should be obvious for a human. I will take suggestions on other questions that regular users can answer easily, but would stump (for a bit anyway) a bot, or bot author. Our textual question thing, does have the ability to randomly pick from a list of questions. Limiting it to just one makes it easier for a bot author to work around. > Any ETA on the new version of PHPBB? Soon-ish. Upgrading from v2 to v3 is fairly staight forward with the build in conversion tools. I just need find some time to convert our theme files to work on v3. -N

Oct. 20, 2011

Re: attrib: Use FormatMessageW() for better internationalization support.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > @@ -72,10 +72,12 @@ static int ATTRIB_wprintf(const WCHAR *format, ...) { > } > > va_start(parms, format); > - len = vsnprintfW(output_bufW, MAX_WRITECONSOLE_SIZE/sizeof(WCHAR), format, parms); > + SetLastError(NO_ERROR); > + len = FormatMessageW(FORMAT_MESSAGE_FROM_STRING, format, 0, 0, output_bufW, > + MAX_WRITECONSOLE_SIZE/sizeof(*output_bufW), &parms); You have to use __ms_va_list with FormatMessage for it to work properly on 64-bit. -- Alexandre Julliard julliard(a)winehq.org

Oct. 20, 2011

Re: vbscript: Added Global_isNull implementation

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=15023 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. 20, 2011

Re: Anyone wants to ban spammer on forum

by Vitaliy Margolen

On 10/19/2011 09:49 AM, Jeremy Newman wrote: > On 10/19/2011 10:21 AM, Tijl Coosemans wrote: >> The past few days there's been spam messages every few minutes and as >> soon as you ban an account an other one appears. Obviously the bots have >> figured out the answer to the captcha. > > Alrighty then, time for me to change the question... Done! > > The new question is: > What operating system does Wine run applications from? > > Should be obvious for a human. Hope that won't upset users of other well known OS <g>. Any ETA on the new version of PHPBB? Vitaliy.

Oct. 20, 2011

Re: Regression testing breakthrough

by Hin-Tak Leung

I have two suggestions - - git clone has a "--depth" option which does a shallow clone (i.e. with some history removed). - you can use "git-archive" to export arbitrary commits out as a tar ball dynamically; there is no need to have store a tar ball permanently. That said, I am doubtful about the usefulness of this in a linux environment, because the system libraries (in the general sense - libjpeg, etc) varies between different linux distros. --- On Wed, 19/10/11, Joel Holdsworth <joel(a)airwebreathe.org.uk> wrote: Alternatively, have you considered doing a .tar.gz of every build snapshot, and placing that on a server somewhere? e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? Then one could write a simple wine regression bisect tool that implements similar semantics to git bisect, but would essentially wrap wget. Then in your server you could have an index file which is a list of the sha commit ids. This would save the user having to clone a 26Gb repository when most of the commits will be irrelevant. Extra bonus points for doing a better job of compressing the small deltas between binaries*, rather than compressing full wine builds. Joel * Are binaries deterministic like this? or do they tend to be completely scrambled? On 18 October 2011 at 09:45 Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Hi > > Since the beginning, I've had issues with regression testing. Despite the > fact it's very useful, it takes forever, it's easy to make a mistake > (especially during "reverse regression testing"), users find it too long and > technical, and only a small minority of regressions are ever bisected. And > several patches need backporting to allow older versions of Wine to compile > and run on today's make, gcc, and libraries - this is the case even for the > 1.0.x releases from less than 3 years ago! > > The problem is of course compilation. "configure" takes at least 40 seconds, > without any way to speed it up on multi-core CPUs. "make" takes > 5 minutes, > and it's only taking longer as Wine gets bigger. Compilation is > fundamentally complex and technical to users. > > But what if we had precompiled binaries, and regression testing consisted of > just running different versions of Wine? > > Wine binaries take up about 122 MB and take over 5 minutes to compile. > There's now 35770 commits between 36def4af0ca85a1d0e66b5207056775bcb3b09ff > (Release 1.0) and "origin". That's about 4.4 terrabytes of storage and over > 4 months of compilation, if each of those versions had to be compiled and > installed into its own prefix, way beyond what most users are willing or > able to store or do. Most patches however end up affecting only a few binary > files in the end, and compiling successive versions allows "make" to be very > quick. > > So I've written a tool that compiles Wine and adds each commit's binaries > into a Git repository. It knows how to compile old versions of Wine > (currently as far back as 1.0). It knows that commits affecting only > ANNOUNCE, .gitignore, and files in dll/ or programs/ ending with .c and such > don't need to go through the endlessly slow "configure", only "make". It is > stateless: if interrupted, it can resume from the last successful commit. It > works around bugs in GNU make (you won't believe how many there are...). > > 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 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? > > Any other ideas? Would you like to see this tool? Can I send an attachment > with it? > > Thank you > Damjan Jovanovic

Oct. 20, 2011

Re: Bug 28791: ensure that dashes value is not 0 for PS_USERSTYLE linestyles

by Damian Dixon

Just removing the zeros will shift the pattern to the left potentially producing an effect that is not expected. I will take a look at what happens on Windows to see what needs to be replicated. On 19 October 2011 20:05, Alexandre Julliard <julliard(a)winehq.org> wrote: > damian dixon <damian.dixon(a)gmail.com> writes: > > > diff --git a/dlls/winex11.drv/pen.c b/dlls/winex11.drv/pen.c > > index b677515..71b1bea 100644 > > --- a/dlls/winex11.drv/pen.c > > +++ b/dlls/winex11.drv/pen.c > > @@ -108,7 +108,7 @@ HPEN X11DRV_SelectPen( PHYSDEV dev, HPEN hpen ) > > case PS_USERSTYLE: > > physDev->pen.dash_len = min(elp->elpNumEntries, > MAX_DASHLEN); > > for(i = 0; i < physDev->pen.dash_len ; i++) > > - physDev->pen.dashes[i] = min(elp->elpStyleEntry[i], > 255); > > + physDev->pen.dashes[i] = min(elp->elpStyleEntry[i], 255) > ? min(elp->elpStyleEntry[i], 255) : 1; > > Removing 0 entries (and merging the adjacent entries) would probably be > more correct. It could also use some test cases. > > -- > Alexandre Julliard > julliard(a)winehq.org >

Oct. 19, 2011

Re: Bug 28791: ensure that dashes value is not 0 for PS_USERSTYLE linestyles

by Alexandre Julliard

damian dixon <damian.dixon(a)gmail.com> writes: > diff --git a/dlls/winex11.drv/pen.c b/dlls/winex11.drv/pen.c > index b677515..71b1bea 100644 > --- a/dlls/winex11.drv/pen.c > +++ b/dlls/winex11.drv/pen.c > @@ -108,7 +108,7 @@ HPEN X11DRV_SelectPen( PHYSDEV dev, HPEN hpen ) > case PS_USERSTYLE: > physDev->pen.dash_len = min(elp->elpNumEntries, MAX_DASHLEN); > for(i = 0; i < physDev->pen.dash_len ; i++) > - physDev->pen.dashes[i] = min(elp->elpStyleEntry[i], 255); > + physDev->pen.dashes[i] = min(elp->elpStyleEntry[i], 255) ? min(elp->elpStyleEntry[i], 255) : 1; Removing 0 entries (and merging the adjacent entries) would probably be more correct. It could also use some test cases. -- Alexandre Julliard julliard(a)winehq.org

Oct. 19, 2011

Re: [PATCH 2/2] vbscript: Added Global_IsEmpty implementation

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=15011 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. 19, 2011

Re: Fix Bug 23124 with an "ln -s"

by Austin English

On Tue, Oct 18, 2011 at 17:25, Ken Sharp <kennybobs(a)o2.co.uk> wrote: > http://bugs.winehq.org/show_bug.cgi?id=23124 > > Could someone tell me if the attached patch would actually work? > > It does compile and works correctly with LANG=en_PH.utf-8 but I'm don't know > that: > > 1. Using an "ln -s" is acceptable, nor if it will work given some file > systems may be unable to use soft links. This will break the mingw/cygwin builds, as well as compiling on fat32 (already broken, but let's not make it worse..). You'll need to do this using autoconf/Makefile magic, $(LN_S), which will use `cp -p` on systems that don't support `ln -s`. -- -Austin

Oct. 19, 2011

Re: vbscript: Added Global_IsEmpty implementation

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=15010 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. 19, 2011

Re: vbscript: Added Global_IsEmpty implementation

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=15010 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. 19, 2011

Re: 80141: vbscript: Added Global_IsEmpty implementation

by Jacek Caban

On 10/19/11 7:11 PM, Dan Kegel wrote: > Hi Jacek, > build failed here... did you forget #include<assert.h> ? > Yes, it was added by another patch in my tree, thanks. Jacek

Oct. 19, 2011

Re: 80141: vbscript: Added Global_IsEmpty implementation

by Dan Kegel

Hi Jacek, build failed here... did you forget #include <assert.h> ? On Wed, Oct 19, 2011 at 9:56 AM, <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/715 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > global.c: In function 'Global_IsEmpty': > global.c:281:5: error: implicit declaration of function 'assert' [-Werror=implicit-function-declaration] > make[1]: *** [global.o] Error 1 > make: *** [dlls/vbscript] Error 2 > make: *** Waiting for unfinished jobs.... > >

Oct. 19, 2011

Re: Anyone wants to ban spammer on forum

by Ken Sharp

On 19/10/11 16:49, Jeremy Newman wrote: > On 10/19/2011 10:21 AM, Tijl Coosemans wrote: >> The past few days there's been spam messages every few minutes and as >> soon as you ban an account an other one appears. Obviously the bots have >> figured out the answer to the captcha. > > Alrighty then, time for me to change the question... Done! > > The new question is: > What operating system does Wine run applications from? > > Should be obvious for a human. Including the human who wrote the bot? > > -N > > >

Oct. 19, 2011

Re: Anyone wants to ban spammer on forum

by Paul Romanyszyn

On 10/19/2011 11:21 AM, Tijl Coosemans wrote: > On Wednesday 19 October 2011 14:08:14 L. Rahyen wrote: >> On 2011-10-19 (October, Wednesday) 02:37:41 Vitaliy Margolen wrote: >>> On 10/18/2011 07:37 PM, Vitaliy Margolen wrote: >>>> So any admins actually watching and want to bad roberbdib3a on forum? >>>> >>>> Also why aren't every moderator has these rights to block spammers, >>>> since we have only one forum. >>> >>> So no takers? I'm guessing we need more forum admins then, so more >>> timezones can be covered. >> >> I agree. I and other morerators have deleted spam messages, but the >> spammer kept using the same account to post more. Inability to ban >> spammer's account is frustrating. I would happely volonteer to be >> forum admin so I can ban spammers. > > The past few days there's been spam messages every few minutes and as > soon as you ban an account an other one appears. Obviously the bots have > figured out the answer to the captcha. > > > > Any way to determine IP address and do something like failtoban and lock the IP our for a few hours. This should be a firewall function not forum software. Paul R.

Oct. 19, 2011

Re: Anyone wants to ban spammer on forum

by Jeremy Newman

On 10/19/2011 10:21 AM, Tijl Coosemans wrote: > The past few days there's been spam messages every few minutes and as > soon as you ban an account an other one appears. Obviously the bots have > figured out the answer to the captcha. Alrighty then, time for me to change the question... Done! The new question is: What operating system does Wine run applications from? Should be obvious for a human. -N

Oct. 19, 2011

Re: Anyone wants to ban spammer on forum

by Tijl Coosemans

On Wednesday 19 October 2011 14:08:14 L. Rahyen wrote: > On 2011-10-19 (October, Wednesday) 02:37:41 Vitaliy Margolen wrote: >> On 10/18/2011 07:37 PM, Vitaliy Margolen wrote: >>> So any admins actually watching and want to bad roberbdib3a on forum? >>> >>> Also why aren't every moderator has these rights to block spammers, >>> since we have only one forum. >> >> So no takers? I'm guessing we need more forum admins then, so more >> timezones can be covered. > > I agree. I and other morerators have deleted spam messages, but the > spammer kept using the same account to post more. Inability to ban > spammer's account is frustrating. I would happely volonteer to be > forum admin so I can ban spammers. The past few days there's been spam messages every few minutes and as soon as you ban an account an other one appears. Obviously the bots have figured out the answer to the captcha.

Oct. 19, 2011

Re: Regression testing breakthrough

by Marcus Meissner

On Wed, Oct 19, 2011 at 04:18:50PM +0200, Frédéric Delanoy wrote: > On Wed, Oct 19, 2011 at 15:50, Marcus Meissner <meissner(a)suse.de> wrote: > > On Wed, Oct 19, 2011 at 02:42:29PM +0100, Ken Sharp wrote: > >> > >> > >> On 19/10/11 13:43, Frédéric Delanoy wrote: > >> >On Wed, Oct 19, 2011 at 14:08, Joel Holdsworth<joel(a)airwebreathe.org.uk> wrote: > >> >>Alternatively, have you considered doing a .tar.gz of every build snapshot, > >> >>and placing that on a server somewhere? > >> >> > >> >>e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? > >> > > >> >tar.xz would compress better > >> > >> tar.lzma? > > > > Having tars of all builds would be way larger I guess. GIT compresses and > > shares objects that are the same. > > > > Ciao, Marcus > > You're talking about using a git tree just to store binaries for each > committed patch, I suppose? > But then you would have to download the whole repository (which can be > quite big) to get compression benefits, right? True, yes. Ciao, Marcus

Oct. 19, 2011

Re: 80135: [PATCH 05/10] gdi32: Implement SetPixel.

by Huw Davies

On Wed, Oct 19, 2011 at 07:04:02AM -0700, Dan Kegel wrote: > Sounds like your temporary todo_wine didn't quite do the trick...? Ah, I see. I was getting a failure on 111 and not 104, presumably due to different XServers. Anyway they all pass again after the entire series is applied. Huw.

Oct. 19, 2011

Re: Regression testing breakthrough

by Frédéric Delanoy

On Wed, Oct 19, 2011 at 15:50, Marcus Meissner <meissner(a)suse.de> wrote: > On Wed, Oct 19, 2011 at 02:42:29PM +0100, Ken Sharp wrote: >> >> >> On 19/10/11 13:43, Frédéric Delanoy wrote: >> >On Wed, Oct 19, 2011 at 14:08, Joel Holdsworth<joel(a)airwebreathe.org.uk> wrote: >> >>Alternatively, have you considered doing a .tar.gz of every build snapshot, >> >>and placing that on a server somewhere? >> >> >> >>e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? >> > >> >tar.xz would compress better >> >> tar.lzma? > > Having tars of all builds would be way larger I guess. GIT compresses and > shares objects that are the same. > > Ciao, Marcus You're talking about using a git tree just to store binaries for each committed patch, I suppose? But then you would have to download the whole repository (which can be quite big) to get compression benefits, right?

Oct. 19, 2011

Re: 80135: [PATCH 05/10] gdi32: Implement SetPixel.

by Dan Kegel

On Wed, Oct 19, 2011 at 6:59 AM, Huw Davies <huw(a)codeweavers.com> wrote: > On Wed, Oct 19, 2011 at 06:46:49AM -0700, Dan Kegel wrote: >> Patches 5-7 failed on WINEDEBUG=warn+heap here: >> palette.c:104: Test failed: getColor=00280000 >> Might be flaky; patch 8 passed. patches 9 and 10 aren't done testing yet. > > It's because I wanted to move SetPixel and GetPixel in separate > patches. I added a temporary todo_wine in patch 5 (SetPixel) to > prevent this test failure, which then got removed in patch 8 > (GetPixel). Sounds like your temporary todo_wine didn't quite do the trick...?

Oct. 19, 2011

Re: 80135: [PATCH 05/10] gdi32: Implement SetPixel.

by Huw Davies

On Wed, Oct 19, 2011 at 06:46:49AM -0700, Dan Kegel wrote: > Patches 5-7 failed on WINEDEBUG=warn+heap here: > > ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p > gdi32_test.exe.so palette.c && touch palette.ok > ... > palette.c:104: Test failed: getColor=00280000 > > Might be flaky; patch 8 passed. patches 9 and 10 aren't done testing yet. It's because I wanted to move SetPixel and GetPixel in separate patches. I added a temporary todo_wine in patch 5 (SetPixel) to prevent this test failure, which then got removed in patch 8 (GetPixel). Huw.

Oct. 19, 2011

Re: Regression testing breakthrough

by Marcus Meissner

On Wed, Oct 19, 2011 at 02:42:29PM +0100, Ken Sharp wrote: > > > On 19/10/11 13:43, Frédéric Delanoy wrote: > >On Wed, Oct 19, 2011 at 14:08, Joel Holdsworth<joel(a)airwebreathe.org.uk> wrote: > >>Alternatively, have you considered doing a .tar.gz of every build snapshot, > >>and placing that on a server somewhere? > >> > >>e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? > > > >tar.xz would compress better > > tar.lzma? Having tars of all builds would be way larger I guess. GIT compresses and shares objects that are the same. Ciao, Marcus

Oct. 19, 2011

Re: 80135: [PATCH 05/10] gdi32: Implement SetPixel.

by Dan Kegel

Patches 5-7 failed on WINEDEBUG=warn+heap here: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so palette.c && touch palette.ok ... palette.c:104: Test failed: getColor=00280000 Might be flaky; patch 8 passed. patches 9 and 10 aren't done testing yet. On Wed, Oct 19, 2011 at 6:18 AM, <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-heaptest while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-heaptest/builds/673 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine gdi32_test.exe.so palette.c > palette.c:104: Test failed: getColor=00280000 > make: *** [palette.ok] Error 1 > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > GnuTLS error: A TLS packet with unexpected length was received. > >

Oct. 19, 2011

Re: Regression testing breakthrough

by Ken Sharp

On 19/10/11 13:43, Frédéric Delanoy wrote: > On Wed, Oct 19, 2011 at 14:08, Joel Holdsworth<joel(a)airwebreathe.org.uk> wrote: >> Alternatively, have you considered doing a .tar.gz of every build snapshot, >> and placing that on a server somewhere? >> >> e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? > > tar.xz would compress better tar.lzma?

Oct. 19, 2011

Re: Anyone wants to ban spammer on forum

by Ken Sharp

On 19/10/11 03:37, Vitaliy Margolen wrote: > On 10/18/2011 07:37 PM, Vitaliy Margolen wrote: >> So any admins actually watching and want to bad roberbdib3a on forum? >> >> Also why aren't every moderator has these rights to block spammers, >> since we >> have only one forum. >> > So no takers? I'm guessing we need more forum admins then, so more > timezones can be covered. I rarely use the forums but if it's that bad I would happily look in a few times a day. UTC+1 > > Vitaliy. > > >

Oct. 19, 2011

Re: [PATCH 1/2] gdi32: Add a string table resource for the translation.

by Alexandre Julliard

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > On Tue, 18 Oct 2011 16:14:36 +0200, Alexandre Julliard wrote: >> Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: >> >> > @@ -1,7 +1,7 @@ >> > EXTRADEFS = -D_GDI32_ >> > MODULE = gdi32.dll >> > IMPORTLIB = gdi32 >> > -IMPORTS = advapi32 >> > +IMPORTS = advapi32 user32 >> >> You don't want to import user32 from gdi32. > > LoadStringW is in user32.dll. Should I use DELAYIMPORTS instead? No, you should do it by hand using kernel32 resource functions. And you should do that only when needed, not on every startup. -- Alexandre Julliard julliard(a)winehq.org

Oct. 19, 2011

Re: Regression testing breakthrough

by Frédéric Delanoy

On Wed, Oct 19, 2011 at 14:08, Joel Holdsworth <joel(a)airwebreathe.org.uk> wrote: > Alternatively, have you considered doing a .tar.gz of every build snapshot, > and placing that on a server somewhere? > > e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? tar.xz would compress better > Then one could write a simple wine regression bisect tool that implements > similar semantics to git bisect, but would essentially wrap wget. Then in > your server you could have an index file which is a list of the sha commit > ids. > > This would save the user having to clone a 26Gb repository when most of the > commits will be irrelevant. Cloning a multi-gig repository is a no-go for many (most?) people, especially for a regression testing they might do only once or twice... > > Extra bonus points for doing a better job of compressing the small deltas > between binaries*, rather than compressing full wine builds. Maybe you could use stuff like xdelta or bsdiff, but then you may have some issues IMO: - (not sure) you should use them on non-compressed files (e.g. .tar) to get small diffs - the total size of individual diffs to download could exceed a single, full, download (especially for old regressions) To make regression faster/easier, we could (in a script of some sort) - phase 1: detect the "release range failure" (failed between wine-1.X.N and wine-1.X.N+1) using only release binaries [or instruct people to do that first using their distrib packages, like RegressionTesting does IIRC] - phase 2: perform bisect between these two releases Just my 2 ¢ Frédéric

Oct. 19, 2011

Re: [3/7] d3d9/tests: Add a test for locking partial blocks (try 2)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 19.10.2011 um 11:49 schrieb Henri Verbeet: > On 18 October 2011 17:37, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> patch 3/7". The point is that test_lockrect_offset() is about the >> offset calculation, not so much about what valid rectangles for block >> based formats are. Tbh I don't see the point in separating those two since both are determined by the block size, but OK. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJOnsGzAAoJEN0/YqbEcdMw3TkP/Rbg9Of3+rt2VGa+5WfEMQm+ 9RMhEEKczrRESh2vqDTpgufsIvGOwrbAmeDG7s89KpUwIBKawyoJhg2lR84/hwH5 DCyUxqKqYDbZzQt84AxHhEUfSvqCa7K4myLIT4BK1IFksI81NSVDTuYL/DtOWuFN KCx2J+z/BlZsURpJM2bGOmDbdy3iLuTYtSNuZFmjNbYVKYKSF3vGXQ1gUEmAdOFn i4BT+WhpFaVBN/YxXIlmwQ7lWuwiJwWDZZAiIAyTZAp+n9H0VE6P49y4kpH8otab AC3p5VV2QlmQyG2iir6WkYX4N/9z8cq6Mv/FRC87IZsIWPAS05XlJdAdWUlaAvO6 Gm81Gxd3WILnKtYvp9g2xhqesd4ZSVQyXNonglcLmKLIbR7hEGm7MWW+V7gyZrCF pjLDMlsg9h8ket7Dcpi9hA/q/8ChYh/dw7LKR8fbAcujgiCQaS3aork/O3CnVenu GO6rZtqFOj19gDcClbD07h8bDnPvKLMeCXNt7S4QIUhrQ8LAzLG1YDHogDxmNAau EDdq4dkfuabbJkMSiDeRAGsMHY99fSk+7fB8pOsEx2AgP2GnfynePboshsDVp3ri 0pKMklL4/2EsYZjca4x6ejqh2+iTdwlWiddIQa60vV9XolEHp4/TM4tIKCUdzfzJ fT3zosKQ6ZakgJ3KopoS =XwMm -----END PGP SIGNATURE-----

Oct. 19, 2011

Re: Anyone wants to ban spammer on forum

by L. Rahyen

On 2011-10-19 (October, Wednesday) 02:37:41 Vitaliy Margolen wrote: > On 10/18/2011 07:37 PM, Vitaliy Margolen wrote: > > So any admins actually watching and want to bad roberbdib3a on forum? > > > > Also why aren't every moderator has these rights to block spammers, since > > we have only one forum. > > So no takers? I'm guessing we need more forum admins then, so more > timezones can be covered. I agree. I and other morerators have deleted spam messages, but the spammer kept using the same account to post more. Inability to ban spammer's account is frustrating. I would happely volonteer to be forum admin so I can ban spammers.

Oct. 19, 2011

Re: Regression testing breakthrough

by Joel Holdsworth

Alternatively, have you considered doing a .tar.gz of every build snapshot, and placing that on a server somewhere? e.g. a folder full of36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? Then one could write a simple wine regression bisect tool that implements similar semantics to git bisect, but would essentially wrap wget. Then in your server you could have an index file which is a list of the sha commit ids. This would save the user having to clone a 26Gb repository when most of the commits will be irrelevant. Extra bonus points for doing a better job of compressing the small deltas between binaries*, rather than compressing full wine builds. Joel * Are binaries deterministic like this? or do they tend to be completely scrambled? On 18 October 2011 at 09:45 Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Hi > > Since the beginning, I've had issues with regression testing. Despite the > fact it's very useful, it takes forever, it's easy to make a mistake > (especially during "reverse regression testing"), users find it too long and > technical, and only a small minority of regressions are ever bisected. And > several patches need backporting to allow older versions of Wine to compile > and run on today's make, gcc, and libraries - this is the case even for the > 1.0.x releases from less than 3 years ago! > > The problem is of course compilation. "configure" takes at least 40 seconds, > without any way to speed it up on multi-core CPUs. "make" takes > 5 minutes, > and it's only taking longer as Wine gets bigger. Compilation is > fundamentally complex and technical to users. > > But what if we had precompiled binaries, and regression testing consisted of > just running different versions of Wine? > > Wine binaries take up about 122 MB and take over 5 minutes to compile. > There's now 35770 commits between 36def4af0ca85a1d0e66b5207056775bcb3b09ff > (Release 1.0) and "origin". That's about 4.4 terrabytes of storage and over > 4 months of compilation, if each of those versions had to be compiled and > installed into its own prefix, way beyond what most users are willing or > able to store or do. Most patches however end up affecting only a few binary > files in the end, and compiling successive versions allows "make" to be very > quick. > > So I've written a tool that compiles Wine and adds each commit's binaries > into a Git repository. It knows how to compile old versions of Wine > (currently as far back as 1.0). It knows that commits affecting only > ANNOUNCE, .gitignore, and files in dll/ or programs/ ending with .c and such > don't need to go through the endlessly slow "configure", only "make". It is > stateless: if interrupted, it can resume from the last successful commit. It > works around bugs in GNU make (you won't believe how many there are...). > > 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 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? > > Any other ideas? Would you like to see this tool? Can I send an attachment > with it? > > Thank you > Damjan Jovanovic

Oct. 19, 2011

Re: [3/7] d3d9/tests: Add a test for locking partial blocks (try 2)

by Henri Verbeet

On 18 October 2011 17:37, Henri Verbeet <hverbeet(a)gmail.com> wrote: > patch 3/7". The point is that test_lockrect_offset() is about the > offset calculation, not so much about what valid rectangles for block > based formats are.

Oct. 19, 2011

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

by Dmitry Timoshkov

Alex Henrie <alexhenrie24(a)gmail.com> wrote: > - WideCharToMultiByte( CP_ACP, 0, msgW, -1, msg, sizeof(msg), NULL, NULL ); > + WideCharToMultiByte( CP_UTF8, 0, msgW, -1, msg, sizeof(msg), NULL, NULL ); > MESSAGE( "wine: %s", msg ); Try CP_UNIXCP intead. -- Dmitry.

Oct. 19, 2011

Re: [PATCH 1/2] gdi32: Add a string table resource for the translation.

by Akihiro Sagawa

On Tue, 18 Oct 2011 16:14:36 +0200, Alexandre Julliard wrote: > Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > > > @@ -1,7 +1,7 @@ > > EXTRADEFS = -D_GDI32_ > > MODULE = gdi32.dll > > IMPORTLIB = gdi32 > > -IMPORTS = advapi32 > > +IMPORTS = advapi32 user32 > > You don't want to import user32 from gdi32. LoadStringW is in user32.dll. Should I use DELAYIMPORTS instead? -- Akihiro Sagawa

Oct. 19, 2011

Re: Anyone wants to ban spammer on forum

by Vitaliy Margolen

On 10/18/2011 07:37 PM, Vitaliy Margolen wrote: > So any admins actually watching and want to bad roberbdib3a on forum? > > Also why aren't every moderator has these rights to block spammers, since we > have only one forum. > So no takers? I'm guessing we need more forum admins then, so more timezones can be covered. Vitaliy.

Oct. 19, 2011

Anyone wants to ban spammer on forum

by Vitaliy Margolen

So any admins actually watching and want to bad roberbdib3a on forum? Also why aren't every moderator has these rights to block spammers, since we have only one forum. - Vitaliy

Oct. 19, 2011

Fix Bug 23124 with an "ln -s"

by Ken Sharp

http://bugs.winehq.org/show_bug.cgi?id=23124 Could someone tell me if the attached patch would actually work? It does compile and works correctly with LANG=en_PH.utf-8 but I'm don't know that: 1. Using an "ln -s" is acceptable, nor if it will work given some file systems may be unable to use soft links. 2. I have correctly edited configure, configure.ac and LINGUAS, or even if I need to edit both. Thanks all, Ken

Oct. 19, 2011

Re: 80121: aclocal.m4: fix compiles on systems that don't support ln -s

by Austin English

On Tue, Oct 18, 2011 at 16:34, <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/678 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > make[1]: *** [avifile.dll16.so] Error 2 > make: *** [dlls/avifile.dll16] Error 2 > make: *** Waiting for unfinished jobs.... Hm, worked here, though trying it again with plain make rather than make -jX, fails. Needs more investigation. Please don't commit. -- -Austin

Oct. 18, 2011

Re: [3/7] d3d9/tests: Add a test for locking partial blocks (try 2)

by Stefan Dösinger

On Tuesday 18 October 2011 20:12:35 Stefan Dösinger wrote: > On Tuesday 18 October 2011 19:36:33 Stefan Dösinger wrote: > > I felt that merging the tests to test all format and pool combinations > > would cause needlessly complicated > > With a few simplifications like skipping all tests without dynamic textures > it turns out okish. It's not too pretty. There are still a bunch of checks > for caps and pools, but it should be readable. This is a version of the patch with both tests merged into one that tests all format-pool combinations. I'll resend the patches tomorrow unless you have further suggestions. I changed the d3d8 patch in a similar way.

Oct. 18, 2011

Odd valgrind warning on ubuntu 11.10 related to set_wm_hints

by Dan Kegel

I've added a suppression for this already to http://code.google.com/p/winezeug/source/browse/trunk/valgrind/valgrind-sup… It looks benign, but it's annoying because the suppression it needs is so wide. I wonder if the gcc bug on ubuntu 11.10 is why there's no useful backtrace there... Syscall param writev(vector[...]) points to uninitialised byte(s) at writev (writev.c:51) by 0x40004: ??? Address 0x4598748 is 160 bytes inside a block of size 16,384 alloc'd at calloc (vg_replace_malloc.c:467) by XOpenDisplay (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0) by x11drv_init_thread_data (x11drv_main.c:689) by thread_init_display (x11drv.h:580) by X11DRV_create_win_data (window.c:2030) by X11DRV_WindowPosChanging (window.c:2429) by set_window_pos (winpos.c:1951) by USER_SetWindowPos (winpos.c:2077) by SetWindowPos (winpos.c:2151) by show_window (winpos.c:1088) by ShowWindow (winpos.c:1186) by WIN_CreateWindowEx (win.c:1498) by CreateWindowExA (win.c:1550) by init (comboex.c:505) by func_comboex (comboex.c:598) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a stack allocation at set_wm_hints (window.c:1128)

Oct. 18, 2011

Re: registry keys of serial ports

by Stefan Leichter

Am Dienstag 18 Oktober 2011, 22:28:26 schrieb Uwe Bonnes: > Hello, > > while hunting down why a drop down box didn't offer me the serial port I > configured, I stumbled across Stefans proposal from Summer 09. The patch > still applied cleanly, and after setting up hal and the hal development > library, the progarm worked as expected. > > What is the status of that proposal? > > Thanks > Hello Uwe, all, looks like i forgot about the stuff for some reason. This is the first bad message. The second one is, that i do not have time to look into this before the end of the year. So if you or anybody else like to work on this stuff, feel free .. Stefan

Oct. 18, 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. > > Thank you :) > > 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 > > > Would you like to see this tool? Can I send an attachment with it? > > If the tool is not too big and is textual, why not > > I've opened a Google Code project: http://raisinrefinery.googlecode.com No releases yet, but you can: svn co http://raisinrefinery.googlecode.com/svn/trunk/RaisinRefinery cd RaisinRefinery mvn package java -jar RaisinRefinery/target/RetroRaisinCellar-0.1-SNAPSHOT.jar 8a7bc4c727fe6330efdfbbb24e6666ee39364c0d..origin /path/to/wine-git /path/to/binary-repository to compile the last 5 commits in today's Git.

Oct. 18, 2011

Re: registry keys of serial ports

by Uwe Bonnes

Hello, while hunting down why a drop down box didn't offer me the serial port I configured, I stumbled across Stefans proposal from Summer 09. The patch still applied cleanly, and after setting up hal and the hal development library, the progarm worked as expected. What is the status of that proposal? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Oct. 18, 2011

Re: po: Update English (US) translation

by Ken Sharp

On 18/10/11 6:35 PM, Alexandre Julliard wrote: > Ken Sharp<kennybobs(a)o2.co.uk> writes: > >> So any changes made should be in both the .rc files AND the .po files >> to keep them in sync? > I resynchronize en_US.po when committing, so you don't need to submit > that part. http://source.winehq.org/patches/data/79974 This should be right then?

Oct. 18, 2011

Re: po: Update English (US) translation

by Ken Sharp

On 18/10/11 6:35 PM, Alexandre Julliard wrote: > Ken Sharp<kennybobs(a)o2.co.uk> writes: > >> So any changes made should be in both the .rc files AND the .po files >> to keep them in sync? > I resynchronize en_US.po when committing, so you don't need to submit > that part. > Excellent, thanks Alexandre, that's what I was looking for. I'll resubmit.

Oct. 18, 2011

Re: Regression testing breakthrough

by André Hentschel

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 > Would you like to see this tool? Can I send an attachment with it? If the tool is not too big and is textual, why not -- Best Regards, André Hentschel

Oct. 18, 2011

Re: [3/7] d3d9/tests: Add a test for locking partial blocks (try 2)

by Stefan Dösinger

On Tuesday 18 October 2011 19:36:33 Stefan Dösinger wrote: > I felt that merging the tests to test all format and pool combinations > would cause needlessly complicated With a few simplifications like skipping all tests without dynamic textures it turns out okish. It's not too pretty. There are still a bunch of checks for caps and pools, but it should be readable.

Oct. 18, 2011

Re: [3/7] d3d9/tests: Add a test for locking partial blocks (try 2)

by Stefan Dösinger

On Tuesday 18 October 2011 17:37:09 Henri Verbeet wrote: > That's not really what I meant with "make this part of the test in > patch 3/7". The point is that test_lockrect_offset() is about the > offset calculation, not so much about what valid rectangles for block > based formats are. And it probably wouldn't hurt to run > test_partial_block_lock() on the other formats like e.g. ATI2N anyway. I felt that merging the tests to test all format and pool combinations would cause needlessly complicated code because some format-pool combinations require surfaces, some require dynamic textures, some require normal textures and some are unsupported. That's why I introduced the new test that loops only over the pools. On the other hand we may at some point care about the offset returned by a allowed partial block lock, which is why putting the per-format test in test_partial_block_lock correct imo. Strictly speaking the test now verifies the block sizes directly instead of just verifying them indirectly as a side product of testing the stride, so we might as well rename it. ATI2N is a good point though. The locking behavior matches the 1x1 "block" definition in the d3d9 test. I'll change the test to verify that we can indeed lock single pixels in formats that are supposedly block-free(and that we can lock single lines in YUY2/UYVY)

Oct. 18, 2011

Re: po: Update English (US) translation

by Alexandre Julliard

Ken Sharp <kennybobs(a)o2.co.uk> writes: > So any changes made should be in both the .rc files AND the .po files > to keep them in sync? I resynchronize en_US.po when committing, so you don't need to submit that part. -- Alexandre Julliard julliard(a)winehq.org

Oct. 18, 2011

Re: Regression testing breakthrough

by Austin English

On Tue, Oct 18, 2011 at 10:26, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Austin English <austinenglish(a)gmail.com> wrote: > > >> > Reverting a patch in latest git is not always possible, instead it's >> > a very useful test to revert the patch at the suspected regression point >> > and see if that really helps. >> >> That still doesn't require a full regression test, just: >> $ git checkout -f $SHA1SUM >> $ ./configure && make -j4 >> # test >> $ git show $SHA1SUM | patch -p1 -R >> $ ./configure && make -j4 >> # retest > > How do you know that $SHA1SUM without a regression test? I was referring to the case you pointed out: > Moreover, often users get asked 'does reverting commit xxxx' help? Without > performing a proper regression test it's impossible to asnwer that question. If a developer asks about a specific commit, then of course you know which one to try :). Otherwise, of course a full regression test is required. -- -Austin

Oct. 18, 2011

Re: Regression testing breakthrough

by Dmitry Timoshkov

Austin English <austinenglish(a)gmail.com> wrote: > > Reverting a patch in latest git is not always possible, instead it's > > a very useful test to revert the patch at the suspected regression point > > and see if that really helps. > > That still doesn't require a full regression test, just: > $ git checkout -f $SHA1SUM > $ ./configure && make -j4 > # test > $ git show $SHA1SUM | patch -p1 -R > $ ./configure && make -j4 > # retest How do you know that $SHA1SUM without a regression test? -- Dmitry.

Oct. 18, 2011

Re: Regression testing breakthrough

by Austin English

On Tue, Oct 18, 2011 at 09:01, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: >> > Moreover, often users get asked 'does reverting commit xxxx' help? Without >> > performing a proper regression test it's impossible to asnwer that >> > question. >> > >> > >> Reverting a commit in the latest git is just 1 round of >> patch+configure+make+run, and reverting to the commit before it in the >> binary repository is just one git command. Why would you need a "proper >> regression test"? > > Reverting a patch in latest git is not always possible, instead it's > a very useful test to revert the patch at the suspected regression point > and see if that really helps. That still doesn't require a full regression test, just: $ git checkout -f $SHA1SUM $ ./configure && make -j4 # test $ git show $SHA1SUM | patch -p1 -R $ ./configure && make -j4 # retest -- -Austin

Oct. 18, 2011

Re: po: Update English (US) translation

by Ken Sharp

On 18/10/11 17:05, Alexandre Julliard wrote: > Ken Sharp<kennybobs(a)o2.co.uk> writes: > >> Okay that should be simple enough, but what is po/en_US.po for then? >> Won't the translations in en_US.po override any US translations in the >> .rc files? > > Yes, but in general they should be identical. We have en_US.po because > there are cases where strings need to be different, for instance when > the .rc string contains a context, or non-ASCII chars. > So any changes made should be in both the .rc files AND the .po files to keep them in sync?

Oct. 18, 2011

Re: po: Update English (US) translation

by Alexandre Julliard

Ken Sharp <kennybobs(a)o2.co.uk> writes: > Okay that should be simple enough, but what is po/en_US.po for then? > Won't the translations in en_US.po override any US translations in the > .rc files? Yes, but in general they should be identical. We have en_US.po because there are cases where strings need to be different, for instance when the .rc string contains a context, or non-ASCII chars. -- Alexandre Julliard julliard(a)winehq.org

Oct. 18, 2011

Re: Regression testing breakthrough

by Dmitry Timoshkov

Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > Moreover, often users get asked 'does reverting commit xxxx' help? Without > > performing a proper regression test it's impossible to asnwer that > > question. > > > > > Reverting a commit in the latest git is just 1 round of > patch+configure+make+run, and reverting to the commit before it in the > binary repository is just one git command. Why would you need a "proper > regression test"? Reverting a patch in latest git is not always possible, instead it's a very useful test to revert the patch at the suspected regression point and see if that really helps. -- Dmitry.

Oct. 18, 2011

Re: Regression testing breakthrough

by Damjan Jovanovic

On Tue, Oct 18, 2011 at 2:32 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Henri Verbeet <hverbeet(a)gmail.com> wrote: > > > On 18 October 2011 10:45, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > > (especially during "reverse regression testing"), users find it too > long and > > > technical, and only a small minority of regressions are ever bisected. > And > > Not true. Even for the regressions that are still open it's currently > > 276 bisected vs. 99 not bisected, and Alexandre said about 90% of > > opened regressions get fixed. > > Moreover, often users get asked 'does reverting commit xxxx' help? Without > performing a proper regression test it's impossible to asnwer that > question. > > Reverting a commit in the latest git is just 1 round of patch+configure+make+run, and reverting to the commit before it in the binary repository is just one git command. Why would you need a "proper regression test"?

Oct. 18, 2011

Re: [3/7] d3d9/tests: Add a test for locking partial blocks (try 2)

by Henri Verbeet

On 18 October 2011 12:43, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Changes: Check for dynamic texture support, moved the format-specific tests to > this patch. > That's not really what I meant with "make this part of the test in patch 3/7". The point is that test_lockrect_offset() is about the offset calculation, not so much about what valid rectangles for block based formats are. And it probably wouldn't hurt to run test_partial_block_lock() on the other formats like e.g. ATI2N anyway.

Oct. 18, 2011

Re: po: Update English (US) translation

by Ken Sharp

On 18/10/11 16:15, Frédéric Delanoy wrote: > On Tue, Oct 18, 2011 at 17:01, Francois Gouget<fgouget(a)free.fr> wrote: >> My understanding it that en.po contains the British translation and is >> treated as just another translation. So instead of containing just the >> strings that need to be different, all the other strings are copied as >> well by the translators so they know what has been checked already. > > For clarity, we should probably have no en_US.po but only en.po (and > possibly other en_XX.po like en_GB.po) > maybe a soft link from en_US.po to en.po to make it clear) If en.po is British English there will be a fair few differences for en_US.po (and en_PH.po). > > The current situation (en.po and en_US.po) makes it look like en_US.po > is an "adapted" version of "standard" en.po (which is then presumably > en_GB), as is e.g. fr_CA vs fr.po > > This is not the first time someone adapts the en_US.po IIRC. > > Frédéric >

Oct. 18, 2011

Re: po: Update English (US) translation

by Ken Sharp

On 18/10/11 16:01, Francois Gouget wrote: > On Tue, 18 Oct 2011, Ken Sharp wrote: > [...] >> Okay that should be simple enough, but what is po/en_US.po for then? Won't the >> translations in en_US.po override any US translations in the .rc files? > > Currently it's 100% translated and I suspect all strings are simply > copied as is: > > 2524 (100.0%) translated, 0 (0.0%) fuzzy, 0 (0.0%) untranslated, total 2524 As I understand it, en_US is picked up by _ENGLISH_US or _DEFAULT. _DEFAULT obviously being the default English sublang, but also US should be the fallback. http://wiki.winehq.org/SublangNeutral So either _DEFAULT _is_ US English and hence only the _DEFAULT needs to be translated to US English (and hence there being no actual need for a US translation) or _DEFAULT should be in British English (and hence no need for a British translation). Of course the same link states that _NEUTRAL should be a British translation (and again _ENGLISH_BRITISH would serve no purpose). The other English sublangs pick up the translation from _NEUTRAL which makes sense, but _US picks up _DEFAULT. So... _DEFAULT = _US _NEUTRAL = _BRITISH _US = obsolete _BRITISH = obsolete And all other sublangs = _NEUTRAL > > > Where it gets a bit strange is that en.po is partially translated even > though it claims to be 'Automatically Generated' (so I'd expect either > 0% or 100%): I think the "Automatically Generated" statement comes from when they were created to replace .rc translations. This is updated automatically when using poedit by your own details, but I won't use poedit as it insists on changing the layout of the existing .po files (which may actually be for the best in the long-run). However, I may simply be misunderstanding this and they are automatically generated from the .rc files. If so then this would clear things up for me no end. I would finally see the light! > > 1748 (69.3%) translated, 0 (0.0%) fuzzy, 776 (30.7%) untranslated, total 2524 > > > My understanding it that en.po contains the British translation and is > treated as just another translation. So instead of containing just the > strings that need to be different, all the other strings are copied as > well by the translators so they know what has been checked already. > If en.po is British (and it is automatically generated) it *should* be picking up _NEUTRAL and _BRITISH translations from the .rc files. If this is the case then en_*.po (with the exception of en_US.po) will be almost identical. Could anyone clarify this? The translation Wiki entry doesn't make this abundantly clear to me. Apologies for the confusion.

Oct. 18, 2011

Re: po: Update English (US) translation

by Frédéric Delanoy

On Tue, Oct 18, 2011 at 17:01, Francois Gouget <fgouget(a)free.fr> wrote: > My understanding it that en.po contains the British translation and is > treated as just another translation. So instead of containing just the > strings that need to be different, all the other strings are copied as > well by the translators so they know what has been checked already. For clarity, we should probably have no en_US.po but only en.po (and possibly other en_XX.po like en_GB.po) maybe a soft link from en_US.po to en.po to make it clear) The current situation (en.po and en_US.po) makes it look like en_US.po is an "adapted" version of "standard" en.po (which is then presumably en_GB), as is e.g. fr_CA vs fr.po This is not the first time someone adapts the en_US.po IIRC. Frédéric

Oct. 18, 2011

Re: po: Update English (US) translation

by Francois Gouget

On Tue, 18 Oct 2011, Ken Sharp wrote: [...] > Okay that should be simple enough, but what is po/en_US.po for then? Won't the > translations in en_US.po override any US translations in the .rc files? Currently it's 100% translated and I suspect all strings are simply copied as is: 2524 (100.0%) translated, 0 (0.0%) fuzzy, 0 (0.0%) untranslated, total 2524 Where it gets a bit strange is that en.po is partially translated even though it claims to be 'Automatically Generated' (so I'd expect either 0% or 100%): 1748 (69.3%) translated, 0 (0.0%) fuzzy, 776 (30.7%) untranslated, total 2524 My understanding it that en.po contains the British translation and is treated as just another translation. So instead of containing just the strings that need to be different, all the other strings are copied as well by the translators so they know what has been checked already. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ All generalizations are false, including this one. -- Mark Twain

Oct. 18, 2011

Re: po: Update English (US) translation

by Ken Sharp

On 18/10/11 15:23, Alexandre Julliard wrote: > Ken Sharp<kennybobs(a)o2.co.uk> writes: > >> From 68519bf26da3d912bf92febc13a34ec00cfd7cc4 Mon Sep 17 00:00:00 2001 >> From: Ken Sharp<kennybobs(a)o2.co.uk> >> Date: Sat, 15 Oct 2011 03:50:43 +0100 >> Subject: [PATCH] po: Update English (US) translation > > There's no translation to update, the rc files are already en_US. If the > strings need changing they have to be changed in the rc files. > Okay that should be simple enough, but what is po/en_US.po for then? Won't the translations in en_US.po override any US translations in the .rc files?

Oct. 18, 2011

Re: po: Update English (US) translation

by Alexandre Julliard

Ken Sharp <kennybobs(a)o2.co.uk> writes: > From 68519bf26da3d912bf92febc13a34ec00cfd7cc4 Mon Sep 17 00:00:00 2001 > From: Ken Sharp <kennybobs(a)o2.co.uk> > Date: Sat, 15 Oct 2011 03:50:43 +0100 > Subject: [PATCH] po: Update English (US) translation There's no translation to update, the rc files are already en_US. If the strings need changing they have to be changed in the rc files. -- Alexandre Julliard julliard(a)winehq.org

Oct. 18, 2011

Re: [PATCH 1/2] gdi32: Add a string table resource for the translation.

by Alexandre Julliard

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > @@ -1,7 +1,7 @@ > EXTRADEFS = -D_GDI32_ > MODULE = gdi32.dll > IMPORTLIB = gdi32 > -IMPORTS = advapi32 > +IMPORTS = advapi32 user32 You don't want to import user32 from gdi32. -- Alexandre Julliard julliard(a)winehq.org

Oct. 18, 2011

Re: Regression testing breakthrough

by Frédéric Delanoy

On Tue, Oct 18, 2011 at 13:42, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > If you are talking about using compiling with ccache instead of the binary > repository, "configure" alone is > 40 seconds configure -C option can speed it up a lot

Oct. 18, 2011

Re: mshtml: Added IHTMLDocument2::elementFromPoint implementation

by Jacek Caban

On 10/18/11 15:22, Marvin wrote: > 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=14979 > > Your paranoid android. > > > === TEST64_W7SP1 (32 bit htmldoc) === > htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer > htmldoc.c:4446: Test failed: tag = L"BODY" > > === TEST64_W7SP1 (64 bit htmldoc) === > htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer > htmldoc.c:4446: Test failed: tag = L"BODY" That machine is already failing on a lot of tests and needs more work before its results are meaningful. Jacek

Oct. 18, 2011

Re: mshtml: Added IHTMLDocument2::elementFromPoint implementation

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=14979 Your paranoid android. === TEST64_W7SP1 (32 bit htmldoc) === htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer htmldoc.c:4446: Test failed: tag = L"BODY" === TEST64_W7SP1 (64 bit htmldoc) === htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer htmldoc.c:4446: Test failed: tag = L"BODY"

Oct. 18, 2011

Re: Regression testing breakthrough

by Dmitry Timoshkov

Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 18 October 2011 10:45, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > (especially during "reverse regression testing"), users find it too long and > > technical, and only a small minority of regressions are ever bisected. And > Not true. Even for the regressions that are still open it's currently > 276 bisected vs. 99 not bisected, and Alexandre said about 90% of > opened regressions get fixed. Moreover, often users get asked 'does reverting commit xxxx' help? Without performing a proper regression test it's impossible to asnwer that question. -- Dmitry.

Oct. 18, 2011

Re: Regression testing breakthrough

by Henri Verbeet

On 18 October 2011 13:42, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > There's currently another 182 regressions that were closed "ABANDONED". > Maybe if regression testing was easier and faster, people wouldn't abandon > them? > Maybe. That's 182 closed ABANDONED, out of 2590 total closed, so that's on the order of 5-10%. Perhaps it's possible to bring that down by making it easier to do bisects, but it's hardly the case that "only a small minority of regressions are ever bisected". > If you are talking about using compiling with ccache instead of the binary > repository, "configure" alone is > 40 seconds, while the average "git > bisect" on the binary repository is about 4. If you are talking about using > ccache to speed up building the binary repository commit by commit, why, > when for most commits "make" takes about 5 seconds and skips all unnecessary > compilation anyway? > > The other advantage I see is the convenience: instead of having to wait or > take breaks while each commit compiles like in normal regression testing, > you can have the tool compile you a small set of revisions (eg. the last > month) while you are away from your computer, then just quickly test them > all in one go when you come back. And you can regression test several > applications without repeatedly compiling Wine. > Regardless of whether this has much advantages over e.g. ccache, it does strike me that this would mostly be useful for people that do a lot of regression testing already. If it allows those people to do regressions tests faster and find more regressions or find them sooner that way that's great, but these aren't the same people that end up abandoning regressions. The problems there are typically more on the level of "What is git?" / "How do I build Wine?" / "Where do I get all these dependencies?", and typically someone would only do one or two bisects.

Oct. 18, 2011

Re: Regression testing breakthrough

by Scott Ritchie

Exciting! On 10/18/2011 01:45 AM, Damjan Jovanovic wrote: > 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? > > Any other ideas? Would you like to see this tool? Can I send an > attachment with it? > Perhaps you could use an intermediary server and a script. The user tells the script "works" or "doesn't" and then the script fetches the binary via rsync from a special directory on the server that has the git repo there. That way the user only needs to download the binaries he runs, and even then they'll be done incrementally via rsync magic. Thanks, Scott Ritchie

Oct. 18, 2011

Re: Regression testing breakthrough

by Damjan Jovanovic

On Tue, Oct 18, 2011 at 12:08 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 18 October 2011 10:45, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > (especially during "reverse regression testing"), users find it too long > and > > technical, and only a small minority of regressions are ever bisected. > And > Not true. Even for the regressions that are still open it's currently > 276 bisected vs. 99 not bisected, and Alexandre said about 90% of > opened regressions get fixed. > > There's currently another 182 regressions that were closed "ABANDONED". Maybe if regression testing was easier and faster, people wouldn't abandon them? > > 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? > > > > Any other ideas? Would you like to see this tool? Can I send an > attachment > > with it? > > > Scripts for making old versions compile may be useful, but for the > most part it sounds like you're essentially duplicating ccache. > If you are talking about using compiling with ccache instead of the binary repository, "configure" alone is > 40 seconds, while the average "git bisect" on the binary repository is about 4. If you are talking about using ccache to speed up building the binary repository commit by commit, why, when for most commits "make" takes about 5 seconds and skips all unnecessary compilation anyway? The other advantage I see is the convenience: instead of having to wait or take breaks while each commit compiles like in normal regression testing, you can have the tool compile you a small set of revisions (eg. the last month) while you are away from your computer, then just quickly test them all in one go when you come back. And you can regression test several applications without repeatedly compiling Wine.

Oct. 18, 2011