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

Re: D3d11 CreateDeviceAndSwapChain

by Roderick Colenbrander

Hi Martell, Thanks for your patch. You sent it almost to the correct place. Wine devel is for discussion, while wine-patches is the mailing list for patches. In addition you are able to follow the status of your patches on http://source.winehq.org/patches/. Thanks, Roderick On Fri, Jan 30, 2015 at 11:27 AM, Martell Malone <martellmalone(a)gmail.com> wrote: > Hi, > > I hope this is the right place to send this > Jacek asked me to send d3d11 patches to wine and not mingw-w64 first. > > More will come so if this is the wrong place please correct me :) > > Kind Regards > Martell > > > >

Jan. 31, 2015

Re: How WINE implements BitBlt function?

by Stefan Dösinger

Am 31.01.2015 um 08:11 schrieb John Found <johnfound(a)asm32.info>: > So, the question: How in WINE is implemented BitBlt function in order to have so high performance and so low CPU load? We use the X render extension. See dlls/winex11.drv/xrender.c. (I am not an expert on the GDI parts of Wine, so no guarantee for correctness of this information. I haven't followed the full path from gdi's BitBlt to the final X11 call)

Jan. 31, 2015

How WINE implements BitBlt function?

by John Found

This question arouse when I have made some tests in assembly language. I have wrote a program that to allocate some memory bitmap, fill it with some image and then draw it on a window. The in-memory processing is pretty fast so the main time consuming operation is the drawing of the bitmap on the window. The code is the same for the Windows and Linux version of the program and only the code that draws the bitmap on the window differs. In the Windows version it uses DIB and BitBlt function and in the Linux version it uses XImage bitmap and XPutImage function from XLib. I expected to have some similar performance of both programs, but was surprised, that in WINE, the Windows version performs approximately by 50% faster (150fps) than the Linux version (90..100fps) and the Linux version loads the CPU much higher than the Windows one. So, the question: How in WINE is implemented BitBlt function in order to have so high performance and so low CPU load? -- John Found <johnfound(a)asm32.info>

Jan. 31, 2015

D3d11 CreateDeviceAndSwapChain

by Martell Malone

Hi, I hope this is the right place to send this Jacek asked me to send d3d11 patches to wine and not mingw-w64 first. More will come so if this is the wrong place please correct me :) Kind Regards Martell

Jan. 30, 2015

Re: [2/3] mciqtz32: "status mode" returns resource strings.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=11379 Your paranoid android. === wxppro (32 bit mci) === mci.c:1287: Test failed: mci capability device type returned MCIERR_DEVICE_LOCKED

Jan. 30, 2015

Re: ieframe:add app: protocol support to make mshtml triggerBeforeNavigate2 event when handle app: hyperlink

by Jacek Caban

Hi Changhui, No, there is no such thing as app protocol handler on Windows and we shouldn't have one. This means that loading will (correctly) fail for this protocol, but BeforeNavigate2 should happen before it has a chance to fail. To support that, we have our own onclick handler for anchor elements, where we initiate loading. See HTMLAnchorElement_handle_event in htmlanchor.c. I tried your test app and it works find for me with recent Wine. Are you testing it against current Git? Jacek On 01/30/15 09:53, Changhui Liu wrote: > Hi Jacek: > I found that the real reason is urlmon!get_protocol_cf return > MK_E_SYNTAX(0x800401e4) when it open this registry > key “HKEY_CLASSES_ROOT\PROTOCOLS\Handler\app” failed. > Do you think the right way is implement a new 'app:' protocol handle > like "HKEY_CLASSES_ROOT\PROTOCOLS\Handler\http"? > > Thank you! > > > > > ------------------ > Regards, > Changhui. > > > > ------------------ Original ------------------ > *From: * "Jacek Caban"<jacek(a)codeweavers.com>; > *Date: * Thu, Jan 15, 2015 05:55 PM > *To: * "wine-devel"<wine-devel(a)winehq.org>; > *Subject: * Re: ieframe:add app: protocol support to make mshtml > triggerBeforeNavigate2 event when handle app: hyperlink > > Hi Changhui, > > On 01/15/15 02:39, Changhui Liu wrote: >> Hi, this verify test need the user click the app: hyperlink in browser, >> so it is hard to write a test in dlls/ieframe/tests. >> >> I upload the test html file and a test exe here: >> http://www.imakevideo.com/app.html >> http://www.imakevideo.com/mfc_web.zip >> >> To run the test, extract mfc_web.zip, then run the mfc_web.exe, click >> the Go button; >> A message "BeforeNavigate2 app:xxx" will popup when click the >> app: hyperlink >> if the BeforeNavigate2 event was triggered as like IE in windows, or >> nothing. > > It doesn't seem right. There is nothing special about app: protocol > handling, BeforeNavigate2 should be called in this case the same way > as for any other protocol. You need to find the real reason why it's > not called instead of calling it in an error case. The bug is likely > to be in mshtml. > > Jacek

Jan. 30, 2015

Re: League of Legends shop in game fix

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While the patch style hints are right, the more fundamental issue is that this patch is a game-specific hack that happens to work by chance rather than fix the real issue. As such it isn't acceptable to Wine. The proper fix is to move memory allocation into the container. This is not a simple task though. Am 2015-01-30 um 00:45 schrieb Alex Henrie: > You'll also need to use `git format-patch` to generate your diffs, > and `git send-email` so that your mail client doesn't add extra > line breaks like it did, and linking to the bug report that this > patch is supposed to fix is always a good idea. Also, Alexandre is > going to expect you to include some new, relevant unit tests in the > patch. > > -Alex > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUy07rAAoJEN0/YqbEcdMwYRgQAIDIs9tbI6fI1JF4KuqyhwoJ nXlM+DVBSMSn2xsbPLXFY8y5slwzRdlkoFOf7mZJWKbJ8F6jlDSkFlZuksqGQFbb o/ROcMGEPgEeOKD3MpVqdDP9DXwulrw16PkZIN1bCidBUZC1bhwRpaqfS2YR849p kh3Dtghg4QiJuotvsQecVQTaJP+QLyFHHOnqSJ4LnoGqHzQ5vG52orNy4AYzjhuc zFXoP7uhLW09q/QeYf1uajYpzu/O6IHPpEuVghaOegMJHawo5uDorWAVMMJLoo0G vTewO60d4BcCQk0eaYp5jDoVSt+TwJT54Rk8sddCdxeh4G6W+BFWCpRjrrWH46vW /7ZFZeBgVFNlR4/gtCejOSKRQm3sRUCNIVMg0RrN7Yd76WDPG0FtNvqVHX2JZaNH pQGKf9pXVsyxgOW/oj/FtsrF/rINhIchLcjO6Gtj9vxCJCiQ4l72f5wrjn/v72tC wQ7yxw14FjlFFl8JEiU3VEhOS1YjMwxVaK/D0vSiZKnmCF8RmTQZ3und0D22shbC mMtOzeRq20PWrxspJ9G274Trc0n34sKfAcn180rUEyjwoO8ZUUjYfvG74iv5RbPl XNQtlbht6uT5bJTEARtViCK4nxa1FEsS+Tt5hT1cXCI8L8S6AUop9B10m4QkZYAX gWFDAeroxDP0clx2hlDB =zU9Z -----END PGP SIGNATURE-----

Jan. 30, 2015

Re: ieframe:add app: protocol support to make mshtml triggerBeforeNavigate2 event when handle app: hyperlink

by Changhui Liu

Hi Jacek: I found that the real reason is urlmon!get_protocol_cf return MK_E_SYNTAX(0x800401e4) when it open this registry key “HKEY_CLASSES_ROOT\PROTOCOLS\Handler\app” failed. Do you think the right way is implement a new 'app:' protocol handle like "HKEY_CLASSES_ROOT\PROTOCOLS\Handler\http"? Thank you! ------------------ Regards, Changhui. ------------------ Original ------------------ From: "Jacek Caban"<jacek(a)codeweavers.com>; Date: Thu, Jan 15, 2015 05:55 PM To: "wine-devel"<wine-devel(a)winehq.org>; Subject: Re: ieframe:add app: protocol support to make mshtml triggerBeforeNavigate2 event when handle app: hyperlink Hi Changhui, On 01/15/15 02:39, Changhui Liu wrote: Hi, this verify test need the user click the app: hyperlink in browser, so it is hard to write a test in dlls/ieframe/tests. I upload the test html file and a test exe here: http://www.imakevideo.com/app.html http://www.imakevideo.com/mfc_web.zip To run the test, extract mfc_web.zip, then run the mfc_web.exe, click the Go button; A message "BeforeNavigate2 app:xxx" will popup when click the app: hyperlink if the BeforeNavigate2 event was triggered as like IE in windows, or nothing. It doesn't seem right. There is nothing special about app: protocol handling, BeforeNavigate2 should be called in this case the same way as for any other protocol. You need to find the real reason why it's not called instead of calling it in an error case. The bug is likely to be in mshtml. Jacek

Jan. 30, 2015

Re: [PATCH] winemac.drv: Always initialize a closure-captured object pointer.

by Ken Thomases

On Jan 29, 2015, at 5:23 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: > You might argue that we don't need to do this because we only use it on > the control paths where we initialize it. Ah, but it *is* used on one of > the other paths: it is captured by the Block closure whether or not we > actually use it inside the Block. This means that, when we copy the > Block onto the heap in OnMainThreadAsync(), the runtime will attempt to > retain it. For some reason, we got away with this in 32-bit > land--probably because the pointer happened to be NULL anyway--but it > broke and died horribly on 64-bit. > > With this change, 64-bit winemac.drv is actually usable. Nice. I was aware of the warning but assumed that it was benign. I'm not sure it's a coincidence that it worked in 32-bit. I don't think that dispatch objects are actually automatically retained by blocks which reference them in 32-bit. It's not entirely related, but it's relatively recent that ARC started doing that and, of course, that requires the modern Objective-C runtime and thus 64-bit. Anyway, I'm glad the Mac driver crashiness in the 64-bit build stemmed from a single cause. I'm sure it wasn't fun to find it. Thanks for doing so. -Ken

Jan. 30, 2015

Re: League of Legends shop in game fix

by Alex Henrie

You'll also need to use `git format-patch` to generate your diffs, and `git send-email` so that your mail client doesn't add extra line breaks like it did, and linking to the bug report that this patch is supposed to fix is always a good idea. Also, Alexandre is going to expect you to include some new, relevant unit tests in the patch. -Alex

Jan. 29, 2015

Re: League of Legends shop in game fix

by Austin English

On Thu, Jan 29, 2015 at 9:19 AM, Monster <manuiglesias96(a)yahoo.es> wrote: > @@ -220,7 +220,10 @@ BOOL wined3d_resource_allocate_sysmem(struct > wined3d_resource *resource) > SIZE_T align = RESOURCE_ALIGNMENT - 1 + sizeof(*p); > void *mem; > - if (!(mem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > resource->size + align))) > + UINT size = resource->size; > + if (resource->width <= 128 && resource->height <= 128) > + size *= 2; > + if (!(mem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size + > align))) > return FALSE; > p = (void **)(((ULONG_PTR)mem + align) & ~(RESOURCE_ALIGNMENT - 1)) - 1; > > > > Please use your real name when sending patches. -- -Austin

Jan. 29, 2015

Re: msvcrt: Bump MSVCRT_MB_LEN_MAX to 6 and use it in MSVCRT__wctomb_l for default buffer length

by Piotr Caban

On 01/28/15 00:25, Orion Poplawski wrote: > Looks like things are a bit version dependent - It appears that is is 2 for > Visual Studio .NET 2003, and 5 for later versions: > > https://msdn.microsoft.com/en-us/library/296az74e%28v=vs.71%29.aspx I'm not sure what should be done in this case. I would go with changing it to 5 in all headers so applications can use it to allocate buffers. 5 is big enough to handle all codepages in wine. > Not sure if I should be producing an updated patch, or if the wine devs can > take it from here. It's your patch. It's best if you send it yourself. Thanks, Piotr

Jan. 29, 2015

Re: [PATCH 1/2] kernel32/tests: Make loader tests independent from each other

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> So why should I leave it as it is? > > There is no actual reason to touch it, and these purely cosmetic changes > > create conflicts with the tests I have in local tree. > > > Well, local merge problems can't be a reason to block cleanups like that. Since that's my code I'd prefer to keep it that way. -- Dmitry.

Jan. 28, 2015

Re: [PATCH 1/2] kernel32/tests: Make loader tests independent from each other

by Nikolay Sivov

On 28.01.2015 18:39, Dmitry Timoshkov wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >>> There are various reasons of the current tests structure, if you are not >>> planning to add new tests please leave the code as it is please. >>> >> Are you going to name those reasons? > I don't think it's really important unless you are going to add new tests. That's how I saw they depend on each other, when I tried to add some more. > >> Currently some tests depend on >> values set by previous tests. >> That's clearly a broken behavior. test_import_resolution() does it right >> already by the way. >> >> So why should I leave it as it is? > There is no actual reason to touch it, and these purely cosmetic changes > create conflicts with the tests I have in local tree. > Well, local merge problems can't be a reason to block cleanups like that.

Jan. 28, 2015

Re: [PATCH 1/2] kernel32/tests: Make loader tests independent from each other

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > > There are various reasons of the current tests structure, if you are not > > planning to add new tests please leave the code as it is please. > > > Are you going to name those reasons? I don't think it's really important unless you are going to add new tests. > Currently some tests depend on > values set by previous tests. > That's clearly a broken behavior. test_import_resolution() does it right > already by the way. > > So why should I leave it as it is? There is no actual reason to touch it, and these purely cosmetic changes create conflicts with the tests I have in local tree. -- Dmitry.

Jan. 28, 2015

Re: [PATCH 1/2] kernel32/tests: Make loader tests independent from each other

by Nikolay Sivov

On 28.01.2015 18:20, Dmitry Timoshkov wrote: >> +const static IMAGE_NT_HEADERS nt_header_template = > 'static const' is a commonly accepted order. > > There are various reasons of the current tests structure, if you are not > planning to add new tests please leave the code as it is please. > Are you going to name those reasons? Currently some tests depend on values set by previous tests. That's clearly a broken behavior. test_import_resolution() does it right already by the way. So why should I leave it as it is?

Jan. 28, 2015

Re: [PATCH 1/2] kernel32/tests: Make loader tests independent from each other

by Dmitry Timoshkov

> +const static IMAGE_NT_HEADERS nt_header_template = 'static const' is a commonly accepted order. There are various reasons of the current tests structure, if you are not planning to add new tests please leave the code as it is please. -- Dmitry.

Jan. 28, 2015

Re: mshtml: Added support for _self target in IHTMLWindow2::open.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=11354 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

Jan. 28, 2015

Re: msvcrt: Fix inconsistent rounding behaviour for sprintf and add tests.

by YongHao Hu

Thank you for your review and advice. I will try to improve it. :) By the way, I will send another independent patch to msvcp tests. On 2015年01月27日 19:02, Piotr Caban wrote: > This is not correct, val may loose to much precision. Also temp can > become INF (in your patch temp is int but I guess it's a mistake). I'm > afraid that in order to fix this bug you'll need to stop using glibcs > sprintf in wine's printf implementation. > > Your patch to msvcp tests depends on this patch. Please send patches > that depend on each other in series.

Jan. 28, 2015

Re: msvcrt: Bump MSVCRT_MB_LEN_MAX to 6 and use it in MSVCRT__wctomb_l for default buffer length

by Orion Poplawski

On 01/26/2015 06:10 AM, Piotr Caban wrote: > On 01/23/15 18:38, Orion Poplawski wrote: >> diff --git a/dlls/msvcrt/msvcrt.h b/dlls/msvcrt/msvcrt.h >> index 41f31b9..401628a 100644 >> --- a/dlls/msvcrt/msvcrt.h >> +++ b/dlls/msvcrt/msvcrt.h >> @@ -47,7 +47,7 @@ >> #define MSVCRT_I64_MAX (((__int64)0x7fffffff << 32) | 0xffffffff) >> #define MSVCRT_I64_MIN (-MSVCRT_I64_MAX-1) >> #define MSVCRT_UI64_MAX (((unsigned __int64)0xffffffff << 32) | 0xffffffff) >> -#define MSVCRT_MB_LEN_MAX 2 >> +#define MSVCRT_MB_LEN_MAX 6 > MB_LEN_MAX equals 5 on windows. It should probably be set to 5 here as well. > Probably include/msvcrt/limits.h should also be changed. > > Thanks, > Piotr Looks like things are a bit version dependent - It appears that is is 2 for Visual Studio .NET 2003, and 5 for later versions: https://msdn.microsoft.com/en-us/library/296az74e%28v=vs.71%29.aspx I have no idea how this intersects with wine's implementation though. Not sure if I should be producing an updated patch, or if the wine devs can take it from here. Thanks, Orion -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

Jan. 27, 2015

Re: [PATCH 3/3] winecfg: add speaker config controls to audio tab

by Andrew Eikum

I think you can squash the last two patches. No need to add symbols before they're used. Does it make sense to have a "system default" configuration as well? For example if the user changes which device ALSA's "default" points to from a 5.1 setup to a stereo setup, the "system default" setting should report the configurations correctly (or, as correctly as the backend allows, but you get the point). This might require storing the user-selected speaker configuration elsewhere in the registry, and updating the real registry entry on mmdevapi load. Couple notes below. On Mon, Jan 26, 2015 at 10:28:26PM +0000, Mark Harmstone wrote: > + info->speaker_config = 999; > + if(SUCCEEDED(hr) && pv.vt == VT_UI4){ > + i = 0; > + while (speaker_configs[i].text_id != 0 && info->speaker_config == 999) { > + if ((speaker_configs[i].speaker_mask & pv.u.ulVal) == speaker_configs[i].speaker_mask) > + info->speaker_config = i; > + i++; > + } > + } This is kind of awkward. Could be a for-loop and break early. > + > + /* fallback to stereo */ > + if(info->speaker_config == 999) > + info->speaker_config = 2; > + Yeah, I don't like 999 either. The "system default" would provide a reasonable fallback option here, too. > + IPropertyStore_Release(ps); > + > return TRUE; > + for (i = 0; i < num_render_devs; i++) { > + ERR("%s -> %u\n", wine_dbgstr_w(render_devs[i].id), speaker_configs[render_devs[i].speaker_config].speaker_mask); Looks like a debug line that should be removed or switched to TRACE. > + pv.u.ulVal = speaker_configs[render_devs[i].speaker_config].speaker_mask; > + WARN("speaker_config = %u\n", pv.u.ulVal); Another debug line? > + > + hr = IPropertyStore_SetValue(ps, &PKEY_AudioEndpoint_PhysicalSpeakers, &pv); > + > + if (FAILED(hr)) > + WARN("IPropertyStore_SetValue failed for %s: 0x%08x\n", wine_dbgstr_w(render_devs[i].id), hr); > + > + IPropertyStore_Commit(ps); This isn't actually implemented in mmdevapi, so we end up with noisy "stub" messages on the terminal. Best thing to do would be to fix the property store implementation, but in lieu of that, I'd just switch the FIXME in mmdevapi with a TRACE. Andrew

Jan. 27, 2015

Re: shell32: Handle TRASH_EnumItems failures correctly

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=11318 Your paranoid android. === wvistau64 (32 bit recyclebin) === recyclebin.c:98: Test failed: Expected recycle bin to have 0x8 bytes === wvistau64 (64 bit recyclebin) === recyclebin.c:98: Test failed: Expected recycle bin to have 0x8 bytes

Jan. 27, 2015

Re: msvcrt: Fix inconsistent rounding behaviour for sprintf and add tests.

by Piotr Caban

On 01/26/15 12:29, YongHao Hu wrote: > + if(flags.Precision >= 0 && toupper(flags.Format)!='G') { > + temp = pow(10, flags.Precision); > + val = round(val * temp) / temp; > + } This is not correct, val may loose to much precision. Also temp can become INF (in your patch temp is int but I guess it's a mistake). I'm afraid that in order to fix this bug you'll need to stop using glibcs sprintf in wine's printf implementation. Your patch to msvcp tests depends on this patch. Please send patches that depend on each other in series. Thanks, Piotr

Jan. 27, 2015

Re: [PATCH 3/3] winecfg: add speaker config controls to audio tab

by André Hentschel

Hi, first, this should be merged with patch 2. (atomic changes) Am 26.01.2015 um 23:28 schrieb Mark Harmstone: > - IPropertyStore_Release(ps); > if(FAILED(hr)){ > CoTaskMemFree(info->id); > info->id = NULL; > + IPropertyStore_Release(ps); > return FALSE; > } This looks like a independent atomic fix... > + hr = IPropertyStore_GetValue(ps, > + &PKEY_AudioEndpoint_PhysicalSpeakers, &pv); > + > + info->speaker_config = 999; > + if(SUCCEEDED(hr) && pv.vt == VT_UI4){ minor whitespace issue(s) and seen some more whitespace issues, no need to keep consistent with existing code here i'd say > + > + /* fallback to stereo */ > + if(info->speaker_config == 999) my thoughts on this: not sure, maybe -1 is better, or ~0. maybe it should be unsigned... I hope my thoughts help anyway

Jan. 26, 2015

Re: [PATCH 2/2] mshtml: Report about protocol as UI resource.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/mshtml/nsio.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) This is apparently causing the script.c test to hang here. -- Alexandre Julliard julliard(a)winehq.org

Jan. 26, 2015