March 2014 - Wine-Devel - list.winehq.org

Re: [PATCH 6/6] user32: Implement EnumDisplayDevicesW() based on EnumDisplayMonitors() and GetMonitorInfoW().

by Alexandre Julliard

Ken Thomases <ken(a)codeweavers.com> writes: > On Mar 28, 2014, at 10:58 AM, Alexandre Julliard wrote: > >> I think it should be the other way around, with EnumDisplayDevices being >> the main function, with some sort of centralized management of display >> devices. > > EnumDisplayMonitors() + GetMonitorInfo() provides the information necessary to implement EnumDisplayDevices(), but not vice versa. > > Can you elaborate on what you envision? What management do you want > centralized, besides the enumeration and querying of properties > represented by those three functions? Do you also mean enumerating > and changing display settings/modes? Would the centralized management > be in the wineserver? In user32? In the graphics driver? Yes, display settings/modes, adding/removing monitors, managing work area, restoring resolution on process exit, etc. There would be parts in user32, parts in the driver, but it should all run in the context of the explorer process. Normal processes should retrieve the info from explorer instead of using graphics driver calls. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2014

Re: apphelp: add a stub for SdbInitDatabase

by Hans Leidekker

On Sun, 2014-03-30 at 14:36 -0700, Austin English wrote: > +PDB WINAPI SdbInitDatabase(DWORD flags, LPCSTR path) > +{ > + FIXME("stub: %u %s\n", flags, debugstr_a(path)); > + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return NULL; > +} Return type should be HSDB. Please trace flags in hex.

March 31, 2014

RE: regsvr32: Replace printf calls with WriteConsole function (try 2)

by Hugh McMaster

On Sunday, 30 March 2014 7:49 AM, Lauri Kenttä wrote: > Hugh McMaster wrote: > > - printf("\t[/i] Call DllInstall passing it an optional [cmdline];\n"); > > - printf("\t when used with /u calls dll uninstall\n"); > > +\ [/i] Call DllInstall, passing an optional [cmdline].\n\ \tWhen > > +used with [/u], regsvr32 also calls DLL Uninstall.\n\ > > This whole "calls DLL Uninstall" thing is a bit weird, as there isn't a function > named DLL Uninstall or DllUninstall. The string was simply an updated version of the official regsvr32 dialog: " /i - Call DllInstall passing it an option [cmdline]; when used with /u calls dll uninstall " But I agree, as there is no DllUninstall function, updating the text for clarity would be preferable. > Maybe you should change it to something more exact like: > "When used with [/u], " + > 1) "passes [also] the uninstall flag [to DllInstall]" > 2) "uses DllInstall to uninstall the DLL" These better capture the essence of the " regsvr32 /u /i ... " command. > 3) "the bInstall parameter is set to FALSE" > 4) "calls DllInstall with bInstall set to FALSE" Both examples are good, but may cause confusion as the Boolean bInstall is not referenced anywhere else in the usage dialog. > If this is too radical, I'd suggest that you at least remove the "also". > With my English, it now says that regsvr32 /i /u calls DllInstall and also calls DLL > Uninstall, which is clearly neither true nor logical. (It really calls UnregisterDll > and DllInstall(FALSE,cmdline).) In addition, repeating "regsvr32" looks strange > to me in this kind of context. Fair point. Using your examples as a starting point, what do you think of the following options: (1) Call DllInstall, passing an optional [cmdline]. When used with [/u], passes an uninstall flag to DllInstall. (2) Call DllInstall, passing an optional [cmdline]. When used with [/u], an uninstall flag is passed to DllInstall. (3) Call DllInstall, passing an optional [cmdline]. When used with [/u], uses DllInstall to uninstall the DLL. (4) Call DllInstall, passing an optional [cmdline]. When used with [/u], the bInstall parameter of DllInstall is set to FALSE. For the record, I'm favouring options (3) and (4).

March 31, 2014

Re: [PATCH 6/6] user32: Implement EnumDisplayDevicesW() based on EnumDisplayMonitors() and GetMonitorInfoW().

by Ken Thomases

On Mar 28, 2014, at 10:58 AM, Alexandre Julliard wrote: > I think it should be the other way around, with EnumDisplayDevices being > the main function, with some sort of centralized management of display > devices. EnumDisplayMonitors() + GetMonitorInfo() provides the information necessary to implement EnumDisplayDevices(), but not vice versa. Can you elaborate on what you envision? What management do you want centralized, besides the enumeration and querying of properties represented by those three functions? Do you also mean enumerating and changing display settings/modes? Would the centralized management be in the wineserver? In user32? In the graphics driver? It's easy enough to imagine adding a new driver entry point for EnumDisplayDevices(), alongside EnumDisplayMonitors() and GetMonitorInfo(), if you'd prefer that it be implemented directly in the graphics driver like the others. That could be more efficient and less kludgy, although entails more code duplication between the drivers. Alternatively, I can envision a new hybrid entry point, something such as: BOOL EnumDisplayMonitorInfo(DWORD devnum, MONITORINFOEX *info); Like EnumDisplayDevices(), this takes a device ordinal and returns FALSE when there are no more devices. User32 could take responsibility for mapping between such ordinals and HMONITORs. Given that mapping, this entry point is obviously sufficient to implement GetMonitorInfo(). User32 could implement EnumDisplayMonitors() as a loop around that, doing the clip rect testing. And EnumDisplayDevices() could also be implemented in terms of this entry point, filling in the DISPLAY_DEVICE from the monitor info. It would be like the implementation in my patch except it wouldn't entail extraneous looping to get to the requested device. I know you don't like entry points that aren't direct analogs for Win32 functions, though. I suspect that neither of these is what you're looking for. If not, then I need a push in the right direction. One note: I think that the graphics driver needs to be aware of the mapping between device names (e.g. "\\.\DISPLAY2") and whatever it uses internally to identify specific displays. I envision the driver needing to look up the display of a DC. So, I've been planning on making the CreateDC() entry point look up the display from the device name and record it in the *_PDEVICE structure. -Ken

March 30, 2014

Re: mshtml: Added IHTMLTable::bgColor property implementation.

by Nikolay Sivov

On 3/30/2014 19:18, Zhenbo Li wrote: > + nsAString_Init(&strColor, NULL); > + nsres = nsIDOMHTMLTableElement_GetBgColor(This->nstable, &strColor); > + nsAString_Finish(&strColor); > + > + if(NS_SUCCEEDED(nsres)) { > + nsAString_GetData(&strColor, &color); > + V_VT(p) = VT_BSTR; > + hres = nscolor_to_str(color, &V_BSTR(p)); > + }else { > + ERR("SetBgColor failed: %08x\n", nsres); > + hres = E_FAIL; > + } I think you can't do GetData() after Finish().

March 30, 2014

Re: [PATCH] comctl32/tests: Fix a couple of uninitialized variables (Coverity)

by Nikolay Sivov

On 3/30/2014 18:26, 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=6070 > > Your paranoid android. > > > === wvistau64 (32 bit button) === > button.c:654: Test failed: BM_SETCHECK on a button: the msg sequence is not complete: expected 0000 - actual 000f > > > No, this is not a new failure, it happened some time ago on Win7. Nothing to do with this patch.

March 30, 2014

Re: [PATCH] comctl32/tests: Fix a couple of uninitialized variables (Coverity)

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=6070 Your paranoid android. === wvistau64 (32 bit button) === button.c:654: Test failed: BM_SETCHECK on a button: the msg sequence is not complete: expected 0000 - actual 000f

March 30, 2014

Re: [PATCH 1/2] ole32: Fix equality check in CommonPrefixWith() for pointer moniker

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=6068 Your paranoid android. === wvista (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === wvistau64 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w2008s64 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w7pro64 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w8 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === wvistau64 (64 bit moniker) === moniker: unhandled exception c0000005 at 000000000042024A === w2008s64 (64 bit moniker) === moniker: unhandled exception c0000005 at 000000000042024A === w7pro64 (64 bit moniker) === moniker: unhandled exception c0000005 at 000000000042024A

March 30, 2014

how to use ced1401 linux driver from wine application ?

by Alois Schlögl

Hi, I'm trying to connect through wine the CED1401 device which is connected through USB. There is a driver in the linux staging tree, (linux-source-3.10/drivers/staging/ced1401/), which I've already compiled into my kernel. The module loads fine and becomes available when connecting to the device. The are several application software for Windows (e.g. ced1401 [1], Spike [2], Signal5, and we have also one running in Igor Pro). The software runs also on Wine, but fails to identify the connected hardware device. I've tried to find relevant information in the wiki; and especially, http://wiki.winehq.org/USB as well as wine developer guide, Chapter 8 Kernel modules. I've a rough idea what is missing, but would like asking what you think is missing, and how much effort it would take to get this working ? --Alois [1] http://appdb.winehq.org/objectManager.php?sClass=application&iId=15958 [2] http://appdb.winehq.org/objectManager.php?sClass=application&iId=9146

March 29, 2014

Re: regsvr32: Replace printf calls with WriteConsole function (try 2)

by Lauri Kenttä

Sorry for being a bit late... Hugh McMaster wrote: > - printf("\t[/i] Call DllInstall passing it an optional > [cmdline];\n"); > - printf("\t when used with /u calls dll uninstall\n"); > +\ [/i] Call DllInstall, passing an optional [cmdline].\n\ > +\tWhen used with [/u], regsvr32 also calls DLL Uninstall.\n\ This whole "calls DLL Uninstall" thing is a bit weird, as there isn't a function named DLL Uninstall or DllUninstall. Maybe you should change it to something more exact like: "When used with [/u], " + 1) "passes [also] the uninstall flag [to DllInstall]" 2) "uses DllInstall to uninstall the DLL" 3) "the bInstall parameter is set to FALSE" 4) "calls DllInstall with bInstall set to FALSE" or something similar. Opinions? If this is too radical, I'd suggest that you at least remove the "also". With my English, it now says that regsvr32 /i /u calls DllInstall and also calls DLL Uninstall, which is clearly neither true nor logical. (It really calls UnregisterDll and DllInstall(FALSE,cmdline).) In addition, repeating "regsvr32" looks strange to me in this kind of context. -- Lauri Kenttä

March 29, 2014