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

Re: USB Support

by Steve Kenton

On 04/25/2015 05:22 AM, Saulius Krasuckas wrote: > * On Tue, 14 Apr 2015, Steve Kenton wrote: >> On 04/14/2015 06:04 PM, Saulius Krasuckas wrote: >>> * On Sun, 12 Apr 2015, Steve Kenton wrote: >>>> I spent some more time looking at this last night and it looks like >>>> the registry enum keys are about every device ever plugged into the >>>> system, whether it's currently present or not and the actual Windows >>>> device tree is maintained in memory, so just the registry keys >>>> probably won't suffice. >>> >>> Steve, it won't of course. But this is the first required step. I >>> would say that another way: >>> >>> let's make the HwDetect [6] (custom program) work in Wine the same way >>> it works in Windows (except for disabling devices -- just the >>> monitoring part). It reads very small amount of data from "Enum\USB" >>> subkey (I guess). >>> >>> Another step might be fixing Wine so "USB Device Tree Viewer" [7] >>> works as in Windows. But this one looks like a lot more complicated >>> testcase. > ... >>> [6] http://www.codeproject.com/Articles/14500/Detecting-Hardware-Insertion-and-… >>> [7] http://www.uwe-sieber.de/usbtreeview_e.html >>> >> I was thinking along those same lines with something like the display >> portion of Windows Device Manager. ~wine/server/device.c has some >> routines for managing devices, I need to spend some more time >> understanding the current state of things. But yes, it does look like a >> good place to start. > > In bug report 37724 Henrik Haftmann talks [8] about similar issue and > offers code excerpt which uses related functions: > > SetupDiGetClassDevs() > SetupDiEnumDeviceInfo() > SetupDiOpenDevRegKey() > SetupDiDestroyDeviceInfoList() > SetupDiEnumDeviceInterfaces() > SetupDiGetDeviceInterfaceDetail() > > You might be interested in collaboration:) > > S. > > [8] https://bugs.winehq.org/show_bug.cgi?id=37724 > Actually, I think I'll come at it starting with a modified regedit so I can get familiar with the Windows API and GUI while displaying device information. And hopefully get a handle on the registry while I'm at it. 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. Uwe Bonnes made this comment in another email: "Newer usb devices often use winusb for usb communication. A translation dll winusb->libusb is thinkable. However the problem of device detection remains." Crawling through /sys and /proc or writing a device driver shim I think I can handle, Displaying the information or adding it to the registry is is murky (to me) which is why I'm looking at such a bass-ackwards approach. Steve

April 29, 2015

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

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > 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? I think it would be better to try to write a test that replicates the problem you are seeing. In particular, testing GetQueueStatus instead of message sequences is not very convincing to me, since it doesn't properly show what's going on. -- Alexandre Julliard julliard(a)winehq.org

April 29, 2015

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

by Alex Henrie

2015-04-28 8:03 GMT-06:00 Alexandre Julliard <julliard(a)winehq.org>: > Alex Henrie <alexhenrie24(a)gmail.com> writes: > >> Alexandre, >> >> What was wrong with this patch that you did not accept it? > > I'm concerned that you have been looking at Windows a bit too much. At first, I thought that Wine actually used this string. On closer look, it seems that Wine always replaces the dialog's string "Borders" with the string resource "Margins [inches]" or "Margins [mm]": https://source.winehq.org/git/wine.git/blob/abd673bde93b76a361ddf7342c538c2… https://source.winehq.org/git/wine.git/blob/abd673bde93b76a361ddf7342c538c2… The following test (run with `./wine dlls/comdlg32/tests/comdlg32_test.exe.so printdlg`) also supports the hypothesis that Wine always overrides the dialog's string: diff --git a/dlls/comdlg32/comdlg32.rc b/dlls/comdlg32/comdlg32.rc index d3deeab..9d37d69 100644 --- a/dlls/comdlg32/comdlg32.rc +++ b/dlls/comdlg32/comdlg32.rc @@ -438,7 +438,7 @@ BEGIN GROUPBOX "Orientation", grp1, 8, 156, 64, 56, BS_GROUPBOX AUTORADIOBUTTON "&Portrait", rad1, 16, 170, 52, 12, BS_AUTORADIOBUTTON AUTORADIOBUTTON "&Landscape", rad2, 16, 190, 52, 12, BS_AUTORADIOBUTTON - GROUPBOX "Borders", grp4, 80, 156, 152, 56, BS_GROUPBOX + GROUPBOX "foobar", grp4, 80, 156, 152, 56, BS_GROUPBOX LTEXT "L&eft:", stc15, 88, 172, 30, 8 EDITTEXT edt4, 119, 170, 36, 12, WS_TABSTOP|WS_GROUP|WS_BORDER LTEXT "&Right:", stc16, 159, 172, 30, 8 diff --git a/dlls/comdlg32/tests/printdlg.c b/dlls/comdlg32/tests/printdlg.c index 7e06c97..d6c7dff 100644 --- a/dlls/comdlg32/tests/printdlg.c +++ b/dlls/comdlg32/tests/printdlg.c @@ -88,7 +88,7 @@ static void test_PageSetupDlgA(void) ZeroMemory(pDlg, sizeof(PAGESETUPDLGA)); pDlg->lStructSize = sizeof(PAGESETUPDLGA); - pDlg->Flags = PSD_RETURNDEFAULT | PSD_NOWARNING; + pDlg->Flags = PSD_NOWARNING; SetLastError(0xdeadbeef); res = PageSetupDlgA(pDlg); ok( res || (CommDlgExtendedError() == PDERR_NODEFAULTPRN), 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? -Alex

April 28, 2015

Re: Wine 64 bit

by Josh DuBois

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

April 28, 2015

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

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Alexandre, > > What was wrong with this patch that you did not accept it? I'm concerned that you have been looking at Windows a bit too much. -- Alexandre Julliard julliard(a)winehq.org

April 28, 2015

Re: include: Added IShellFolderViewDual definition

by Nikolay Sivov

On 04/28/2015 12:30 PM, Marvin wrote: > 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=13085 > > Your paranoid android. > > > === build (build) === > Patch failed to apply > I had another patch in a queue that broke this one, will resend.

April 28, 2015

Re: [PATCH 5/5] d3d9/tests: Add spotlight and light range tests.

by Henri Verbeet

On 27 April 2015 at 17:39, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + static const float pi = 3.141592654f; I guess you'll have to resubmit this for the testbot, but while you're at it, I think I prefer M_PI.

April 28, 2015

Re: include: Added IShellFolderViewDual definition

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=13085 Your paranoid android. === build (build) === Patch failed to apply

April 28, 2015

Re: [PATCH 3/6] dmloader: Add and use a generic IPersistStream_GetClassID.

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=13066 Your paranoid android. === build (build) === Make failed

April 27, 2015

Re: [PATCH 2/6] dmloader/tests: Add more DirectMusicCollection tests.

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=13065 Your paranoid android. === build (build) === Make failed

April 27, 2015