October 2016 - Wine-devel - list.winehq.org

IP dual stack
by Roman Pišl 16 Oct '16

16 Oct '16

Hi, I sent a small patch to fix a bug where it is not possible to disable IPV6_V6ONLY as it is always enabled in WS_bind(). I have discovered, that my patch is wrong and Matthieu Nottale already proposed right solution. But it wasn't merged. What is the current status of the patch? May I help somehow? I would like to fix that bug (it breaks our application). Roman

2 1

Re: mscoree: Add CorIsLatestSvc function stub.
by Vincent Povirk 16 Oct '16

16 Oct '16

>From poking at it with python ctypes, I believe this function takes 2 pointer arguments and returns an HRESULT. Have you found a real app that calls this? As far as I know, it's only called by native .NET components that shouldn't be used with builtin mscoree.

1 0

build WoW64 in chroots
by wylda＠volny.cz 15 Oct '16

15 Oct '16

Hello, some year ago i built WoW64 per Wine's wiki. But that was re-phrased now or maybe today things are not so complicated in case WoW64 built in chroots32/64. Now it is not clear to me, what are the proper WoW64 steps? : 1. inside chroot64: build wine64 (add extra switch --enable-win64) ****** change chroot ****** 2. inside chroot32: build wine32_tools 3. inside chroot32: build wine32 (uses above points 1. and 2.) 4. inside chroot32: "make install" of wine32 from above point 3 to build some last bits of code (or should be wine32_tools?) ****** change chroot ****** 5. inside chroot64: "make install" of wine32 from above point 4 (but why wine32_tools dir also needs to be available in chroot64??) 6. inside chroot64: "make install" of wine64 from above point 1 (and install dir is the same like in point 5) Or can this be simplified to: 1. inside chroot64: build wine64 (add extra switch --enable-win64) ****** change chroot ****** 2. inside chroot32: build wine32_tools 3. inside chroot32: build wine32 (uses above points 1. and 2.) 4. inside chroot32: "make install" of wine32 from above point 3 to build some last bits of code ****** change chroot ****** 5. inside chroot64: "make install" of wine64 from above point 1 (and install dir is the same like in point 4) Regards, W.

1 0

Re: libwine: Add public symbol to access list of debug options.
by Sebastian Lackner 14 Oct '16

14 Oct '16

On 09.10.2016 18:56, Sebastian Lackner wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > Fixes https://bugs.winehq.org/show_bug.cgi?id=41457. > > Currently, the "edit debug channels" feature of taskmgr is broken in > release builds, because: > > * "debug_options" is not exported as a public symbol > * taskmgr passes SYMOPT_PUBLICS_ONLY to SymSetOptions > > This combination does not make any sense (not even installing debug > packages is sufficient). This patch replaces debug_options with > __wine_dbg_options and makes it a public symbol. > > libs/wine/debug.c | 24 ++++++++++++------------ > libs/wine/wine.def | 1 + > libs/wine/wine.map | 1 + > programs/taskmgr/dbgchnl.c | 2 +- > programs/winedbg/info.c | 2 +- > 5 files changed, 16 insertions(+), 14 deletions(-) > Any opinions regarding this patch? An alternative approach would be to fix taskmgr (remove SYMOPT_PUBLICS_ONLY), and ask users to install debug packages if they want to use this feature. Would that be preferred? Regards, Sebastian

2 1

Re: [PATCH 1/5] wined3d: Add a quirk for GL implementations not supporting sRGB FBO attachments.
by Henri Verbeet 14 Oct '16

14 Oct '16

On 14 October 2016 at 00:03, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > As it seems to be the case for i915 (at least with some Mesa versions). > > This is only a problem because the GL implementation also exposes > EXT_texture_sRGB_decode and when that extension is available we always > use the sRGB format. > > For bug 41052. > Just disabling EXT_texture_sRGB in this case is probably fine, but it's a little unfortunate that we already retrieve this information in init_format_fbo_compat_info(). Would it be hard to use that information instead?

1 0

Re: [PATCH v2 4/4] winehid: Implement handing internal ioctls
by Sebastian Lackner 14 Oct '16

14 Oct '16

On 12.10.2016 18:19, Aric Stewart wrote: > > Mostly by passing them to the bus driver where platform specific actions > happen > > v2: Suggestion from Sebastian Lackner > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winehid.sys/main.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 47 insertions(+) > This patch no longer applies because of the slightly modified version of patch 1/2. I have already prepared a rebased version, but I'm wondering a bit: Couldn't we just pass through ALL ioctls (without any filtering in winehid)? This would reduce the code complexity even further. HID related FIXMEs could also be printed in winebus. hid_internal_dispatch should probably use the "hid" debug channel anyway. What do you think? Regards, Sebastian

2 3

Re: [1/3] gdiplus/tests: Add tests for 0-pixel pens.
by Marvin 13 Oct '16

13 Oct '16

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 https://testbot.winehq.org/JobDetails.pl?Key=26156 Your paranoid android. === wxppro (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w2003std (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === wvistau64 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w2008s64 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w7u (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w7pro64 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w8 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w864 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w1064 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === wvistau64 (64 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w2008s64 (64 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w7pro64 (64 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w864 (64 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w1064 (64 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0

1 0

Re: [PATCH 2/2] include: Add a padding WORD to ensure that wWeight is at the correct offset.
by Marvin 13 Oct '16

13 Oct '16

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 https://testbot.winehq.org/JobDetails.pl?Key=26151 Your paranoid android. === wxppro (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w2003std (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === wvistau64 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w2008s64 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w7u (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w7pro64 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w8 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w864 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w1064 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === wvistau64 (64 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w2008s64 (64 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w7pro64 (64 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w864 (64 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w1064 (64 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0

2 1

Re: [PATCH 3/4] include: Define IoSkipCurrentIrpStackLocation
by Sebastian Lackner 13 Oct '16

13 Oct '16

On 12.10.2016 12:31, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > include/ddk/wdm.h | 2 ++ > 1 file changed, 2 insertions(+) > > > > 0003-include-Define-IoSkipCurrentIrpStackLocation.txt > > > diff --git a/include/ddk/wdm.h b/include/ddk/wdm.h > index 5602f7d..5671948 100644 > --- a/include/ddk/wdm.h > +++ b/include/ddk/wdm.h > @@ -1175,9 +1175,11 @@ NTSTATUS WINAPI ObCloseHandle(IN HANDLE handle); > # ifdef NONAMELESSSTRUCT > # define IoGetCurrentIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.s.u2.CurrentStackLocation) > # define IoGetNextIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.s.u2.CurrentStackLocation - 1) > +# define IoSkipCurrentIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.s.u2.CurrentStackLocation++); ((_Irp)->CurrentLocation++) > # else > # define IoGetCurrentIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.u2.CurrentStackLocation) > # define IoGetNextIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.u2.CurrentStackLocation - 1) > +# define IoSkipCurrentIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.u2.CurrentStackLocation++); ((_Irp)->CurrentLocation++) > # endif > #else > # ifdef NONAMELESSSTRUCT > Is this definition based on a Windows header file? I have only found two versions, either with a "{ ... }" block or with a static inline function. Your definition would not work correctly in a situation like this: if (...) IoSkipCurrentIrpStackLocation(irp); Which would be expanded to: if (...) irp->Tail.Overlay.s.u2.CurrentStackLocation++; irp->CurrentLocation++; Please note that the second statement is no longer conditional. Also, what about the two other #ifdef branches directly below? Regards, Sebastian

3 5

Re: [PATCH v4 1/2] libwine: Don't call exit in the shared library.
by Sebastian Lackner 12 Oct '16

12 Oct '16

On 11.10.2016 16:21, Jens Reyer wrote: > From: Michael Gilbert <mgilbert(a)debian.org> > Signed-off-by: Jens Reyer <jre.winesim(a)gmail.com> > --- > libs/wine/config.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libs/wine/config.c b/libs/wine/config.c > index 3b5dd68..c0b3bdd 100644 > --- a/libs/wine/config.c > +++ b/libs/wine/config.c > @@ -68,7 +68,7 @@ static void fatal_error( const char *err, ... ) > fprintf( stderr, "wine: " ); > vfprintf( stderr, err, args ); > va_end( args ); > - exit(1); > + abort(); > } > > /* die on a fatal error */ > @@ -81,7 +81,7 @@ static void fatal_perror( const char *err, ... ) > vfprintf( stderr, err, args ); > perror( " " ); > va_end( args ); > - exit(1); > + abort(); > } > > /* malloc wrapper */ > I'm not sure if this is really a good idea. In contrast to exit, abort() might trigger the creation of a core dump. Unfortunately fatal_[p]error is also used at many places as a shortcut for "fprintf(stderr,...); exit(1)". This means after this change, a lot of users might see "Aborted (core dumped)" even for harmless error messages. Patch 2 is even more misleading, and shows such a message when the user wants to see the WINEDEBUG help: $ WINEDEBUG=help ./wine winecfg [...] Available message classes: err, warn, fixme, trace Aborted (Core dumped) Before changing things in Winelib, it would first be necessary to modify all involved tools and dlls to avoid fatal_[p]error for harmless errors. Regards, Sebastian

4 4