- wine-devel - winehq.org

Re: [PATCH 2/8] wined3d: Avoid potential division by 0 when computing fog scale.
by Henri Verbeet 17 Jun '15

17 Jun '15

On 16 June 2015 at 22:45, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > get_fog_start_end(context, state, &start, &end); > - scale = 1.0f / (end - start); > + scale = end == start ? INFINITY : 1.0f / (end - start); Do we really need this? It almost feels nicer to just pass "end - start" to the shader and handle the division there, or perhaps even just pass "start".

3 3

[PATCH 1/2] secur32: Added support for a few more algorithms in schannel_get_cipher_algid.
by Hugh McMaster 17 Jun '15

17 Jun '15

On Tue, 16 Jun 2015 13:46:32 +0200, Jacek Caban wrote: >- case GNUTLS_CIPHER_AES_256_CBC: return CALG_AES; >+ case GNUTLS_CIPHER_AES_128_GCM: return CALG_AES_128; >+ case GNUTLS_CIPHER_AES_192_CBC: return CALG_AES_192; >+ case GNUTLS_CIPHER_AES_256_GCM: >+ case GNUTLS_CIPHER_AES_256_CBC: return CALG_AES_256; Those changes are causing fatal build errors in Wine: schannel_gnutls.c: In function ‘schannel_get_cipher_algid’: schannel_gnutls.c:272:10: error: ‘GNUTLS_CIPHER_AES_128_GCM’ undeclared (first use in this function) case GNUTLS_CIPHER_AES_128_GCM: return CALG_AES_128; ^ schannel_gnutls.c:272:10: note: each undeclared identifier is reported only once for each function it appears in schannel_gnutls.c:274:10: error: ‘GNUTLS_CIPHER_AES_256_GCM’ undeclared (first use in this function) case GNUTLS_CIPHER_AES_256_GCM: ^ make[1]: *** [schannel_gnutls.o] Error 1 make[1]: Leaving directory `/home/hugh/wine-test/dlls/secur32' make: *** [dlls/secur32] Error 2 -- Hugh McMaster

3 5

Re: [PATCH 3/8] wined3d: Cleanup and simplify texture sampling code generation.
by Henri Verbeet 17 Jun '15

17 Jun '15

On 16 June 2015 at 22:45, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > switch (resource_type) > { > case WINED3D_SHADER_RESOURCE_TEXTURE_1D: ... > + type_part = "1D"; > break; There's nothing necessarily wrong with this, but it also seems that aside from the "texrect" handling you could just use the same lookup table you're using for the coordinate mask size.

1 0

Re: [PATCH] riched20: Fix link notification conditions and add tests.
by Alexandre Julliard 17 Jun '15

17 Jun '15

Alex Henrie <alexhenrie24(a)gmail.com> writes: > @@ -4121,6 +4121,10 @@ LRESULT ME_HandleMessage(ME_TextEditor *editor, UINT msg, WPARAM wParam, > return 0; > case WM_SETCURSOR: > { > + POINT cursor_pos; > + if (wParam == (WPARAM)editor->hWnd && GetCursorPos(&cursor_pos) && > + ScreenToClient(editor->hWnd, &cursor_pos)) > + ME_LinkNotify(editor, msg, 0, MAKELPARAM(cursor_pos.x, cursor_pos.y)); Getting the current cursor position doesn't look right, it should be the message position. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [2/3] ntdll: Alter security cookie on WIN64 (try 2)
by Alexandre Julliard 17 Jun '15

17 Jun '15

André Hentschel <nerv(a)dawncrow.de> writes: > This time ARM64-only > I had trouble with that patch for x86_64 when testing EmEditor... > Still it is the only way to get an app on arm64 to start... There shouldn't be any reason to make this platform-specific, or 64-bit specific for that matter. And a hardcoded cookie is not exactly secure... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] riched20/tests: Some more EM_SETSEL tests
by Marvin 17 Jun '15

17 Jun '15

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=14363 Your paranoid android. === w2008s64 (64 bit editor) === editor.c:5939: Test failed: wrong event mask (0x0) during WM_COMMAND

2 1

Re: [1/2] Add stub dll d3dcompiler_46
by Matteo Bruni 17 Jun '15

17 Jun '15

2015-06-16 11:14 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > > > Changelog: > Add stub dll d3dcompiler_46 > > > Best Regards > Alistair Leslie-Hughes These two patches look fine to me except for the LPJUNK + hungarian notation in DllMain(). BTW where did you find that version number for d3dcompiler_46? Windows 8 SDK? Just curious, I found two different version of d3dcompiler_46.dll bundled with various stuff which have different version numbers (even between them).

2 1

Re: [PATCH 1/4] msvcr120: Add ___lc_locale_name_func implementation
by Marvin 16 Jun '15

16 Jun '15

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=14355 Your paranoid android. === w2008s64 (32 bit msvcr120) === msvcr120.c:209: Test failed: 0 - lc_names[1] = L"en-US" msvcr120.c:206: Test failed: 2 - lc_names[1] = L"zh-CN" msvcr120.c:209: Test failed: 3 - lc_names[1] = L"nl-NL" msvcr120.c:209: Test failed: 4 - lc_names[1] = L"en-US" msvcr120.c:209: Test failed: 5 - lc_names[1] = L"fr-FR" msvcr120.c:209: Test failed: 6 - lc_names[1] = L"de-DE" msvcr120.c:209: Test failed: 7 - lc_names[1] = L"hu-HU" msvcr120.c:209: Test failed: 8 - lc_names[1] = L"is-IS" msvcr120.c:209: Test failed: 9 - lc_names[1] = L"ja-JP" msvcr120.c:209: Test failed: 10 - lc_names[1] = L"ko-KR" msvcr120.c:209: Test failed: 11 - lc_names[1] = L"es-MX" === w2008s64 (64 bit msvcr120) === msvcr120.c:209: Test failed: 0 - lc_names[1] = L"en-US" msvcr120.c:206: Test failed: 2 - lc_names[1] = L"zh-CN" msvcr120.c:209: Test failed: 3 - lc_names[1] = L"nl-NL" msvcr120.c:209: Test failed: 4 - lc_names[1] = L"en-US" msvcr120.c:209: Test failed: 5 - lc_names[1] = L"fr-FR" msvcr120.c:209: Test failed: 6 - lc_names[1] = L"de-DE" msvcr120.c:209: Test failed: 7 - lc_names[1] = L"hu-HU" msvcr120.c:209: Test failed: 8 - lc_names[1] = L"is-IS" msvcr120.c:209: Test failed: 9 - lc_names[1] = L"ja-JP" msvcr120.c:209: Test failed: 10 - lc_names[1] = L"ko-KR" msvcr120.c:209: Test failed: 11 - lc_names[1] = L"es-MX"

1 0

Re: Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.)
by Jeremy White 16 Jun '15

16 Jun '15

Hi all, On 06/15/2015 02:32 PM, Michael Müller wrote: > Hi Jeremy, > > I actually intended to send the following response to wine-devel, but > the other Wine Staging developers feared that this might continue the > flamewar. Nevertheless, I think the ideas should still reach you, just > treat them as my personal opinion. In case you are comfortable with the > content, feel free to forward or respond to it on wine-devel. I thought these were all interesting points, and wanted to respond publicly. > > I think it is too easy to blame Alexandre for all Wine problems. He is > involved in some of them, but there are also other ways to improve Wine > which are completely unrelated to him. I think even CodeWeavers could > make Wine more community-friendly simply by being more transparent. > > Here are two examples of what I mean: > > 1. CodeWeavers adds a lot of hacks to Crossover to get applications to > work, in case a proper fix would be too much work. From what I have > heard those hacks are only added after the problem has been analyzed and > documented in your bug tracker. I don't understand though why no one in > the Wine community access to this analysis (i.e. why are these bugs not > documented in the public bug tracker)? It seems to be a waste of energy > if the Wine community needs to debug the problem a second time. I think that breaks down into two issues. First, yes, we do have hacks in CrossOver, but I think 'a lot' is unfair. We really try to avoid those hacks, and we work hard to eliminate them. For example, I reviewed our tracker that lists our hacks. We have about 100 outstanding; in the last 6 months, we removed 4 with upstream fixes, and added 1 new one. Further, we have long felt that our diff with winehq was tragically large. But nicely, I can now compare it to wine-staging, and claim that it is relatively modest <grin>. We touch 28K lines in 228 files versus 100K lines in 509 files for wine-staging [1]. Second, for bugs, yes, we do have our own bug tracker, and it is (mostly) private. That's appropriate for CrossOver only bugs, and we do have a lot of customers with whom we have confidentiality agreements, so it's necessary in that case. We do have an official company policy that any Wine related bug in our tracker is supposed to have a related WineHQ bug, and we are supposed to bias our troubleshooting and work in favor of WineHQ. That is true for all bugs, including ones that are hacks. In doing a spot check of that, it looks like we don't do that great a job of adhering to that policy; maybe 30% of the time (although we do have a number of staff members who are particularly good at mostly using WineHQ). I have to agree that this is arguably less than ideal, and I will exhort our staff to do better. But my gut sense is that the perception may be that we have this magical treasure trove of extra information, and the reality is fairly far from that. > > 2. CodeWeavers seems to act like a black box from my point of view. It > is not really clear what you guys are working on and therefore a lot of > Wine developers (who are not part of CW) try to avoid touching the same > areas of Wine. As far as I know CW is currently working on Office 2013 > for example, but there is not a single bug in the WineHQ bug tracker > about this. On the other hand I talked with some CW developers on the > IRC and I had the impression that they wouldn't mind help from the > community to fix certain issues. We all profit from having those bugs > fixed faster. Ouch. I'm not sure how to respond to that. I think we've been accused of being a bit opaque in the past, and I think I've promised to try to do better. Looks like I failed. We do tend to get a lot of NDAs and things that make us careful with information, but we also just have a lot of the strong silent types on staff. But the very last thing I want to do is suppress any work on Wine. My thinking, though, has long been the opposite of yours. That if we advertise an area of work, we risk a 'chilling' effect. There are far more bugs with 'Office' than we could ever handle by ourselves; I would never want someone to stay away from a bug that looked interesting or fun, just because we tend to do a lot of the work on Office. I always thought the perk of being a non CW Wine hacker is that you get to pick and choose the fun parts. I get to make the CW hackers do the yucky, nasty, stuff... <evil grin>. Further, we really do just about all of our work on wine-devel; you can tell what we're working on just by seeing the patches there. For the record, we are working on Office 2013, which is right now mired in a lot of work on dwrite, I believe. If you look at Henri and Nikolay's recent patches, you'll see the work on it. We have lovely purple blobs in Excel instead of readable text (although I'm told I can have those blobs in any color I like). Beyond that, our work is all over the map. I guess the action item here remains the same - for us to do a better job of communicating, so we no longer seem mysterious or opaque. I'll work on that. > > Alexandre needs to find a way how to improve the patch acceptance > process in a way he feels comfortable with, but before everyone starts > blaming him for all problems, there are also other areas which can be > improved. Don't get me wrong, I don't want to say that CW is root of all > evil (I think its very great that you guys keep Wine alive), I just > thought you might be interested in these ideas, especially because these > are things where you have influence on. Yes, thank you - this is very helpful. I think there is clearly a problem, a problem that has gotten worse lately, and it would be great if we can find a way to improve matters. Again, there is far more than enough work to do; to lose any energy to misunderstanding or inter personal friction is just stupid and inefficient. One issue you didn't raise that I want to elevate as a straw man, and then knock down, is the perception that an @codeweavers.com email address is some sort of guarantee of patch acceptance. Trust me, I am painfully aware that it doesn't help :-/. It is true that I tend to hire people that Alexandre trusts (which makes sense, if you think about it), but that's a different way of coloring the situation. And I can tell you that Alexandre is a man of deep integrity, and he is both personally committed to keeping his work on Wine separate from his work for CodeWeavers, and CodeWeavers is contractually bound to allow that. > > Not directly related to the previous mail, but I think its not > sufficient to hope that WineConf will automatically solve all problems. > The WineConf might be a good place to discuss individual ideas, but we > may want to start collecting them in advance. Agreed; hence my desire to make sure to get this down in the email archives as well, and my hope that we can articulate the concerns and possible improvements now as well. But there is something really powerful about meeting face to face that is very nice. It's particularly nice when you can go to the bar to curse Alexandre over beers later <grin>. Cheers, Jeremy [1] This was my methodology, which may be flawed: wine-staging git, removing outsized fonts-Missing_Fonts patch: [~/xfer/wine-staging/patches] grep -h '^diff' */00*.patch | sort | uniq | wc -l 509 [~/xfer/wine-staging/patches] cat */00*.patch | wc -l 107666 CrossOver stats: [~/w/crossover/wine] git diff wine-1.7.45 | grep -h '^diff' | wc -l 228 [~/w/crossover/wine] git diff wine-1.7.45 | wc -l 28388

1 0

Re: ntdll: Improve stub of NtQueryEaFile.
by Alexandre Julliard 16 Jun '15

16 Jun '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Based on a patch by Qian Hong. I don't remember seeing any such patch. Qian is around, so I expect he should be able to submit his own work himself. Then you can submit your part as your own separate patch. It's not a big deal for a small patch like this, but I don't want you to get into the habit of submitting patches containing bits and pieces of other people's work. I expect developers to stand behind their work, and take responsibility for getting their patches committed. Helping them is good, but taking over their work isn't. -- Alexandre Julliard julliard(a)winehq.org

15 26

Re: scrrun: Implement ITextStream Close
by Marvin 16 Jun '15

16 Jun '15

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=14331 Your paranoid android. === w2000pro (32 bit filesystem) === filesystem.c:1385: Test failed: got 0x800a005b === w2003std (32 bit filesystem) === filesystem.c:1385: Test failed: got 0x800a005b

1 0

Re: [1/2] ntdll: Set platform register x18 to TEB on ARM64 (resend)
by Alexandre Julliard 16 Jun '15

16 Jun '15

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -788,6 +788,17 @@ void signal_free_thread( TEB *teb ) > > > /********************************************************************** > + * set_x18 > + * > + * Win64/ARM applications expect the TEB pointer to be in the x18 platform register. > + */ > +extern void set_x18( TEB *teb ); > +__ASM_GLOBAL_FUNC( set_x18, > + "mov x18, x0\n\t" /* TEB -> platform register */ > + "ret" ) You don't really need a global function for this. -- Alexandre Julliard julliard(a)winehq.org

1 0

odbccp32: Implement SQLGetPrivateProfileString (try 5)
by Hugh McMaster 16 Jun '15

16 Jun '15

On Sun, 14 Jun 2015 14:58:36 +1000, Alistair Leslie-Hughes wrote: > >+ ret = SQLGetPrivateProfileStringW(sect, entry, string, retval, cbRetBuffer, file); >+ if(ret) >+ { >+ WideCharToMultiByte(CP_ACP, 0, retval, -1, RetBuffer, cbRetBuffer, NULL, NULL); >+ RetBuffer[ret] = 0; >+ } If retval is null terminated, you do not need RetBuffer[ret] = 0;. The -1 in WideCharToMultiByte means the function calculates the length of the input string, including any null terminating character. If the input string is null terminated, the output string is also null terminated. So, if this is the case, you are actually null-terminating twice and, depending on the size of cbRetBuffer, the second null termination may be out of bounds. If retval isn't null terminated, you should use the return value of WideCharToMultiByte (the number of bytes written to RetBuffer) instead of 'ret'.

1 0

Re: scrrun: Implement ITextStream Close
by Nikolay Sivov 16 Jun '15

16 Jun '15

> struct textstream *This = impl_from_ITextStream(iface); > - FIXME("(%p): stub\n", This); > - return E_NOTIMPL; > + HRESULT hr = S_OK; > + > + TRACE("(%p)\n", This); > + > + if(!CloseHandle(This->file)) > + hr = S_FALSE; > + > + This->file = NULL; > + > + return hr; This could be right way to do it, but it would be interesting to see what happens to other methods behavior when called on closed stream, like Read() for example.

2 1

Re: odbccp32: Implement SQLGetPrivateProfileString (try 5)
by Nikolay Sivov 16 Jun '15

16 Jun '15

> + sect = heap_strdupAtoW(lpszSection); > + entry = heap_strdupAtoW(lpszEntry); > + string = heap_strdupAtoW(lpszDefault); > + file = heap_strdupAtoW(lpszFilename); > + retval = heap_alloc(cbRetBuffer*sizeof(WCHAR)); > + > + ret = SQLGetPrivateProfileStringW(sect, entry, string, retval, cbRetBuffer, file); > + if(ret) > + { > + WideCharToMultiByte(CP_ACP, 0, retval, -1, RetBuffer, cbRetBuffer, NULL, NULL); > + RetBuffer[ret] = 0; > + } > + > + heap_free(sect); > + heap_free(entry); > + heap_free(string); > + heap_free(file); > + > + heap_free(retval); Structurally it's fine, but you're using WCHAR count as CP_ACP char count, and it's wrong assumption in general.

1 0

Re: [1/3] winhttp: Improve parsing of cookie values.
by Marvin 16 Jun '15

16 Jun '15

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=14301 Your paranoid android. === w2000pro (32 bit winhttp) === winhttp.c:945: Test failed: failed to receive response 12152 winhttp.c:950: Test failed: failed unexpectedly 12019 winhttp.c:951: Test failed: request failed unexpectedly 3735928559

2 1

Re: [2/3] msvcirt: Add implementation of streambuf::sputc
by Piotr Caban 16 Jun '15

16 Jun '15

On 06/15/15 17:34, Iván Matellanes wrote: > + test_overflow_this = &sb2; > + ret = (int) call_func2(p_streambuf_sputc, &sb3, 'c'); You probably wanted to set the test_overflow_this to sb3 here. Thanks, Piotr

1 0

Re: [PATCH 1/4] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromClipper (try 2).
by Stefan Dösinger 15 Jun '15

15 Jun '15

Hi, > + hr = DirectDrawCreateClipper(0, &clipper, NULL); > + ref = get_refcount((IUnknown *)clipper); You're not reading ref anywhere as far as I can see. Did you forget to re-check the refcount after creating the device? If the refcount is incremented by 2 or more: See if the clipper is assigned to the render target and / or depth stencil. This wouldn't really do anything, but it's Microsoft we're talking about here. > + hr = IDirect3DRM_QueryInterface(d3drm1, &IID_IDirect3DRM2, (void **)&d3drm2); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM3 interface (hr = %x).\n", hr); Minor mistake: IDirect3DRM2 vs IDirect3DRM3. > + memcpy(&driver, &IID_IDirect3DRGBDevice, sizeof(GUID)); I think an assignment should do the job. > + hr = IDirect3DRM2_CreateDeviceFromClipper(d3drm2, clipper, &driver, rc.right, rc.bottom, &device2); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRMDevice2 interface (hr = %x).\n", hr); I'd say "Cannot create IDirect3DRMDevice2 (hr = ...)" here. You're not retrieving an interface here. > + /* Fetch immediate mode device in order to access render target */ > + hr = IDirect3DRMDevice2_GetDirect3DDevice2(device2, &d3ddevice2); > + todo_wine ok(hr == D3DRM_OK, "Cannot get IDirect3DDevice2 interface (hr = %x).\n", hr); > + if (FAILED(hr)) > + { > + IDirect3DRMDevice2_Release(device2); > + IDirect3DRM2_Release(d3drm2); > + IDirect3DRM_Release(d3drm1); > + IDirectDrawClipper_Release(clipper); > + return; > + } You can use the cleanup label here too if you initialize the interface pointers to NULL and add checks for NULL before calling release. > + /* Check properties of primary and depth surfaces */ > + desc.dwSize = sizeof(desc); > + hr = IDirectDrawSurface_GetSurfaceDesc(surface, &desc); > + ok(hr == DD_OK, "Cannot get surface desc structure (hr = %x).\n", hr); > + if (FAILED(hr)) > + goto cleanup; Minor nitpick: A "primary" surface represents the screen content. The correct term in in this case is "render target". Note that a primary surface can be a render target in fullscreen mode. > + ok((desc.dwWidth == rc.right) && (desc.dwHeight == rc.bottom), "Expected surface dimentions = %d, %d, got %d, %d.\n", > + rc.right, rc.bottom, desc.dwWidth, desc.dwHeight); > + expected_caps = DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE | DDSCAPS_SYSTEMMEMORY; > + todo_wine ok(desc.ddsCaps.dwCaps == expected_caps, "Expected %x for caps, got %x.\n", expected_caps, desc.ddsCaps.dwCaps); As discussed on IRC ignore DDSCAPS_SYSTEMMEMORY here. I think it happens because you use a RGB device, and I don't think it's something we should care about unless an application depends on this. Check dwRGBBitCount of the render target. It should match the bit depth of the screen mode. > + if (FAILED(hr = IDirectDraw_SetDisplayMode(ddraw, desc.dwWidth, desc.dwHeight, 8))) > + { > + win_skip("Cannot set display mode to 8bpp (hr = %x), skipping tests.\n", hr); > + IDirectDrawSurface7_Release(surface7); > + IDirectDrawSurface_Release(ds); > + IDirectDrawSurface_Release(surface); > + IUnknown_Release(unknown); > + IDirectDraw_Release(ddraw); > + goto cleanup; > + } There's no need to try to set the display mode to 8. Also testing if changing the mode works is outside the scope of this test. What's interesting is that the pixel format of the primary surface of a new device after changing the mode. Please also check the Z bit depth, and if the surface has stencil bits.

2 2

Re: [PATCH 2/5] wined3d: Implement SM4 discard in the GLSL shader backend.
by Matteo Bruni 15 Jun '15

15 Jun '15

2015-06-15 14:07 GMT+02:00 Henri Verbeet <hverbeet(a)codeweavers.com>: > --- > dlls/wined3d/glsl_shader.c | 35 +++++++++++++++++++++-------------- > 1 file changed, 21 insertions(+), 14 deletions(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 5ba246e..eb98ffe 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -4704,22 +4704,29 @@ static void shader_glsl_texreg2rgb(const struct wined3d_shader_instruction *ins) > * If any of the first 3 components are < 0, discard this pixel */ > static void shader_glsl_texkill(const struct wined3d_shader_instruction *ins) > { > - struct glsl_dst_param dst_param; > + if (ins->ctx->reg_maps->shader_version.major >= 4) > + { > + struct glsl_src_param src_param; > > - /* The argument is a destination parameter, and no writemasks are allowed */ > - shader_glsl_add_dst_param(ins, &ins->dst[0], &dst_param); > - if (ins->ctx->reg_maps->shader_version.major >= 2) > + shader_glsl_add_src_param(ins, &ins->src[0], WINED3DSP_WRITEMASK_0, &src_param); > + shader_addline(ins->ctx->buffer, "if (bool(floatBitsToUint(%s))) discard;\n", src_param.param_str); > + } > + else > { > - if (ins->ctx->reg_maps->shader_version.major >= 4) > - FIXME("SM4 discard not implemented.\n"); > - /* 2.0 shaders compare all 4 components in texkill */ > - shader_addline(ins->ctx->buffer, "if (any(lessThan(%s.xyzw, vec4(0.0)))) discard;\n", dst_param.reg_name); > - } else { > - /* 1.X shaders only compare the first 3 components, probably due to the nature of the texkill > - * instruction as a tex* instruction, and phase, which kills all a / w components. Even if all > - * 4 components are defined, only the first 3 are used > - */ > - shader_addline(ins->ctx->buffer, "if (any(lessThan(%s.xyz, vec3(0.0)))) discard;\n", dst_param.reg_name); > + struct glsl_dst_param dst_param; > + > + /* The argument is a destination parameter, and no writemasks are allowed */ > + shader_glsl_add_dst_param(ins, &ins->dst[0], &dst_param); > + > + /* 2.0 shaders compare all 4 components in texkill. */ > + if (ins->ctx->reg_maps->shader_version.major >= 2) > + shader_addline(ins->ctx->buffer, "if (any(lessThan(%s.xyzw, vec4(0.0)))) discard;\n", dst_param.reg_name); > + /* 1.x shaders only compare the first 3 components, probably due to > + * the nature of the texkill instruction as a tex* instruction, and > + * phase, which kills all .w components. Even if all 4 components are > + * defined, only the first 3 are used. */ > + else > + shader_addline(ins->ctx->buffer, "if (any(lessThan(%s.xyz, vec3(0.0)))) discard;\n", dst_param.reg_name); > } > } > > -- > 2.1.4 FWIW, https://msdn.microsoft.com/en-us/library/windows/desktop/hh446968%28v=vs.85… mentions two variants of the discard instruction. Any clue how is that _z vs _nz part encoded?

2 1

DInput axis mapping explanation
by Michael Gardner 15 Jun '15

15 Jun '15

Please forgive me if this is the wrong list or a stupid question, but I already tried wine-users and the WineHQ forums and no one could answer. I'm trying to understand Wine's DirectInput axis mapping feature (registry key HKEY_CURRENT_USER\Software\Wine\DirectInput). The documentation at http://wiki.winehq.org/UsefulRegistryKeys gives some details but seems to assume you already know how the feature works. (You could also consider this an RFE for better DInput axis mapping docs, which I'd be happy to write if I can first understand the feature.) I understand that I can make a registry key with the same name as my joystick device and a value that's a comma-separated list of axes, which will act as some kind of mapping. But how does this mapping work? What is being mapped to what, exactly? The docs give an example mapping without explaining what it does, or how you'd arrive at that mapping given whatever result you're looking for. I've also read https://forum.winehq.org/viewtopic.php?t=14899, but it also doesn't explain how these mappings work in the abstract. Once again, my apologies if this is the wrong place, but if there's anyone who might have the knowledge I'm looking for then it would be the Wine devs.

2 1

Re: [PATCH] winscard: add stubs for SCardListReadersA/W (try 2)
by Matteo Bruni 15 Jun '15

15 Jun '15

2015-06-15 9:31 GMT+02:00 Marcus Meissner <marcus(a)jet.franken.de>: > From: Austin English <austinenglish(a)gmail.com> > > Fixes http://bugs.winehq.org/show_bug.cgi?id=26978 > > replaced return code after suggestion by Bruno Jesus. > --- > dlls/winscard/winscard.c | 12 ++++++++++++ > dlls/winscard/winscard.spec | 4 ++-- > 2 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/dlls/winscard/winscard.c b/dlls/winscard/winscard.c > index bcf8129..70b3914 100644 > --- a/dlls/winscard/winscard.c > +++ b/dlls/winscard/winscard.c > @@ -129,3 +129,15 @@ void WINAPI SCardReleaseStartedEvent(void) > { > FIXME("stub\n"); > } > + > +LONG WINAPI SCardListReadersA(SCARDCONTEXT context, LPCSTR groups, LPSTR readers, LPDWORD buflen) Not sure it matters much here but I'd stick to avoiding LP* types, as by usual Wine style.

1 0

Re: riched: Added ITextDocument2 definition and corresponding tests
by Alexandre Julliard 15 Jun '15

15 Jun '15

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > From 5583828198dff5f5e19606ba11f1cf961f78f7c5 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <nsivov(a)codeweavers.com> > Date: Tue, 2 Jun 2015 01:32:52 +0300 > Subject: [PATCH] riched: Added ITextDocument2 definition and corresponding > tests It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M riched20.dll -p riched20_test.exe.so richole && touch richole.ok fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} fixme:richedit:IRichEditOleImpl_inner_fnQueryInterface 0x3334e0: unhandled interface {01c25500-4268-11d1-883a-3c8b00c10000} richole.c:150: Test failed: got 0x80004002 wine: Unhandled page fault on read access to 0x00000000 at address 0x7ed4b59e (thread 0009), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wininet: Use random names when caching very long urls.
by Piotr Caban 15 Jun '15

15 Jun '15

Hi, this will not work for filenames a little shorter than MAX_PATH. Whole file path needs to fit into MAX_PATH characters (not only the file name). Thanks, Piotr

1 0

Re: [PATCH 2/4] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromSurface (try 2).
by Stefan Dösinger 15 Jun '15

15 Jun '15

> Am 11.06.2015 um 13:51 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > > + hr = IDirect3DDevice2_GetRenderTarget(d3ddevice2, &surface); > + ok(hr == DD_OK, "Cannot get surface to the render target (hr = %x)\n", hr); > + if (FAILED(hr)) > + goto cleanup; > + > + /* Check properties of primary and depth surfaces */ > + memset(&desc, 0, sizeof(desc)); > + desc.dwSize = sizeof(desc); > + hr = IDirectDrawSurface_GetSurfaceDesc(surface, &desc); > + ok(hr == DD_OK, "Cannot get surface desc structure (hr = %x)\n", hr); > + if (FAILED(hr)) > + goto cleanup; Checking the surface desc isn't really relevant here. The interesting check is if the render target returned by GetRenderTarget is the surface you passed to CreateDeviceFromSurface. Please add a test that shows that an error is returned if the surface was created without 3DDEVICE. > > + hr = IDirectDrawSurface_GetAttachedSurface(surface, &caps, &ds); > + ok(hr == DD_OK, "Cannot get attached depth surface (hr = %x)\n", hr); > + if (FAILED(hr)) > + goto cleanup; What happens if you attach a depth surface yourself before calling CreateDeviceFromSurface? Does d3drm replace it? > + hr = IDirectDrawSurface_QueryInterface(surface, &IID_IDirectDrawSurface7, (void**)&surface7); > + ok(hr == DD_OK, "Cannot get IDirectDrawSurface7 interface (hr = %x)\n", hr); > + > + IDirectDrawSurface_Release(ds); > + IDirectDrawSurface_Release(surface); > + IDirectDrawSurface7_Release(surface7); The QueryInterface call here is redundant.

3 3

Re: [PATCH 2/3] configure: Check if -lunwind is needed for libunwind.
by Alexandre Julliard 15 Jun '15

15 Jun '15

Ken Thomases <ken(a)codeweavers.com> writes: > --- > configure.ac | 26 ++++++++++++++++++++++++++ > dlls/ntdll/Makefile.in | 2 +- > 2 files changed, 27 insertions(+), 1 deletion(-) I'm not sure what we gain by using libunwind on other platforms, but assuming it's useful it would have to be loaded dynamically. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/6] configure: Don't touch platform register x18 on ARM64
by Alexandre Julliard 15 Jun '15

15 Jun '15

André Hentschel <nerv(a)dawncrow.de> writes: > diff --git a/configure.ac b/configure.ac > index 79110c1..b26ae3e 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -178,6 +178,9 @@ case $host in > CFLAGS="$CFLAGS -marm" > AC_SUBST(TARGETFLAGS,"-marm") > ;; > + aarch64*) > + CFLAGS="$CFLAGS -ffixed-x18" I don't see how this can work. It would have to be made the toolchain default to apply to all system libraries. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] kernel32/tests: Add a partial test for GetConsoleFontSize
by Marvin 15 Jun '15

15 Jun '15

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=14266 Your paranoid android. === w8 (32 bit console) === console.c:1511: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1511: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1511: Test failed: [18] Expected output count to be 3735928559, got 2359244 console.c:1755: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1755: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1755: Test failed: [18] Expected output count to be 3735928559, got 2359244

2 1

Re: [PATCH 1/2] kernel32/tests: Add a test for GetLargestConsoleWindowSize
by Marvin 15 Jun '15

15 Jun '15

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=14265 Your paranoid android. === w8 (32 bit console) === console.c:1489: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1489: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1489: Test failed: [18] Expected output count to be 3735928559, got 2359244 console.c:1733: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1733: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1733: Test failed: [18] Expected output count to be 3735928559, got 2359244

2 1

Re: [PATCH] winscard: add stubs for SCardListReadersA/W
by Bruno Jesus 15 Jun '15

15 Jun '15

On Sunday, June 14, 2015, Marcus Meissner <marcus(a)jet.franken.de> wrote: > From: Austin English <austinenglish(a)gmail.com <javascript:;>> > > Fixes http://bugs.winehq.org/show_bug.cgi?id=26978 > --- > dlls/winscard/winscard.c | 12 ++++++++++++ > dlls/winscard/winscard.spec | 4 ++-- > 2 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/dlls/winscard/winscard.c b/dlls/winscard/winscard.c > index bcf8129..cf7d52d 100644 > --- a/dlls/winscard/winscard.c > +++ b/dlls/winscard/winscard.c > @@ -129,3 +129,15 @@ void WINAPI SCardReleaseStartedEvent(void) > { > FIXME("stub\n"); > } > + > +LONG WINAPI SCardListReadersA(SCARDCONTEXT context, LPCSTR groups, LPSTR > readers, LPDWORD buflen) > +{ > + FIXME("(%lx, %s, %p, %p) stub\n", context, debugstr_a(groups), > readers, buflen); > + return SCARD_F_INTERNAL_ERROR; > +} > + > +LONG WINAPI SCardListReadersW(SCARDCONTEXT context, LPCWSTR groups, > LPWSTR readers, LPDWORD buflen) > +{ > + FIXME("(%lx, %s, %p, %p) stub\n", context, debugstr_w(groups), > readers, buflen); > + return SCARD_F_INTERNAL_ERROR; > +} Hi, that is not a good return code for error, it's better to return SCARD_E_NO_READERS_AVAILABLE. Most applications I tested will understand this error more properly and display better diagnose message to user. Best Regards, Bruno

1 0

Re: [PATCH 2/3] configure: Check if -lunwind is needed for libunwind.
by Ken Thomases 15 Jun '15

15 Jun '15

On Jun 14, 2015, at 9:22 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > --- > configure.ac | 26 ++++++++++++++++++++++++++ > dlls/ntdll/Makefile.in | 2 +- > 2 files changed, 27 insertions(+), 1 deletion(-) Forgot to mention: this is for <https://bugs.winehq.org/show_bug.cgi?id=38713>. -Ken

1 0

Re: [PATCH] advapi32: Implement GetWindowsAccountDomainSid.
by Marvin 14 Jun '15

14 Jun '15

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=14271 Your paranoid android. === w2000pro (32 bit security) === security.c:5882: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5888: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5889: Test failed: expected size 24, got 68 security.c:5894: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5900: Test failed: expected ERROR_INSUFFICIENT_BUFFER, got 1337 security.c:5901: Test failed: expected size 24, got 1 security.c:5906: Test failed: GetWindowsAccountDomainSid failed with error 1337 security.c:5907: Test failed: last error should not change security.c:5908: Test failed: expected size 24, got 68 security: unhandled exception c0000005 at 0043AC94 === wxppro (32 bit security) === security.c:5882: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5888: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5889: Test failed: expected size 24, got 68 security.c:5894: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5900: Test failed: expected ERROR_INSUFFICIENT_BUFFER, got 1337 security.c:5901: Test failed: expected size 24, got 1 security.c:5906: Test failed: GetWindowsAccountDomainSid failed with error 1337 security.c:5907: Test failed: last error should not change security.c:5908: Test failed: expected size 24, got 68 security: unhandled exception c0000005 at 0043AC94 === w2003std (32 bit security) === security.c:5882: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5888: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5889: Test failed: expected size 24, got 68 security.c:5894: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5900: Test failed: expected ERROR_INSUFFICIENT_BUFFER, got 1337 security.c:5901: Test failed: expected size 24, got 1 security.c:5906: Test failed: GetWindowsAccountDomainSid failed with error 1337 security.c:5907: Test failed: last error should not change security.c:5908: Test failed: expected size 24, got 68 security: unhandled exception c0000005 at 0043AC94 === w7u (32 bit security) === security.c:5882: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5888: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5889: Test failed: expected size 24, got 68 security.c:5894: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5900: Test failed: expected ERROR_INSUFFICIENT_BUFFER, got 1337 security.c:5901: Test failed: expected size 24, got 1 security.c:5906: Test failed: GetWindowsAccountDomainSid failed with error 1337 security.c:5907: Test failed: last error should not change security.c:5908: Test failed: expected size 24, got 68 security: unhandled exception c0000005 at 0043AC94 === w8 (32 bit security) === security.c:5882: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5888: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5889: Test failed: expected size 24, got 68 security.c:5894: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5900: Test failed: expected ERROR_INSUFFICIENT_BUFFER, got 1337 security.c:5901: Test failed: expected size 24, got 1 security.c:5906: Test failed: GetWindowsAccountDomainSid failed with error 1337 security.c:5907: Test failed: last error should not change security.c:5908: Test failed: expected size 24, got 68 security: unhandled exception c0000005 at 0043AC94

1 0

Re: winemac.drv: Improved App name on windows and menus (Mac Driver)
by Theodore Dubois 14 Jun '15

14 Jun '15

I'm curious, given this, how Crossover manages to make the application menu title the same as the Windows program that is running, despite the actual executable being wineloader. Does it work if the executable has no bundle id? ~Theodore > But, more importantly, the title that a program sets for the application menu is ignored by Cocoa. It uses the bundle name regardless. So, this change has no effect.

2 1

Re: hlsl compiler question
by Matteo Bruni 14 Jun '15

14 Jun '15

2015-06-14 10:42 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi Matteo, > > I was looking at this bug as if affects "Star Trek Online" as well. > > Do you know what/how much work it would be to get this fixed? > > http://bugs.winehq.org/show_bug.cgi?id=32932 > > Any help would be great. It still might be way out of my depth to fix. > > Best Regards > Alistair Leslie-Hughes Hi Alistair, fixing that specific bug (i.e. support for the ": register" syntax) is pretty trivial, I even have a patch for that in my queue. It's been postponed by other stuff for a long time but in principle I can send it in the next few days. The problem is that fixing it won't probably help for actually running Star Trek Online, nullDC or any other program currently blocked by that. The HLSL compiler is still missing a lot of stuff, only the parser is currently implemented and the code generation part is totally absent. Cheers, Matteo.

1 0

Re: gdiplus: Implement GdipCreateRegionRgnData.
by Vincent Povirk 14 Jun '15

14 Jun '15

Seems like there are some unnecessary changes (cases reordered, element type fixme changed, breaking from default case), but it looks good otherwise.

1 0

Re: riched: Added ITextDocument2 definition and corresponding tests
by Marvin 13 Jun '15

13 Jun '15

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=14249 Your paranoid android. === w2000pro (32 bit richole) === richole.c:178: Test failed: error: 126

1 0

Re: [PATCH] ntdll: link libunwind if present
by Ken Thomases 13 Jun '15

13 Jun '15

Hi, On Jun 13, 2015, at 5:17 AM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > On openSUSE 13.1/13.2 otherwise ntdll x86_64 build will fail with: > … This new link error is <https://bugs.winehq.org/show_bug.cgi?id=38713>. > (probably on x86 it all is inlined, but this is not the case for x86_64) The new code that introduced this issue is in x86_64-only code (signal_x86_64.c). Thanks for your attempt to fix the problem I created. I'm not sure why your configure check is in an if statement having to do with the support for CFI directives. Also, the symbol you're checking for (_U_dyn_register) seems suspicious. It's not mentioned in the link errors. Also, I'm not sure it's a reliable export from libunwind. As indicated in the bug report, libunwind does annoying symbol renaming that's not consistent among platforms. (It's definitely not present on OS X, although that's because Apple provides a somewhat customized interface.) Erich Hoover and I are working on a different approach on the bug. He attached a patch and I attached a counter-proposal patch. I'd appreciate if you could check that mine solves the problem for you. Thanks, Ken

1 0

Re: odbccp32: Implement SQLGetPrivateProfileString (try 4)
by Nikolay Sivov 13 Jun '15

13 Jun '15

On 13.06.2015 12:41, Alistair Leslie-Hughes wrote: > + ret = SQLGetPrivateProfileStringW(sect, entry, string, retval, cbRetBuffer, file); > + if(ret) > + { > + int i, len; > + > + len = ret < cbRetBuffer ? ret : cbRetBuffer; > + for (i=0; i < len; i++) > + RetBuffer[i] = retval[i]; > + RetBuffer[i] = 0; > + } You can't convert it like that, the idea is to do A->W conversion for inputs and W->A for output. Inputs are handled by heap_strdupAtoW(), so you need a single WideCharToMultiByte for retbuffer.

1 0

Re: [PATCH] oledb32: free memory on error exit (Coverity)
by Nikolay Sivov 13 Jun '15

13 Jun '15

On 13.06.2015 8:54, Marcus Meissner wrote: > 966609 Resource leak > --- > dlls/oledb32/datainit.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/oledb32/datainit.c b/dlls/oledb32/datainit.c > index 3c5293a..3a6c924 100644 > --- a/dlls/oledb32/datainit.c > +++ b/dlls/oledb32/datainit.c > @@ -520,6 +520,8 @@ static HRESULT get_dbpropset_from_proplist(struct dbprops *props, DBPROPSET **pr > if (FAILED(hr)) > { > ERR("failed to init property %s value as type %d\n", debugstr_w(pair->name), descr->type); > + CoTaskMemFree(*propset); > + *propset = NULL; > return hr; > } > > free_dbpropset() should be used for that, otherwise you'll still be leaking values.

1 0

Re: [PATCH 1/6] msvcp110: Add tr2_sys__File_size implementation and test.(try 4)
by Piotr Caban 12 Jun '15

12 Jun '15

On 06/11/15 17:43, YongHao Hu wrote: > +@ cdecl -ret64 -arch=win32 ?_File_size@sys@tr2@std@@YA_KPBD@Z(str) msvcp120.?tr2_sys__File_size > +@ cdecl -ret64 -arch=win64 ?_File_size@sys@tr2@std@@YA_KPEBD@Z(str) msvcp120.?tr2_sys__File_size This is not going to work. Thanks, Piotr

2 1

Re: [1/3] include: Add stuff related to WSAPoll() (try 2)
by Alexandre Julliard 12 Jun '15

12 Jun '15

Bruno Jesus <00cpxxx(a)gmail.com> writes: > try 2: > I found the solution to typedef the struct pollfd just like it's done > with fd_set. Unfortunately that doesn't work on mingw: In file included from ../../../wine/include/winsock2.h:50:0, from ../../../wine/include/ws2tcpip.h:22, from ../../../wine/dlls/jsproxy/main.c:34: ../../../wine/include/winsock2.h:287:19: error: redefinition of ‘struct pollfd’ ../../../wine/include/ws2def.h:27:18: note: in definition of macro ‘WS’ In file included from ../../../wine/dlls/jsproxy/main.c:20:0: ../../../wine/include/wine/port.h:284:8: note: originally defined here -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: [PATCH 2/2] dwrite: Fix splitted range length, initial test for GetMetrics()
by Marvin 12 Jun '15

12 Jun '15

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=14198 Your paranoid android. === wvistau64 (32 bit layout) === layout.c:2355: Test failed: got 4 === w2008s64 (32 bit layout) === layout.c:2355: Test failed: got 4 === w7u (32 bit layout) === layout.c:2355: Test failed: got 4 === wvistau64 (64 bit layout) === layout.c:2355: Test failed: got 4 === w2008s64 (64 bit layout) === layout.c:2355: Test failed: got 4

1 0

Re: [PATCH 5/6] msvcp110: Add tr2_sys__Make_dir implementation and test.
by Piotr Caban 12 Jun '15

12 Jun '15

Hi, On 06/11/15 17:45, YongHao Hu wrote: > + { "N:\\abc", -1 }, N:\\abc looks like a valid path for me. I guess this test will fail if someone have N: drive. Thanks, Piotr

1 0

Re: [1/1] advapi32/tests: Add preliminary event tracing tests. (try 3)
by Marvin 12 Jun '15

12 Jun '15

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=14196 Your paranoid android. === w2000pro (32 bit eventlog) === eventlog.c:768: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:776: Test failed: Expected success eventlog.c:784: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === wxppro (32 bit eventlog) === eventlog.c:686: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:695: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:768: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:776: Test failed: Expected success eventlog.c:784: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w2003std (32 bit eventlog) === eventlog.c:686: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:695: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:768: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:776: Test failed: Expected success eventlog.c:784: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === wvistau64 (32 bit eventlog) === eventlog.c:695: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:768: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:776: Test failed: Expected success eventlog.c:784: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w2008s64 (32 bit eventlog) === eventlog.c:695: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:768: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:776: Test failed: Expected success eventlog.c:784: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w7u (32 bit eventlog) === eventlog.c:695: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:768: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:776: Test failed: Expected success eventlog.c:784: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w8 (32 bit eventlog) === eventlog.c:695: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:768: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:776: Test failed: Expected success eventlog.c:784: Test failed: Expected ERROR_ALREADY_EXISTS, got 87

1 0

Re: [PATCH 4/4] d3drm/tests: Add refcount tests for IDirect3DRMDevice*
by Stefan Dösinger 11 Jun '15

11 Jun '15

I think these tests are best integrated into CreateDeviceFromClipper. Similar tests are needed for the other creation methods, with some modifications. Check if the reference count of the surface passed to CreateDeviceFromSurface is incremented, and similarly for the device passed to CreateDeviceFromD3D. > Am 11.06.2015 um 13:51 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > > The refcount tests for d3drm1 are the same for the device created from all three creation methods. > --- > dlls/d3drm/tests/d3drm.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 81 insertions(+) > > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index ac4c8fe..ecf1d4d 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -2367,6 +2367,86 @@ cleanup: > IDirectDraw_Release(ddraw1); > } > > +static void test_device_refcount(void) > +{ > + IDirect3DRM *d3drm1; > + IDirect3DRM2 *d3drm2; > + IDirect3DRM3 *d3drm3; > + IDirect3DRMDevice *device1; > + IDirect3DRMDevice2 *device2; > + IDirect3DRMDevice3 *device3; > + IDirectDrawClipper *clipper; > + HWND window; > + HRESULT hr; > + ULONG ref1, ref2, cref1, cref2; > + GUID driver; > + RECT rc; > + > + > + window = CreateWindowA("static", "d3drm_test", WS_OVERLAPPEDWINDOW, 0, 0, 300, 200, 0, 0, 0, 0); > + GetClientRect(window, &rc); > + hr = DirectDrawCreateClipper(0, &clipper, NULL); > + ok(hr == DD_OK, "Cannot get IDirectDrawClipper interface (hr = %x)\n", hr); > + hr = IDirectDrawClipper_SetHWnd(clipper, 0, window); > + ok(hr == DD_OK, "Cannot set HWnd to Clipper (hr = %x)\n", hr); > + > + hr = Direct3DRMCreate(&d3drm1); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", hr); > + ref1 = get_refcount((IUnknown *)d3drm1); > + cref1 = get_refcount((IUnknown *)clipper); > + memcpy(&driver, &IID_IDirect3DRGBDevice, sizeof(GUID)); > + hr = IDirect3DRM_CreateDeviceFromClipper(d3drm1, clipper, &driver, rc.right, rc.bottom, &device1); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRMDevice interface (hr = %x)\n", hr); > + ref2 = get_refcount((IUnknown *)d3drm1); > + cref2 = get_refcount((IUnknown *)clipper); > + ok(ref2 > ref1, "expected ref2 > ref1, got ref1 = %d , ref2 = %d\n", ref1, ref2); > + ok(cref2 > cref1, "expected cref2 > cref1, got cref1 = %d , cref2 = %d\n", cref1, cref2); > + if (device1) > + IDirect3DRMDevice_Release(device1); > + ref2 = get_refcount((IUnknown *)d3drm1); > + cref2 = get_refcount((IUnknown *)clipper); > + ok(ref1 == ref2, "expected ref1 == ref2, got ref1 = %d, ref2 = %d\n", ref1, ref2); > + ok(cref1 == cref2, "expected cref1 == cref2, got cref1 = %d, cref2 = %d\n", cref1, cref2); > + > + hr = IDirect3DRM_QueryInterface(d3drm1, &IID_IDirect3DRM2, (void **)&d3drm2); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM2 interface (hr = %x).\n", hr); > + ref1 = get_refcount((IUnknown *)d3drm1); > + cref1 = get_refcount((IUnknown *)clipper); > + hr = IDirect3DRM2_CreateDeviceFromClipper(d3drm2, clipper, &driver, rc.right, rc.bottom, &device2); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRMDevice2 interface (hr = %x)\n", hr); > + ref2 = get_refcount((IUnknown *)d3drm1); > + cref2 = get_refcount((IUnknown *)clipper); > + ok(ref2 > ref1, "expected ref2 > ref1, got ref1 = %d , ref2 = %d\n", ref1, ref2); > + ok(cref2 > cref1, "expected cref2 > cref1, got cref1 = %d , cref2 = %d\n", cref1, cref2); > + if (device2) > + IDirect3DRMDevice2_Release(device2); > + ref2 = get_refcount((IUnknown *)d3drm1); > + cref2 = get_refcount((IUnknown *)clipper); > + ok(ref1 == ref2, "expected ref1 == ref2, got ref1 = %d, ref2 = %d\n", ref1, ref2); > + ok(cref1 == cref2, "expected cref1 == cref2, got cref1 = %d, cref2 = %d\n", cref1, cref2); > + > + hr = IDirect3DRM_QueryInterface(d3drm1, &IID_IDirect3DRM3, (void **)&d3drm3); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM3 interface (hr = %x).\n", hr); > + ref1 = get_refcount((IUnknown *)d3drm1); > + cref1 = get_refcount((IUnknown *)clipper); > + hr = IDirect3DRM3_CreateDeviceFromClipper(d3drm3, clipper, &driver, rc.right, rc.bottom, &device3); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRMDevice3 interface (hr = %x)\n", hr); > + ref2 = get_refcount((IUnknown *)d3drm1); > + cref2 = get_refcount((IUnknown *)clipper); > + ok(ref2 > ref1, "expected ref2 > ref1, got ref1 = %d, ref2 = %d\n", ref1, ref2); > + ok(cref2 > cref1, "expected cref2 > cref1, got cref1 = %d , cref2 = %d\n", cref1, cref2); > + if (device3) > + IDirect3DRMDevice3_Release(device3); > + ref2 = get_refcount((IUnknown *)d3drm1); > + cref2 = get_refcount((IUnknown *)clipper); > + ok(ref1 == ref2, "expected ref1 == ref2, got ref1 = %d, ref2 = %d\n", ref1, ref2); > + ok(cref1 == cref2, "expected cref1 == cref2, got cref1 = %d, cref2 = %d\n", cref1, cref2); > + > + IDirectDrawClipper_Release(clipper); > + IDirect3DRM2_Release(d3drm2); > + IDirect3DRM3_Release(d3drm3); > +} > + > START_TEST(d3drm) > { > test_MeshBuilder(); > @@ -2387,4 +2467,5 @@ START_TEST(d3drm) > test_create_device_from_clipper(); > test_create_device_from_surface(); > test_create_device_from_d3d(); > + test_device_refcount(); > } > -- > 1.9.3 (Apple Git-50) > > >

2 1

Re: [PATCH] ddraw: Make some functions hotpachable.
by Stefan Dösinger 11 Jun '15

11 Jun '15

This is fine with me. Note though that when I dealt with Fraps I noticed that it expects new interfaces to thunk to old interfaces, not the other way around like we do. We'll probably have to do something similar if we want these apps to work on ddraw. Also at least Fraps expects the functions to be at the same offset in the loaded library image. Setting a constant load address makes this work, but it's an overkill and Alexandre said no to it. > Am 11.06.2015 um 17:38 schrieb Marcus Meissner <marcus(a)jet.franken.de>: > > From: Michael Müller <michael(a)fds-team.de> > > --- > dlls/ddraw/surface.c | 55 ++++++++++++++++++++++++++++------------------------ > 1 file changed, 30 insertions(+), 25 deletions(-) > > diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c > index f716cfc..77a3d44 100644 > --- a/dlls/ddraw/surface.c > +++ b/dlls/ddraw/surface.c > @@ -1155,7 +1155,7 @@ static HRESULT WINAPI ddraw_surface1_Lock(IDirectDrawSurface *iface, RECT *rect, > * For more details, see IWineD3DSurface::UnlockRect > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_Unlock(IDirectDrawSurface7 *iface, RECT *pRect) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Unlock(IDirectDrawSurface7 *iface, RECT *pRect) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface7(iface); > HRESULT hr; > @@ -1171,7 +1171,7 @@ static HRESULT WINAPI ddraw_surface7_Unlock(IDirectDrawSurface7 *iface, RECT *pR > return hr; > } > > -static HRESULT WINAPI ddraw_surface4_Unlock(IDirectDrawSurface4 *iface, RECT *pRect) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_Unlock(IDirectDrawSurface4 *iface, RECT *pRect) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface4(iface); > > @@ -1180,7 +1180,7 @@ static HRESULT WINAPI ddraw_surface4_Unlock(IDirectDrawSurface4 *iface, RECT *pR > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, pRect); > } > > -static HRESULT WINAPI ddraw_surface3_Unlock(IDirectDrawSurface3 *iface, void *data) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_Unlock(IDirectDrawSurface3 *iface, void *data) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface3(iface); > > @@ -1190,7 +1190,7 @@ static HRESULT WINAPI ddraw_surface3_Unlock(IDirectDrawSurface3 *iface, void *da > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, NULL); > } > > -static HRESULT WINAPI ddraw_surface2_Unlock(IDirectDrawSurface2 *iface, void *data) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_Unlock(IDirectDrawSurface2 *iface, void *data) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface2(iface); > > @@ -1200,7 +1200,7 @@ static HRESULT WINAPI ddraw_surface2_Unlock(IDirectDrawSurface2 *iface, void *da > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, NULL); > } > > -static HRESULT WINAPI ddraw_surface1_Unlock(IDirectDrawSurface *iface, void *data) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_Unlock(IDirectDrawSurface *iface, void *data) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface(iface); > > @@ -1210,7 +1210,8 @@ static HRESULT WINAPI ddraw_surface1_Unlock(IDirectDrawSurface *iface, void *dat > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, NULL); > } > > -static HRESULT WINAPI ddraw_surface7_Flip(IDirectDrawSurface7 *iface, IDirectDrawSurface7 *src, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Flip(IDirectDrawSurface7 *iface, > + IDirectDrawSurface7 *src, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface7(iface); > struct ddraw_surface *src_impl = unsafe_impl_from_IDirectDrawSurface7(src); > @@ -1332,7 +1333,8 @@ static HRESULT WINAPI ddraw_surface7_Flip(IDirectDrawSurface7 *iface, IDirectDra > return hr; > } > > -static HRESULT WINAPI ddraw_surface4_Flip(IDirectDrawSurface4 *iface, IDirectDrawSurface4 *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_Flip(IDirectDrawSurface4 *iface, > + IDirectDrawSurface4 *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface4(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface4(dst); > @@ -1343,7 +1345,8 @@ static HRESULT WINAPI ddraw_surface4_Flip(IDirectDrawSurface4 *iface, IDirectDra > dst_impl ? &dst_impl->IDirectDrawSurface7_iface : NULL, flags); > } > > -static HRESULT WINAPI ddraw_surface3_Flip(IDirectDrawSurface3 *iface, IDirectDrawSurface3 *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_Flip(IDirectDrawSurface3 *iface, > + IDirectDrawSurface3 *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface3(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface3(dst); > @@ -1354,7 +1357,8 @@ static HRESULT WINAPI ddraw_surface3_Flip(IDirectDrawSurface3 *iface, IDirectDra > dst_impl ? &dst_impl->IDirectDrawSurface7_iface : NULL, flags); > } > > -static HRESULT WINAPI ddraw_surface2_Flip(IDirectDrawSurface2 *iface, IDirectDrawSurface2 *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_Flip(IDirectDrawSurface2 *iface, > + IDirectDrawSurface2 *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface2(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface2(dst); > @@ -1365,7 +1369,8 @@ static HRESULT WINAPI ddraw_surface2_Flip(IDirectDrawSurface2 *iface, IDirectDra > dst_impl ? &dst_impl->IDirectDrawSurface7_iface : NULL, flags); > } > > -static HRESULT WINAPI ddraw_surface1_Flip(IDirectDrawSurface *iface, IDirectDrawSurface *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_Flip(IDirectDrawSurface *iface, > + IDirectDrawSurface *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface(dst); > @@ -1514,7 +1519,7 @@ static HRESULT ddraw_surface_blt_clipped(struct ddraw_surface *dst_surface, cons > * See IWineD3DSurface::Blt for more details > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_Blt(IDirectDrawSurface7 *iface, RECT *DestRect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Blt(IDirectDrawSurface7 *iface, RECT *DestRect, > IDirectDrawSurface7 *SrcSurface, RECT *SrcRect, DWORD Flags, DDBLTFX *DDBltFx) > { > struct ddraw_surface *dst_surface = impl_from_IDirectDrawSurface7(iface); > @@ -1640,7 +1645,7 @@ static HRESULT WINAPI ddraw_surface7_Blt(IDirectDrawSurface7 *iface, RECT *DestR > } > } > > -static HRESULT WINAPI ddraw_surface4_Blt(IDirectDrawSurface4 *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_Blt(IDirectDrawSurface4 *iface, RECT *dst_rect, > IDirectDrawSurface4 *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface4(iface); > @@ -1653,7 +1658,7 @@ static HRESULT WINAPI ddraw_surface4_Blt(IDirectDrawSurface4 *iface, RECT *dst_r > src ? &src->IDirectDrawSurface7_iface : NULL, src_rect, flags, fx); > } > > -static HRESULT WINAPI ddraw_surface3_Blt(IDirectDrawSurface3 *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_Blt(IDirectDrawSurface3 *iface, RECT *dst_rect, > IDirectDrawSurface3 *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface3(iface); > @@ -1666,7 +1671,7 @@ static HRESULT WINAPI ddraw_surface3_Blt(IDirectDrawSurface3 *iface, RECT *dst_r > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags, fx); > } > > -static HRESULT WINAPI ddraw_surface2_Blt(IDirectDrawSurface2 *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_Blt(IDirectDrawSurface2 *iface, RECT *dst_rect, > IDirectDrawSurface2 *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface2(iface); > @@ -1679,7 +1684,7 @@ static HRESULT WINAPI ddraw_surface2_Blt(IDirectDrawSurface2 *iface, RECT *dst_r > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags, fx); > } > > -static HRESULT WINAPI ddraw_surface1_Blt(IDirectDrawSurface *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_Blt(IDirectDrawSurface *iface, RECT *dst_rect, > IDirectDrawSurface *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface(iface); > @@ -2640,7 +2645,7 @@ static HRESULT WINAPI ddraw_surface2_PageUnlock(IDirectDrawSurface2 *iface, DWOR > * DDERR_UNSUPPORTED > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_BltBatch(IDirectDrawSurface7 *iface, DDBLTBATCH *Batch, DWORD Count, DWORD Flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_BltBatch(IDirectDrawSurface7 *iface, DDBLTBATCH *Batch, DWORD Count, DWORD Flags) > { > TRACE("iface %p, batch %p, count %u, flags %#x.\n", iface, Batch, Count, Flags); > > @@ -2648,7 +2653,7 @@ static HRESULT WINAPI ddraw_surface7_BltBatch(IDirectDrawSurface7 *iface, DDBLTB > return DDERR_UNSUPPORTED; > } > > -static HRESULT WINAPI ddraw_surface4_BltBatch(IDirectDrawSurface4 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_BltBatch(IDirectDrawSurface4 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface4(iface); > > @@ -2657,7 +2662,7 @@ static HRESULT WINAPI ddraw_surface4_BltBatch(IDirectDrawSurface4 *iface, DDBLTB > return ddraw_surface7_BltBatch(&surface->IDirectDrawSurface7_iface, batch, count, flags); > } > > -static HRESULT WINAPI ddraw_surface3_BltBatch(IDirectDrawSurface3 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_BltBatch(IDirectDrawSurface3 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface3(iface); > > @@ -2666,7 +2671,7 @@ static HRESULT WINAPI ddraw_surface3_BltBatch(IDirectDrawSurface3 *iface, DDBLTB > return ddraw_surface7_BltBatch(&surface->IDirectDrawSurface7_iface, batch, count, flags); > } > > -static HRESULT WINAPI ddraw_surface2_BltBatch(IDirectDrawSurface2 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_BltBatch(IDirectDrawSurface2 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface2(iface); > > @@ -2675,7 +2680,7 @@ static HRESULT WINAPI ddraw_surface2_BltBatch(IDirectDrawSurface2 *iface, DDBLTB > return ddraw_surface7_BltBatch(&surface->IDirectDrawSurface7_iface, batch, count, flags); > } > > -static HRESULT WINAPI ddraw_surface1_BltBatch(IDirectDrawSurface *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_BltBatch(IDirectDrawSurface *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface(iface); > > @@ -4093,7 +4098,7 @@ static HRESULT WINAPI ddraw_surface7_GetLOD(IDirectDrawSurface7 *iface, DWORD *M > * For more details, see IWineD3DSurface::BltFast > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_BltFast(IDirectDrawSurface7 *iface, DWORD dstx, DWORD dsty, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_BltFast(IDirectDrawSurface7 *iface, DWORD dstx, DWORD dsty, > IDirectDrawSurface7 *Source, RECT *rsrc, DWORD trans) > { > struct ddraw_surface *This = impl_from_IDirectDrawSurface7(iface); > @@ -4165,7 +4170,7 @@ static HRESULT WINAPI ddraw_surface7_BltFast(IDirectDrawSurface7 *iface, DWORD d > } > } > > -static HRESULT WINAPI ddraw_surface4_BltFast(IDirectDrawSurface4 *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_BltFast(IDirectDrawSurface4 *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface4 *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface4(iface); > @@ -4178,7 +4183,7 @@ static HRESULT WINAPI ddraw_surface4_BltFast(IDirectDrawSurface4 *iface, DWORD d > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags); > } > > -static HRESULT WINAPI ddraw_surface3_BltFast(IDirectDrawSurface3 *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_BltFast(IDirectDrawSurface3 *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface3 *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface3(iface); > @@ -4191,7 +4196,7 @@ static HRESULT WINAPI ddraw_surface3_BltFast(IDirectDrawSurface3 *iface, DWORD d > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags); > } > > -static HRESULT WINAPI ddraw_surface2_BltFast(IDirectDrawSurface2 *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_BltFast(IDirectDrawSurface2 *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface2 *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface2(iface); > @@ -4204,7 +4209,7 @@ static HRESULT WINAPI ddraw_surface2_BltFast(IDirectDrawSurface2 *iface, DWORD d > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags); > } > > -static HRESULT WINAPI ddraw_surface1_BltFast(IDirectDrawSurface *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_BltFast(IDirectDrawSurface *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface(iface); > -- > 1.8.4.5 > > >

1 0

Re: [PATCH] ddraw: Make some functions hotpachable.
by Stefan Dösinger 11 Jun '15

11 Jun '15

This is fine with me. Note though that when I dealt with Fraps I noticed that it expects new interfaces to thunk to old interfaces, not the other way around like we do. We'll probably have to do something similar if we want these apps to work on ddraw. Also at least Fraps expects the functions to be at the same offset in the loaded library image. Setting a constant load address makes this work, but it's an overkill and Alexandre said no to it. > Am 11.06.2015 um 17:38 schrieb Marcus Meissner <marcus(a)jet.franken.de>: > > From: Michael Müller <michael(a)fds-team.de> > > --- > dlls/ddraw/surface.c | 55 ++++++++++++++++++++++++++++------------------------ > 1 file changed, 30 insertions(+), 25 deletions(-) > > diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c > index f716cfc..77a3d44 100644 > --- a/dlls/ddraw/surface.c > +++ b/dlls/ddraw/surface.c > @@ -1155,7 +1155,7 @@ static HRESULT WINAPI ddraw_surface1_Lock(IDirectDrawSurface *iface, RECT *rect, > * For more details, see IWineD3DSurface::UnlockRect > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_Unlock(IDirectDrawSurface7 *iface, RECT *pRect) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Unlock(IDirectDrawSurface7 *iface, RECT *pRect) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface7(iface); > HRESULT hr; > @@ -1171,7 +1171,7 @@ static HRESULT WINAPI ddraw_surface7_Unlock(IDirectDrawSurface7 *iface, RECT *pR > return hr; > } > > -static HRESULT WINAPI ddraw_surface4_Unlock(IDirectDrawSurface4 *iface, RECT *pRect) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_Unlock(IDirectDrawSurface4 *iface, RECT *pRect) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface4(iface); > > @@ -1180,7 +1180,7 @@ static HRESULT WINAPI ddraw_surface4_Unlock(IDirectDrawSurface4 *iface, RECT *pR > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, pRect); > } > > -static HRESULT WINAPI ddraw_surface3_Unlock(IDirectDrawSurface3 *iface, void *data) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_Unlock(IDirectDrawSurface3 *iface, void *data) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface3(iface); > > @@ -1190,7 +1190,7 @@ static HRESULT WINAPI ddraw_surface3_Unlock(IDirectDrawSurface3 *iface, void *da > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, NULL); > } > > -static HRESULT WINAPI ddraw_surface2_Unlock(IDirectDrawSurface2 *iface, void *data) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_Unlock(IDirectDrawSurface2 *iface, void *data) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface2(iface); > > @@ -1200,7 +1200,7 @@ static HRESULT WINAPI ddraw_surface2_Unlock(IDirectDrawSurface2 *iface, void *da > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, NULL); > } > > -static HRESULT WINAPI ddraw_surface1_Unlock(IDirectDrawSurface *iface, void *data) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_Unlock(IDirectDrawSurface *iface, void *data) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface(iface); > > @@ -1210,7 +1210,8 @@ static HRESULT WINAPI ddraw_surface1_Unlock(IDirectDrawSurface *iface, void *dat > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, NULL); > } > > -static HRESULT WINAPI ddraw_surface7_Flip(IDirectDrawSurface7 *iface, IDirectDrawSurface7 *src, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Flip(IDirectDrawSurface7 *iface, > + IDirectDrawSurface7 *src, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface7(iface); > struct ddraw_surface *src_impl = unsafe_impl_from_IDirectDrawSurface7(src); > @@ -1332,7 +1333,8 @@ static HRESULT WINAPI ddraw_surface7_Flip(IDirectDrawSurface7 *iface, IDirectDra > return hr; > } > > -static HRESULT WINAPI ddraw_surface4_Flip(IDirectDrawSurface4 *iface, IDirectDrawSurface4 *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_Flip(IDirectDrawSurface4 *iface, > + IDirectDrawSurface4 *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface4(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface4(dst); > @@ -1343,7 +1345,8 @@ static HRESULT WINAPI ddraw_surface4_Flip(IDirectDrawSurface4 *iface, IDirectDra > dst_impl ? &dst_impl->IDirectDrawSurface7_iface : NULL, flags); > } > > -static HRESULT WINAPI ddraw_surface3_Flip(IDirectDrawSurface3 *iface, IDirectDrawSurface3 *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_Flip(IDirectDrawSurface3 *iface, > + IDirectDrawSurface3 *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface3(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface3(dst); > @@ -1354,7 +1357,8 @@ static HRESULT WINAPI ddraw_surface3_Flip(IDirectDrawSurface3 *iface, IDirectDra > dst_impl ? &dst_impl->IDirectDrawSurface7_iface : NULL, flags); > } > > -static HRESULT WINAPI ddraw_surface2_Flip(IDirectDrawSurface2 *iface, IDirectDrawSurface2 *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_Flip(IDirectDrawSurface2 *iface, > + IDirectDrawSurface2 *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface2(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface2(dst); > @@ -1365,7 +1369,8 @@ static HRESULT WINAPI ddraw_surface2_Flip(IDirectDrawSurface2 *iface, IDirectDra > dst_impl ? &dst_impl->IDirectDrawSurface7_iface : NULL, flags); > } > > -static HRESULT WINAPI ddraw_surface1_Flip(IDirectDrawSurface *iface, IDirectDrawSurface *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_Flip(IDirectDrawSurface *iface, > + IDirectDrawSurface *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface(dst); > @@ -1514,7 +1519,7 @@ static HRESULT ddraw_surface_blt_clipped(struct ddraw_surface *dst_surface, cons > * See IWineD3DSurface::Blt for more details > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_Blt(IDirectDrawSurface7 *iface, RECT *DestRect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Blt(IDirectDrawSurface7 *iface, RECT *DestRect, > IDirectDrawSurface7 *SrcSurface, RECT *SrcRect, DWORD Flags, DDBLTFX *DDBltFx) > { > struct ddraw_surface *dst_surface = impl_from_IDirectDrawSurface7(iface); > @@ -1640,7 +1645,7 @@ static HRESULT WINAPI ddraw_surface7_Blt(IDirectDrawSurface7 *iface, RECT *DestR > } > } > > -static HRESULT WINAPI ddraw_surface4_Blt(IDirectDrawSurface4 *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_Blt(IDirectDrawSurface4 *iface, RECT *dst_rect, > IDirectDrawSurface4 *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface4(iface); > @@ -1653,7 +1658,7 @@ static HRESULT WINAPI ddraw_surface4_Blt(IDirectDrawSurface4 *iface, RECT *dst_r > src ? &src->IDirectDrawSurface7_iface : NULL, src_rect, flags, fx); > } > > -static HRESULT WINAPI ddraw_surface3_Blt(IDirectDrawSurface3 *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_Blt(IDirectDrawSurface3 *iface, RECT *dst_rect, > IDirectDrawSurface3 *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface3(iface); > @@ -1666,7 +1671,7 @@ static HRESULT WINAPI ddraw_surface3_Blt(IDirectDrawSurface3 *iface, RECT *dst_r > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags, fx); > } > > -static HRESULT WINAPI ddraw_surface2_Blt(IDirectDrawSurface2 *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_Blt(IDirectDrawSurface2 *iface, RECT *dst_rect, > IDirectDrawSurface2 *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface2(iface); > @@ -1679,7 +1684,7 @@ static HRESULT WINAPI ddraw_surface2_Blt(IDirectDrawSurface2 *iface, RECT *dst_r > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags, fx); > } > > -static HRESULT WINAPI ddraw_surface1_Blt(IDirectDrawSurface *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_Blt(IDirectDrawSurface *iface, RECT *dst_rect, > IDirectDrawSurface *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface(iface); > @@ -2640,7 +2645,7 @@ static HRESULT WINAPI ddraw_surface2_PageUnlock(IDirectDrawSurface2 *iface, DWOR > * DDERR_UNSUPPORTED > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_BltBatch(IDirectDrawSurface7 *iface, DDBLTBATCH *Batch, DWORD Count, DWORD Flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_BltBatch(IDirectDrawSurface7 *iface, DDBLTBATCH *Batch, DWORD Count, DWORD Flags) > { > TRACE("iface %p, batch %p, count %u, flags %#x.\n", iface, Batch, Count, Flags); > > @@ -2648,7 +2653,7 @@ static HRESULT WINAPI ddraw_surface7_BltBatch(IDirectDrawSurface7 *iface, DDBLTB > return DDERR_UNSUPPORTED; > } > > -static HRESULT WINAPI ddraw_surface4_BltBatch(IDirectDrawSurface4 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_BltBatch(IDirectDrawSurface4 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface4(iface); > > @@ -2657,7 +2662,7 @@ static HRESULT WINAPI ddraw_surface4_BltBatch(IDirectDrawSurface4 *iface, DDBLTB > return ddraw_surface7_BltBatch(&surface->IDirectDrawSurface7_iface, batch, count, flags); > } > > -static HRESULT WINAPI ddraw_surface3_BltBatch(IDirectDrawSurface3 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_BltBatch(IDirectDrawSurface3 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface3(iface); > > @@ -2666,7 +2671,7 @@ static HRESULT WINAPI ddraw_surface3_BltBatch(IDirectDrawSurface3 *iface, DDBLTB > return ddraw_surface7_BltBatch(&surface->IDirectDrawSurface7_iface, batch, count, flags); > } > > -static HRESULT WINAPI ddraw_surface2_BltBatch(IDirectDrawSurface2 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_BltBatch(IDirectDrawSurface2 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface2(iface); > > @@ -2675,7 +2680,7 @@ static HRESULT WINAPI ddraw_surface2_BltBatch(IDirectDrawSurface2 *iface, DDBLTB > return ddraw_surface7_BltBatch(&surface->IDirectDrawSurface7_iface, batch, count, flags); > } > > -static HRESULT WINAPI ddraw_surface1_BltBatch(IDirectDrawSurface *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_BltBatch(IDirectDrawSurface *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface(iface); > > @@ -4093,7 +4098,7 @@ static HRESULT WINAPI ddraw_surface7_GetLOD(IDirectDrawSurface7 *iface, DWORD *M > * For more details, see IWineD3DSurface::BltFast > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_BltFast(IDirectDrawSurface7 *iface, DWORD dstx, DWORD dsty, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_BltFast(IDirectDrawSurface7 *iface, DWORD dstx, DWORD dsty, > IDirectDrawSurface7 *Source, RECT *rsrc, DWORD trans) > { > struct ddraw_surface *This = impl_from_IDirectDrawSurface7(iface); > @@ -4165,7 +4170,7 @@ static HRESULT WINAPI ddraw_surface7_BltFast(IDirectDrawSurface7 *iface, DWORD d > } > } > > -static HRESULT WINAPI ddraw_surface4_BltFast(IDirectDrawSurface4 *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_BltFast(IDirectDrawSurface4 *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface4 *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface4(iface); > @@ -4178,7 +4183,7 @@ static HRESULT WINAPI ddraw_surface4_BltFast(IDirectDrawSurface4 *iface, DWORD d > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags); > } > > -static HRESULT WINAPI ddraw_surface3_BltFast(IDirectDrawSurface3 *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_BltFast(IDirectDrawSurface3 *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface3 *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface3(iface); > @@ -4191,7 +4196,7 @@ static HRESULT WINAPI ddraw_surface3_BltFast(IDirectDrawSurface3 *iface, DWORD d > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags); > } > > -static HRESULT WINAPI ddraw_surface2_BltFast(IDirectDrawSurface2 *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_BltFast(IDirectDrawSurface2 *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface2 *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface2(iface); > @@ -4204,7 +4209,7 @@ static HRESULT WINAPI ddraw_surface2_BltFast(IDirectDrawSurface2 *iface, DWORD d > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags); > } > > -static HRESULT WINAPI ddraw_surface1_BltFast(IDirectDrawSurface *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_BltFast(IDirectDrawSurface *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface(iface); > -- > 1.8.4.5 > > >

1 0

Re: winemac.drv: Improved App name on windows and menus (Mac Driver)
by Ken Thomases 11 Jun '15

11 Jun '15

Hi, On Jun 10, 2015, at 9:48 AM, Vitor Marques <vitor251093(a)gmail.com> wrote: > In the actual code, the Mac Driver uses the Bundle Name on the Hide and Quit buttons, but not in the main menu item, which doesn't make sense since that's the most important place for the app name. It's a very simple change that surely will be very welcome to all Mac users. I've also attached the patch in case Gmail's line-wrapping cause any trouble. Although I have not tested, the changes are simple enough to be analyzed in sight. My system is a Mac OS X 10.10. Thanks for your interest in the Mac driver and your attempt to improve it. Unfortunately, it's clear you haven't tested, since this won't run. You've misspelled "length" as "lenght", which would cause an unrecognized selector exception at run time if it even compiles. But, more importantly, the title that a program sets for the application menu is ignored by Cocoa. It uses the bundle name regardless. So, this change has no effect. Was there an actual problem behavior that you observed that you were trying to fix? Or was this just determined by reading the code? -Ken

2 2

Re: [PATCH 1/4] msvcp110: Add tr2_sys__File_size implementation and test.(try 3)
by Piotr Caban 11 Jun '15

11 Jun '15

On 06/09/15 18:49, YongHao Hu wrote: > try 3: > Add errno and SetLastError test. The series looks good for me. The GetLastError value seems to be inconsistent (it's best visible in _Equivalent tests). I'm not sure why I've asked you about testing GetLastError, I was probably thinking about errno. Anyway I don't think it's useful to test it in future. Thanks, Piotr

2 5

Re: PATCH: ParseX509EncodedCertificateForListBoxEntry stub
by Henri Verbeet 11 Jun '15

11 Jun '15

I suppose I'll give Austin a hand because I like the occasional Valgrind runs. On 11 June 2015 at 11:24, Marcus Meissner <marcus(a)jet.franken.de> wrote: > +DWORD WINAPI ParseX509EncodedCertificateForListBoxEntry(LPBYTE cert, DWORD len, LPSTR szlistbox, LPDWORD listbox) Please avoid the pointer typedefs and Hungarian. I.e., "char *listbox", "DWORD *listbox_size", etc. > + FIXME("stub: %p %d %s %p\n", cert, len, debugstr_a(szlistbox), listbox); I'm not a particular fan of this tracing style, but I suppose it's the local wininet style. "len" is a DWORD, so unsigned, so %u. "szlistbox" is an output parameter, so tracing it as a string makes no sense. > -@ stub ParseX509EncodedCertificateForListBoxEntry > +@ stdcall ParseX509EncodedCertificateForListBoxEntry(ptr long str ptr) Similarly, "str" is wrong for output parameters. > +DWORD WINAPI ParseX509EncodedCertificateForListBoxEntry(LPBYTE,DWORD,LPSTR,LPDWORD); While not strictly wrong, I really think it's much more readable to include the parameter names in the prototypes. I suppose that's local wininet style too, but IMHO we should just fix it in that regard. Also, pointer typedefs again.

2 1

Re: winemac.drv: Improved App name on windows and menus (Mac Driver)
by Huw Davies 11 Jun '15

11 Jun '15

On Wed, Jun 10, 2015 at 11:48:35AM -0300, Vitor Marques wrote: > Although I have not tested, the changes are simple enough > to be analyzed in sight. Indeed they are, see below. You really do need to test your patches. And yes, gmail messed up the whitespace. > diff --git a/dlls/winemac.drv/cocoa_app.m b/dlls/winemac.drv/cocoa_app.m > index 82925c8..a9d98c6 100644 > --- a/dlls/winemac.drv/cocoa_app.m > +++ b/dlls/winemac.drv/cocoa_app.m > @@ -214,14 +214,14 @@ - (void) transformProcessToForeground > > mainMenu = [[[NSMenu alloc] init] autorelease]; > > - // Application menu > - submenu = [[[NSMenu alloc] initWithTitle:@"Wine"] autorelease]; > + // Application name > bundleName = [[NSBundle mainBundle] objectForInfoDictionaryKey:(NSString*)kCFBundleNameKey]; > + if (!bundleName || ![bundleName lenght]) bundleName = @"Wine"; "lenght" is not what you want here. Huw.

2 2

2025

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