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