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

Re: IP dual stack

by Sebastian Lackner

On 16.10.2016 20:20, Roman Pišl wrote: > 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 > Hello Roman, I don't know if Matthieu is willing to give it another try, but you can also submit a patch written by someone else. Just make sure to include a From: header at the beginning, and add your own Signed-off-by line (which means that you are willing to take responsibility). Here you can see an example of such a patch: http://source.winehq.org/patches/data/127089 Regards, Sebastian

Oct. 16, 2016

IP dual stack

by Roman Pišl

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

Oct. 16, 2016

Imort system certificates in crypt32@Wine

by Donat Enikeev

Oct. 16, 2016

Re: mscoree: Add CorIsLatestSvc function stub.

by Vincent Povirk

>>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. > > At least two apps calls this function after .NET 4.5.1 (offline) have > been installed. If .NET is installed then builtin mscoree should not be used.

Oct. 16, 2016

mscoree: Add CorIsLatestSvc function stub.

by Andrey Gusev

>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. At least two apps calls this function after .NET 4.5.1 (offline) have been installed.

Oct. 16, 2016

Re: mscoree: Add CorIsLatestSvc function stub.

by Vincent Povirk

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

Oct. 15, 2016

build WoW64 in chroots

by wylda＠volny.cz

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.

Oct. 15, 2016

Re: libwine: Add public symbol to access list of debug options.

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > 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? If that works, it's probably good enough. It's better to avoid changing the libwine public interface if at all possible. -- Alexandre Julliard julliard(a)winehq.org

Oct. 14, 2016

Re: [PATCH 1/5] wined3d: Add a quirk for GL implementations not supporting sRGB FBO attachments.

by Henri Verbeet

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?

Oct. 14, 2016

Re: libwine: Add public symbol to access list of debug options.

by Sebastian Lackner

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

Oct. 14, 2016

Re: [PATCH v2 4/4] winehid: Implement handing internal ioctls

by Aric Stewart

On 10/14/16 6:35 AM, Sebastian Lackner wrote: > On 14.10.2016 06:25, Aric Stewart wrote: >> >> Yup, rebased and resent >> >> thanks! >> -aric >> > > Actually I was thinking about an even more simplified solution like: > > --- snip --- > static NTSTATUS WINAPI internal_ioctl(DEVICE_OBJECT *device, IRP *irp) > { > /* All these are handled by the lower level driver */ > IoSkipCurrentIrpStackLocation(irp); > return IoCallDriver(((HID_DEVICE_EXTENSION *)device->DeviceExtension)->NextDeviceObject, irp); > } > --- snip --- > > The function in winebus also has tracing for unsupported ioctls for example. > Does that make sense, or do you prefer to keep the IoControlCode checks > (even if we do not seem to need them yet). > > Regards, > Sebastian > I think I prefer keeping the IoControlCode checks and having an explicit passthrough of only the HID things for now. Thought I realized you had removed the ntoskrnl dependency so my v3 patch is incorrect. Working a v4. -aric

Oct. 13, 2016

Re: [PATCH v2 4/4] winehid: Implement handing internal ioctls

by Sebastian Lackner

On 14.10.2016 06:25, Aric Stewart wrote: > > Yup, rebased and resent > > thanks! > -aric > Actually I was thinking about an even more simplified solution like: --- snip --- static NTSTATUS WINAPI internal_ioctl(DEVICE_OBJECT *device, IRP *irp) { /* All these are handled by the lower level driver */ IoSkipCurrentIrpStackLocation(irp); return IoCallDriver(((HID_DEVICE_EXTENSION *)device->DeviceExtension)->NextDeviceObject, irp); } --- snip --- The function in winebus also has tracing for unsupported ioctls for example. Does that make sense, or do you prefer to keep the IoControlCode checks (even if we do not seem to need them yet). Regards, Sebastian

Oct. 13, 2016

Re: [PATCH v2 4/4] winehid: Implement handing internal ioctls

by Aric Stewart

On 10/14/16 5:09 AM, Sebastian Lackner wrote: > 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 > Yup, rebased and resent thanks! -aric

Oct. 13, 2016

Re: [PATCH v2 4/4] winehid: Implement handing internal ioctls

by Sebastian Lackner

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

Oct. 13, 2016

Re: Do we delete spammers accounts from bugzilla?

by Sebastian Lackner

On 05.10.2016 17:58, Alexandre Julliard wrote: > Bruno Jesus <00cpxxx(a)gmail.com> writes: > >> Today we had one more piece of spam, the bot registered the account a >> few moments before creating a bug. In this case should we use >> bugzilla's admin features to delete the user? > > I always disable the user right away, yes. This is done by setting > the Disable text in the user admin page. > Today there was so much spam that I finally decided to write a script for it. ;) For all people interested, the script is available here: https://github.com/slackner/bugzilla-tools/blob/master/delete_spam.py Usage: ./delete_spam.py ID [ID ...] So far the script does not implement any actual spam detection, it only simplifies the cleanup task. The script uses the Bugzilla xmlrpc API to disable the guilty bug creator, and also updates the bug status itself (change title, hide comments, and so on). If someone wants to contribute any improvements, patches and pull-requests are welcome. *g* ;) Regards, Sebastian

Oct. 13, 2016

Re: [1/3] gdiplus/tests: Add tests for 0-pixel pens.

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

Oct. 13, 2016

Re: [PATCH 2/2] include: Add a padding WORD to ensure that wWeight is at the correct offset.

by Huw Davies

On 13 Oct 2016, at 16:41, Marvin <testbot(a)winehq.org> wrote: > 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 I screwed up. I’ll send a new version. Huw.

Oct. 13, 2016

Re: [PATCH 2/2] include: Add a padding WORD to ensure that wWeight is at the correct offset.

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

Oct. 13, 2016

Re: [PATCH 3/4] include: Define IoSkipCurrentIrpStackLocation

by Sebastian Lackner

On 13.10.2016 09:27, Aric Stewart wrote: > On 10/13/16 9:09 AM, Alexandre Julliard wrote: >> Sebastian Lackner <sebastian(a)fds-team.de> writes: >> >>> I assume you are looking at an old version then, and Microsoft fixed >>> this mistake in the meantime. Windows 10 header files contain for example: >>> >>> --- snip --- >>> FORCEINLINE >>> VOID >>> IoSkipCurrentIrpStackLocation ( >>> _Inout_ PIRP Irp >>> ) >>> [...] >>> { >>> NT_ASSERT(Irp->CurrentLocation <= Irp->StackCount); >>> Irp->CurrentLocation++; >>> Irp->Tail.Overlay.CurrentStackLocation++; >>> } >>> --- snip --- >>> >>> Nevertheless, I think both "{...}" and using an inline function is fine >>> in this case. >> >> It should be either an inline function (preferred) or a "do {} while(0)" >> block. A "{...}" block will cause syntax errors in some cases. @Alexandre: I know that {...} can cause problems, but didn't object because it is also used in some Windows header files. Nevertheless, you are right, lets better do it the right way. ;) >> > > To do an inline function, which you prefer, would you like it in those #ifdef blocks? > > Like this? > > #ifdef NONAMELESSUNION > # ifdef NONAMELESSSTRUCT > # define IoGetCurrentIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.s.u2.CurrentStackLocation) > # define IoGetNextIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.s.u2.CurrentStackLocation - 1) > inline void IoSkipCurrentIrpStackLocation(IRP *_Irp) {_Irp->Tail.Overlay.s.u2.CurrentStackLocation++; _Irp->CurrentLocation++;} > # else @Aric: Its up to you if you want to define it in the #ifdef blocks or below, but you definitely need to handle the different combinations of NONAMELESSUNION/ NONAMELESSSTRUCT to make sure it compiles fine. Please note that the function should be marked as "static inline", not just "inline". Also, you can rename "_Irp" to "irp" because there is no longer any risk of name collisions when using an inline function. Regards, Sebastian

Oct. 13, 2016

Re: [PATCH 3/4] include: Define IoSkipCurrentIrpStackLocation

by Aric Stewart

On 10/13/16 9:09 AM, Alexandre Julliard wrote: > Sebastian Lackner <sebastian(a)fds-team.de> writes: > >> I assume you are looking at an old version then, and Microsoft fixed >> this mistake in the meantime. Windows 10 header files contain for example: >> >> --- snip --- >> FORCEINLINE >> VOID >> IoSkipCurrentIrpStackLocation ( >> _Inout_ PIRP Irp >> ) >> [...] >> { >> NT_ASSERT(Irp->CurrentLocation <= Irp->StackCount); >> Irp->CurrentLocation++; >> Irp->Tail.Overlay.CurrentStackLocation++; >> } >> --- snip --- >> >> Nevertheless, I think both "{...}" and using an inline function is fine >> in this case. > > It should be either an inline function (preferred) or a "do {} while(0)" > block. A "{...}" block will cause syntax errors in some cases. > To do an inline function, which you prefer, would you like it in those #ifdef blocks? Like this? #ifdef NONAMELESSUNION # ifdef NONAMELESSSTRUCT # define IoGetCurrentIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.s.u2.CurrentStackLocation) # define IoGetNextIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.s.u2.CurrentStackLocation - 1) inline void IoSkipCurrentIrpStackLocation(IRP *_Irp) {_Irp->Tail.Overlay.s.u2.CurrentStackLocation++; _Irp->CurrentLocation++;} # else ... -aric

Oct. 13, 2016

Re: [PATCH 3/4] include: Define IoSkipCurrentIrpStackLocation

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > I assume you are looking at an old version then, and Microsoft fixed > this mistake in the meantime. Windows 10 header files contain for example: > > --- snip --- > FORCEINLINE > VOID > IoSkipCurrentIrpStackLocation ( > _Inout_ PIRP Irp > ) > [...] > { > NT_ASSERT(Irp->CurrentLocation <= Irp->StackCount); > Irp->CurrentLocation++; > Irp->Tail.Overlay.CurrentStackLocation++; > } > --- snip --- > > Nevertheless, I think both "{...}" and using an inline function is fine > in this case. It should be either an inline function (preferred) or a "do {} while(0)" block. A "{...}" block will cause syntax errors in some cases. -- Alexandre Julliard julliard(a)winehq.org

Oct. 13, 2016

Re: [PATCH v4 1/2] libwine: Don't call exit in the shared library.

by Jens Reyer

Also thanks to you, AJ and Ken! On 12.10.2016 17:12, Ken Thomases wrote: > On Oct 12, 2016, at 7:52 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> >> Jens Reyer <jre.winesim(a)gmail.com> writes: >> >>> On 11.10.2016 16:59, Sebastian Lackner wrote: >>>> 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. >>> >>> Thanks a lot, that's the advice I've been looking for (obviously not >>> with the hoped for outcome). >>> >>> Unfortunately the todo is beyond my capabilities. I'll discuss that at >>> Debian and propose to drop the patch for now. >>> >>> Instead I'll file a bug here since I haven't heard anyone rejecting the >>> goal of getting rid of exit in the shared library itself. >> >> I don't think that's a useful goal. It's not a bad idea to review its >> usage, and possibly replace it where it makes sense, but there are also >> places where exit is needed. > > The reason for this is that libwine is not like other libraries where Debian's check may make sense. It's not a general-purpose library. It's only really useful for Wine itself and for a program which wants to be an alternative Wine loader. The client of libwine will want it to call exit() when needed. > > Is there a way to make an exception to Debian's lintian checks? No worries, lintian is just a tool giving hints. At least at this check's severity following it is no hard requirement. I'll add an override for this check, linking to this thread (your answers are really valued for this!). Greets jre

Oct. 12, 2016

Re: Compile default Visual C++ 6 project with winegcc

by André Hentschel

Am 11.10.2016 um 10:32 schrieb A B: > I'm trying to compile the default sample win32 ,Hello World project . I did |winegcc -m32 -o test2 test2.cpp| . It runs ok , but resources are not loaded ,there is empty windows title and missing File and Help menus. > What is the correct way to make also load the resources? > > > Try winemaker, it should help you with the process. At best if there is a project file (dsp)

Oct. 12, 2016

Re: [PATCH 4/4] winehid: Implement handing internal ioctls

by Sebastian Lackner

On 12.10.2016 12:31, Aric Stewart wrote: > Mostly by passing them to the bus driver where platform specific actions > happen > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winehid.sys/main.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 48 insertions(+) > > > > 0004-winehid-Implement-handing-internal-ioctls.txt > > > diff --git a/dlls/winehid.sys/main.c b/dlls/winehid.sys/main.c > index e8c91bb..7c17321 100644 > --- a/dlls/winehid.sys/main.c > +++ b/dlls/winehid.sys/main.c > @@ -25,6 +25,7 @@ > #include "windef.h" > #include "winbase.h" > #include "winternl.h" > +#include "winioctl.h" > #include "ddk/wdm.h" > #include "ddk/hidport.h" > #include "wine/debug.h" > @@ -33,6 +34,52 @@ WINE_DEFAULT_DEBUG_CHANNEL(hid_minidriver); > > static HID_MINIDRIVER_REGISTRATION registration; > > +static NTSTATUS WINAPI internal_ioctl(DEVICE_OBJECT *device, IRP *irp) > +{ > + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation(irp); > + Some tracing wouldn't hurt here. > + irp->IoStatus.Information = 0; > + > + switch (irpsp->Parameters.DeviceIoControl.IoControlCode) > + { > + case IOCTL_GET_PHYSICAL_DESCRIPTOR: > + TRACE("IOCTL_GET_PHYSICAL_DESCRIPTOR\n"); > + break; > + case IOCTL_HID_ACTIVATE_DEVICE: > + TRACE("IOCTL_HID_ACTIVATE_DEVICE\n"); > + break; > + case IOCTL_HID_DEACTIVATE_DEVICE: > + TRACE("IOCTL_HID_DEACTIVATE_DEVICE\n"); > + break; > + case IOCTL_HID_GET_INDEXED_STRING: > + TRACE("IOCTL_HID_GET_INDEXED_STRING\n"); > + break; I assume there are no plans (yet) to implement those. Shouldn't they be marked as FIXME then? > + case IOCTL_HID_GET_DEVICE_ATTRIBUTES: > + case IOCTL_HID_GET_DEVICE_DESCRIPTOR: > + case IOCTL_HID_GET_REPORT_DESCRIPTOR: > + case IOCTL_HID_GET_STRING: > + case IOCTL_HID_GET_INPUT_REPORT: > + case IOCTL_HID_READ_REPORT: > + case IOCTL_HID_SET_OUTPUT_REPORT: > + case IOCTL_HID_WRITE_REPORT: > + case IOCTL_HID_GET_FEATURE: > + case IOCTL_HID_SET_FEATURE: > + { > + /* All these are handled by the lower level driver */ > + IoSkipCurrentIrpStackLocation(irp); > + return IoCallDriver(((HID_DEVICE_EXTENSION*)device->DeviceExtension)->NextDeviceObject, irp); > + } > + default: > + { > + ULONG code = irpsp->Parameters.DeviceIoControl.IoControlCode; > + FIXME("Unsupported ioctl %x (device=%x access=%x func=%x method=%x)\n" > + , code, code >> 16, (code >> 14) & 3, (code >> 2) & 0xfff, code & 3); > + } > + } > + IoCompleteRequest( irp, IO_NO_INCREMENT ); > + return irp->IoStatus.u.Status; After IoCompleteRequest the IRP struct should not be accessed anymore. > +} > + > static NTSTATUS WINAPI add_device(DRIVER_OBJECT *driver, DEVICE_OBJECT *device) > { > TRACE("\n"); > @@ -44,6 +91,7 @@ NTSTATUS WINAPI DriverEntry(DRIVER_OBJECT *driver, UNICODE_STRING *path) > { > TRACE("%s\n", debugstr_w(path->Buffer)); > > + driver->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = internal_ioctl; > driver->DriverExtension->AddDevice = add_device; > > registration.DriverObject = driver; > > >

Oct. 12, 2016

Re: ntdll/tests: Added a test of using NtCancelIoEx on iosb associated with pipe listening.

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 https://testbot.winehq.org/JobDetails.pl?Key=26128 Your paranoid android. === w864 (32 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231 === w1064 (32 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231 === w1064 (64 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231

Oct. 12, 2016

Re: [PATCH] winebus.sys: Implement IOCTL_HID_GET_STRING for hidraw

by Sebastian Lackner

On 12.10.2016 17:27, Aric Stewart wrote: > True, However a language ID of 00 means vendor default. Which is what > I am pretty sure we get out of the underlying calls. Anything of > another language will be unimplemented and should return that code. If you want to handle it in the vtbl functions thats also fine, but the type should probably be unsigned then (otherwise it might be negative depending on what is stored in the upper word).

Oct. 12, 2016

Re: [PATCH] winebus.sys: Implement IOCTL_HID_GET_STRING for hidraw

by Aric Stewart

On 10/12/16 4:02 PM, Sebastian Lackner wrote: > On 12.10.2016 12:12, Aric Stewart wrote: >> Signed-off-by: Aric Stewart <aric(a)codeweavers.com> >> --- >> dlls/winebus.sys/bus.h | 1 + >> dlls/winebus.sys/bus_udev.c | 70 +++++++++++++++++++++++++++++++++++++++++++++ >> dlls/winebus.sys/main.c | 11 +++++++ >> 3 files changed, 82 insertions(+) >> >> >> >> 0001-winebus.sys-Implement-IOCTL_HID_GET_STRING-for-hidraw.txt >> >> >> diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h >> index 9ab242c..9094e17 100644 >> --- a/dlls/winebus.sys/bus.h >> +++ b/dlls/winebus.sys/bus.h >> @@ -24,6 +24,7 @@ typedef struct >> { >> int (*compare_platform_device)(DEVICE_OBJECT *device, void *platform_dev); >> NTSTATUS (*get_reportdescriptor)(DEVICE_OBJECT *device, BYTE *buffer, DWORD length, DWORD *out_length); >> + NTSTATUS (*get_string)(DEVICE_OBJECT *device, int index, WCHAR *buffer, DWORD length); >> } platform_vtbl; >> >> void *get_platform_private(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; >> diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c >> index 22ea07d..4ded568 100644 >> --- a/dlls/winebus.sys/bus_udev.c >> +++ b/dlls/winebus.sys/bus_udev.c >> @@ -51,7 +51,9 @@ >> #include "winnls.h" >> #include "winternl.h" >> #include "ddk/wdm.h" >> +#include "ddk/hidtypes.h" >> #include "wine/debug.h" >> +#include "wine/unicode.h" >> >> #include "bus.h" >> >> @@ -144,10 +146,78 @@ static NTSTATUS hidraw_get_reportdescriptor(DEVICE_OBJECT *device, BYTE *buffer, >> #endif >> } >> >> +static NTSTATUS hidraw_get_string(DEVICE_OBJECT *device, int index, WCHAR *buffer, DWORD length) >> +{ >> + struct udev_device *usbdev; >> + struct platform_private *private = impl_from_DEVICE_OBJECT(device); >> + >> + usbdev = udev_device_get_parent_with_subsystem_devtype(private->udev_device, "usb", "usb_device"); >> + if (usbdev) >> + { >> + WCHAR *str = NULL; >> + switch (index) >> + { >> + case HID_STRING_ID_IPRODUCT: >> + str = get_sysattr_string(usbdev, "product"); >> + break; >> + case HID_STRING_ID_IMANUFACTURER: >> + str = get_sysattr_string(usbdev, "manufacturer"); >> + break; >> + case HID_STRING_ID_ISERIALNUMBER: >> + str = get_sysattr_string(usbdev, "serial"); >> + break; >> + default: >> + ERR("Unhandled string index %i\n", index); >> + return STATUS_NOT_IMPLEMENTED; >> + } >> + if (str) >> + { >> + if (strlenW(str) >= length) >> + { >> + HeapFree(GetProcessHeap(), 0, str); >> + return STATUS_BUFFER_TOO_SMALL; >> + } >> + strcpyW(buffer, str); >> + HeapFree(GetProcessHeap(), 0, str); >> + return STATUS_SUCCESS; >> + } >> + else if (length) >> + buffer[0] = 0; >> + return STATUS_SUCCESS; > > Shouldn't it still return STATUS_BUFFER_TOO_SMALL when length == 0? > >> + } >> + else >> + { >> +#ifdef HAVE_LINUX_HIDRAW_H >> + static char str[MAX_PATH] = {0}; > > Isn't there a risk of race-conditions that multiple HID devices attempt to use > this static buffer at the same time? > >> + >> + switch (index) >> + { >> + case HID_STRING_ID_IPRODUCT: >> + ioctl(private->device_fd, HIDIOCGRAWNAME(MAX_PATH), &str); >> + break; >> + case HID_STRING_ID_IMANUFACTURER: >> + break; >> + case HID_STRING_ID_ISERIALNUMBER: >> + break; >> + default: >> + ERR("Unhandled string index %i\n", index); >> + return STATUS_NOT_IMPLEMENTED; >> + } >> +#endif >> + if (str[0]) > > If HAVE_LINUX_HIDRAW_H is not available this will break compilation (str undeclared). > >> + MultiByteToWideChar(CP_ACP, 0, str, -1, buffer, length); >> + else if (length) >> + buffer[0] = 0; > > It would be better to do length checking also in this case. > >> + >> + return STATUS_SUCCESS; >> + } >> +} >> + >> static const platform_vtbl hidraw_vtbl = >> { >> compare_platform_device, >> hidraw_get_reportdescriptor, >> + hidraw_get_string, >> }; >> >> static void try_add_device(struct udev_device *dev) >> diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c >> index ad09ec1..a7b76df 100644 >> --- a/dlls/winebus.sys/main.c >> +++ b/dlls/winebus.sys/main.c >> @@ -421,6 +421,17 @@ NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) >> irp->IoStatus.Information = length; >> break; >> } >> + case IOCTL_HID_GET_STRING: >> + { >> + DWORD index = (DWORD)irpsp->Parameters.DeviceIoControl.Type3InputBuffer; > > This will trigger a compilation warning on 64-bit. You have to cast to a ptr-size integer > type first, for example: > > DWORD index = (ULONG_PTR)irpsp->Parameters.DeviceIoControl.Type3InputBuffer; > > Also, accoding to MSDN, the content of the variable is a composite value: > > """Parameters.DeviceIoControl.Type3InputBuffer in the I/O stack location of the IRP contains > a composite value. The two most significant bytes contain the language ID of the string to > be retrieved. The two least significant bytes contain one of the following three constant values...""" > True, However a language ID of 00 means vendor default. Which is what I am pretty sure we get out of the underlying calls. Anything of another language will be unimplemented and should return that code. -aric >> + TRACE("IOCTL_HID_GET_STRING[%i]\n", index); >> + irp->IoStatus.u.Status = status = ext->vtbl->get_string(device, >> + index, (WCHAR*)(irp->UserBuffer), >> + irpsp->Parameters.DeviceIoControl.OutputBufferLength/sizeof(WCHAR)); >> + if (status == STATUS_SUCCESS) >> + irp->IoStatus.Information = (strlenW((WCHAR*)(irp->UserBuffer)) + 1) * sizeof(WCHAR); >> + break; >> + } >> default: >> { >> ULONG code = irpsp->Parameters.DeviceIoControl.IoControlCode; >> >> >> >

Oct. 12, 2016

Re: [PATCH 1/2] ws2_32: Pass completion routing to NtDeviceIoControlFile in server_ioctl_sock only if caller provided comple

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 https://testbot.winehq.org/JobDetails.pl?Key=26126 Your paranoid android. === wvistau64 (32 bit sock) === An error occurred while waiting for the test to complete: network read timed out (wait2/connect:AgentVersion.h:0/9)

Oct. 12, 2016

Re: [PATCH 3/4] include: Define IoSkipCurrentIrpStackLocation

by Sebastian Lackner

On 12.10.2016 16:57, Aric Stewart wrote: > > True, the wdm.h I looked at in the ddk did not appear to block the > two statements together so your statement would not work on windows > either. I was adding them to look like the other statements in our > header. > > Now I have not opposition to putting them in a block, but just saying > that it is not done that way in the windows header. I assume you are looking at an old version then, and Microsoft fixed this mistake in the meantime. Windows 10 header files contain for example: --- snip --- FORCEINLINE VOID IoSkipCurrentIrpStackLocation ( _Inout_ PIRP Irp ) [...] { NT_ASSERT(Irp->CurrentLocation <= Irp->StackCount); Irp->CurrentLocation++; Irp->Tail.Overlay.CurrentStackLocation++; } --- snip --- Nevertheless, I think both "{...}" and using an inline function is fine in this case. > > Yeah, i just missed the other 2 locations. But I should update them > with the correct bracketing. > > The rest of the code seems to use (...) but do you feel like it > should be {..}? No, it also wouldn't compile if you replace it with {...} there because the result is usually assigned to a variable. Those definitions look fine to me and are not affected by this problem. > > -aric

Oct. 12, 2016

Re: [PATCH v4 1/2] libwine: Don't call exit in the shared library.

by Ken Thomases

On Oct 12, 2016, at 7:52 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > > Jens Reyer <jre.winesim(a)gmail.com> writes: > >> On 11.10.2016 16:59, Sebastian Lackner wrote: >>> 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. >> >> Thanks a lot, that's the advice I've been looking for (obviously not >> with the hoped for outcome). >> >> Unfortunately the todo is beyond my capabilities. I'll discuss that at >> Debian and propose to drop the patch for now. >> >> Instead I'll file a bug here since I haven't heard anyone rejecting the >> goal of getting rid of exit in the shared library itself. > > I don't think that's a useful goal. It's not a bad idea to review its > usage, and possibly replace it where it makes sense, but there are also > places where exit is needed. The reason for this is that libwine is not like other libraries where Debian's check may make sense. It's not a general-purpose library. It's only really useful for Wine itself and for a program which wants to be an alternative Wine loader. The client of libwine will want it to call exit() when needed. Is there a way to make an exception to Debian's lintian checks? -Ken

Oct. 12, 2016

Re: [PATCH 3/4] include: Define IoSkipCurrentIrpStackLocation

by Aric Stewart

On 10/12/16 4:10 PM, Sebastian Lackner wrote: > 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? > True, the wdm.h I looked at in the ddk did not appear to block the two statements together so your statement would not work on windows either. I was adding them to look like the other statements in our header. Now I have not opposition to putting them in a block, but just saying that it is not done that way in the windows header. Yeah, i just missed the other 2 locations. But I should update them with the correct bracketing. The rest of the code seems to use (...) but do you feel like it should be {..}? -aric > Regards, > Sebastian >

Oct. 12, 2016

Re: [PATCH 3/4] include: Define IoSkipCurrentIrpStackLocation

by Sebastian Lackner

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

Oct. 12, 2016

Re: [PATCH] winebus.sys: Implement IOCTL_HID_GET_STRING for hidraw

by Sebastian Lackner

On 12.10.2016 12:12, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus.h | 1 + > dlls/winebus.sys/bus_udev.c | 70 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/winebus.sys/main.c | 11 +++++++ > 3 files changed, 82 insertions(+) > > > > 0001-winebus.sys-Implement-IOCTL_HID_GET_STRING-for-hidraw.txt > > > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index 9ab242c..9094e17 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -24,6 +24,7 @@ typedef struct > { > int (*compare_platform_device)(DEVICE_OBJECT *device, void *platform_dev); > NTSTATUS (*get_reportdescriptor)(DEVICE_OBJECT *device, BYTE *buffer, DWORD length, DWORD *out_length); > + NTSTATUS (*get_string)(DEVICE_OBJECT *device, int index, WCHAR *buffer, DWORD length); > } platform_vtbl; > > void *get_platform_private(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index 22ea07d..4ded568 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -51,7 +51,9 @@ > #include "winnls.h" > #include "winternl.h" > #include "ddk/wdm.h" > +#include "ddk/hidtypes.h" > #include "wine/debug.h" > +#include "wine/unicode.h" > > #include "bus.h" > > @@ -144,10 +146,78 @@ static NTSTATUS hidraw_get_reportdescriptor(DEVICE_OBJECT *device, BYTE *buffer, > #endif > } > > +static NTSTATUS hidraw_get_string(DEVICE_OBJECT *device, int index, WCHAR *buffer, DWORD length) > +{ > + struct udev_device *usbdev; > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + > + usbdev = udev_device_get_parent_with_subsystem_devtype(private->udev_device, "usb", "usb_device"); > + if (usbdev) > + { > + WCHAR *str = NULL; > + switch (index) > + { > + case HID_STRING_ID_IPRODUCT: > + str = get_sysattr_string(usbdev, "product"); > + break; > + case HID_STRING_ID_IMANUFACTURER: > + str = get_sysattr_string(usbdev, "manufacturer"); > + break; > + case HID_STRING_ID_ISERIALNUMBER: > + str = get_sysattr_string(usbdev, "serial"); > + break; > + default: > + ERR("Unhandled string index %i\n", index); > + return STATUS_NOT_IMPLEMENTED; > + } > + if (str) > + { > + if (strlenW(str) >= length) > + { > + HeapFree(GetProcessHeap(), 0, str); > + return STATUS_BUFFER_TOO_SMALL; > + } > + strcpyW(buffer, str); > + HeapFree(GetProcessHeap(), 0, str); > + return STATUS_SUCCESS; > + } > + else if (length) > + buffer[0] = 0; > + return STATUS_SUCCESS; Shouldn't it still return STATUS_BUFFER_TOO_SMALL when length == 0? > + } > + else > + { > +#ifdef HAVE_LINUX_HIDRAW_H > + static char str[MAX_PATH] = {0}; Isn't there a risk of race-conditions that multiple HID devices attempt to use this static buffer at the same time? > + > + switch (index) > + { > + case HID_STRING_ID_IPRODUCT: > + ioctl(private->device_fd, HIDIOCGRAWNAME(MAX_PATH), &str); > + break; > + case HID_STRING_ID_IMANUFACTURER: > + break; > + case HID_STRING_ID_ISERIALNUMBER: > + break; > + default: > + ERR("Unhandled string index %i\n", index); > + return STATUS_NOT_IMPLEMENTED; > + } > +#endif > + if (str[0]) If HAVE_LINUX_HIDRAW_H is not available this will break compilation (str undeclared). > + MultiByteToWideChar(CP_ACP, 0, str, -1, buffer, length); > + else if (length) > + buffer[0] = 0; It would be better to do length checking also in this case. > + > + return STATUS_SUCCESS; > + } > +} > + > static const platform_vtbl hidraw_vtbl = > { > compare_platform_device, > hidraw_get_reportdescriptor, > + hidraw_get_string, > }; > > static void try_add_device(struct udev_device *dev) > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index ad09ec1..a7b76df 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -421,6 +421,17 @@ NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) > irp->IoStatus.Information = length; > break; > } > + case IOCTL_HID_GET_STRING: > + { > + DWORD index = (DWORD)irpsp->Parameters.DeviceIoControl.Type3InputBuffer; This will trigger a compilation warning on 64-bit. You have to cast to a ptr-size integer type first, for example: DWORD index = (ULONG_PTR)irpsp->Parameters.DeviceIoControl.Type3InputBuffer; Also, accoding to MSDN, the content of the variable is a composite value: """Parameters.DeviceIoControl.Type3InputBuffer in the I/O stack location of the IRP contains a composite value. The two most significant bytes contain the language ID of the string to be retrieved. The two least significant bytes contain one of the following three constant values...""" > + TRACE("IOCTL_HID_GET_STRING[%i]\n", index); > + irp->IoStatus.u.Status = status = ext->vtbl->get_string(device, > + index, (WCHAR*)(irp->UserBuffer), > + irpsp->Parameters.DeviceIoControl.OutputBufferLength/sizeof(WCHAR)); > + if (status == STATUS_SUCCESS) > + irp->IoStatus.Information = (strlenW((WCHAR*)(irp->UserBuffer)) + 1) * sizeof(WCHAR); > + break; > + } > default: > { > ULONG code = irpsp->Parameters.DeviceIoControl.IoControlCode; > > >

Oct. 12, 2016

Re: [PATCH v4 1/2] libwine: Don't call exit in the shared library.

by Alexandre Julliard

Jens Reyer <jre.winesim(a)gmail.com> writes: > On 11.10.2016 16:59, Sebastian Lackner wrote: >> 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. > > Thanks a lot, that's the advice I've been looking for (obviously not > with the hoped for outcome). > > Unfortunately the todo is beyond my capabilities. I'll discuss that at > Debian and propose to drop the patch for now. > > Instead I'll file a bug here since I haven't heard anyone rejecting the > goal of getting rid of exit in the shared library itself. I don't think that's a useful goal. It's not a bad idea to review its usage, and possibly replace it where it makes sense, but there are also places where exit is needed. -- Alexandre Julliard julliard(a)winehq.org

Oct. 12, 2016

Re: [PATCH v4 1/2] libwine: Don't call exit in the shared library.

by Jens Reyer

On 11.10.2016 16:59, Sebastian Lackner wrote: > 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. Thanks a lot, that's the advice I've been looking for (obviously not with the hoped for outcome). Unfortunately the todo is beyond my capabilities. I'll discuss that at Debian and propose to drop the patch for now. Instead I'll file a bug here since I haven't heard anyone rejecting the goal of getting rid of exit in the shared library itself. Greets jre

Oct. 12, 2016

Re: [PATCH 1/2] Tests for CertRegisterSystemStore

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 https://testbot.winehq.org/JobDetails.pl?Key=26111 Your paranoid android. === w864 (64 bit store) === store.c:2664: Test failed: CertAddCertificateContextToStore failed store.c:2665: Test failed: Unexpected cert3 store: unhandled exception c0000005 at 000000000044B790

Oct. 12, 2016

Re: [resend] riched20-add-support-for-EM_PASTESPECIAL

by Huw Davies

On Tue, Oct 11, 2016 at 10:54:44PM -0600, Kenneth Haley wrote: > partial fix for https://bugs.winehq.org/show_bug.cgi?id=14530 > > Support CF_TEXT & CF_UNICODETEXT clipboard formats. > > Tested on Arch Linux. > > Signed-off-by: K. Haley <haleykd(a)users.sf.net> > --- > dlls/riched20/editor.c | 42 +++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 41 insertions(+), 1 deletion(-) > > diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c > index 8b94ccf..7eeda2a 100644 > --- a/dlls/riched20/editor.c > +++ b/dlls/riched20/editor.c > @@ -2232,6 +2232,45 @@ static BOOL ME_Paste(ME_TextEditor *editor) > return TRUE; > } > > +static BOOL ME_PasteSpecial(ME_TextEditor *editor, BOOL unicode, UINT cf, REPASTESPECIAL *rps) > +{ > + DWORD dwFormat = SF_TEXT; > + EDITSTREAM es; > + ME_GlobalDestStruct gds; > + > + if (rps != NULL && rps->dwAspect != 0) { > + FIXME("REPASTESPECIAL structure handling not yet implemented\n"); > + } > + > + switch(cf) > + { > + // on XP CF_TEXT appears to paste unicode into W version of controll > + case CF_TEXT: > + case CF_UNICODETEXT: > + cf=CF_UNICODETEXT; > + if (!IsClipboardFormatAvailable(cf)) > + return FALSE; > + es.pfnCallback = ME_ReadFromHGLOBALUnicode; > + dwFormat|=SF_UNICODE; > + if (!unicode) > + FIXME("convert unicode to ANSI\n"); > + break; > + default: > + FIXME("Clipboard formats other than CF_TEXT and CF_UNICODETEXT not yet implemented!\n"); > + return FALSE; > + } > + > + if (!OpenClipboard(editor->hWnd)) > + return FALSE; > + gds.hData = GetClipboardData(cf); > + gds.nLength = 0; > + es.dwCookie = (DWORD_PTR)&gds; > + ME_StreamIn(editor, dwFormat|SFF_SELECTION, &es, FALSE); > + > + CloseClipboard(); > + return TRUE; > +} Sorry, I let this patch slip last time. Thanks for resubmitting. Unfortunately, this needs to be merged with the regular pasting code, which itself needs some work. Probably with regular paste querying for formats we want and calling an underlying 'getdata' function. Paste special would also call this function with the format specified. Additionally, all of this should use the Ole clipboard rather than the user32 api. Also note, we don't want C++ style comments in Wine. Huw.

Oct. 12, 2016

Re: Compile default Visual C++ 6 project with winegcc

by Kirn Gill

You'll need to use the Wine IDL Compiler (widl) to compile the resources into a separate object file (.o file). You will then need to include this file in the linking stage (since you're using winegcc to both compile and link, you'd do something like winegcc -m32 -o test2 test2.cpp resources.o). -- Kirn Gill II Mobile (SMS only): +1 813-330-8354 <+18133308354> VoIP: +1 813-704-0420 BBM: 7B963E04 Email: segin2005(a)gmail.com LinkedIn: http://www.linkedin.com/pub/kirn-gill/32/49a/9a6 On Tue, Oct 11, 2016 at 3:32 AM, A B <dianaxxyyzz(a)gmail.com> wrote: > I'm trying to compile the default sample win32 ,Hello World project . I > did winegcc -m32 -o test2 test2.cpp . It runs ok , but resources are not > loaded ,there is empty windows title and missing File and Help menus. > What is the correct way to make also load the resources? > > > >

Oct. 12, 2016

Re: wine X button on top bar

by Kirn Gill

There will be no such logic to find out if a windows is the "main". The concept doesn't exist in the Windows API, and thus trying to add such a concept will likely cause all sorts of problems. If a program has such an internal concept, great! But Wine nor the X desktop will know this, since there simply isn't any reliable mechanism to determine this. You could add per-application hacks, but 1. that's not the goal of the Wine project and 2. this would be an extreme amount of work (years) for very little end-user benefit, while also risking breaking applications. -- Kirn Gill II Mobile (SMS only): +1 813-330-8354 <+18133308354> VoIP: +1 813-704-0420 BBM: 7B963E04 Email: segin2005(a)gmail.com LinkedIn: http://www.linkedin.com/pub/kirn-gill/32/49a/9a6 On Mon, Oct 10, 2016 at 1:20 PM, A B <dianaxxyyzz(a)gmail.com> wrote: > Thinking from wine perspective , what will be the logic to find out if a > hwnd is for the main window of a program ? > > > > > >

Oct. 12, 2016

Re: [PATCH v4 1/2] libwine: Don't call exit in the shared library.

by Sebastian Lackner

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

Oct. 11, 2016

Re: [PATCH v4 0/2] Don't call exit in the shared library.

by Sebastian Lackner

On 11.10.2016 16:21, Jens Reyer wrote: > This includes dropping the wrong ones pointed out by Sebastian > Lackner (Thanks a lot! Note however that it always compiled just > fine with these changes) and the rejected ones for wpp (I assume > they are not related to the shared library). Those changes were in an #ifdef block, I assume the code was just never compiled on Debian.

Oct. 11, 2016

Re: ntoskrnl.exe: add KeAcquireInStackQueuedSpinLock stub

by Sebastian Lackner

On 11.10.2016 03:17, Austin English wrote: > For https://bugs.winehq.org/show_bug.cgi?id=41472 > In my header files it is defined as FASTCALL: --- snip --- NTKERNELAPI VOID FASTCALL KeAcquireInStackQueuedSpinLock ( _Inout_ PKSPIN_LOCK SpinLock, _Out_ PKLOCK_QUEUE_HANDLE LockHandle ); --- snip --- You will have to use the DEFINE_FASTCALL*_ENTRYPOINT macros to implement it. In the spec files it should also be marked with -norelay then. Regards, Sebastian

Oct. 11, 2016

Re: kernel32: Avoid two potential buffer overflows of cStr in create_hardware_branch.

by Sebastian Lackner

On 09.10.2016 22:30, Gerald Pfeifer wrote: > On Sun, 9 Oct 2016, Sebastian Lackner wrote: >> On 08.10.2016 22:31, Gerald Pfeifer wrote: >>> + char cStr[sizeof(dent->d_name)+sizeof(procname_ide_media)], >> http://man7.org/linux/man-pages/man3/readdir.3.html says: >> >> """The standard also notes that the use of sizeof(d_name) is >> incorrect; use strlen(d_name) instead. (On some systems, this field >> is defined as char d_name[1]!)""" >> >> This means your solution will not work on all systems. > > Interesting, thanks! Does this happen on any system we care about? > > I checked a current GNU/Linux system and FreeBSD, and on both > sizeof(d_name) works. Still, good to make this more portable, > so would > > char cStr[NAME_MAX+sizeof(procname_ide_media)] > > work? > > According to that man page > > Warning: applications should avoid any dependence on the size of the > d_name field. POSIX defines it as char d_name[], a character array of > unspecified size, with at most NAME_MAX characters preceding the termi- > nating null byte ('\0'). > > so we should be fine, shouldn't we? > > Gerald > NAME_MAX is only used at a few places, so not sure if it works on all platforms. The best method is usually to allocate a buffer dynamically, but not sure if its worth the effort for such old legacy code. Adding a length check at the beginning is probably easier. Btw, please also note that cUnixDeviceName is also affected by potential buffer overflow issues. Regards, Sebastian

Oct. 11, 2016

Re: [PATCH] d2d1: Make some of drawing calls a wrappers over DrawGeometry()

by Henri Verbeet

On 10 October 2016 at 16:29, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/d2d1/render_target.c | 45 ++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 42 insertions(+), 3 deletions(-) > This is ok, although for future reference, I'd prefer those as "Implement d2d_d3d_render_target_DrawRectangle().", etc.

Oct. 11, 2016

Re: ntdll: give user an error message if WINEARCH is not win32/win64

by Sebastian Lackner

On 11.10.2016 03:46, Austin English wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=41378 > > See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838474 At the time WINEARCH is checked it is already too late. The wineprefix has already been created (with fallback to the native arch if something weird was passed).

Oct. 11, 2016

Compile default Visual C++ 6 project with winegcc

by A B

I'm trying to compile the default sample win32 ,Hello World project . I did winegcc -m32 -o test2 test2.cpp . It runs ok , but resources are not loaded ,there is empty windows title and missing File and Help menus. What is the correct way to make also load the resources?

Oct. 11, 2016

Re: [PATCH resend] winex11: Send SC_KEYMENU on managed windows.

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 https://testbot.winehq.org/JobDetails.pl?Key=26094 Your paranoid android. === w7pro64 (32 bit msg) === msg.c:11036: Test failed: msg.message = 30 instead of WM_TIMER msg.c:11040: Test failed: msg.message = 30 instead of WM_TIMER msg.c:11043: Test failed: msg.message = 30 instead of WM_TIMER === w1064 (64 bit msg) === msg.c:7444: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 001a

Oct. 11, 2016

Re: [PATCH 1/2] shell32: add SHRemoveLocalizedName stub

by Austin English

Yes, it should. Thanks for reviewing Dmitry. On Tue, Oct 11, 2016 at 1:05 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Austin English <austinenglish(a)gmail.com> wrote: > >> +HRESULT SHRemoveLocalizedName(const WCHAR *path) >> +{ >> + FIXME("%s stub\n", debugstr_w(path)); >> + return S_OK; >> +} > > Shouldn't it be WINAPI? > > -- > Dmitry. -- -Austin GPG: 14FB D7EA A041 937B

Oct. 11, 2016

Re: [PATCH 1/2] shell32: add SHRemoveLocalizedName stub

by Dmitry Timoshkov

Austin English <austinenglish(a)gmail.com> wrote: > +HRESULT SHRemoveLocalizedName(const WCHAR *path) > +{ > + FIXME("%s stub\n", debugstr_w(path)); > + return S_OK; > +} Shouldn't it be WINAPI? -- Dmitry.

Oct. 11, 2016

Re: visual studio 6 create file read only

by A B

The problem was ,when using build in msvcrt.dll ,in winecfg , it created files -r-r--r-- , so it display errors about it can not write to project files . But I removed the override from winecfg and now works On Tue, Oct 11, 2016 at 2:45 AM, A B <dianaxxyyzz(a)gmail.com> wrote: > fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x5f40190e ignored > fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x5f40190e ignored > fixme:ntdll:NtLockFile I/O completion on lock not implemented yet > > > On Tue, Oct 11, 2016 at 2:42 AM, A B <dianaxxyyzz(a)gmail.com> wrote: > >> Hello , >> Visual studio 6 create files read only , but photoshop is fine (r,w) . >> What could be the cause? >> > >

Oct. 10, 2016

Re: visual studio 6 create file read only

by A B

fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x5f40190e ignored fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x5f40190e ignored fixme:ntdll:NtLockFile I/O completion on lock not implemented yet On Tue, Oct 11, 2016 at 2:42 AM, A B <dianaxxyyzz(a)gmail.com> wrote: > Hello , > Visual studio 6 create files read only , but photoshop is fine (r,w) . > What could be the cause? >

Oct. 10, 2016

visual studio 6 create file read only

by A B

Hello , Visual studio 6 create files read only , but photoshop is fine (r,w) . What could be the cause?

Oct. 10, 2016

Re: [v2] preloader: Allow a debugger to find ld.so's rendezvous-struct

by Keno Fischer

I had submitted v3 of this patch, but I don't see it on https://source.winehq.org/patches/ anymore. Was there some review comments I missed somewhere? On Thu, Sep 8, 2016 at 10:44 PM, Keno Fischer <keno(a)juliacomputing.com> wrote: > Ok, that can probably be done with some linker script magic, since > this is merely a warning in the assembler. I'll take a look at that. > > On Thu, Sep 8, 2016 at 10:36 PM, Alexandre Julliard <julliard(a)winehq.org> > wrote: > > Keno Fischer <keno(a)juliacomputing.com> writes: > > > >> Whether .dynamic is writable depends on the architecture (I believe > >> the only one on which it isn't is MIPS, but I could be wrong about > >> that). Looks like binutils doesn't take that into account when issuing > >> this diagnostic in the assembler and expects .dynamic to have > >> SHF_ALLOC only. Probably something to complain about to them. I don't > >> believe there's an actual problem though, just an incorrect > >> diagnostic. > > > > We don't want to introduce build warnings though, so even if this is a > > binutils bug it would have to be avoided somehow. > > > > -- > > Alexandre Julliard > > julliard(a)winehq.org >

Oct. 10, 2016

Re: wine X button on top bar

by A B

I made it to finnaly work for visual studio 6 , to do not crash if user click X ,and a menu is oppened. I had to send WM_KILLFOCUS . I know this is a ugly patch but somebody maybe inspire and make the correct fix. Is just what works for me till now .Must be improved. I modified user32/message.c Here are all mods I did : void DoSomething(HWND hwnd); BOOL CALLBACK DoSomethingHelper(HWND hwnd, LPARAM lParam); void DoSomethingToWindowTree(HWND hwndRoot); void DoSomething(HWND hwnd) { WCHAR str[80]; PostMessageW( hwnd, WM_KILLFOCUS, WM_SETFOCUS ,0); GetWindowTextW( hwnd, str, sizeof(str)/sizeof(WCHAR) ); printf("\n Window name: %s " , debugstr_w(str) ); } BOOL CALLBACK DoSomethingHelper(HWND hwnd, LPARAM lParam) { DoSomething(hwnd); return TRUE; } void DoSomethingToWindowTree(HWND hwndRoot) { DWORD pid; EnumThreadWindows( GetWindowThreadProcessId(hwndRoot, &pid) , DoSomethingHelper, 0); } /*********************************************************************** * SendMessageW (USER32.@) */ LRESULT WINAPI SendMessageW( HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam ) { DWORD_PTR res = 0; struct send_message_info info; info.type = MSG_UNICODE; info.hwnd = hwnd; info.msg = msg; info.wparam = wparam; info.lparam = lparam; info.flags = SMTO_NORMAL; info.timeout = 0; if ( msg == WM_CLOSE) { DoSomethingToWindowTree(hwnd); PostMessageW( hwnd, WM_CLOSE, 0 ,0); return TRUE; } send_message( &info, &res, TRUE ); return res; } On Mon, Oct 10, 2016 at 9:30 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Oct 10, 2016, at 1:15 PM, A B <dianaxxyyzz(a)gmail.com> wrote: > > > Thank you for your response. > > I ' m trying to send WM_QUIT before send WM_CLOSE,when a user click on X > ,but only when he close the main window . This is a ugly patch that prevent > visual studio 6 to crash if a menu is opened and user click on X . > > That way I need to know if the hwnd from handle_wm_protocols() is the > one of the main window or not , cause I need to send WM_QUIT only if user > close his main program window. > > Rather than sending WM_QUIT, I recommend that you try sending > WM_CANCELMODE. You can send that to any window which the window manager > closes without unintended consequences, so you don't need to attempt to > determine which is the "main" window. In fact, this may not even be a > hack; it might be the right thing to do. > > > On Oct 10, 2016, at 1:20 PM, A B <dianaxxyyzz(a)gmail.com> wrote: > > > Thinking from wine perspective , what will be the logic to find out if a > hwnd is for the main window of a program ? > > There is no logic to find that out because "main window" is not a > well-defined concept and means nothing in terms of Wine/Windows internals. > Visual Studio itself may consider one of its windows "main", but that is > not exposed to Wine. The only significance is how VS behaves. > > -Ken > >

Oct. 10, 2016

Re: wine X button on top bar

by Ken Thomases

On Oct 10, 2016, at 1:15 PM, A B <dianaxxyyzz(a)gmail.com> wrote: > Thank you for your response. > I ' m trying to send WM_QUIT before send WM_CLOSE,when a user click on X ,but only when he close the main window . This is a ugly patch that prevent visual studio 6 to crash if a menu is opened and user click on X . > That way I need to know if the hwnd from handle_wm_protocols() is the one of the main window or not , cause I need to send WM_QUIT only if user close his main program window. Rather than sending WM_QUIT, I recommend that you try sending WM_CANCELMODE. You can send that to any window which the window manager closes without unintended consequences, so you don't need to attempt to determine which is the "main" window. In fact, this may not even be a hack; it might be the right thing to do. On Oct 10, 2016, at 1:20 PM, A B <dianaxxyyzz(a)gmail.com> wrote: > Thinking from wine perspective , what will be the logic to find out if a hwnd is for the main window of a program ? There is no logic to find that out because "main window" is not a well-defined concept and means nothing in terms of Wine/Windows internals. Visual Studio itself may consider one of its windows "main", but that is not exposed to Wine. The only significance is how VS behaves. -Ken

Oct. 10, 2016

Re: wine X button on top bar

by A B

Thinking from wine perspective , what will be the logic to find out if a hwnd is for the main window of a program ?

Oct. 10, 2016

Re: wine X button on top bar

by A B

Thank you for your response. I ' m trying to send WM_QUIT before send WM_CLOSE,when a user click on X ,but only when he close the main window . This is a ugly patch that prevent visual studio 6 to crash if a menu is opened and user click on X . That way I need to know if the hwnd from handle_wm_protocols() is the one of the main window or not , cause I need to send WM_QUIT only if user close his main program window. On Mon, Oct 10, 2016 at 9:07 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > I'm CC'ing the list. Please keep the discussion on the list. > > On Oct 10, 2016, at 12:26 PM, A B <dianaxxyyzz(a)gmail.com> wrote: > > > > If we run the command: wine program.exe , does wine save the hwnd of the > main window for the program.exe ? And how to get it ? For example if I want > to printf in wine logs ,the hwnd of the main window of program.exe , is > this hwnd saved somewhere in a wine variable ? > > The concept of "main window" of a program is purely a human > interpretation. There's no such concept in the Win32 API. Therefore, > there's no specific variable in Wine which holds the "main" window's handle. > > You can collect a +win debug log and you'll see the window handle of all > of the windows created by the program (along with a lot of activity related > to them). It's up to you to determine which is the main window. > > -Ken > >

Oct. 10, 2016

Re: wine X button on top bar

by Ken Thomases

I'm CC'ing the list. Please keep the discussion on the list. On Oct 10, 2016, at 12:26 PM, A B <dianaxxyyzz(a)gmail.com> wrote: > > If we run the command: wine program.exe , does wine save the hwnd of the main window for the program.exe ? And how to get it ? For example if I want to printf in wine logs ,the hwnd of the main window of program.exe , is this hwnd saved somewhere in a wine variable ? The concept of "main window" of a program is purely a human interpretation. There's no such concept in the Win32 API. Therefore, there's no specific variable in Wine which holds the "main" window's handle. You can collect a +win debug log and you'll see the window handle of all of the windows created by the program (along with a lot of activity related to them). It's up to you to determine which is the main window. -Ken

Oct. 10, 2016

Re: wine X button on top bar

by Ken Thomases

On Oct 9, 2016, at 8:30 PM, A B <dianaxxyyzz(a)gmail.com> wrote: > > If "Allow windows manager to decorate window" is on. > What is the function name that knows a user click this X button and send the WM_CLOSE to the app? The window manager sends ClientMessage with type WM_PROTOCOLS and the protocol value WM_DELETE_WINDOW. This is handled in dlls/winex11.drv/event.c: X11DRV_ClientMessage() -> handle_wm_protocols(). -Ken

Oct. 10, 2016

Re: [v2 PATCH] d2d1: Support shared bitmaps created from dxgi surface

by Henri Verbeet

On 10 October 2016 at 13:33, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> It's in fact possible to share dxgi resources between different >> devices and supposedly even different processes, but doing that would >> require using IDXGIResource::GetSharedHandle(), >> ID3D10Device::OpenSharedResource(), and D3D10_RESOURCE_MISC_SHARED, >> all of which are currently unimplemented in Wine. I'm not sure if d2d1 >> allows it. > > This sounds like too much, with nothing that depends on this yet. Yeah, implementing resource sharing is going to be a little painful. More so because you can also share e.g. d3d9 surfaces with d3d11. > I guess different device case/same process is easy to test, > but if it's a general sharing rule of dxgi/d3d10/11 to restrict resource > to device it was created from, tests should go to dxgi/d3d10/11 instead. > Possibly. In general using resources from a different device is certainly not going to work correctly, but the API may not explicitly enforce that everywhere and just crash or ignore calls. It should be easy enough to test for something like CreateShaderResourceView(), but e.g. VSSetShaderResources() would have less opportunities for giving feedback about using a view from a different device, and you likely wouldn't notice anything until you tried to draw with that setup. > Undefined because same surface is used for render target and bitmap? Yeah. Generally speaking binding resources as both inputs and outputs at the same time results in undefined behaviour, although that behaviour may very well end up being "does what you'd expect" on the particular hardware and driver you're testing with at the time. > Do you want me to change that? Not necessarily, I think it's fine for the test to show that this is allowed, although I do wonder a little if the Vista failure might be related.

Oct. 10, 2016

Re: [v2 PATCH] d2d1: Support shared bitmaps created from dxgi surface

by Nikolay Sivov

On 10.10.2016 14:15, Henri Verbeet wrote: > On 8 October 2016 at 19:18, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: >> -HRESULT d2d_bitmap_create_shared(ID2D1Factory *factory, ID3D10Device *target_device, >> +HRESULT d2d_bitmap_create_shared(ID2D1RenderTarget *render_target, ID3D10Device *target_device, >> REFIID iid, void *data, const D2D1_BITMAP_PROPERTIES *desc, struct d2d_bitmap **bitmap) >> { >> + D2D1_BITMAP_PROPERTIES d; >> + ID2D1Factory *factory; >> + >> + ID2D1RenderTarget_GetFactory(render_target, &factory); >> + ID2D1Factory_Release(factory); > This is a little improper. It does save a few lines, but I'd rather > just release it after we're actually done with it. Okay. > >> + else if (IsEqualGUID(iid, &IID_IDXGISurface) || IsEqualGUID(iid, &IID_IDXGISurface1)) > "else" is redundant here, although that's minor. Sure. > >> + { >> + ID3D10ShaderResourceView *view; >> + DXGI_SURFACE_DESC surface_desc; >> + IDXGISurface *surface = data; >> + ID3D10Resource *resource; >> + D2D1_SIZE_U pixel_size; >> + HRESULT hr; >> + >> + if (FAILED(IDXGISurface_QueryInterface(surface, &IID_ID3D10Resource, (void **)&resource))) >> + { >> + WARN("Failed to get d3d resource from dxgi surface.\n"); >> + return E_FAIL; >> + } >> + >> + hr = ID3D10Device_CreateShaderResourceView(target_device, resource, NULL, &view); > I think we should validate the dxgi surface's device matches the > target device first, like in the IID_ID2D1Bitmap case. Will do. > > It's in fact possible to share dxgi resources between different > devices and supposedly even different processes, but doing that would > require using IDXGIResource::GetSharedHandle(), > ID3D10Device::OpenSharedResource(), and D3D10_RESOURCE_MISC_SHARED, > all of which are currently unimplemented in Wine. I'm not sure if d2d1 > allows it. This sounds like too much, with nothing that depends on this yet. I guess different device case/same process is easy to test, but if it's a general sharing rule of dxgi/d3d10/11 to restrict resource to device it was created from, tests should go to dxgi/d3d10/11 instead. > >> + /* Shared DXGI surface. */ >> + desc.type = D2D1_RENDER_TARGET_TYPE_DEFAULT; >> + desc.pixelFormat.format = DXGI_FORMAT_B8G8R8A8_UNORM; >> + desc.pixelFormat.alphaMode = D2D1_ALPHA_MODE_PREMULTIPLIED; >> + desc.dpiX = 0.0f; >> + desc.dpiY = 0.0f; >> + desc.usage = D2D1_RENDER_TARGET_USAGE_NONE; >> + desc.minLevel = D2D1_FEATURE_LEVEL_DEFAULT; >> + >> + hr = ID2D1Factory_CreateDxgiSurfaceRenderTarget(factory1, surface2, &desc, &rt2); >> + ok(SUCCEEDED(hr), "Failed to create render target, hr %#x.\n", hr); >> + >> + bitmap_desc.pixelFormat.format = DXGI_FORMAT_B8G8R8A8_UNORM; >> + bitmap_desc.pixelFormat.alphaMode = D2D1_ALPHA_MODE_PREMULTIPLIED; >> + bitmap_desc.dpiX = 0.0f; >> + bitmap_desc.dpiY = 0.0f; >> + >> + hr = ID2D1RenderTarget_CreateSharedBitmap(rt2, &IID_IDXGISurface, surface2, &bitmap_desc, &bitmap2); >> + ok(SUCCEEDED(hr) || broken(hr == E_INVALIDARG) /* vista */, "Failed to create bitmap, hr %#x.\n", hr); > It's interesting that this works. I'd expect actually drawing with > that bitmap on that render target to be undefined though. > Undefined because same surface is used for render target and bitmap? Do you want me to change that?

Oct. 10, 2016

Re: [v2 PATCH] d2d1: Support shared bitmaps created from dxgi surface

by Henri Verbeet

On 8 October 2016 at 19:18, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > -HRESULT d2d_bitmap_create_shared(ID2D1Factory *factory, ID3D10Device *target_device, > +HRESULT d2d_bitmap_create_shared(ID2D1RenderTarget *render_target, ID3D10Device *target_device, > REFIID iid, void *data, const D2D1_BITMAP_PROPERTIES *desc, struct d2d_bitmap **bitmap) > { > + D2D1_BITMAP_PROPERTIES d; > + ID2D1Factory *factory; > + > + ID2D1RenderTarget_GetFactory(render_target, &factory); > + ID2D1Factory_Release(factory); This is a little improper. It does save a few lines, but I'd rather just release it after we're actually done with it. > + else if (IsEqualGUID(iid, &IID_IDXGISurface) || IsEqualGUID(iid, &IID_IDXGISurface1)) "else" is redundant here, although that's minor. > + { > + ID3D10ShaderResourceView *view; > + DXGI_SURFACE_DESC surface_desc; > + IDXGISurface *surface = data; > + ID3D10Resource *resource; > + D2D1_SIZE_U pixel_size; > + HRESULT hr; > + > + if (FAILED(IDXGISurface_QueryInterface(surface, &IID_ID3D10Resource, (void **)&resource))) > + { > + WARN("Failed to get d3d resource from dxgi surface.\n"); > + return E_FAIL; > + } > + > + hr = ID3D10Device_CreateShaderResourceView(target_device, resource, NULL, &view); I think we should validate the dxgi surface's device matches the target device first, like in the IID_ID2D1Bitmap case. It's in fact possible to share dxgi resources between different devices and supposedly even different processes, but doing that would require using IDXGIResource::GetSharedHandle(), ID3D10Device::OpenSharedResource(), and D3D10_RESOURCE_MISC_SHARED, all of which are currently unimplemented in Wine. I'm not sure if d2d1 allows it. > + /* Shared DXGI surface. */ > + desc.type = D2D1_RENDER_TARGET_TYPE_DEFAULT; > + desc.pixelFormat.format = DXGI_FORMAT_B8G8R8A8_UNORM; > + desc.pixelFormat.alphaMode = D2D1_ALPHA_MODE_PREMULTIPLIED; > + desc.dpiX = 0.0f; > + desc.dpiY = 0.0f; > + desc.usage = D2D1_RENDER_TARGET_USAGE_NONE; > + desc.minLevel = D2D1_FEATURE_LEVEL_DEFAULT; > + > + hr = ID2D1Factory_CreateDxgiSurfaceRenderTarget(factory1, surface2, &desc, &rt2); > + ok(SUCCEEDED(hr), "Failed to create render target, hr %#x.\n", hr); > + > + bitmap_desc.pixelFormat.format = DXGI_FORMAT_B8G8R8A8_UNORM; > + bitmap_desc.pixelFormat.alphaMode = D2D1_ALPHA_MODE_PREMULTIPLIED; > + bitmap_desc.dpiX = 0.0f; > + bitmap_desc.dpiY = 0.0f; > + > + hr = ID2D1RenderTarget_CreateSharedBitmap(rt2, &IID_IDXGISurface, surface2, &bitmap_desc, &bitmap2); > + ok(SUCCEEDED(hr) || broken(hr == E_INVALIDARG) /* vista */, "Failed to create bitmap, hr %#x.\n", hr); It's interesting that this works. I'd expect actually drawing with that bitmap on that render target to be undefined though.

Oct. 10, 2016

wine X button on top bar

by A B

Hello, If "Allow windows manager to decorate window" is on. What is the function name that knows a user click this X button and send the WM_CLOSE to the app? Thank you

Oct. 9, 2016

Re: kernel32: Avoid two potential buffer overflows of cStr in create_hardware_branch.

by Gerald Pfeifer

On Sun, 9 Oct 2016, Sebastian Lackner wrote: > On 08.10.2016 22:31, Gerald Pfeifer wrote: >> + char cStr[sizeof(dent->d_name)+sizeof(procname_ide_media)], > http://man7.org/linux/man-pages/man3/readdir.3.html says: > > """The standard also notes that the use of sizeof(d_name) is > incorrect; use strlen(d_name) instead. (On some systems, this field > is defined as char d_name[1]!)""" > > This means your solution will not work on all systems. Interesting, thanks! Does this happen on any system we care about? I checked a current GNU/Linux system and FreeBSD, and on both sizeof(d_name) works. Still, good to make this more portable, so would char cStr[NAME_MAX+sizeof(procname_ide_media)] work? According to that man page Warning: applications should avoid any dependence on the size of the d_name field. POSIX defines it as char d_name[], a character array of unspecified size, with at most NAME_MAX characters preceding the termi- nating null byte ('\0'). so we should be fine, shouldn't we? Gerald

Oct. 9, 2016

Re: kernel32: Avoid two potential buffer overflows of cStr in create_hardware_branch.

by Sebastian Lackner

On 08.10.2016 22:31, Gerald Pfeifer wrote: > + char cStr[sizeof(dent->d_name)+sizeof(procname_ide_media)], http://man7.org/linux/man-pages/man3/readdir.3.html says: """The standard also notes that the use of sizeof(d_name) is incorrect; use strlen(d_name) instead. (On some systems, this field is defined as char d_name[1]!)""" This means your solution will not work on all systems.

Oct. 9, 2016

Re: Running drivers in userspace/VM

by Aleksey Bragin

Hello, I'd like to chime in into that interesting discussion. What address space do these drivers run in? Is it a shared ntoskrnl.exe process for all processes ran by Wine or does Wine spawn a new ntoskrnl.exe per each new process? Regards, Aleksey Bragin On 09.10.2016 13:40, Marcus Meissner wrote: > Hi, > > Wine itself implements a minimal NT driver layer, with the main goal currently > to run copy protection drivers and later on HID and USB drivers that > operate on top of the NT HID and USB core drivers. > > So Wine implements some bits of ntoskrnl.exe, doing (c). > > So far I have not heard of anyone planning to do the other parts, and I can > not realistically evaluate the scope. > > Ciao, Marcus > On Fri, Oct 07, 2016 at 06:10:15PM +0300, KOLANICH wrote: >> Hello everybody. ReactOS project is devoted to making an OS kernel binary compatible with NT kernel. In their official FAQ it is written that they cannot be replaced with GNU/Linux + Wine because of drivers which cannot be run in Wine. I'm a bit sceptical about their OS, so I wonder why cannot drivers be run in wine? >> >> Drivers are run in ring 0 or 1, right? Why it is impossible/too complicated to >> a) expose some privileged instructions into userland through API; >> b) expose IO space using IOPL; >> c) make a mock of NT kernel to allow the drivers use its ABI; >> d) patch the binaries automatically to use API instead of privileged instructions; >> e) if a driver doesn't works well enough in userland, create a micro-VM using VT-x and VT-d and put there NT kernel mock and the driver? >> >> >

Oct. 9, 2016

Re: Running drivers in userspace/VM

by Marcus Meissner

Hi, Wine itself implements a minimal NT driver layer, with the main goal currently to run copy protection drivers and later on HID and USB drivers that operate on top of the NT HID and USB core drivers. So Wine implements some bits of ntoskrnl.exe, doing (c). So far I have not heard of anyone planning to do the other parts, and I can not realistically evaluate the scope. Ciao, Marcus On Fri, Oct 07, 2016 at 06:10:15PM +0300, KOLANICH wrote: > Hello everybody. ReactOS project is devoted to making an OS kernel binary compatible with NT kernel. In their official FAQ it is written that they cannot be replaced with GNU/Linux + Wine because of drivers which cannot be run in Wine. I'm a bit sceptical about their OS, so I wonder why cannot drivers be run in wine? > > Drivers are run in ring 0 or 1, right? Why it is impossible/too complicated to > a) expose some privileged instructions into userland through API; > b) expose IO space using IOPL; > c) make a mock of NT kernel to allow the drivers use its ABI; > d) patch the binaries automatically to use API instead of privileged instructions; > e) if a driver doesn't works well enough in userland, create a micro-VM using VT-x and VT-d and put there NT kernel mock and the driver? > >

Oct. 9, 2016

Re: [PATCH] d2d1: Support shared bitmaps created using dxgi surface

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 https://testbot.winehq.org/JobDetails.pl?Key=26077 Your paranoid android. === wvistau64 (32 bit d2d1) === d2d1.c:2194: Test failed: Failed to create bitmap, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040C9E8 === w2008s64 (32 bit d2d1) === d2d1.c:2194: Test failed: Failed to create bitmap, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040C9E8 === wvistau64 (64 bit d2d1) === d2d1.c:2194: Test failed: Failed to create bitmap, hr 0x80070057. d2d1: unhandled exception c0000005 at 000000000040C3BC === w2008s64 (64 bit d2d1) === d2d1.c:2194: Test failed: Failed to create bitmap, hr 0x80070057. d2d1: unhandled exception c0000005 at 000000000040C3BC

Oct. 7, 2016

Re: [PATCH v3 5/6] libwine: Don't call exit in the shared library.

by Sebastian Lackner

On 07.10.2016 18:39, Jens Reyer wrote: > @@ -140,18 +140,18 @@ static int try_mmap_fixed (void *addr, size_t len, int prot, int flags, > mapped and we must fail. */ > for ( i = 0; i < len; i += pagesize ) > if ( mincore( (caddr_t)addr + i, pagesize, &vec ) != -1 ) > - _exit(1); > + abort(); > > /* Perform the mapping with MAP_FIXED set. This is safe > now, as none of the pages is currently in use. */ > result = mmap( addr, len, prot, flags | MAP_FIXED, fildes, off ); > if ( result == addr ) > - _exit(0); > + break; > > if ( result != (void *) -1 ) /* This should never happen ... */ > munmap( result, len ); > > - _exit(1); > + abort(); > } > > /* reap child */ The _exit() calls are happening from a child process here, so there is nothing to change. I also doubt it will compile with the "break;" which is not even inside a loop. Regards, Sebastian

Oct. 7, 2016

Re: [PATCH v3 1/6] libport: Don't call exit in the shared library.

by Sebastian Lackner

On 07.10.2016 18:39, Jens Reyer wrote: > From: Michael Gilbert <mgilbert(a)debian.org> > Signed-off-by: Jens Reyer <jre.winesim(a)gmail.com> > --- > libs/port/spawn.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/libs/port/spawn.c b/libs/port/spawn.c > index 97364e7..c1a95a2 100644 > --- a/libs/port/spawn.c > +++ b/libs/port/spawn.c > @@ -55,20 +55,20 @@ int _spawnvp(int mode, const char *cmdname, const char *const argv[]) > if (mode == _P_DETACH) > { > pid = fork(); > - if (pid == -1) _exit(1); > - else if (pid > 0) _exit(0); > + if (pid == -1) abort(); > + else if (pid > 0) return pid; The _exit() calls are happening from a child process here, so there is nothing to change. In fact, returning to the caller even breaks the code. Regards, Sebastian > /* else in grandchild */ > } > > signal( SIGPIPE, SIG_DFL ); > execvp(cmdname, (char **)argv); > - _exit(1); > + abort(); > } > > if (pid == -1) > return -1; > > - if (mode == _P_OVERLAY) exit(0); > + if (mode == _P_OVERLAY) abort(); > > if (mode == _P_WAIT || mode == _P_DETACH) > { >

Oct. 7, 2016

Running drivers in userspace/VM

by KOLANICH

Hello everybody. ReactOS project is devoted to making an OS kernel binary compatible with NT kernel. In their official FAQ it is written that they cannot be replaced with GNU/Linux + Wine because of drivers which cannot be run in Wine. I'm a bit sceptical about their OS, so I wonder why cannot drivers be run in wine? Drivers are run in ring 0 or 1, right? Why it is impossible/too complicated to a) expose some privileged instructions into userland through API; b) expose IO space using IOPL; c) make a mock of NT kernel to allow the drivers use its ABI; d) patch the binaries automatically to use API instead of privileged instructions; e) if a driver doesn't works well enough in userland, create a micro-VM using VT-x and VT-d and put there NT kernel mock and the driver?

Oct. 7, 2016

Re: wined3d: Add missing '\n' to FIXME() messages.

by Henri Verbeet

On 6 October 2016 at 15:31, Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > + FIXME("unknown_semantics(0x%08x).\n", semantic->usage); Could you change that to something like "Unrecognised semantic usage %#x.\n"? > + if (mmask) FIXME("_unrecognized_modifier(%#x).\n", mmask); Similarly, something like "Unrecognised modifier %#x.\n" would probably be more appropriate here.

Oct. 7, 2016

Re: [PATCH 02/16] rpcrt4: Restore original error code when ReadFile fails with ERROR_MORE_DATA.

by Jacek Caban

On 06.10.2016 14:27, Alexandre Julliard wrote: > Jacek Caban <jacek(a)codeweavers.com> writes: > >> @@ -448,6 +448,7 @@ static int rpcrt4_conn_np_read(RpcConnection *Connection, >> char *buf = buffer; >> BOOL ret = TRUE; >> unsigned int bytes_left = count; >> + DWORD err = GetLastError(); >> >> while (bytes_left) >> { >> @@ -460,6 +461,7 @@ static int rpcrt4_conn_np_read(RpcConnection *Connection, >> bytes_left -= bytes_read; >> buf += bytes_read; >> } >> + if (ret) SetLastError(err); > I'd suggest using NtReadFile instead. Good point, thanks. I sent an updated patch. It seems to me that we could even get rid the loop here once message mode support is in (but it would need closer look at rpcrt4 first). Thanks, Jacek

Oct. 6, 2016

Re: [PATCH 02/16] rpcrt4: Restore original error code when ReadFile fails with ERROR_MORE_DATA.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > @@ -448,6 +448,7 @@ static int rpcrt4_conn_np_read(RpcConnection *Connection, > char *buf = buffer; > BOOL ret = TRUE; > unsigned int bytes_left = count; > + DWORD err = GetLastError(); > > while (bytes_left) > { > @@ -460,6 +461,7 @@ static int rpcrt4_conn_np_read(RpcConnection *Connection, > bytes_left -= bytes_read; > buf += bytes_read; > } > + if (ret) SetLastError(err); I'd suggest using NtReadFile instead. -- Alexandre Julliard julliard(a)winehq.org

Oct. 6, 2016

Re: [PATCH] winebus.sys: Implement IOCTL_HID_GET_DEVICE_ATTRIBUTES for hid devices

by Aric Stewart

On 10/6/16 7:00 AM, Sebastian Lackner wrote: > On 06.10.2016 04:51, Aric Stewart wrote: >> Signed-off-by: Aric Stewart <aric(a)codeweavers.com> >> --- >> dlls/winebus.sys/bus.h | 1 + >> dlls/winebus.sys/bus_udev.c | 1 + >> dlls/winebus.sys/main.c | 41 +++++++++++++++++++++++++++++++++++++++++ >> 3 files changed, 43 insertions(+) >> >> >> >> 0001-winebus.sys-Implement-IOCTL_HID_GET_DEVICE_ATTRIBUTES-.txt >> >> >> diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h >> index 099558b..342a66b 100644 >> --- a/dlls/winebus.sys/bus.h >> +++ b/dlls/winebus.sys/bus.h >> @@ -34,3 +34,4 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, >> const GUID *class, const platform_vtbl *vtbl, DWORD platform_data_size) DECLSPEC_HIDDEN; >> DEVICE_OBJECT *bus_find_hid_device(const platform_vtbl *vtbl, void *platform_dev) DECLSPEC_HIDDEN; >> void bus_remove_hid_device(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; >> +NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; >> diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c >> index 93e56f3..a01d88e 100644 >> --- a/dlls/winebus.sys/bus_udev.c >> +++ b/dlls/winebus.sys/bus_udev.c >> @@ -299,6 +299,7 @@ NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry >> >> udev_driver_obj = driver; >> driver->MajorFunction[IRP_MJ_PNP] = common_pnp_dispatch; >> + driver->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = hid_internal_dispatch; > > I guess you intentionally did not name it "common_*" because non-HID devices might > need a different handler, is that correct? > That is correct. -aric >> >> if (!(events[0] = CreateEventW(NULL, TRUE, FALSE, NULL))) >> goto error; >> diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c >> index 09a59d6..ef19322 100644 >> --- a/dlls/winebus.sys/main.c >> +++ b/dlls/winebus.sys/main.c >> @@ -30,7 +30,9 @@ >> #include "winternl.h" >> #include "winreg.h" >> #include "setupapi.h" >> +#include "winioctl.h" >> #include "ddk/wdm.h" >> +#include "ddk/hidport.h" >> #include "wine/debug.h" >> #include "wine/unicode.h" >> #include "wine/list.h" >> @@ -346,6 +348,45 @@ NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) >> return status; >> } >> >> +NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) >> +{ >> + NTSTATUS rc = irp->IoStatus.u.Status; > > I would suggest to use rename the variable to "status". > >> + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation(irp); >> + struct device_extension *extension = (struct device_extension *)device->DeviceExtension; >> + >> + TRACE("(%p, %p)\n", device, irp); >> + >> + switch(irpsp->Parameters.DeviceIoControl.IoControlCode) > > There is a space missing after "switch". > >> + { >> + case IOCTL_HID_GET_DEVICE_ATTRIBUTES: >> + { >> + PHID_DEVICE_ATTRIBUTES attr = (PHID_DEVICE_ATTRIBUTES)irp->UserBuffer; > > It would be better to use HID_DEVICE_ATTRIBUTES * instead of the version with the "P" prefix. > Also, please add a check for Parameters.DeviceIoControl.OutputBufferLength to make sure > the buffer is big enough. > > >> + TRACE("IOCTL_HID_GET_DEVICE_ATTRIBUTES\n"); >> + >> + RtlZeroMemory(attr, sizeof(HID_DEVICE_ATTRIBUTES)); > > Is there any specific reason to use RtlZeroMemory instead of memset? Something like > memset(attr, 0, sizeof(*attr)) would be easier. ;) > >> + attr->Size = sizeof(HID_DEVICE_ATTRIBUTES); >> + attr->VendorID = extension->vid; >> + attr->ProductID = extension->pid; >> + attr->VersionNumber = extension->version; >> + irp->IoStatus.u.Status = rc = STATUS_SUCCESS; >> + irp->IoStatus.Information = sizeof(HID_DEVICE_ATTRIBUTES); >> + break; >> + } >> + default: >> + { >> + ULONG code = irpsp->Parameters.DeviceIoControl.IoControlCode; >> + FIXME("Unsupported ioctl %x (device=%x access=%x func=%x method=%x)\n", >> + code, code >> 16, (code >> 14) & 3, (code >> 2) & 0xfff, code & 3); >> + break; >> + } >> + } >> + >> + if (rc != STATUS_PENDING) >> + IoCompleteRequest( irp, IO_NO_INCREMENT ); > > Do you need to handle asynchronous requests in this function? If not you can remove the > if check. For consistency reasons, you should probably remove the space after "(" and > before ")" in the IoCompleteRequest call. > >> + >> + return rc; >> +} >> + >> NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) >> { >> static const WCHAR udevW[] = {'\\','D','r','i','v','e','r','\\','U','D','E','V',0}; >> >> >> >

Oct. 6, 2016

Re: [PATCH] winebus.sys: Implement IOCTL_HID_GET_DEVICE_ATTRIBUTES for hid devices

by Sebastian Lackner

On 06.10.2016 04:51, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus.h | 1 + > dlls/winebus.sys/bus_udev.c | 1 + > dlls/winebus.sys/main.c | 41 +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 43 insertions(+) > > > > 0001-winebus.sys-Implement-IOCTL_HID_GET_DEVICE_ATTRIBUTES-.txt > > > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index 099558b..342a66b 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -34,3 +34,4 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > const GUID *class, const platform_vtbl *vtbl, DWORD platform_data_size) DECLSPEC_HIDDEN; > DEVICE_OBJECT *bus_find_hid_device(const platform_vtbl *vtbl, void *platform_dev) DECLSPEC_HIDDEN; > void bus_remove_hid_device(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > +NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index 93e56f3..a01d88e 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -299,6 +299,7 @@ NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry > > udev_driver_obj = driver; > driver->MajorFunction[IRP_MJ_PNP] = common_pnp_dispatch; > + driver->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = hid_internal_dispatch; I guess you intentionally did not name it "common_*" because non-HID devices might need a different handler, is that correct? > > if (!(events[0] = CreateEventW(NULL, TRUE, FALSE, NULL))) > goto error; > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 09a59d6..ef19322 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -30,7 +30,9 @@ > #include "winternl.h" > #include "winreg.h" > #include "setupapi.h" > +#include "winioctl.h" > #include "ddk/wdm.h" > +#include "ddk/hidport.h" > #include "wine/debug.h" > #include "wine/unicode.h" > #include "wine/list.h" > @@ -346,6 +348,45 @@ NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) > return status; > } > > +NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) > +{ > + NTSTATUS rc = irp->IoStatus.u.Status; I would suggest to use rename the variable to "status". > + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation(irp); > + struct device_extension *extension = (struct device_extension *)device->DeviceExtension; > + > + TRACE("(%p, %p)\n", device, irp); > + > + switch(irpsp->Parameters.DeviceIoControl.IoControlCode) There is a space missing after "switch". > + { > + case IOCTL_HID_GET_DEVICE_ATTRIBUTES: > + { > + PHID_DEVICE_ATTRIBUTES attr = (PHID_DEVICE_ATTRIBUTES)irp->UserBuffer; It would be better to use HID_DEVICE_ATTRIBUTES * instead of the version with the "P" prefix. Also, please add a check for Parameters.DeviceIoControl.OutputBufferLength to make sure the buffer is big enough. > + TRACE("IOCTL_HID_GET_DEVICE_ATTRIBUTES\n"); > + > + RtlZeroMemory(attr, sizeof(HID_DEVICE_ATTRIBUTES)); Is there any specific reason to use RtlZeroMemory instead of memset? Something like memset(attr, 0, sizeof(*attr)) would be easier. ;) > + attr->Size = sizeof(HID_DEVICE_ATTRIBUTES); > + attr->VendorID = extension->vid; > + attr->ProductID = extension->pid; > + attr->VersionNumber = extension->version; > + irp->IoStatus.u.Status = rc = STATUS_SUCCESS; > + irp->IoStatus.Information = sizeof(HID_DEVICE_ATTRIBUTES); > + break; > + } > + default: > + { > + ULONG code = irpsp->Parameters.DeviceIoControl.IoControlCode; > + FIXME("Unsupported ioctl %x (device=%x access=%x func=%x method=%x)\n", > + code, code >> 16, (code >> 14) & 3, (code >> 2) & 0xfff, code & 3); > + break; > + } > + } > + > + if (rc != STATUS_PENDING) > + IoCompleteRequest( irp, IO_NO_INCREMENT ); Do you need to handle asynchronous requests in this function? If not you can remove the if check. For consistency reasons, you should probably remove the space after "(" and before ")" in the IoCompleteRequest call. > + > + return rc; > +} > + > NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) > { > static const WCHAR udevW[] = {'\\','D','r','i','v','e','r','\\','U','D','E','V',0}; > > >

Oct. 6, 2016

Re: Problems with WM_DROPFILES

by Michael Stefaniuc

On 10/06/2016 12:46 PM, John Found wrote: > On Thu, 6 Oct 2016 10:28:14 +0300 > John Found <johnfound(a)asm32.info> wrote: > >> Any ideas about fixing all this mess? Writing own WindowFromPoint especially for the drag&drop operations? >> > > Well, that was exactly what I tried and everything seems to work good. In the attachment is the modified file: "dlls/winex11.drv/xdnd.c" > > Please someone to review it and if it fits the standards of the project, commit it to the repository (or what the git people do with the modified files)... Diffs are easier to review so here it is (generated with just 'git diff') bye michael

Oct. 6, 2016

Re: Problems with WM_DROPFILES

by John Found

On Thu, 6 Oct 2016 10:28:14 +0300 John Found <johnfound(a)asm32.info> wrote: > Any ideas about fixing all this mess? Writing own WindowFromPoint especially for the drag&drop operations? > Well, that was exactly what I tried and everything seems to work good. In the attachment is the modified file: "dlls/winex11.drv/xdnd.c" Please someone to review it and if it fits the standards of the project, commit it to the repository (or what the git people do with the modified files)... If not, give me some directions what to do further. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

Oct. 6, 2016

Re: [PATCH 5/7] wined3d: Avoid destroying active contexts.

by Józef Kucia

On Thu, Oct 6, 2016 at 11:46 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 6 October 2016 at 11:45, Józef Kucia <joseph.kucia(a)gmail.com> wrote: >> FWIW, a copy of the wined3d creation flags is stored in d3d_info, so >> "context->d3d_info.wined3d_creation_flags" is the proper way to get >> them. > Right, d3d_info is "new". Yeah, wined3d_creation_flags is even newer. It was introduced together with WINED3D_SRGB_READ_WRITE_CONTROL.

Oct. 6, 2016

Re: [PATCH 5/7] wined3d: Avoid destroying active contexts.

by Henri Verbeet

On 6 October 2016 at 11:45, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > FWIW, a copy of the wined3d creation flags is stored in d3d_info, so > "context->d3d_info.wined3d_creation_flags" is the proper way to get > them. Right, d3d_info is "new".

Oct. 6, 2016

Re: [PATCH 5/7] wined3d: Avoid destroying active contexts.

by Józef Kucia

On Thu, Oct 6, 2016 at 11:28 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > Still, ideally the context wouldn't have a device pointer either. I > think the legitimate accesses to the device are mostly either > accessing shared resources like textures and samplers, or using the > device to get at the wined3d creation flags. We can probably store the > shared resources in some structure inside the device, and then store a > pointer to that in the context instead, and probably just copy the > flags. FWIW, a copy of the wined3d creation flags is stored in d3d_info, so "context->d3d_info.wined3d_creation_flags" is the proper way to get them.

Oct. 6, 2016

Re: [PATCH] d2d1/tests: Initial tests for bitmap render target

by Henri Verbeet

On 5 October 2016 at 17:33, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static inline BOOL float_eq(FLOAT left, FLOAT right) > +{ > + int x = *(int *)&left; > + int y = *(int *)&right; > + > + if (x < 0) > + x = INT_MIN - x; > + if (y < 0) > + y = INT_MIN - y; > + > + return abs(x - y) <= 8; > +} Not wrong per se, but in the D3D tests that's generally called "compare_float()" and takes an explicit "ulps" argument. Is "8" based on test results or a guess? It seems fairly large for something that shouldn't be a particularly complicated calculation. Also, "float". > + /* Both pixel size and DIP size are specified. */ > + set_size_u(&pixel_size, 128, 128); > + hr = ID2D1HwndRenderTarget_CreateCompatibleRenderTarget(hwnd_rt, &size, &pixel_size, NULL, > + D2D1_COMPATIBLE_RENDER_TARGET_OPTIONS_NONE, &rt); > + ok(SUCCEEDED(hr), "Failed to create render target, hr %#x.\n", hr); > + > + /* Doubled pixel size dimensions with the same DIP size give doubled dpi. */ > + ID2D1BitmapRenderTarget_GetDpi(rt, dpi2, dpi2 + 1); > + ok(dpi[0] == dpi2[0] / 2.0f && dpi[1] == dpi2[1] / 2.0f, "Got dpi mismatch.\n"); As an aside, the reason some of the existing tests use different DPI settings for the x and y axes is to avoid accidentally swapping them in the implementation.

Oct. 6, 2016

Re: [PATCH 5/7] wined3d: Avoid destroying active contexts.

by Henri Verbeet

On 5 October 2016 at 11:17, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Ideally, a pointer to a swapchain would be completely removed from > struct wined3d_context. Yeah. One of the things that made me hesitate a bit about the first patch in this series is that it was originally an explicit design decision to avoid storing a pointer to the device in the context. At the time we needed the swapchain pointer, I think for the window or DC handle or something. Over time the reasons for having the swapchain pointer mostly went away, and it ended up as more of a way to get around not being able to access the device. Perhaps that's worse than what we were trying to avoid. Still, ideally the context wouldn't have a device pointer either. I think the legitimate accesses to the device are mostly either accessing shared resources like textures and samplers, or using the device to get at the wined3d creation flags. We can probably store the shared resources in some structure inside the device, and then store a pointer to that in the context instead, and probably just copy the flags.

Oct. 6, 2016

Re: Problems with WM_DROPFILES

by John Found

After some talks and hints in the chat (thanks, puk, tbodt, nsivov!) I was able to fix the problem at least partially. The problem is that WINE uses WindowFromPoint to detect the drop target. WindowFromPoint uses WM_NCHITTEST to test the window and does not return windows returning HTTRANSPARENT. This way, these windows (tab controls for example) can not be drop targets at all. On the other hand, testing my code in Windows, I noticed, that it does not send WM_NCHITTEST at all and the "transparent" children are properly detected as a drop target. It is a big question why Windows does not send WM_NCHITTEST. It is documented behavior in the cases when WindowFromPoint is called from another thread. So, what is the thread that control the drag and drop operations? In the case of WINE it is obviously the same thread as the window creator (as long as it sends WM_NCHITTEST). In the case of Windows - it can be simply another thread, or drag/drop operation does not use WindowFromPoint. Any ideas about fixing all this mess? Writing own WindowFromPoint especially for the drag&drop operations? On Wed, 5 Oct 2016 11:57:11 +0300 John Found <johnfound(a)asm32.info> wrote: > I just realized, that in WINE, my windows receive WM_DROPFILES only if they are > top level windows. All children windows never accept WM_DROPFILES, regardless of > the presence of WS_EX_ACCEPTFILES or calling DragAcceptFiles() for this child window. > > In Windows everything works OK and the children correctly receive WM_DROPFILES message. > > Is it a bug in WINE, or something OS/WM dependent? > > How to fix it? Is it a good idea, for example, to accept the message in the main window and dispatch it to the respective children windows (by using DragQueryPoint) - this approach should work both in WINE and Windows. > > WINE v1.9.19 > XFCE4 window manager. > > -- > http://fresh.flatassembler.net > http://asm32.info > John Found <johnfound(a)asm32.info> > > -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

Oct. 6, 2016

Re: [PATCH v2] winebus.sys: Implement common IRP_MJ_POWER handling

by Aric Stewart

On 10/5/16 3:38 PM, Sebastian Lackner wrote: > On 05.10.2016 15:01, Aric Stewart wrote: >> >> v2: Suggestions from Sebastian Lackner >> Signed-off-by: Aric Stewart <aric(a)codeweavers.com> >> --- >> dlls/winebus.sys/bus.h | 1 + >> dlls/winebus.sys/bus_udev.c | 1 + >> dlls/winebus.sys/main.c | 21 +++++++++++++++++++++ >> 3 files changed, 23 insertions(+) > > I have submitted a patch which initializes all MajorFunction handlers with > a stub implementation [1]. This also matches Windows behavior. Please let > me know if you think this patch should still be applied (I guess on Windows > the bus drivers handle IRP_MJ_POWER, right?) or if we should skip it for now > if it was just to fix the crash. > > [1] http://source.winehq.org/patches/data/126881 Your patch should be sufficient. Right now none of our bus drivers need to handle this but if we find a case where they do then we can add an implementaion. -aric > > Regards, > Sebastian > > >

Oct. 5, 2016

Re: [PATCH 16/16] ntdll/tests: Added a test of using NtCancelIoEx on iosb associated with pipe listening.

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 https://testbot.winehq.org/JobDetails.pl?Key=26052 Your paranoid android. === w864 (32 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231 === w1064 (32 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231 === w864 (64 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231 === w1064 (64 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231

Oct. 5, 2016

Re: [PATCH v2] winebus.sys: Implement common IRP_MJ_POWER handling

by Sebastian Lackner

On 05.10.2016 15:01, Aric Stewart wrote: > > v2: Suggestions from Sebastian Lackner > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus.h | 1 + > dlls/winebus.sys/bus_udev.c | 1 + > dlls/winebus.sys/main.c | 21 +++++++++++++++++++++ > 3 files changed, 23 insertions(+) I have submitted a patch which initializes all MajorFunction handlers with a stub implementation [1]. This also matches Windows behavior. Please let me know if you think this patch should still be applied (I guess on Windows the bus drivers handle IRP_MJ_POWER, right?) or if we should skip it for now if it was just to fix the crash. [1] http://source.winehq.org/patches/data/126881 Regards, Sebastian

Oct. 5, 2016

Re: wine-1.8.5-rc2 Available

by André Hentschel

Am 05.10.2016 um 10:23 schrieb Michael Stefaniuc: > Hello guys, > > wine-1.8.5-rc2 is now available, including the tag: > https://github.com/mstefani/wine-stable > https://static-winehq.rhcloud.com/stable/ > > The commit "user32: Prevent resetting WS_MINIMIZE through > SetWindowLong." was deferred as Józef and Alexandre were not convinced > about that one. > > bye > michael > > > > Builds fine in buildroot

Oct. 5, 2016

Re: Some code ambiguity in tab control code.

by John Found

On Wed, 5 Oct 2016 21:11:14 +0200 André Hentschel <nerv(a)dawncrow.de> wrote: > > Hi, > what you found here looks like a copy&paste error to me, what happens to your problem if you make your suggested change? > > I am not sure I can clone wine, edit and then compile and have working product at the end. I am programming in assembly language and using Fossil version control. The world of C/C++ and git is very, very orthogonal to what I can do. :( -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

Oct. 5, 2016

Re: Some code ambiguity in tab control code.

by André Hentschel

Am 29.09.2016 um 23:49 schrieb John Found: > Hi. > > Trying without success to show tooltips for a tabcontrol, I found the following problems in the source code. Notice, that my skills in C++ are poor, so it is very possible the following is a false alarm. > > I am quote https://github.com/wine-mirror/wine/blob/master/dlls/comctl32/tab.c (hope it is the proper source code) > > This seems to be a bug: WM_LBUTTONDOWN is relayed in the WM_MOUSEMOVE handler. But WM_LBUTTONDOWN will always hide the tooltip. WM_MOUSEMOVE instead will set the timer for showing the tooltip. > >> static LRESULT >> TAB_MouseMove (TAB_INFO *infoPtr, WPARAM wParam, LPARAM lParam) >> { >> int redrawLeave; >> int redrawEnter; >> >> if (infoPtr->hwndToolTip) >> TAB_RelayEvent (infoPtr->hwndToolTip, infoPtr->hwnd, >> WM_LBUTTONDOWN, wParam, lParam); >> >> /* Determine which tab to highlight. Redraw tabs which change highlight >> ** status. */ >> TAB_RecalcHotTrack(infoPtr, &lParam, &redrawLeave, &redrawEnter); >> >> hottrack_refresh (infoPtr, redrawLeave); >> hottrack_refresh (infoPtr, redrawEnter); >> >> return 0; >> } > > > The WM_LBUTTONDOWN is relayed twice? Why? It is not exactly a bug, but sub-optimal. > >> static LRESULT >> TAB_LButtonDown (TAB_INFO *infoPtr, WPARAM wParam, LPARAM lParam) >> { >> POINT pt; >> INT newItem; >> UINT dummy; >> >> if (infoPtr->hwndToolTip) >> TAB_RelayEvent (infoPtr->hwndToolTip, infoPtr->hwnd, >> WM_LBUTTONDOWN, wParam, lParam); >> >> if (!(infoPtr->dwStyle & TCS_FOCUSNEVER)) { >> SetFocus (infoPtr->hwnd); >> } >> >> if (infoPtr->hwndToolTip) >> TAB_RelayEvent (infoPtr->hwndToolTip, infoPtr->hwnd, >> WM_LBUTTONDOWN, wParam, lParam); >> > > > > > Hi, what you found here looks like a copy&paste error to me, what happens to your problem if you make your suggested change?

Oct. 5, 2016

Re: [PATCH] msvcrt: Implement __std_type_info_hash

by GOUJON Alexandre

On 10/05/2016 10:56 AM, Piotr Caban wrote: > <snip> > Please change name of fnvPrime variable to something like fnv_prime. > Also you will need to initialize it using #ifdef, something like this > should work: > #ifdef _WIN64 > MSVCRT_size_t hash = ... > #else > MSVCRT_size_t hash = ... > #endif > <snip> Done. You used both #ifdef _WIN64 and if(sizeof(void*) == sizeof(int)) in the test but now I see the difference. I just sent another version. Thanks for the feedback!

Oct. 5, 2016

Re: Problems with WM_DROPFILES

by Michael Stefaniuc

On 10/05/2016 06:07 PM, Michael Stefaniuc wrote: > On 10/05/2016 05:53 PM, John Found wrote: >> Hello. Please, give me some receiving confirmation. >> I have a feeling I am stealth-banned from this mailing list. > You're not banned but this stuff is probably better directed to bugzilla > or irc. > > Actually as you already did a lot of troubleshooting submitting a test > case to wine-patches(a)redhat.com would get more attention. Bloody muscle memory... that should of course be wine-patches(a)winehq.org bye michael >> On Wed, 5 Oct 2016 11:57:11 +0300 >> John Found <johnfound(a)asm32.info> wrote: >> >>> I just realized, that in WINE, my windows receive WM_DROPFILES only if they are >>> top level windows. All children windows never accept WM_DROPFILES, regardless of >>> the presence of WS_EX_ACCEPTFILES or calling DragAcceptFiles() for this child window. >>> >>> In Windows everything works OK and the children correctly receive WM_DROPFILES message. >>> >>> Is it a bug in WINE, or something OS/WM dependent? >>> >>> How to fix it? Is it a good idea, for example, to accept the message in the main window and dispatch it to the respective children windows (by using DragQueryPoint) - this approach should work both in WINE and Windows. >>> >>> WINE v1.9.19 >>> XFCE4 window manager.

Oct. 5, 2016

Re: Problems with WM_DROPFILES

by Michael Stefaniuc

Hello John! On 10/05/2016 05:53 PM, John Found wrote: > Hello. Please, give me some receiving confirmation. > I have a feeling I am stealth-banned from this mailing list. You're not banned but this stuff is probably better directed to bugzilla or irc. Actually as you already did a lot of troubleshooting submitting a test case to wine-patches(a)redhat.com would get more attention. bye michael > > On Wed, 5 Oct 2016 11:57:11 +0300 > John Found <johnfound(a)asm32.info> wrote: > >> I just realized, that in WINE, my windows receive WM_DROPFILES only if they are >> top level windows. All children windows never accept WM_DROPFILES, regardless of >> the presence of WS_EX_ACCEPTFILES or calling DragAcceptFiles() for this child window. >> >> In Windows everything works OK and the children correctly receive WM_DROPFILES message. >> >> Is it a bug in WINE, or something OS/WM dependent? >> >> How to fix it? Is it a good idea, for example, to accept the message in the main window and dispatch it to the respective children windows (by using DragQueryPoint) - this approach should work both in WINE and Windows. >> >> WINE v1.9.19 >> XFCE4 window manager.

Oct. 5, 2016

Re: Problems with WM_DROPFILES

by Bruno Jesus

On Wed, Oct 5, 2016 at 12:53 PM, John Found <johnfound(a)asm32.info> wrote: > Hello. Please, give me some receiving confirmation. > I have a feeling I am stealth-banned from this mailing list. Hello, you are here. It is just that probably nobody knows how to help, sorry.

Oct. 5, 2016

Re: Do we delete spammers accounts from bugzilla?

by Alexandre Julliard

Bruno Jesus <00cpxxx(a)gmail.com> writes: > Today we had one more piece of spam, the bot registered the account a > few moments before creating a bug. In this case should we use > bugzilla's admin features to delete the user? I always disable the user right away, yes. This is done by setting the Disable text in the user admin page. -- Alexandre Julliard julliard(a)winehq.org

Oct. 5, 2016

Re: Problems with WM_DROPFILES

by John Found

Hello. Please, give me some receiving confirmation. I have a feeling I am stealth-banned from this mailing list. On Wed, 5 Oct 2016 11:57:11 +0300 John Found <johnfound(a)asm32.info> wrote: > I just realized, that in WINE, my windows receive WM_DROPFILES only if they are > top level windows. All children windows never accept WM_DROPFILES, regardless of > the presence of WS_EX_ACCEPTFILES or calling DragAcceptFiles() for this child window. > > In Windows everything works OK and the children correctly receive WM_DROPFILES message. > > Is it a bug in WINE, or something OS/WM dependent? > > How to fix it? Is it a good idea, for example, to accept the message in the main window and dispatch it to the respective children windows (by using DragQueryPoint) - this approach should work both in WINE and Windows. > > WINE v1.9.19 > XFCE4 window manager. > > -- > http://fresh.flatassembler.net > http://asm32.info > John Found <johnfound(a)asm32.info> > > -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

Oct. 5, 2016

Do we delete spammers accounts from bugzilla?

by Bruno Jesus

Today we had one more piece of spam, the bot registered the account a few moments before creating a bug. In this case should we use bugzilla's admin features to delete the user? Best wishes, Bruno

Oct. 5, 2016

Re: [PATCH] msvcrt: Implement __std_type_info_hash

by Piotr Caban

On 10/05/16 10:57, Dmitry Timoshkov wrote: > Piotr Caban <piotr.caban(a)gmail.com> wrote: > >>> + return hash ^ (hash >> 32); >> This will also cause compilation warning during 32-bit compilation. >> >>> diff --git a/dlls/ucrtbase/tests/cpp.c b/dlls/ucrtbase/tests/cpp.c >>> index 1a01fea..659269c 100644 >>> --- a/dlls/ucrtbase/tests/cpp.c >>> +++ b/dlls/ucrtbase/tests/cpp.c >>> @@ -163,7 +163,7 @@ static void test___std_type_info(void) >>> ti1.mangled[2] = 0; >>> hash1 = p___std_type_info_hash(&ti1); >>> #ifdef _WIN64 >>> - todo_wine ok(hash1 == 0xcbf29ce44fd0bfc1, "hash = %p\n", (void*)hash1); >>> + ok(hash1 == 0xcbf29ce44fd0bfc1, "hash = %p\n", (void*)hash1); >> And this. > > This one can't cause a compilation warning since it's conditionally > compiled. > I've thought about this one: if(sizeof(void*) == sizeof(int)) ok(hash1 == 0x40c5b8c, "hash = %p\n", (void*)hash1); + else + ok(hash1 == 0xaf63bc4c29620a60, "hash = %p\n", (void*)hash1);

Oct. 5, 2016

Re: [PATCH] msvcrt: Implement __std_type_info_hash

by Dmitry Timoshkov

Piotr Caban <piotr.caban(a)gmail.com> wrote: > > + return hash ^ (hash >> 32); > This will also cause compilation warning during 32-bit compilation. > > > diff --git a/dlls/ucrtbase/tests/cpp.c b/dlls/ucrtbase/tests/cpp.c > > index 1a01fea..659269c 100644 > > --- a/dlls/ucrtbase/tests/cpp.c > > +++ b/dlls/ucrtbase/tests/cpp.c > > @@ -163,7 +163,7 @@ static void test___std_type_info(void) > > ti1.mangled[2] = 0; > > hash1 = p___std_type_info_hash(&ti1); > > #ifdef _WIN64 > > - todo_wine ok(hash1 == 0xcbf29ce44fd0bfc1, "hash = %p\n", (void*)hash1); > > + ok(hash1 == 0xcbf29ce44fd0bfc1, "hash = %p\n", (void*)hash1); > And this. This one can't cause a compilation warning since it's conditionally compiled. -- Dmitry.

Oct. 5, 2016

Problems with WM_DROPFILES

by John Found

I just realized, that in WINE, my windows receive WM_DROPFILES only if they are top level windows. All children windows never accept WM_DROPFILES, regardless of the presence of WS_EX_ACCEPTFILES or calling DragAcceptFiles() for this child window. In Windows everything works OK and the children correctly receive WM_DROPFILES message. Is it a bug in WINE, or something OS/WM dependent? How to fix it? Is it a good idea, for example, to accept the message in the main window and dispatch it to the respective children windows (by using DragQueryPoint) - this approach should work both in WINE and Windows. WINE v1.9.19 XFCE4 window manager. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

Oct. 5, 2016