August 2012 - Wine-Devel - list.winehq.org

Re: Have there been any problems with Wine on GCC 4.7?

by Eric Pouech

> diff --git a/configure.ac b/configure.ac > index 4bd43d1..c80fd8a 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1746,6 +1746,8 @@ then > WINE_TRY_CFLAGS([-Wtype-limits]) > WINE_TRY_CFLAGS([-Wunused-but-set-parameter]) > WINE_TRY_CFLAGS([-Wwrite-strings]) > + WINE_TRY_CFLAGS([-gdwarf-2]) > + WINE_TRY_CFLAGS([-gstrict-dwarf]) > > dnl gcc-4.6+ omits frame pointers by default, breaking some copy protections > case $host_cpu in > > would be simpler, unless I'm missing something. > would work too (even if this would be preferable) + WINE_TRY_CFLAGS([-gdwarf-2 -gstrict-dwarf])

Aug. 13, 2012

Re: Have there been any problems with Wine on GCC 4.7?

by Austin English

On Mon, Aug 13, 2012 at 2:29 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > In the meantime, I suppose I could enable the -gdwarf-2 compiler option. > > > yes (but it's a bit more tricky than it sounds) > something like this will do > > A+ > > diff --git a/configure.ac b/configure.ac > index 4bd43d1..2624dc1 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -236,6 +236,12 @@ then > AC_SUBST(TARGETFLAGS,"-b $host_alias $TARGETFLAGS") > fi > > +dnl Check the debug format (force pure dwarf-2 debug format until we > correctly support other versions) > +tmp_cflags=$CFLAGS > +CFLAGS=`echo $CFLAGS | sed -e 's/-g\\>/-gdwarf-2 -gstrict-dwarf/'` > +AC_LINK_IFELSE([AC_LANG_SOURCE([[int main(int argc, char **argv) { return > 0; }]])], > + [], [CFLAGS=$tmp_cflags]) > + > dnl Check for flex > AC_CHECK_PROGS(FLEX,flex,none) > if test "$FLEX" = "none" > > > > diff --git a/configure.ac b/configure.ac index 4bd43d1..c80fd8a 100644 --- a/configure.ac +++ b/configure.ac @@ -1746,6 +1746,8 @@ then WINE_TRY_CFLAGS([-Wtype-limits]) WINE_TRY_CFLAGS([-Wunused-but-set-parameter]) WINE_TRY_CFLAGS([-Wwrite-strings]) + WINE_TRY_CFLAGS([-gdwarf-2]) + WINE_TRY_CFLAGS([-gstrict-dwarf]) dnl gcc-4.6+ omits frame pointers by default, breaking some copy protections case $host_cpu in would be simpler, unless I'm missing something. -- -Austin

Aug. 13, 2012

Re: [PATCH 3/3] [Msacm32]: in acmFormatChoose, added support for template

by Eric Pouech

Le 13/08/2012 09:51, Dmitry Timoshkov a écrit : > Eric Pouech <eric.pouech(a)orange.fr> wrote: > >>> It would look much better without all those 'ret' + 'else' things. >> well, wine doesn't have coding guidelines... >> so I don't know what "look much better" means (project wise) > For this particalr patch it means: > > 1. less code > 2. simpler code > 3. more readable code > > and has nothing to do with coding guidelines for the whole project. > > P.S. > I didn't even ask about the point in adding a bunch of spaces between > 'MMRESULT' and 'ret' :) > feel free to do it. I won't A+

Aug. 13, 2012

Re: Have there been any problems with Wine on GCC 4.7?

by Eric Pouech

> In the meantime, I suppose I could enable the -gdwarf-2 compiler option. yes (but it's a bit more tricky than it sounds) something like this will do A+ diff --git a/configure.ac b/configure.ac index 4bd43d1..2624dc1 100644 --- a/configure.ac +++ b/configure.ac @@ -236,6 +236,12 @@ then AC_SUBST(TARGETFLAGS,"-b $host_alias $TARGETFLAGS") fi +dnl Check the debug format (force pure dwarf-2 debug format until we correctly support other versions) +tmp_cflags=$CFLAGS +CFLAGS=`echo $CFLAGS | sed -e 's/-g\\>/-gdwarf-2 -gstrict-dwarf/'` +AC_LINK_IFELSE([AC_LANG_SOURCE([[int main(int argc, char **argv) { return 0; }]])], + [], [CFLAGS=$tmp_cflags]) + dnl Check for flex AC_CHECK_PROGS(FLEX,flex,none) if test "$FLEX" = "none"

Aug. 13, 2012

Re: [PATCH 2/4] wined3d: Fix pixel format alpha/red masks.

by Henri Verbeet

On 13 August 2012 20:20, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + * Pixel formats with more than 4 bpp do not have correct masks, because the > + * high masks do not fit into the 32 bit values needed for ddraw. The masks > + * are only used for ddraw mostly, and to figure out if the format has an alpha > + * component (the POSTPIXELSHADER_BLENDING test also uses those masks to know > + * if there is more than 1 alpha bit and a red component), so that doesn't > + * matter. The 64 and 128 bit formats are not supported by ddraw anyway. > */ We'll probably want these as offset + mask, or perhaps offset + size.

Aug. 13, 2012

Re: joy.cpl: Corrected misplaced elements when using high DPIs

by Alexandre Julliard

Lucas Zawacki <lfzawacki(a)gmail.com> writes: > From: Lucas Zawacki <lfzawacki(a)gmail.com> > > Fixes bug #31316 > > joy.cpl uses CreateWindow and SetWindowPos to draw some elements > and the hardcoded coordinates where wrong when the dpi was set to anything > bigger than 96px in winecfg. My approach to solve is normalize the > coordinates based on the dialog window size. You probably want to use MapDialogRect instead. -- Alexandre Julliard julliard(a)winehq.org

Aug. 13, 2012

Re: [PATCH 3/3] [Msacm32]: in acmFormatChoose, added support for template

by Dmitry Timoshkov

Eric Pouech <eric.pouech(a)orange.fr> wrote: > > It would look much better without all those 'ret' + 'else' things. > well, wine doesn't have coding guidelines... > so I don't know what "look much better" means (project wise) For this particalr patch it means: 1. less code 2. simpler code 3. more readable code and has nothing to do with coding guidelines for the whole project. P.S. I didn't even ask about the point in adding a bunch of spaces between 'MMRESULT' and 'ret' :) -- Dmitry.

Aug. 13, 2012

Re: [PATCH 3/3] [Msacm32]: in acmFormatChoose, added support for template

by Eric Pouech

> It would look much better without all those 'ret' + 'else' things. well, wine doesn't have coding guidelines... so I don't know what "look much better" means (project wise) A+ -- Eric Pouech

Aug. 13, 2012

Re: _vcomp_fork stack frame puzzle

by Dan Kegel

Using varargs like Andre tried doesn't work because pushing a va_list isn't the same as pushing a list of arguments. So I think we need assembly. The assembly I gave earlier is wrong because it cleans up the stack, which it's not allowed to do. I've attached an updated patch to http://bugs.winehq.org/show_bug.cgi?id=26688 with a _vcomp_fork that works for simple loops with and without bound variables. I guess the next step is porting the serial stub for _vcomp_fork to 64 bits.

Aug. 12, 2012

Re: Have there been any problems with Wine on GCC 4.7?

by Scott Ritchie

On 08/12/2012 01:08 AM, Eric Pouech wrote: > Le 24/07/2012 04:06, Scott Ritchie a écrit : >> Wine is the last remaining package still depending on GCC 4.5 in the >> current Ubuntu alpha, it would be nice to drop GCC 4.5 and forward port >> Wine, however 4.6 is known to not work too well. >> >> But now we have 4.7 -- have there been any bugs attributed to its usage? >> >> Thanks, >> Scott Ritchie >> >> >> > afaik, gcc 4.7 enables by default dwarf4 as its default debug format, > whilst wine (dbghelp) only supports dwarf2 > it generates a lot of conbursome backtraces in winegdb > I've started to add dwarf4 support to wine, but don't hold your breath > (it's going to be hard and tedious afaict and will require quite a few > changes to dbghelp for correctness) > (and I have little time right now <g>) > > BTW : fedora 17 ships with gcc 4.7 > > A+ > > > In the meantime, I suppose I could enable the -gdwarf-2 compiler option. Thanks, Scott Ritchie

Aug. 12, 2012

Re: [PATCH 3/3] [Msacm32]: in acmFormatChoose, added support for template

by Dmitry Timoshkov

Eric Pouech <eric.pouech(a)orange.fr> wrote: > MMRESULT WINAPI acmFormatChooseW(PACMFORMATCHOOSEW pafmtc) > { > - return DialogBoxParamW(MSACM_hInstance32, MAKEINTRESOURCEW(DLG_ACMFORMATCHOOSE_ID), > - pafmtc->hwndOwner, FormatChooseDlgProc, (LPARAM)pafmtc); > + MMRESULT ret; > + > + if (pafmtc->fdwStyle & ACMFORMATCHOOSE_STYLEF_ENABLETEMPLATEHANDLE) > + ret = DialogBoxIndirectParamW(MSACM_hInstance32, (LPCDLGTEMPLATEW)pafmtc->hInstance, > + pafmtc->hwndOwner, FormatChooseDlgProc, (LPARAM)pafmtc); > + else if (pafmtc->fdwStyle & ACMFORMATCHOOSE_STYLEF_ENABLETEMPLATE) > + ret = DialogBoxParamW(pafmtc->hInstance, pafmtc->pszTemplateName, > + pafmtc->hwndOwner, FormatChooseDlgProc, (LPARAM)pafmtc); > + else > + ret = DialogBoxParamW(MSACM_hInstance32, MAKEINTRESOURCEW(DLG_ACMFORMATCHOOSE_ID), > + pafmtc->hwndOwner, FormatChooseDlgProc, (LPARAM)pafmtc); > + return ret; > } It would look much better without all those 'ret' + 'else' things. -- Dmitry.

Aug. 12, 2012

Re: Have there been any problems with Wine on GCC 4.7?

by Eric Pouech

Le 24/07/2012 04:06, Scott Ritchie a écrit : > Wine is the last remaining package still depending on GCC 4.5 in the > current Ubuntu alpha, it would be nice to drop GCC 4.5 and forward port > Wine, however 4.6 is known to not work too well. > > But now we have 4.7 -- have there been any bugs attributed to its usage? > > Thanks, > Scott Ritchie > > > afaik, gcc 4.7 enables by default dwarf4 as its default debug format, whilst wine (dbghelp) only supports dwarf2 it generates a lot of conbursome backtraces in winegdb I've started to add dwarf4 support to wine, but don't hold your breath (it's going to be hard and tedious afaict and will require quite a few changes to dbghelp for correctness) (and I have little time right now <g>) BTW : fedora 17 ships with gcc 4.7 A+

Aug. 12, 2012

Re: _vcomp_fork stack frame puzzle

by Dan Kegel

On Fri, Aug 10, 2012 at 7:37 PM, Dan Kegel <dank(a)kegel.com> wrote: > Yes indeed, this works: > > extern void WINAPIV VCOMP__vcomp_fork(DWORD parallel, int ncount, void > (__cdecl *helper)(__ms_va_list), ...); > __ASM_GLOBAL_FUNC( VCOMP__vcomp_fork, > "pop %eax\n\t" /* save return address */ > "add $8,%esp\n\t" /* skip parallel and ncount */ > "pop %ebx\n\t" /* save helper */ > "push %eax\n\t" /* set up return address */ > "jmp %ebx" /* enter handler */ > ) (Or maybe %edx instead of %ebx; http://en.wikipedia.org/wiki/X86_calling_conventions suggests %ebx shouldn't be modified by the callee.)

Aug. 11, 2012

Re: _vcomp_fork stack frame puzzle

by Dan Kegel

Yes indeed, this works: extern void WINAPIV VCOMP__vcomp_fork(DWORD parallel, int ncount, void (__cdecl *helper)(__ms_va_list), ...); __ASM_GLOBAL_FUNC( VCOMP__vcomp_fork, "pop %eax\n\t" /* save return address */ "add $8,%esp\n\t" /* skip parallel and ncount */ "pop %ebx\n\t" /* save helper */ "push %eax\n\t" /* set up return address */ "jmp %ebx" /* enter handler */ )

Aug. 11, 2012

Re: Wiki is down

by Dimi Paun

Wiki back up, sorry for the glitch! Y'all have a nice weekend :) Dimi. On 12-08-10 3:59 PM, Austin English wrote: > Mind taking a look? :) > > Have a great weekend! > -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Aug. 10, 2012

Wiki is down

by Austin English

Mind taking a look? :) Have a great weekend! -- -Austin

Aug. 10, 2012

Re: user32: Menu should not be activated by menu key while mouse buttons are down.

by Jan Boon

Okay, will write a test case later today or tomorrow. When trying to fix the issue I had, I noticed that in the function where it currently handles the logic for the menu key, it only received messages WM_MOUSEACTIVATE on pressing and WM_CAPTURECHANGED on release (in the tested application), but no mouse down or up messages, which caused the mouse down not to set the iMenuSysKey to 0 if the mouse button was pressed after holding alt (and additionally it also needs to not select the menu either when hitting alt while the mouse button is already down). (Also, when trying this manually on linux, gnome desktop wm mouse-button-modifier should be changed from Alt to something else, because it intercepts the alt-mouse combos before wine sees them it seems.) So, since the function is not receiving all the messages here, which I assume are not all forwarded to the default handler by 3ds Max, would it be better to hook into the messages or mouse status at an earlier point in the code (to handle the first case where the mouse is pressed after alt)? And is there a saner way that can be used here to check if the mouse is down (when alt is pressed after mouse down)? On Fri, Aug 10, 2012 at 8:14 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Jan Boon <jan.boon(a)kaetemi.be> wrote: > > > Fix for bug #31434. > > 1. this kind of change requires a test case, some of the changes look wrong > 2. formatting is broken due to not standard tab size > 3. patch introduces compile-time warnings, that's not accepatable > > -- > Dmitry. >

Aug. 10, 2012

Re: _vcomp_fork stack frame puzzle

by Dan Kegel

Yeah, it might be as simple as _vcomp_vfork proc add sp,4 ; skip parallel flag and arg count ret ; jump to helper function, leaving its args on stack or something like that.

Aug. 10, 2012

Re: _vcomp_fork stack frame puzzle

by André Hentschel

Am 09.08.2012 07:49, schrieb Dan Kegel: > It seems like Andre's varargs code should be right, > but something's not connecting. I even tried beer, > and it still didn't work. :D maybe you should try to write it in assembler and later try to move things to C... -- Best Regards, André Hentschel

Aug. 9, 2012

Re: [01/17] gdiplus: Add more tests for GdipMeasureString using device with custom resolution. Take 4.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > Other than patch 15 the series looks good to me, and I've seen or > thought about most of this before, but do you really have to send a > series of 17 patches at once? The idea is to try get them accepted in shorter time than usually since more than a week was basically lost. -- Dmitry.

Aug. 9, 2012

Re: [01/17] gdiplus: Add more tests for GdipMeasureString using device with custom resolution. Take 4.

by Vincent Povirk

Other than patch 15 the series looks good to me, and I've seen or thought about most of this before, but do you really have to send a series of 17 patches at once?

Aug. 9, 2012

_vcomp_fork stack frame puzzle

by Dan Kegel

Having fun trying to figure out what's in the black box of _vcomp_fork(), the helper function that spawns threads in Visual C's OpenMP support library. The C source code #include <stdio.h> #include <omp.h> int main(int argc, char **argv) { double d; double e; int i; printf("&d is %p, &e is %p\n", &d, &e); #pragma omp parallel for for (i=0; i<3; i++) { printf("&d is %p\n", &d); } #pragma omp parallel for for (i=0; i<3; i++) { printf("&d is %p, &e is %p\n", &d, &e); } return 0; } when compiled with cl /MD /openmp /FAs odd.c generates an .exe and a mixed assembly / source .asm listing. The compiler puts the loop into a helper function, and invokes the helper using _vcomp_fork(), which is called with a flag saying whether to parallelize, a pointer to the helper function, a count, and then a pointer to each variable referenced by the loop from the outer scope. The code in the helper function knows to get the addresses of the variables from the stack. When run with native vcomp.dll, this prints out the right addresses inside the loop. When run with my slightly less stubby builtin vcomp patch attached to http://bugs.winehq.org/show_bug.cgi?id=26688 (based on Andre's earlier patch), it prints out garbage. It seems like Andre's varargs code should be right, but something's not connecting. I even tried beer, and it still didn't work. I guess I should fire up a debugger and see what's going on, but I don't want to accidentally see too much about what native's doing. Suggestions, anyone? - Dan

Aug. 9, 2012

Re: [15/17] gdiplus: Delete GDI objects once they are not needed anymore.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > Yes, but gdip_format_string still uses the HDC to do measurements for > the layout calculation. (And draw_string_callback uses it to decide > where to draw underlines.) You are right, this patch can be dropped then, #16 and #17 don't depend on this one. -- Dmitry.

Aug. 9, 2012

Re: [15/17] gdiplus: Delete GDI objects once they are not needed anymore.

by Vincent Povirk

Yes, but gdip_format_string still uses the HDC to do measurements for the layout calculation. (And draw_string_callback uses it to decide where to draw underlines.) On Wed, Aug 8, 2012 at 11:53 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Vincent Povirk <madewokherd(a)gmail.com> wrote: > >> This will break text rendering. We need the correct font to be >> selected on the hdc during the call to gdip_format_string. > > GdipDrawDriverString creates and selects the font on the DC. > > -- > Dmitry.

Aug. 9, 2012

Re: [15/17] gdiplus: Delete GDI objects once they are not needed anymore.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > This will break text rendering. We need the correct font to be > selected on the hdc during the call to gdip_format_string. GdipDrawDriverString creates and selects the font on the DC. -- Dmitry.

Aug. 9, 2012