wine-devel March 2014

78 participants
252 discussions

Fixing conflicts between WineD3D and WGL
by Ken Thomases 28 Apr '14

28 Apr '14

Hi, This email brings together several threads of conversation that have been spread across different bug reports. Sorry for the length. The problem: WineD3D is based on WGL (a.k.a. opengl32). As a consequence, it conflicts with application use of WGL in a number of ways. It's also limited by WGL, which doesn't allow for all of the behaviors of DirectDraw and Direct3D. https://bugs.winehq.org/show_bug.cgi?id=28869 WineD3D needs to make its own GL context current temporarily and then restore the previous GL context, but WGL requires a DC to restore it and the DC may no longer be valid. https://bugs.winehq.org/show_bug.cgi?id=29301 WineD3D changes the window style of the device window when it should not. It needs to do that in order to render to the full screen where WGL only allows full-featured rendering to a window. https://bugs.winehq.org/show_bug.cgi?id=2082 Again, WineD3D is rendering to a window when it wants to render full-screen. In this case, the affected apps create an owned window that sits in front of the device window, obscuring it. http://bugs.winehq.org/show_bug.cgi?id=29934 WineD3D sets a pixel format on the application window. This conflicts with a later attempt by the app to set a different pixel format on the window via WGL. I think the solution to these problems is for WineD3D to have an alternative path to set up its GL context. Henri and I have been discussing using Wine-specific extensions to WGL to do this. There's already the extension WGL_WINE_pixel_format_passthrough which provides the wglSetPixelFormatWINE() function which is just like GDI's SetPixelFormat() and WGL's wglSetPixelFormat() except it allows for changing the pixel format after it's been set once. WineD3D needs to change it even though WGL doesn't allow that. In some of the bug reports listed above, I've suggested adding new extensions or modifying WGL_WINE_pixel_format_passthrough. We probably need a more comprehensive approach. WGL exposes various pieces of state to the application. Ideally, WineD3D would not alter any of that state since such alterations are visible to the app and Direct3D doesn't do that on Windows. I'm not sure that's achievable but we should at least minimize such visible state changes to the extent we can. WGL state: * The DC pixel format. For window DCs (which I believe are the only ones of real interest), this is actually a property of the window, not the DC. Changed by SetPixelFormat(), wglSetPixelFormat(); exposed by GetPixelFormat(), wglGetPixelFormat(). * The current GL context for the thread. Changed by wglMakeCurrent(), wglMakeContextCurrentARB(); exposed by wglGetCurrentContext(). * The DC for the current GL context. Changed by wglMakeCurrent(), wglMakeContextCurrentARB(); exposed by wglGetCurrentDC(), wglGetCurrentReadDCARB(). The most important things to achieve are a) to not "consume" the only opportunity the app has to set the window's pixel format, and b) to restore the app's current GL context (and implicitly its DC) when returning control to it. I don't think it's necessary to avoid WineD3D ever changing WGL's notion of the current context. Certainly, while a WineD3D GL context is current, GL functions like glClear() will operate on WineD3D's context. If the app thinks its context is current and calls GL functions, its context better really be current. So, WineD3D really needs to restore the app's context before returning control (and it generally does, I think). If it's going to do that, then wglGetCurrentContext() will take care of itself. Same for wglGetCurrentDC(). Here's my proposal: Extension WGL_WINE_surface: HANDLE wglCreateSurfaceWINE(HDC hdc, int pixel_format); // if hdc is GetDC(<some normal window>), a window surface is created // if hdc is GetDC(0), GetDC(GetDesktopWindow()), or CreateDC("display", …), a full-screen surface is created. // once the surface is created, it no longer refers to hdc void wglDestroySurfaceWINE(HANDLE surface); HDC wglGetSurfaceDCWINE(HANDLE surface); // Returns a DC created for the surface. This is not the DC passed in to wglCreateSurfaceWINE(). void wglReleaseSurfaceDCWINE(HANDLE surface, HDC hdc); This is somewhat modeled on WGL_ARB_pbuffer. <http://www.opengl.org/registry/specs/ARB/wgl_pbuffer.txt> A surface represents a "place" where GL can render, a potential target for a context. It can correspond to a Win32 window or it can be a full-screen surface. A full-screen surface will likely be a platform window (X11 or Mac) managed by the graphics driver but won't be a Win32 window. It should not interfere with mouse events or focus. A surface has a pixel format, similar to a window. Even if the surface was created from a window DC, its pixel format is independent of the window's. Since a surface is created with a pixel format, it shouldn't be necessary to set one with SetPixelFormat() on a surface DC. If it helps keep WineD3D's code simpler, we could allow it. I'm not sure if it will be necessary to support changing the pixel format after it's been set, using wglSetPixelFormatWINE(), or if the surface should just be destroyed and recreated as necessary. Doing the latter may eventually allow the removal of wglSetPixelFormatWINE(). The lifetime of a surface controls whatever resources the graphics driver has to manage for it. For a normal window, this may include a drawable. For a full-screen surface, this would include any full-screen platform window it might have created. WineD3D would obtain a DC from a surface using wglGetSurfaceDCWINE() just as it now obtains one for a window using GetDC(). There can be multiple DCs for a given surface. In particular, a DC can only be used on a single thread, so multiple threads would each have to get their own DC. The different lifetimes of surfaces vs. surface DCs is why this proposal differs from my approach in bug 2082, where I proposed an extension which just added full-screen DCs without a corresponding full-screen surface object. Destroying a surface while it still has extant surface DCs results in undefined behavior. Once WineD3D has a surface DC, it should be able to work with it as it currently does with window DCs. wglMakeCurrent() with a surface DC will associate the context with the surface drawable. For a surface created from a window, this would work as it does now in the graphics drivers with the exception of how the drawable is looked up from the DC. For a full-screen surface, this would target whatever full-screen drawable the graphics driver provides (possibly a platform window). There's a wrinkle having to do with the pixel format. User32 and the wineserver use the fact that a window has a pixel format to compute the "surface region" for the top-level window. This is a different "surface" than the concept central to this proposal. This "surface" is used for client-side GDI rendering using the DIB engine. Maintaining a surface region is necessary to prevent the contents of the window surface buffer from being blitted on top of any 3D rendering done to the window. To keep that functioning, the graphics drivers will still have to inform user32 that 3D rendering is being done to the window. It can do that using the existing mechanism, but that's not currently reversible because it's tied to the pixel format and that's a permanent property of a window. We'd like it to be reversible, since WineD3D can stop targeting a window. I'm thinking of using a count in user32. Extension WGL_WINE_make_current: BOOL wglMakeContextCurrentWINE(HGLRC hglrc); The standard WGL function wglMakeCurrent() combines two operations. It sets the a GL context's drawable to the provided DC and it makes the GL context current for the thread. This new function, wglMakeContextCurrentWINE(), would only do the latter. It would make a GL context current for the thread without changing which DC it's associated with. Both the X11 and Mac drivers already maintain the necessary state to do that. They don't need to have the DC passed in again. (If a GL context is associated with separate draw and read DCs using wglMakeContextCurrentARB(), then this function will leave it associated with both DCs.) This allows WineD3D to faithfully restore the app's previously-current WGL context. This addresses bug 28869. I considered some other designs but I don't think they work well. I looked for a way to do without special DCs. We could directly specify a pixel format when creating a context rather than getting it from the window or surface via the DC. We could make a context current directly on a surface rather than a surface DC. Unfortunately, too much of WGL depends on having a DC. For example, ChoosePixelFormat() and wglSwapBuffers(). What do folks think? Any feedback would be appreciated. -Ken

7 21

[RFC 1/11] Linux FF: Joystick control panel program
by Elias Vanderstuyft 27 Apr '14

27 Apr '14

a) When unloading conditional effects in joy.cpl, the program crashes: When unloading the conditional effect array entries, Wine tries to access an invalid (high) address because dieffect.lpvTypeSpecificParams was not set at the time the effect was created. So declare a valid 'standard' (maxed out) conditional effect. For other unknown effects: - The same can happen when CustomForce effects are available, but because Wine's FF dinput->linux translation does not support this yet, we simply print a FIXME to indicate a possible cause if a crash would happen. - The same for other (unsupported) effects (this is probably not safe?), but then we print a WARN. => This is probably not safe, but these effects won't be unloaded, because they will never be allowed to be created: I tested this by using a dummy FF device that advertised to support CustomForce, but because JoystickAImpl_EnumEffects() does not handle CustomForce, no CustomForce entry was generated in the joy.cpl application, and there was no crash at exit. Solution: After the code of joy.cpl/main.c:766 : else if (IsEqualGUID(&pdei->guid, &GUID_Sine) || IsEqualGUID(&pdei->guid, &GUID_Square) || IsEqualGUID(&pdei->guid, &GUID_Triangle) || IsEqualGUID(&pdei->guid, &GUID_SawtoothUp) || IsEqualGUID(&pdei->guid, &GUID_SawtoothDown)) { DIPERIODIC pforce; pforce.dwMagnitude = DI_FFNOMINALMAX; pforce.lOffset = 0; pforce.dwPhase = 0; pforce.dwPeriod = FF_PERIOD_TIME; dieffect.cbTypeSpecificParams = sizeof(pforce); dieffect.lpvTypeSpecificParams = &pforce; dieffect.dwFlags |= DIEP_TYPESPECIFICPARAMS; } add the following code : else if (IsEqualGUID(&pdei->guid, &GUID_Spring) || IsEqualGUID(&pdei->guid, &GUID_Damper) || IsEqualGUID(&pdei->guid, &GUID_Inertia) || IsEqualGUID(&pdei->guid, &GUID_Friction)) { DICONDITION cxyforce[2]; int i; for (i = 0; i < 2; ++i) { cxyforce[i].lOffset = 0; cxyforce[i].lPositiveCoefficient = DI_FFNOMINALMAX; cxyforce[i].lNegativeCoefficient = DI_FFNOMINALMAX; cxyforce[i].dwPositiveSaturation = DI_FFNOMINALMAX; cxyforce[i].dwNegativeSaturation = DI_FFNOMINALMAX; cxyforce[i].lDeadBand = 0; } dieffect.cbTypeSpecificParams = sizeof(cxyforce); dieffect.lpvTypeSpecificParams = cxyforce; dieffect.dwFlags |= DIEP_TYPESPECIFICPARAMS; } else if (IsEqualGUID(&pdei->guid, &GUID_CustomForce)) { FIXME("Unhandled type specific parameters of CustomForce effect, this may lead to memory errors later on.\n"); } else WARN("Possibly unhandled type specific parameters of effect with guid %x.\n", pdei->guid); b) Weirdly, I had to add these commands that evaluates the DIEFFECT pointers at the end of each if-case, otherwise the pointers seemed to point to other address or data on that address was getting overwritten: TRACE("&rforce=0x%x\n", &rforce); TRACE("&cforce=0x%x\n", &cforce); TRACE("&pforce=0x%x\n", &pforce); TRACE("&cxyforce[0]=0x%x; &cxyforce[1]=0x%x\n", &(cxyforce[0]), &(cxyforce[1])); Elias

2 5

Advice fixing #13683 (DirectX mouse overlay?)
by Christopher Thielen 27 Apr '14

27 Apr '14

Hi wine-devel, I'm attempting to fix http://bugs.winehq.org/show_bug.cgi?id=13683 but need some advice as to where to start. I'm not too familiar with hacking on Wine. I'd like to test Stefan Dösinger's theory outlined in the comments for #13683 that the missing second mouse cursor is perhaps being implemented using DirectX overlays and that Wine's lack of overlay compatibility flags is to blame. Would the proper action to test this theory be to fake a certain set of flags in dlls/d3d8/device.c's static HRESULT WINAPI d3d8_device_GetDeviceCaps(IDirect3DDevice8 *iface, D3DCAPS8 *caps) ? If that proves to be the issue, I'd then need to write proper code to report the correct set of flags presumably. Is there any easy way to see which DLLs Wine loads when running an application? I appreciate any advice, I'm new but want to help, Christopher Thielen

4 25

Wine test week 2 - nice apparent progress
by Jeremy White 18 Apr '14

18 Apr '14

My script results are here: http://www.winehq.org/~jwhite/ebd5f96aea22.html We had a lot of tests that had failed on Windows 7 ultimate that we now skip; that has reduced the number of apparent failures on the new testbot machines down under 20. We've also had some nice work from folks like Dmitry (thanks!). I'll keep annotating the failures until they all have notes. I do have one that could use a sucker^H^H^H^H^H^Hvolunteer: http://test.winehq.org/data/ebd5f96aea22f4093d4ceb109bdead2657666c57/xp_new… I had asked Misha Koshelev (the apparent last person to meaningfully change those tests) if he wanted to look into it, but he's in the middle of a medical internship working brutal hours, so he demurred. Cheers, Jeremy

6 7

Application for GSoC 2014 - riched20: implement ITextDocument::Range and ITextRange
by Jactry Zeng 15 Apr '14

15 Apr '14

Hello folks, I am Jactry Zeng, a junior who majoring in Electronic Science from China. And also a very fresh developer of Wine. My nickname in #winehackers is jactry. :) I would like to apply for this year's GSoC to work for Wine. I have entered Wine's GSoC last year. What I have work for is ITextDocument, I implemented some functions of it. I got some experience of Wine development and fixed some other bugs[0] of richedit during that time. I continued the work of ITextDocument after GSoC, I know there is still a lot of work worth to do. Such as ITextDocument::Range[1], which is used to get an ITextRange object of the content. And functions of ITextRange[2] are used to operate this range of text. Now in Wine, ITextRange was implemented mix with ITextSelection[3][4]. And ITextDocument::GetSelection[5] which is used to get an ITextSelection object is similar to ITextRange. In an easy way, we can implement ITextDocument::Range using some cast (I have a dirty hack in attachment). But I don't think it is a permanent solution. There are four parts in my plan: --- Part 0: Do some COM cleanup. --- Because ITextRange is implemented mix with ITextSelection now, so we should do some COM cleanup to create an ITextRange interface independently. And create a ITextSelection interface inherits from ITextRange. This is just the preparatory work for implementing ITextRange and I will begin this part before GSoC. ( So it is signed as part zore :b ) --- Part 1: Implement ITextDocument::Range. --- I will write more tests for ITextDocument::Range and ITextDocument::GetSelection first. Than try to implement ITextDocumen::Range. When this part is finished, bug 12458[6] and bug 18303[7] will benefit from it. --- Part 2: Implement functions of ITextRange --- In this part, I will try my best to implement some functions of ITextRange. I will write some tests for them first and than implement them. I think this is the hard part. And these functions will be implemented preferentially: GetText, GetDuplicate, GetStar, GetEnd, Copy, SetText. Because GetDuplicate and GetEnd were needed by bug 18303, and these functions seem was depend on the others. After these functions were implemented, I think bug 18303 will be fixed! ( Oh, this one of my pursues! ;) ) --- Part 3: Imporve all the code for being merged by upstream. --- This is the last part, I will improve all the patches for being merged by upstream, including what I did last year. After this part is finished, Wine will really has an initial implementation of ITextDocument and ITextRange. Maybe it will spend a lot of time, and I will continue this work after GSoC if I can't finish all of this part during GSoC. I think after all these are finished not only bug 18303 and bug 12458 will benefit from it, but also many other softwares. Because TOM interfaces are so important and be used frequently in real world applications. I appreciate for any comment. Thank you. :) attachments: dirty hack of ITextDocument::Range: dirty_hack.txt patch 0001: tests for ITextDocument_Range [0] http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=author&am…<http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=author&s=jactry> [1] http://msdn.microsoft.com/en-us/library/windows/desktop/bb774097(v=vs.85).a… [2] http://msdn.microsoft.com/en-us/library/windows/desktop/bb774058(v=vs.85).a… [3] http://msdn.microsoft.com/en-us/library/windows/desktop/bb774060(v=vs.85).a… [4] http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/riched20/richole.c#l7… [5] http://msdn.microsoft.com/en-us/library/windows/desktop/bb774013(v=vs.85).a… [6] http://bugs.winehq.org/show_bug.cgi?id=12458 [7] http://bugs.winehq.org/show_bug.cgi?id=18303 -- Regards, Jactry Zeng

1 1

Re: mshtml: Added IHTMLTable::width property implementation.
by Jacek Caban 02 Apr '14

02 Apr '14

Hi Zhenbo, On 03/31/14 16:26, Zhenbo Li wrote: > As my test case shows, windows would truncate float numbers. > I considered VarInt() in oleaut32.dll, but I think to declare > var2str_length() is more clear. +static HRESULT var2str_length(nsAString *nsstr, const VARIANT *p) +{ + static WCHAR buf[64]; + static const WCHAR formatW[] = {'%','d',0}; + LONG width; + + switch(V_VT(p)) { + case VT_BSTR: + return nsAString_Init(nsstr, V_BSTR(p)); + case VT_R8: + width = (LONG)(V_R8(p)); + break; + case VT_R4: + width = (LONG)(V_R4(p)); + break; + case VT_I4: + width = V_I4(p); + break; + default: + FIXME("unsupported arg %s\n", debugstr_variant(p)); + return E_NOTIMPL; + } + sprintfW(buf, formatW, width); + return nsAString_Init(nsstr, buf); +} I would like to see this more generic. How about having var_to_nsstr? It seems to me that we don't really have to convert floats here. Gecko and/or getter may do that instead. If we really have to it here, then some sort of flags controlling helper behaviour on floats may be cleaner. + nsAString val; + HRESULT nsres; nsresult and HRESULT, although are very similar, are two different things and should not be mixed. + DOUBLE width; + + TRACE("(%p)->(%p)\n", This, p); + nsAString_Init(&val, NULL); + nsres = nsIDOMHTMLTableElement_GetWidth(This->nstable, &val); + + V_VT(p) = VT_BSTR; + nsres = return_nsstr(nsres, &val, &V_BSTR(p)); Please don't use return_nsstr this way. It's a strange helper with unusual behaviour in terms of freeing input parameters to make common Gecko wrapping functions cleaner. Using this for string conversion looks bad. Esp in this case, where it adds unneeded BSTR allocation in cases where the string is converted to int later. However, see bellow first. + if (nsres != S_OK) + return nsres; + + nsres = VarR8FromStr(V_BSTR(p), 0, 0, &width); + if (nsres == S_OK){ + VariantClear(p); + V_VT(p) = VT_I4; + V_I4(p) = (LONG)width; + } + return S_OK; +#define cmp_length(a,b) _cmp_length(__LINE__,a,b) +static void _cmp_length(unsigned line, VARIANT got, const char * exstr) +{ + static char buf[64]; + ok_(__FILE__,line) (V_VT(&got)==VT_BSTR || V_VT(&got)==VT_I4, + "V_VT is %hu, expected VT_BSTR(%hu) or VT_I4(%hu)\n", + V_VT(&got), VT_BSTR, VT_I4); + + if (V_VT(&got) == VT_BSTR){ + ok_(__FILE__,line) (!strcmp_wa(V_BSTR(&got), exstr), + "Expected %s, got %s\n", exstr, wine_dbgstr_w(V_BSTR(&got))); + } + else { + sprintf(buf, "%d", V_I4(&got)); + ok_(__FILE__,line) (!strcmp(buf, exstr), + "Expected %s, got %d\n", exstr, V_I4(&got)); + } +} This test should be stricter. You decide on the way to compare based on the value you received. This means that if the implementation always returns VT_BSTR, this will success as well. In fact, my quick testing suggests that native IE always returns string in this case. Also, please consider using more targeted helper so that test would look like: test_table_width(table, "11"); Thanks, Jacek

2 2

how to use ced1401 linux driver from wine application ?
by Alois Schlögl 01 Apr '14

01 Apr '14

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

2 4

Wine GPU decoding
by Michael Müller 01 Apr '14

01 Apr '14

Hi, it is probably still a bit early, but nevertheless I would like to announce a feature I am currently working on and present you the first results. As some of you have already noticed (http://bugs.winehq.org/show_bug.cgi?id=35868) I've recently submitted some simple stub patches to add the dxva2 dll. The original purposes was to get a browser plugin working, which expects that this library is available, and otherwise refuses to run. The library exports some functions which are used by several applications (like VLC, Flash, Silverlight, ...) for GPU decoding. I started to work to on these functions and I want to present you a first result which you can see here: https://dl.dropboxusercontent.com/u/61413222/dxva2.png This is actually the windows version of VLC playing a MPEG2 movie with GPU acceleration using DXVA2. My implementation of dxva2 uses the VAAPI on Linux to do the actual gpu decoding and should support AMD, Intel and NVIDIA cards. Currently only MPEG2 decoding is supported as it is one of the easier codecs and other ones like H264 needs a lot more of buffers, which need be translated from the DXVA format to VAAPI. The second easiest codec to implement would be mpeg4 but as none of my graphic cards support mpeg4, I will most probably continue with VC-1. Anyway, I need to clean up the patches a bit as they add about 3000 new lines of code and test it with some other graphic cards before I can provide them, but there are also some problems, mostly d3d9 related, for which I would like to get your opinion. The most difficult part is that DXVA2 is completely based on Direct3D9Device and Direct3DSurface9. The DXVA2 places the output images into a Surface and the applications locks the surface to get the output data or simply presents it to the screen. Although it would be much more efficient to directly blit the data in the graphic card at least VLC reads it back into system memory as the decoding and output pipeline are separated. The problem is that I actually need to allocate twice the amount of memory for decoding. since I need to provide the Direct3D Surfaces to the application and I also need to provide buffers to VAAPI. This is not a big problem for mpeg2 since it only uses 3 output images as a B Frame can only reference the last and the next frame. Anyway, for H264 this is getting insane as it requires to store up to 16 output images so that i would need to allocate 16 VAAPI buffers and 16 Direct3D surfaces. Currently i lock both kind of buffers after rendering a frame and do the synchronization in system memory, which is kind of inefficient depending on the surface type. My original idea was to do the copy in the graphic card as I can copy the image to a texture after decoding, but after Sebastian implemented this part we found out that the VAAPI implies a format conversion to RGB when copying data to a texture. This is actually a no go since VLC will refuse to use hardware acceleration when the output format is RGB. I also think it is kind of stupid to convert the RGB data back to YUV so that we end up with 3 color coder conversion (YUV->RGB->YUV->RGB). Some Intel developer wrote (see vaCopySurfaceGLX() at http://markmail.org/message/a3sav6q3dm5qvmat) that it would be possible to implement a copy in NV12 format for NVIDIA and Intel but not AMD. We could try to ask them to implement it, so that we can at least do it efficient for these two vendors. Anyway, if other applications continue to copy the data back to system memory it might be better to instead wrap the VAAPI buffers as Direct3D9 surfaces so that we can directly map the VAAPI buffers when LockRect() is called instead of copying the data. Though this would imply problems when the applications tries to pass this interface to Present(). So what do the wined3d guys think? Is it better to convince the Intel developers to allow a copy in YUV format and copy the data directly into the texture of an Direct3D9 surface or wrap the VAAPI buffers as Direct3D9Surface and add some glue code when an applications tries to render it? Or do you have any better ideas? Regards, Michael

4 8

Re: regsvr32: Replace printf calls with WriteConsole function (try 2)
by Lauri Kenttä 01 Apr '14

01 Apr '14

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ä

3 4

Re: [PATCH 6/6] user32: Implement EnumDisplayDevicesW() based on EnumDisplayMonitors() and GetMonitorInfoW().
by Alexandre Julliard 31 Mar '14

31 Mar '14

Ken Thomases <ken(a)codeweavers.com> writes: > For <http://bugs.winehq.org/show_bug.cgi?id=34978>. > --- > dlls/user32/misc.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++------- > 1 file changed, 84 insertions(+), 12 deletions(-) I think it should be the other way around, with EnumDisplayDevices being the main function, with some sort of centralized management of display devices. -- Alexandre Julliard julliard(a)winehq.org

2 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel March 2014