January 2011 - Wine-devel - list.winehq.org

Re: libs/wine: Fix regression caused by 5af634fd3b7ff7e4d6f8af34f6139315fdbbc8c4 for non-x86 architectures
by Austin English 14 Jan '11

14 Jan '11

2011/1/13 André Hentschel <nerv(a)dawncrow.de>: > --- > libs/wine/config.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/libs/wine/config.c b/libs/wine/config.c > index e15012b..2c365a4 100644 > --- a/libs/wine/config.c > +++ b/libs/wine/config.c > @@ -456,7 +456,7 @@ const char *wine_get_build_id(void) > /* exec a binary using the preloader if requested; helper for wine_exec_wine_binary */ > static void preloader_exec( char **argv, int use_preloader ) > { > -#ifdef linux > +#ifdef linux && defined(__i386__) && defined(__x86_64__) > if (use_preloader) > { > static const char preloader[] = "wine-preloader"; > -- Causes a warning here: ./config.c:459:14: warning: extra tokens at end of #ifdef directive Additionally, you're mixing ifdef and if defined. I used the below patch on powerpc, which works well: diff --git a/libs/wine/config.c b/libs/wine/config.c index 4a2bced..7fce02b 100644 --- a/libs/wine/config.c +++ b/libs/wine/config.c @@ -456,7 +456,7 @@ const char *wine_get_build_id(void) /* exec a binary using the preloader if requested; helper for wine_exec_wine_binary */ static void preloader_exec( char **argv, int use_preloader ) { -#ifdef linux +#if defined (__linux__) && (defined(__i386__) || defined(__x86_64__)) if (use_preloader) { static const char preloader[] = "wine-preloader"; -- -Austin

1 0

Re: [2/7] kernel32: Improve parameter validation for ReadConsoleOutputCharacterA.
by Marvin 13 Jan '11

13 Jan '11

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

3 3

Re: kernel32/tests: Use the right return type and a better failed test message
by Marvin 12 Jan '11

12 Jan '11

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=8267 Your paranoid android. === W7PRO (32 bit pipe) === Failure running script in VM: Exceeded timeout limit of 135 sec === W7PROX64 (32 bit pipe) === Failure running script in VM: Exceeded timeout limit of 135 sec

1 0

Re: [PATCH] windowscodecs/tests: Fix crash introduced with eaf394a9ac4c.
by Marvin 12 Jan '11

12 Jan '11

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=8269 Your paranoid android. === WINEBUILD (build) === Patch failed to apply === W2K8SE (32 bit converter) === TestLauncher.c:200: Test failed: Can't locate import module name in C:\winetest\windowscodecs_test.exe === W7PRO (32 bit converter) === No test summary line found === W7PROX64 (32 bit converter) === No test summary line found

1 0

Re: [PATCH 1/3] msvcr90: Implement _set_abort_behavior [try2]
by Alexandre Julliard 12 Jan '11

12 Jan '11

Detlef Riekenberg <wine.dev(a)web.de> writes: > @@ -36,6 +36,11 @@ static MSVCRT_purecall_handler purecall_handler = NULL; > > static const char szMsgBoxTitle[] = "Wine C++ Runtime Library"; > > +#ifndef _WRITE_ABORT_MSG > +#define _WRITE_ABORT_MSG 1 > +#define _CALL_REPORTFAULT 2 > +#endif These should go in msvcrt.h with the appropriate prefix and corresponding test. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msvcrt: Partially implement _set_abort_behavior
by Detlef Riekenberg 12 Jan '11

12 Jan '11

On Mi, 2011-01-12 at 00:48 +0300, Nikolay Sivov wrote: > Date: Wed, 12 Jan 2011 00:46:26 +0300 > Subject: [PATCH 1/1] Partially implement _set_abort_behavior Please search the patches queue first. try 2: http://source.winehq.org/patches/data/70231 try 1: http://source.winehq.org/patches/data/70136 > +static int MSVCRT_abort_behavior = MSVCRT__WRITE_ABORT_MSG | > MSVCRT__WRITE_CALL_REPORTFAULT; - _set_abort_behavior get unsigned int, but you use an int. Why? - mingw header have the same name as msdn. Why are you using different names? > /********************************************************************* > + * _set_abort_behavior (MSVCRT.@) > + * > + * Not exported by native msvcrt, added in msvcr80 > + */ > +int CDECL MSVCRT__set_abort_behavior(int flags, int mask) > +{ - need unsigned int > diff --git a/dlls/msvcrt/msvcrt.h b/dlls/msvcrt/msvcrt.h > > +/* _set_abort_behavior codes */ > +#define MSVCRT__WRITE_ABORT_MSG 1 > +#define MSVCRT__WRITE_CALL_REPORTFAULT 2 > + > +int __cdecl MSVCRT__set_abort_behavior(int,int); - correct location is stdlib.h - names are wrong - need unsigned int > -- By by ... Detlef

2 1

windowscodecs: Use Mac OS X native ICNS support, not libicns
by Joerg-Cyril.Hoehle＠t-systems.com 12 Jan '11

12 Jan '11

Ken, Thank you! Indeed I never installed libicns on my Mac (why use an external library on the particular OS that created the need for ICNS format support?) and even reverted Damjan's patch to still create .png images like the Linux systems. Then I use sips -i to create .command files with icons -- as I explained on the Wiki. http://wiki.winehq.org/MacOSX/FAQs >Besides being referenced by .desktop files which aren't used, Why not instead create .command files like I explain on the Wiki? Basically, instead of xyz.desktop: Path=/foo/bar Exec=env WINEPREFIX=... wine ... Icon=... create a xyz.command: #! /bin/sh cd /foo/bar && exec env WINEPREFIX=... wine ... >the ICNS files are written to /tmp, as things stand. Good. It's valuable to have a place where to obtain the icons even after the installer finishes. I'm used to peeking at ~/.local/share/icons to see which icons I can associate with .command files on MacOS (and .desktop on Linux). In my particular case, it's useful to have the .png because I can use it for both Linux and MacOS. Regards, Jörg Höhle FWIW, I've compiled 1.3.11 which includes your patch but have not tested it yet.

1 0

Re: d3d9/tests: Skip tests if not running in the foreground
by Marvin 12 Jan '11

12 Jan '11

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=8260 Your paranoid android. === W2K8SE (32 bit device) === Can't copy TestLauncher to VM: Cannot connect to the virtual machine

1 0

windowscodecs: Use Mac OS X native ICNS support, not libicns.
by Ken Thomases 12 Jan '11

12 Jan '11

Hi Damjan, I was intrigued to see the ICNS support you added to windowscodecs some months ago. Neat work! However, I'm confused about why you used the third-party libicns library. As near as I can tell, the ICNS support is only used on Mac OS X and it's not likely to ever be used elsewhere. If that's the case, why did you not build it on top of the native ICNS support built into Mac OS X? Using the native frameworks would avoid one more external dependency that would need to be shipped with Wine on the Mac. I'm attaching a patch that changes to using the ApplicationServices framework instead of libicns. I wanted to get your input before sending it to wine-patches. What do you think? Thanks, Ken ----------------------------------------------------------------------- The ICNS support is only used on Mac OS X and is not anticipated to be used on any other platform. So, we can rely on the native frameworks rather than a third-party dependency. --- configure.ac | 16 +-- dlls/windowscodecs/Makefile.in | 1 + dlls/windowscodecs/icnsformat.c | 270 ++++++++++++++++----------------------- include/config.h.in | 10 +- 4 files changed, 119 insertions(+), 178 deletions(-)

3 5

Re: [PATCH 1/3] winemenubuilder: Icon heights/widths of 0 mean 256, for Vista icons.
by Damjan Jovanovic 12 Jan '11

12 Jan '11

The 256x256 pixel icons are designed to be viewed in that size. They can, and often do, contain a different picture to the smaller icons. When you scale them down to a smaller size, they look bad. On MacOS that may not matter since multiple icon sizes are written and the best is chosen, but on freedesktops we only write 1 icon size at the moment, and then it gets scaled to something like 64x64, so it really does make a difference. Install eMule and see its icons on Gnome as an example. On Tue, Jan 11, 2011 at 5:48 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > > The existing code would always prefer a smaller icon because it was > misinterpreting 256x256 icons as 0x0. > --- > programs/winemenubuilder/winemenubuilder.c | 32 +++++++++++++++------------ > 1 files changed, 18 insertions(+), 14 deletions(-) > > > > >

2 3