July 2015 - Wine-Devel - list.winehq.org

Re: [PATCH 2/5] rpcrt4: Set CorrDespIncrement to the size of the (non-range) /robust payload.
by Dmitry Timoshkov July 13, 2015

July 13, 2015

Huw Davies <huw(a)codeweavers.com> wrote: > +static void test_NdrCorrelationInitialize(void) > +{ > + MIDL_STUB_MESSAGE stub_msg; > + BYTE buf[256]; > + > + memset( &stub_msg, 0, sizeof(stub_msg) ); > + memset( buf, 0, sizeof(buf) ); > + > + NdrCorrelationInitialize( &stub_msg, buf, sizeof(buf), 0 ); > + ok( stub_msg.CorrDespIncrement == 2 || > + broken(stub_msg.CorrDespIncrement == 0), /* <= Win 2003 */ > + "got %d\n", stub_msg.CorrDespIncrement ); > + > + stub_msg.CorrDespIncrement = 1; > + NdrCorrelationInitialize( &stub_msg, buf, sizeof(buf), 0 ); > + ok( stub_msg.CorrDespIncrement == 1, "got %d\n", stub_msg.CorrDespIncrement ); > +} Probably having memset() calls before both tests would make it more convincing. -- Dmitry.

2 1

Re: (resend 2)[1/5]hidclass.sys: Implement helper IoCallMinidriver
by Henri Verbeet July 13, 2015

July 13, 2015

On 10 July 2015 at 21:39, Aric Stewart <aric(a)codeweavers.com> wrote: > +NTSTATUS IoCallMinidriver(ULONG code, DEVICE_OBJECT *device, VOID *in_buff, ULONG in_size, VOID *out_buff, ULONG out_size) DECLSPEC_HIDDEN; This is unused until patch 3/5. It also seems like a really bad idea to name internal helper functions like Windows functions. > + if (out_size) > + { > + buffer = HeapAlloc(GetProcessHeap(), 0, out_size); > + memcpy(buffer, out_buff, out_size); > + } Either out_buff and out_size are really badly named, or this is really suspicious.

2 1

Re: [1/2] gdi32: EnumFontFamilies should enumerate substituted fonts when directly asked for.
by Marvin July 13, 2015

July 13, 2015

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=15259 Your paranoid android. === w2000pro (32 bit font) === font.c:4054: Test failed: Times New Roman Baltic should be enumerated font.c:4056: Test failed: Times New Roman Baltic should be enumerated === wvistau64 (32 bit font) === The test timed out === wvistau64 (64 bit font) === The test timed out

1 0

Re: d3drm: Add stubs for IDirect3DRMDevice methods.
by Stefan Dösinger July 13, 2015

July 13, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, You aren't returning the version 1 interface from QueryInterface. Am 2015-07-11 um 14:40 schrieb Aaryaman Vasishta: > if (IsEqualGUID(riid, &IID_IDirect3DRMDevice3)) > *out = (IUnknown*)&object->IDirect3DRMDevice3_iface; > - else > + else if (IsEqualGUID(riid, &IID_IDirect3DRMDevice2)) > *out = (IUnknown*)&object->IDirect3DRMDevice2_iface; > + else > + *out = (IUnknown*)&object->IDirect3DRMDevice_iface; You can call QueryInterface instead of doing GUID checks like this. Just initialize ref = 0, then call QI and you'll return a ref = 1 device. Another option, if you like this better, is to always return e.g. a IDirect3DRMDevice3 from Direct3DRMDevice_create, remove the riid parameter and do the QueryInterface in the caller. In this case init the refcount to 1 and call device3_Release in the caller after calling QI to obtain the right interface. The first 3 patches look good to me. I'll ack them tomorrow. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVok1NAAoJEN0/YqbEcdMwlFcQAJUgHXSjnseG9zIMJuKwiOoU K0IeSIAODnpT/+Mqc307owC7WBnKhTu4XLmZA1F7NxTxqdIcH85BsYx/LdLSeipq Y9KnTOg6dD00bNrujqyoZ5RmFI/pA+BXwhNXrwfbFg+RLr21ecQTpfRuDn3ENmPM VjWPHsfd4QIRqd+0Qo4LHAAS4UDmMm/avLdN+Gh5AOsDvOQYWW6reaerxYz6k61h rlkZwu1gLsSFTsA/PGz4W3nacVZkfcH8JourB80CJ/+bdPj1DfVImCpa2sx/WQ3g KMzwmR4MnS0n8/F2wGsqx/VMIKQ3zBblWVy4ZkZaMao6wA5IOoISSFXWrQlfUZrS GU5sRGwyVlaYK8qCzBOn3TdHhrrNLpg5hHkCqpN2JM1IgNYVaMevjZ+ISJhvaKXO GlQKwxOdB0M/SRWIPQ2261eQG/31lGEYm9ocu7i4USmNkaVZZCKlBt6wqsbmj6hF 7J2eU2KtfUoJwRozZRPaEdcKa0Xdp9AfrOrq4wilvEpIuUBI2leVVpOBQrbDD1c6 Z7/z8I1hmIw8ZPNl9NIIx7IyRrtnV3GBFG8rmWfRkHMMmIlZKqnC7+Yzgj5UF7Ai vr89VCzoAGj1Du/Xr8x5vmciLAdoRVNNTqV6QTPYqOgOQkodyls8RxH/IwM1sH/6 ZHUuK1kI7/vyX2WkYPi1 =1vdj -----END PGP SIGNATURE-----

3 3

Looking at Bugzilla Bug 38665 - Toontown Rewritten Launcher under Wine/FreeBSD gives "ValueError: Empty certificate data"
by Neel Chauhan July 12, 2015

July 12, 2015

Hi, Can you please look at the Wine Bugzilla Bug 38665. The URL is: https://bugs.winehq.org/show_bug.cgi?id=38665 Thanks, Neel Chauhan

1 0

Re: (resend)[1/5]hidclass.sys: Implement helper IoCallMinidriver
by Dmitry Timoshkov July 10, 2015

July 10, 2015

Aric Stewart <aric(a)codeweavers.com> wrote: > +HRESULT IoCallMinidriver(ULONG code, PDEVICE_OBJECT device, PVOID in_buff, ULONG in_size, PVOID out_buff, ULONG out_size) What 'HRESULT' is supposed to represent in the kernel space? (Especially when actually an NTSTATUS is being returned). That applies to all patches in the series. Also it would be nice to get rid of all LPJUNK style types used all over the place. -- Dmitry.

3 2

Re: [PATCH 5/5] wined3d: Don't install fog compatibility wrappers in core profile contexts.
by Stefan Dösinger July 10, 2015

July 10, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-07-10 um 00:06 schrieb Matteo Bruni: > - if (!gl_info->supported[EXT_FOG_COORD]) > + if (!gl_info->supported[EXT_FOG_COORD] && gl_info->supported[WINED3D_GL_LEGACY_CONTEXT]) Shouldn't that depend on the chosen vertex pipeline implementation rather than the context type? I don't think we need those wrappers in legacy contexts if we're using GLSL for vertex processing. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVn66UAAoJEN0/YqbEcdMwwaMP/1NL3D/IB/tP6Ch1CH/SkwLc LVHe5/NZNTJNXCAj3EH+8yKvDZig3aC3yNemO+KZhu+UKdK4iOeoJeHGAxyu1Fa+ d4Vh8aMyG8QFfKDIiaRG8/qxL18HwBBVnp0KtAq2eOB8847XdL0sXGPW0SHiDaWZ 57oE3W85Ym1hfdn6RhRx0QGMFsLlil5d9vd6IF8yAXluItNNH+SDxdVmBwg2IfrA hpH6f5GcEtqG4VZd8ete6DwgEqEQDtvqdlRlcf/HTUSu8RF0Kr+y0SC00Q1NUfEb /QHboR9Vc1Uwca8MZqm9PgsT9aeZgHv5f7K79AewFUnHqj7ZckGM9ptHuPS2pWzM ChHNghvP22LCnhndKl71WJqFTCobGfjNwmD3+ffedBmu7UNLfl2hKSbQCpr3cCCa NDxKlUATuZWKpqJfGrcMbt10grgGolZfbGM99/ngQdeILZc7uwHXveGQJYlerrCz s89ey8dQydozL/sh9QCllcUI58DVE0DOx7rYlvI4/mZMD1+E131JAdIiqDWQYnS5 EVViK+uBXYWTGlTOg1btU9TK0gpzcBSCu3WEfV+BnjhZdR18jQfOzYD1hvy8c36A wBalWpvI6Iqbe/5f32MniyBFaJA2CCaqqZgd5sVx3Y0Y7mhfMk/kgC0vdc9h4tgh N77kUu44pDmGazZwxmjM =6Cds -----END PGP SIGNATURE-----

2 1

Re: msi/tests: Avoid test failures on win2k3.
by Marvin July 10, 2015

July 10, 2015

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=15219 Your paranoid android. === wvistau64 (32 bit install) === The test timed out === w7u (32 bit install) === Failure running script in VM: timed out waiting for the child process

1 0

Re: crossover programs missing from source code
by Theodore Dubois July 10, 2015

July 10, 2015

I'm not really interested in the source code, I just want to know what the programs do. And yes, I forgot about ntoskrnl, the only dll with an exe extension. I generated that list using ls, grep, and diff, and didn't look over it that carefully. ~Theodore On Jul 05, 2015, at 10:09 AM, Ben Klein <shacklein(a)gmail.com> wrote: In particular, all the cx* programs are Crossover-specific and should not appear in upstream wine at any point. On 6 July 2015 at 02:07, Vincent Povirk <madewokherd(a)gmail.com> wrote: The LGPL doesn't require us to publish the source code of individual .exe.so or .dll.so binaries if we're not basing them on LGPL code. I haven't checked the whole list, but most of these are programs CodeWeavers developed internally and thus controls the copyright on, and they mostly exist for integration with other components of CrossOver. That doesn't mean we can't or shouldn't publish the code, just that we probably haven't considered it. At the very least, I think we want to publish the source code of anything that exists for Windows compatibility. Note that ntoskrnl.exe is actually in the dlls/ directory of the Wine source tree, and it should be there in the CrossOver/Wine source code as well.

3 3

Re: Adding RID_TYPEHID RawInput support to user32
by Aric Stewart July 10, 2015

July 10, 2015

On 7/6/15 10:53 AM, Nathan Schulte wrote: > On 07/06/2015 07:40 AM, Aric Stewart wrote: >> Hello there, Sorry for the delay I was away on vacation until today. >> >> Yes, RawInput support should go through hid.dll. That is actually part of the reason I am doing the hid work the ways I am doing it. I want to be able to fully and correctly support RawInput as well as dinput, xinput and winmm joysticks. >> >> For wine work, you can have all the user32 stuff using the hid.dll HidD_ and HidP_ functions as they can be considered user land work. If you find there are HidD_ or HidP_ function you need that are not implemented, then that can be done. >> >> Right now the hid.dll work has gotten in but I am just starting to get the underlying hid minidriver work in place. Without the minidriver work hid.dll will not do much. > > I found your recent discussion from April ("Wine Joysticks, seeking a plan"), as well as reviewed your current work to hid.dll. I've been learning about the stack as I go along, but it seems documented enough to get a grasp of. These are the minidrivers you're talking about? > > https://msdn.microsoft.com/en-us/library/windows/hardware/jj131707(v=vs.85)… > > You're thinking of creating one per platform/API (on the hosting side: Linux/evdev, (Unix/Linux?) X11, Unix/Mac *), or mirroring MS's setup? I'm not sure how the loading of those libraries works (I did see the HidRegisterMinidriver routine though), so maybe the question is inaccurate. So the next round of patches have been submitted so you can see my hidclass and minidriver work. The goal is to have all the system native minidriver be in the winehidminidriver.sys so that it can be independent from the graphics driver. Wine's hidclass.sys can handle multiple minidrivers in one service, so we should not need independent minidrivers for every platform. Which should be handy. > > On 07/06/2015 07:40 AM, Aric Stewart wrote: >> Yes all the user32 work will need to be done. >> >> Xinput is on my goal list also. Xinput should also be a client of hid.dll > > Sounds good. I'll try to help where I can. It sounds like I need to become more familiar with the system before I'm really useful. There are 3 places I can really use help. 1) Review patches: I always love good reviews on my patches. Leads to stronger code. 2) Above hid.dll: This is doing the development work on RawInput, Xinput, Dinput and such to become clients of the user level hid.dll functions to access joysticks and gamepads. This should mostly be learning the respective APIs and hooking them into HID. RawInput is probably the easiest as it does not do much with the HID reports other than just pass them on. 3) Linux minidrivers: I have implemented the OS/X minidriver because that is what I am most familiar with. There is work to implement the linux and linuxinput minidrivers. This is for someone familiar with or wants to become familiar with the lower level linux interfaces. -aric

3 7