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

Re: d3dx9_36: add D3DXDisassembleShader stub (try 2)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-05 um 09:56 schrieb Dmitry Timoshkov: >> LPCSTR -> const char * > > That's how it's supposed to look like - LPCSTR, not const char *. > This is a public API, not an internal helper. https://www.winehq.org/pipermail/wine-devel/2010-June/084460.html > Then the header should be fixed instead: > https://msdn.microsoft.com/ru-ru/library/windows/desktop/bb172820%28v=vs.85… Well, no, it is a good place where the header can be visually different from Microsoft's and still be compatible. Unless you consider something like #define LPCSTR float #include <d3d11.h> an appropriate use of those types. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU0zbQAAoJEN0/YqbEcdMwYzcP/3Kw8OLVDqNqVsBaOjKvl8jG 8flFB9PaM0gC7aXHjbO4kZhruzZTK2tk/VFCYsGARMoVnIKmug7NDEkowVC+FClQ F0bZG0zKdSAVAXtlfqKJX0qBIpOU7plumeSxE4i+hyG1OLBatDw+PcQOQJxbmmyU rud/9/XMD4qqtNTDhTIU6/S34xWWf0trnRSLB3LnnHVOoJBpmKEBirwlO3k5lMuS RAPn5fzyrKY1OgGkFlitQQUmuTwG82BAFrIwJ3+ZVWUwGOnuEHDEna+zkXf6StIr xrmJDgB2vpq2tjvWAvnJdng/ToWDY3tMsyU4k7E8MSVbhKOdHINgxAAAQu8Cv5x8 s9TP0/edmYhA9iXbrQBNbnl1UCiTnOfFhNelIyXC7E0u2AIlnvhch7zcPlg514B0 druV/1o6dfF/zUIfYL21GDgW1U3+NeI3Se+3W4LfwFL0X/YYHxa+u8NO/+Eu2ZwN ALb7g4goOjTmnkGMyyn2Wi4x2QaU3z9lZu61dCNEHftKvg0kWi4TmC89gEsadVDZ OSQdgLxz667lfSjdUXjFBlgBjz25RvyjePq5K4ti3wn1luezoC5QOjGIhFn1RhpL 3xeCECTOMgGaeM+WR0mVsh3adXKLE58kwSUJ+oBP6+iXajfzyWg0aid+uSEnLOL3 05YAl1yuybQYCoJKB6Oy =rnt9 -----END PGP SIGNATURE-----

Feb. 5, 2015

Re: How WINE implements BitBlt function?

by John Found

On Wed, 04 Feb 2015 12:24:30 +0200 Shachar Shemesh <shachar(a)shemesh.biz> wrote: > > > On 31/01/2015 12:19, Stefan Dösinger wrote: > > > 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) > > Perhaps using XSHM for such things would be better (at least when the X > server is local, which is almost always the case). > > Shachar > I never heard about XSHM, but it sounds really interesting. Unfortunately Google gives some very sketchy references about it. Is there more informative documentation about XSHM? -- John Found <johnfound(a)asm32.info>

Feb. 5, 2015

Re: d3dx9_36: add D3DXDisassembleShader stub (try 2)

by Dmitry Timoshkov

Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Am 2015-02-05 um 05:14 schrieb Austin English: > > +HRESULT WINAPI D3DXDisassembleShader(const DWORD *shader, BOOL > > colorcode, LPCSTR comments, LPD3DXBUFFER *disassembly) > Please no LPCRAP: > > LPCSTR -> const char * That's how it's supposed to look like - LPCSTR, not const char *. This is a public API, not an internal helper. > LPD3DXBUFFER * -> ID3DXBuffer ** > > It is even written this way in our header. Then the header should be fixed instead: https://msdn.microsoft.com/ru-ru/library/windows/desktop/bb172820%28v=vs.85… -- Dmitry.

Feb. 5, 2015

Re: d3dx9_36: add D3DXDisassembleShader stub (try 2)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-05 um 05:14 schrieb Austin English: > +HRESULT WINAPI D3DXDisassembleShader(const DWORD *shader, BOOL > colorcode, LPCSTR comments, LPD3DXBUFFER *disassembly) Please no LPCRAP: LPCSTR -> const char * LPD3DXBUFFER * -> ID3DXBuffer ** It is even written this way in our header. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU0yySAAoJEN0/YqbEcdMwXNsP/RgpIfaoj7Xhc0QXmCfH4Idh 9A9ohj99ZYAgK4QRaxXwNU9Uoys4TpJVxTDZ31C8WgnSosY+RUPt5hHx64Qe7LY+ wCwDC4wGJGZGVdPmlmTdahhQi9G8BauTs9uHcVvMZThllgfhgGHPOjn90muzcSyx PcXd2cOVnzJwaUNmJ7BrFt1luzqdRUW+v0xu31a8wsFFeIMQGA99DEeDu2ZOiu6/ UWArtccpb0QrDP/A4C5+YAuMcQHeQvWbGMrsCnrm3DBCJN46AIlLcQzw73Leq17Q aY3g6uct8SpCXD8p+KNXfe6FU/qe52QFHjI6yVS9FgjYuHwkjUuIH2CN4au7Dq22 WMt9NZI/fys+MZ5ThKmd6W10kMUpbcHHQxWbDf2zbzaGOxWX+vULNVQhMoCppCF6 0PsYhz+A5HadKgbkk28bhoIVDLefEevw/ov4X1veXEwO/0Xyb/YeLF5XiykM2LQG q6cIAik1kpawJ+YIZYILSZUjgxFmR2q5UF+qotucNdQhbNwfai0MdMMxFZMtxeUD OWwEpILVCp8JLPnTaXYt7D231TPsvLdh0hWMUy6Sk0pOsi8wVf5tO21UO3UT9Vas 7GDaW04KyzKBfD6ArONETOKHGYeozvghmPCmTrA/c8JZ69JBCuA+qk4KdjJ4RvKB rTs9Aao9URRAA9Q4PBM/ =c5KR -----END PGP SIGNATURE-----

Feb. 5, 2015

Re: d3dx9_36: add a stub for D3DXDisassembleShader

by Austin English

On Wed, Feb 4, 2015 at 10:02 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Austin English <austinenglish(a)gmail.com> wrote: > > > +@ stdcall D3DXDisassembleShader(ptr long ptr ptr) > ... > > +HRESULT WINAPI D3DXDisassembleShader(const DWORD *shader, BOOL > colorcode, LPCSTR comments, LPD3DXBUFFER *disassembly) > > LPCSTR -> spec -> str > > -- > Dmitry. > Thanks, will resend. -- -Austin

Feb. 5, 2015

Re: d3dx9_36: add a stub for D3DXDisassembleShader

by Dmitry Timoshkov

Austin English <austinenglish(a)gmail.com> wrote: > +@ stdcall D3DXDisassembleShader(ptr long ptr ptr) ... > +HRESULT WINAPI D3DXDisassembleShader(const DWORD *shader, BOOL colorcode, LPCSTR comments, LPD3DXBUFFER *disassembly) LPCSTR -> spec -> str -- Dmitry.

Feb. 5, 2015

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

by Changhui Liu

Hi Jacek: I found that mshtml will not fire BeforeNavigate event if the app: protocol hyper link is in a frame window, like this page http://www.imakevideo.com/app2.html I attached a patch solved this situation, do you think is it right? The test app is here: http://www.imakevideo.com/mfc_web.zip Thank you. ------------------ Regards, Changhui. ------------------ Original ------------------ From: "Jacek Caban"<jacek(a)codeweavers.com>; Date: Fri, Jan 30, 2015 08:24 PM To: "Changhui Liu"<liuchanghui(a)linuxdeepin.com>; "wine-devel"<wine-devel(a)winehq.org>; Subject: Re: ieframe:add app: protocol support to make mshtml triggerBeforeNavigate2event when handle app: hyperlink 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

Feb. 5, 2015

Re: jscript: Don't use builtin property for exposing Boolean constructor.

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=11427 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

Feb. 4, 2015

Re: [PATCH 3/3] dwrite/tests: Fix couple of leaks when creating test font instance (resent)

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=11425 Your paranoid android. === build (build) === Patch failed to apply

Feb. 4, 2015

Re: [PATCH 1/3] dwrite: No need for return value in collection_find_family()

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -1424,11 +1424,14 @@ static HRESULT WINAPI dwritefontcollection_GetFontFamily(IDWriteFontCollection * > return create_fontfamily(This->family_data[index], iface, family); > } > > -static HRESULT collection_find_family(struct dwrite_fontcollection *collection, const WCHAR *name, UINT32 *index, BOOL *exists) > +static void collection_find_family(struct dwrite_fontcollection *collection, const WCHAR *name, UINT32 *index, BOOL *exists) Returning the index instead would probably make the code cleaner. -- Alexandre Julliard julliard(a)winehq.org

Feb. 4, 2015