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

Re: ws2_32: Include inttypes.h for UINT32_MAX.

by Francois Gouget

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. static inline INT64 get_rcvsnd_timeo( int fd, BOOL is_recv) ... timeout = get_rcvsnd_timeo(fd, optname == WS_SO_RCVTIMEO); *(int *)optval = timeout <= UINT32_MAX ? timeout : UINT32_MAX; -- 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

Re: ws2_32: Include inttypes.h for UINT32_MAX.

by Henri Verbeet

On 29 April 2015 at 11:34, Francois Gouget <fgouget(a)free.fr> wrote: > This fixes compilation on FreeBSD. > --- > > The only other files that use UINT32_MAX are: > * The .yy.c files. These are generated and always do an ifndef+define. > * dlls/mshtml/nsembed.c though it calls it PR_UINT32_MAX for some reason. > * dlls/jscript/string.c which simply defines it. > * dlls/winemac.drv/macdrv_cocoa.h which presumably gets it from the Mac > OS X headers. > > Maybe mshtml and jscript should use inttypes.h, or to the contrary, > maybe ws2_32 should use the ifndef+define approach. > 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.

April 29, 2015

Re: USB Support

by Joel Holdsworth

> 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

April 29, 2015

Re: USB Support

by Uwe Bonnes

>>>>> "Steve" == Steve Kenton <skenton(a)ou.edu> writes: Steve> I got into this because I'm writing firmware for a custom USB Steve> device to use in an embedded Linux system and the vendor tools Steve> are only available for Windows. Sigh. And of course Wine handles Steve> everything fine *except* the USB snooping. I've spent my entire Steve> professional life working the in Unix workstation & HPC world Steve> staring with PDP-11 and later VAX "boot me" tapes from Bell Labs Steve> / Western Electric. I think the last time I had to write a Steve> Windows GUI app was when the original Windows 95 was released :-( Steve> So I'm woefully out of date on Windows. Steve> Uwe Bonnes made this comment in another email: Steve> "Newer usb devices often use winusb for usb communication. A Steve> translation dll winusb->libusb is thinkable. However the problem Steve> of device detection remains." Steve> Crawling through /sys and /proc or writing a device driver shim I Steve> think I can handle, Displaying the information or adding it to Steve> the registry is is murky (to me) which is why I'm looking at such Steve> a bass-ackwards approach. Probably the USB device handling is devided into a DLL for USB access and the programm itself using the DLL. Perhaps the DLL API is public or you may get it with some kind of NDA from the vendor. In that case writing a replacement DLL is also an option. This is not generic at all, but may solve your problem. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 29, 2015

Re: user32: After handling an internal message give a chance to real message to arrive.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> I may have one, once I understand what you are trying to fix. What is > >> the actual problem that prompted you to write the tests and the fix? > > > > The problem is described in the first test for sending inter-thread > > messages: https://www.winehq.org/pipermail/wine-patches/2015-April/138750.html > > My original guess was that the problem is caused by internal message > > handling in Wine, and the tests I created confirmed that there is a problem > > in that area. The patch we are discussing fixes the problem discovered > > by these tests. > > I still don't understand why internal messages would be different. Is > that because you get only one inter-thread message instead of several? The problem is that once Get/PeekMessage handles an internal message it doesn't yield control to another thread and checks the message queue immediately, this misses a sent message from another thread and instead returns a previously posted one. I admit that this is a pure artificial thing that I stumbled upon, but it reveals a real bug in Wine with internal message handling. > I think it would be better to try to write a test that replicates the > problem you are seeing. I tried to simplify the tests since calling EndDialog+GetMessage+DestroyMessage from different threads may create pretty complicated scenarios, and most obvious (to me) things to test are SendMessage+Get/PeekMessage and SetWindowPos+ Get/PeekMessage from different threads are two cases that should cover things that I think may lead to the observed bug(s). I can sertainly add more tests, but only when already sent ones are accepted to avoid creating conflicts and resending them again. > In particular, testing GetQueueStatus instead of > message sequences is not very convincing to me, since it doesn't > properly show what's going on. I tried to test both as much as possible, did I miss some cases where one of GetQueueStatus or a message sequence is not tested? -- Dmitry.

April 29, 2015

Re: [PATCH] wined3d: fix different level count while texture update

by Henri Verbeet

On 28 April 2015 at 20:18, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > Bug 38048 > According to MSDN > https://msdn.microsoft.com/en-us/library/windows/desktop/bb205858(v=vs.85) > source texture CAN have greater level count then destination > Current comparison "!=“ causes black textures as discussed in the bugzilla. > This may be correct, it may not be. This change needs tests, and I believe that was pointed out in the bug report already.

April 29, 2015

Re: [PATCH] wined3d: fix Unrecognized usage flags

by Henri Verbeet

Please use git send-email for sending patches. On 28 April 2015 at 09:18, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_TEXTURE); This is fine, but WINED3DUSAGE_OWNDC is missing here as well. Is "buf" still larger enough after you add these flags? > - if (usage) FIXME("Unrecognized usage flag(s) %#x\n", usage); > + if (usage & ~WINED3DUSAGE_QUERY_MASK) FIXME("Unrecognized usage flag(s) %#x\n", usage); I think it makes more sense to do this in the caller. It may make even more sense to just merge debug_d3dusage() and debug_d3dusagequery().

April 29, 2015

Re: Wine 64 bit

by Alexandre Julliard

Charles Davis <cdavis5x(a)gmail.com> writes: > By the way, I can tell you right now that WoW64 won’t work quite > yet. Mac OS has no separate lib32/lib64 directories, so we need to > produce fat DLLs. I have another patch (also attached) to teach > kernel32 to recognize fat binaries, but there’s no build system > infrastructure for making fat DLLs yet. If you want to try out WoW64, > you’ll have to do that manually with lipo(1). (I’ve actually submitted > this second patch, but AJ hasn’t taken it. I guess he’s unconvinced > that it’s correct. Maybe if we try out WoW64 and it works, he’ll be > more convinced. ;) You'd have to make a more convincing argument for this. Not having lib32/lib64 is not an issue since Wine is looking for dlls in its own directory anyway. It would be trivial to use lib/wine32 and lib/wine64 or some similar scheme. -- Alexandre Julliard julliard(a)winehq.org

April 29, 2015

Re: Wine 64 bit

by Charles Davis

Sorry for the belated response. GCC takes forever to build on my system. > On Apr 28, 2015, at 8:26 AM, Josh DuBois <duboisj(a)codeweavers.com> wrote: > > > I was interested in compiling 64-bit wine on OS X the other day and hit some problems, so I thought I would resurrect this thread. I used gcc 4.8 from macports, because as far as I could tell there wasn't a chance of using any version of clang without patching it. Using gcc I hit winehq bug 38380 right away: > > https://bugs.winehq.org/show_bug.cgi?id=38380 > > With Ken's help I tried the attached patch, which allowed a few places where wine has assembly code calling 64-bit windows functions to assemble with Apple's broken assembler. 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.) I still need to get my __ms_va_list patches upstream into LLVM/Clang, but there’s a big rewrite going on related to pointer types in LLVM IR that affects my patch (i.e. it’ll make it simpler), so I’m waiting for that to go through first. > > The only other problem I hit was the pagezero thing discussed below: > > On 1/23/15 12:03 AM, cdavis5x(a)gmail.com wrote: >>>> 0003-configure-Support-64-bit-compilation-on-Mac-OS.patch >>> Regarding the -pagezero_size option: 1) it might as well be unconditional. The 32-bit code assumes a 4096-byte page-zero, implicit in the base address of WINE_DOS. >> It’s conditional in my tree because I have another patch that turns off the __PAGEZERO segment, then sticks the WINE_DOS segment at address 0. I submitted that patch once, but Alexandre rejected it because we lack V86 support anyway on Mac OS, so what’s it matter if Win16 and Win9x programs can’t access the IVT, BDA or DOS Data Segment? :) I guess I could make it unconditional (since he’s not going to take my patch to make it 0 on 32-bit), but it’d be redundant on 32-bit, because the default size of the __PAGEZERO segment there is 4k. > Did any resolution to this problem ever appear? Just now, attached to this email. ;) (NOTE: You’ll have to regenerate configure after applying this change.) > If that were fixed and we had a workaround for the broken Apple assembler, I think you could compile and test 64-bit wine on OS X. (The mac driver still won't compile without clang, but passing --disable-winemac.drv at least allowed use of the X11 driver.) > > I haven't tested much so far, but I at least got a working prefix and ran notepad (once with relay logging, even). 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. Mac OS has no separate lib32/lib64 directories, so we need to produce fat DLLs. I have another patch (also attached) to teach kernel32 to recognize fat binaries, but there’s no build system infrastructure for making fat DLLs yet. If you want to try out WoW64, you’ll have to do that manually with lipo(1). (I’ve actually submitted this second patch, but AJ hasn’t taken it. I guess he’s unconvinced that it’s correct. Maybe if we try out WoW64 and it works, he’ll be more convinced. ;) Chip

April 29, 2015

Re: [PATCH] comdlg32: Change "Borders" to "Margins".

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > If I am correct, it would be better to replace "Borders" with "" so > that translators have one less string to worry about. Is that > acceptable to you? If the string is not used, then of course it's better to remove it. -- Alexandre Julliard julliard(a)winehq.org

April 29, 2015