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

Re: Strange wined3d crash

by Francois Gouget

On Wed, 29 Apr 2015, Henri Verbeet wrote: > On 29 April 2015 at 12:40, Francois Gouget <fgouget(a)free.fr> wrote: > > I am getting a strange wined3d crash during the d3d8:device test. > > > Is that a regression? We did touch the shader generation code recently. It is actually. This is the patch that introduced the crash: commit 28343db2083de7b4afe4079da090520f44b5544d Author: Matteo Bruni <mbruni(a)codeweavers.com> Date: Mon Apr 27 17:39:12 2015 +0200 wined3d: Don't use the builtin FFP uniforms for the lights. While at it, use D3D-like uniforms for the light parameters and (consequently) implement range and proper D3D spotlights support. I can test patches but I'm not sure I'll have time to debug this much further for a while :-( Note that this is with an Intel HD Graphics 4600 GPU. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ $live{free} || die "";

April 29, 2015

Re: ws2_32: Include inttypes.h for UINT32_MAX.

by Jacek Caban

On 04/29/15 15:50, Bruno Jesus wrote: > On Wed, Apr 29, 2015 at 10:44 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: >> When setting the timeout, the value may be rounded. If it's rounded up >> from 0xffffffff, the value will not fit in 32-bit unsigned type. It's >> not theoretical, I've seen this happening. > Hi, Jacek. Thanks for the reply, so why can't we take care of the > overflow inside the helper function and still return an ULONG to > callers? Its callers accept different types. getsockopt uses unsigned type, so it may handle all values up to 0xffffffff. In case of sendto and recv_base, we need to pass it to poll, which accepts signed types. That's why I left handling overflows to callers. Jacek

April 29, 2015

Re: ws2_32: Include inttypes.h for UINT32_MAX.

by Bruno Jesus

On Wed, Apr 29, 2015 at 10:44 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > When setting the timeout, the value may be rounded. If it's rounded up > from 0xffffffff, the value will not fit in 32-bit unsigned type. It's > not theoretical, I've seen this happening. Hi, Jacek. Thanks for the reply, so why can't we take care of the overflow inside the helper function and still return an ULONG to callers?

April 29, 2015

Re: ws2_32: Include inttypes.h for UINT32_MAX.

by Jacek Caban

On 04/29/15 14:13, Bruno Jesus wrote: > Hi all, I don't really understand why this change was made, windows > uses 4 byte to set and get the value. It's not possible to set a value > higher than 0xffffffff When setting the timeout, the value may be rounded. If it's rounded up from 0xffffffff, the value will not fit in 32-bit unsigned type. It's not theoretical, I've seen this happening. Jacek

April 29, 2015

Re: ws2_32: Include inttypes.h for UINT32_MAX.

by Henri Verbeet

On 29 April 2015 at 12:22, Francois Gouget <fgouget(a)free.fr> wrote: > The timeout receives a 64 bit value so using an unsigned int would not > work. > Do you mean for "timeout" or for the assignment to "optval"? The current code is pretty much just broken for negative values. Since it's a timeout I'm guessing those just aren't supposed to happen, but in that case get_rcvsnd_timeo() should return a UINT64, and the assignment to "optval" should use e.g. "*(unsigned int *)optval = ...;".

April 29, 2015

Re: Wine 64 bit

by Josh DuBois

On 4/29/15 12:40 AM, Charles Davis wrote: > I don’t use Apple’s broken as(1), because I patch Clang, whose integrated assembler is decidedly un-broken. That’s why I never submitted a patch for that. (In fact, it’s possible to make as(1) invoke Clang to do the assembly, if you pass it the ‘-q’ switch.) Ah. Passing -q to as gave me a raft of errors the first time I tried. Clang's assembler choked on unrecognized .stabs directives and would not assemble, but removing -gstabs+ from the compile line allows clang to assemble relay.s without changing the movq instructions by passing -q to as. I'm not familiar with the impact, if any, that will have on debugging. It still seems useful to me to be able to assemble with Apples as and compile with gcc. Is there harm in changing the various movq instructions to be compatible with Apple's as? > That’s great! In fact, that’s actually further than I get building with Clang—even with my patches applied to it. (It doesn’t help that Clang produces broken DWARF unwind info for Win64 ABI functions, which I really need to fix…) > > By the way, I can tell you right now that WoW64 won’t work quite yet. Someone on bug 38380 claims to have gotten even father and successfully run 64-bit windows code. All of the 64-bit windows apps I tried seemed to have 32-bit installers, so I guess WoW64 is really necessary to give it a good try.

April 29, 2015

Re: USB Support

by Joel Holdsworth

> Thanks for the tip. I picked up a used usb protocol analyzer for a good > price to diagnose the immediate problem (lots of NAKs at an unexpected > time) but I'd still like to pursue getting USB support into wine and not > have to depend on a Windows box (or VM) for any part of the project. > Fair enough. Well I happen to know Peter Stuge who is the guy behind libusb (http://www.libusb.org/) He tends to hang out at #sigrok under the username "CareBear\" . I would recommend having a chat with him. Joel

April 29, 2015

Re: ws2_32: Include inttypes.h for UINT32_MAX.

by Bruno Jesus

On Wed, Apr 29, 2015 at 7:22 AM, Francois Gouget <fgouget(a)free.fr> wrote: > On Wed, 29 Apr 2015, Henri Verbeet wrote: > [...] >> Arguably it shouldn't be using UINT32_MAX at all, since it isn't >> actually used with uint32_t. I guess it should be using e.g. unsigned >> int with UINT_MAX instead. > > The timeout receives a 64 bit value so using an unsigned int would not > work. But using UINT_MAX plus the native limits.h can work. Hi all, I don't really understand why this change was made, windows uses 4 byte to set and get the value. It's not possible to set a value higher than 0xffffffff, actually I don't even now if that value is valid, only tests can tell the truth. Unless this is a very specific broken application that uses the mysterious unixism hack from socket.c: 5295 } else if (optlen == sizeof(struct timeval)) { 5296 WARN("SO_SND/RCVTIMEO for %d bytes: assuming unixism\n", optlen); Best wishes, Bruno

April 29, 2015

Re: USB Support

by Steve Kenton

On 4/29/2015 4:27 AM, Joel Holdsworth wrote: > >> I got into this because I'm writing firmware for a custom USB device >> to use in an embedded Linux system and the vendor tools are only >> available for Windows. Sigh. And of course Wine handles everything >> fine *except* the USB snooping. I've spent my entire professional >> life working the in Unix workstation & HPC world staring with PDP-11 and >> later VAX "boot me" tapes from Bell Labs / Western Electric. I think >> the last time I had to write a Windows GUI app was when the original >> Windows 95 was released :-( So I'm woefully out of date on Windows. > > I probably shouldn't tell you this because I *really* want USB support > in Wine, but you can currently do this currently using a VM. Run your > application in a Windows in VirtualBox, then you can use Linux's > usbmon to sniff the traffic. > > To do the capture I usually start off with wireshark, and then use > this command line tool that I maintain: > > https://github.com/jhol/usbdump > > With a command line packet trace, you can then do greps, diffs, vidiff > etc. to reverse engineer the protocol. > > Kind Regards > Joel > > Thanks for the tip. I picked up a used usb protocol analyzer for a good price to diagnose the immediate problem (lots of NAKs at an unexpected time) but I'd still like to pursue getting USB support into wine and not have to depend on a Windows box (or VM) for any part of the project. Steve

April 29, 2015

Strange wined3d crash

by Francois Gouget

I am getting a strange wined3d crash during the d3d8:device test. It's annoying because it only happens with the 64 bit build, and disappears if I add traces (+d3d or +d3d_shader), and even if I add a FIXME() just before the crash. The crash happens in shader_glsl_ffp_vertex_lighting(): shader_addline(buffer, "gl_FrontSecondaryColor = %s * specular;\n", specular); According to the checks I've been able to do the specular pointer is still correct when this gets called. Here's the backtrace: http://pastebin.com/DKvXTVJn Any idea what's up? It almost feels like a compiler bug (gcc 4.9.2 (Debian 4.9.2-10) here). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

April 29, 2015