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

Re: [PATCH 1/2] ntdll: Support 64-bit Mac OS.

by Alexandre Julliard

Charles Davis <cdavis5x(a)gmail.com> writes: > diff --git a/dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec > index 51de6e7..acd0271 100644 > --- a/dlls/ntdll/ntdll.spec > +++ b/dlls/ntdll/ntdll.spec > @@ -1429,6 +1429,7 @@ > > # signal handling > @ cdecl __wine_set_signal_handler(long ptr) > +@ cdecl -arch=x86_64 __wine_current_teb() That's not better than exporting NtCurrentTeb. -- Alexandre Julliard julliard(a)winehq.org

Feb. 3, 2015

Re: [2/2] kernel32: force 4096 byte page alignment.

by Tijl Coosemans

On Mon, 02 Feb 2015 22:20:57 +0200 David Naylor <dbn(a)freebsd.org> wrote: > FreeBSD prefers to use a 0x200000 (super) page alignment however this causes > the image base to be displaced from the requested 0x7b800000. Forcing a > smaller page size ensures FreeBSD can place the image starting at 0x7b800000. Just to clarify, the output of "readelf -l kernel32.dll.so" gives this: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x7b800000 0x7b800000 0x0c9e74 0x0c9e74 R E 0x200000 LOAD 0x0ca000 0x7baca000 0x7baca000 0x1a7eb0 0x1a8550 RW 0x200000 The segments have an alignment of 0x200000 bytes. This places the first segment at 0x7b800000 and the second at 0x7ba00000+Offset. With a MemSiz of 0x1a8550 this pushes the second segment over 0x7bc00000 where ntdll has been mapped already so loading kernel32 at 0x7b800000 fails. The patch forces a smaller alignment so the second segment fits below 0x7bc00000.

Feb. 3, 2015

Re: Add d3d11_CreateDeviceAndSwapChain

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-02 um 20:24 schrieb Martell Malone: > + FIXME("stub: adapter %p, driver_type %s, swrast %p, flags > %#x, feature_levels %p, levels %#x, sdk_version %d, " You're still printing sdk_version as a signed value. Please use %u instead of %d. Otherwise this looks good to me. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU0IM3AAoJEN0/YqbEcdMw5v8P/3A5kt9fIPCVCTgXfM0A6uKS 8cCXPITuKmeub7obw7EiEhsQH/4pw80bKOhmFKZvpK0knrKeU7wZvojbP18n39j1 vVqpqvtzbkfsBwLZ/Z0AeC/evVACfMmw1Al3BMBTDhxFb+uv+rVI9spG06XRPx8P e3pWlzoGniaZG8YP6TguA0gfrcMcGWEOWT59nstWW0HXlMFdsE1OoMM5Wd+XrpB+ AuEHGNFiHacgNxVfpnk6wQw5TK2uXW79ZbjX2wnrDiXkYvUZBts34Xo5cTdXNMXp DugbwLQtoC3Yu4rHxymjZTNbJLDY0bAOgBo4YwMCVnfLj7zbwvNABqtEIKtVs5Mx XsovTKzLD5sPmWnCxMtC5Qmz/aQebOYWF9bB3vYju876h69J5aJt4OjGU0HfLd4g 26uQEWgT+UbU0Lavofn3w9jcO4qEBl3NbmTs4egsw8n5Ry5f+N58BX1OdaOSdkmy a3Io6NgV48I/FjbxdlqpMz10I+06VlWiMdlmQSKxWTN1t5AxTm8/dTHLMC4+D7nn FOeWvOr3Wy4ocBWoOpT94etIBxut8IMfSHzEKsoll7kib3daYVDPv97pAbKdV3fT tZhzhWif+sqneVpk9QnCqhd9v9Kd29axqTBy7JiZ9t8TYxFTrXu50ZgC5oX/zKBV 4jVGoA2kY+Gtv9KR6SH0 =R0+9 -----END PGP SIGNATURE-----

Feb. 3, 2015

Re: [1/2] loader: FreeBSD requires pre_exec() on x86_64

by David Naylor

On Monday, 2 February 2015 22:22:24 André Hentschel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 02.02.2015 um 21:20 schrieb David Naylor: > > Just as with i386, FreeBSD requires the maximum size of the data segment > > to be extended on x86_64 for Wine to work correctly. > > --- > > > > loader/main.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/loader/main.c b/loader/main.c > > index ac67290..bb4f949 100644 > > --- a/loader/main.c > > +++ b/loader/main.c > > @@ -181,7 +181,7 @@ static int pre_exec(void) > > > > return 1; /* we have a preloader on x86-64 */ > > > > } > > > > -#elif (defined(__FreeBSD__) || defined (__FreeBSD_kernel__) || > > defined(__DragonFly__)) && defined(__i386__) +#elif (defined(__FreeBSD__) > > || defined (__FreeBSD_kernel__) || defined(__DragonFly__)) && > > (defined(__i386__) || defined(__x86_64__))> > > static int pre_exec(void) > > { > > This is already fixed for a while, see: > > https://www.winehq.org/wwn/383#Wine64%20on%20FreeBSD > -> https://bugs.winehq.org/show_bug.cgi?id=34330 > -> > https://source.winehq.org/git/wine.git/blobdiff/036670810c7e8bf55a5ee0e71e3 > 2fa4a097dac02..4b708fc325753f1bb1c8210bb67757ebbf9f60dd:/loader/main.c Excellent, sorry I missed this (I tried to do a git pull last night but it was getting stuck - and I was basing my work on Wine 1.7.33). Thank you for fixing this. I worked on part 2 of this patch with Tijl to get Wine running on FreeBSD. With that patch applied we were able to successfully test a 64-bit version of 7Zip. Regards

Feb. 3, 2015

Re: [2/2] Directx 11.2 idl's d3d11_2.idl

by Martell Malone

Apologies this was meant for wine-patches. Can an admin delete this thread. Thank you On Tue, Feb 3, 2015 at 3:45 AM, Martell Malone <martellmalone(a)gmail.com> wrote: > The second idl needed for dx11.2 function and structure compliance. > > Please review :) >

Feb. 3, 2015

[2/2] Directx 11.2 idl's d3d11_2.idl

by Martell Malone

The second idl needed for dx11.2 function and structure compliance. Please review :)

Feb. 3, 2015

Re: [1/2] loader: FreeBSD requires pre_exec() on x86_64

by André Hentschel

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 02.02.2015 um 21:20 schrieb David Naylor: > Just as with i386, FreeBSD requires the maximum size of the data segment to be > extended on x86_64 for Wine to work correctly. > --- > loader/main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/loader/main.c b/loader/main.c > index ac67290..bb4f949 100644 > --- a/loader/main.c > +++ b/loader/main.c > @@ -181,7 +181,7 @@ static int pre_exec(void) > return 1; /* we have a preloader on x86-64 */ > } > > -#elif (defined(__FreeBSD__) || defined (__FreeBSD_kernel__) || defined(__DragonFly__)) && defined(__i386__) > +#elif (defined(__FreeBSD__) || defined (__FreeBSD_kernel__) || defined(__DragonFly__)) && (defined(__i386__) || defined(__x86_64__)) > > static int pre_exec(void) > { > > > > This is already fixed for a while, see: https://www.winehq.org/wwn/383#Wine64%20on%20FreeBSD -> https://bugs.winehq.org/show_bug.cgi?id=34330 -> https://source.winehq.org/git/wine.git/blobdiff/036670810c7e8bf55a5ee0e71e3… -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBAgAGBQJUz+qIAAoJEGm5GZTakYssKKEL/1kc5U/Um4TIfoIWFCZZoenL XhlZwjyJ90hJDicOZAHCKZxIcpu5J0fld52FIB5JunJZGSVcIXtcwmp1OwiA1BT4 5QPGR1WJ2bL4MU2lWw6+IEFZoL92Z7EsFkKjEM5l+u0l/APXp/5pq7Tj61qYvyoI HWhgauD7oWSK9PThWVdT7KiLmWFMLL5Rt3wB4coVExOhNah2jfGsJUDQUW08fX6B wKIB2r+O0h7xaR+zjnZSdB8iBqSTuCasUcaq0YcT8NccPQedlKJswnVu809Ygdg4 5PDn89Y1MGbSBIlcM8PjRtQrfU7bWLqOXmbY5bpaJbRbABz39UryrW0RleDTWC/G 8sJ3jtF7sO3YILQeFaaLUc0lyD64uGnwEoeGTJjB6n4khSVG5ZCsbn+twU6TwlT4 JYRfCNLgAv/fr9LnoI54HmBuyOscpP/1k9UO/6w2mQvugLe5k6TBQoiUMkk5le93 TbyOop4cFqHXR6DPfaIRuJ1czdrqVrZ1kZySKXubSg== =gd3v -----END PGP SIGNATURE-----

Feb. 2, 2015

Fwd: Add d3d11_CreateDeviceAndSwapChain

by Martell Malone

This is the explanation for the d3d11 patch I submitted to wine-patches. Stefan said Henri might have an interest so I should post the explanation here Comments are welcome :) ---------- Forwarded message ---------- From: Martell Malone <martellmalone(a)gmail.com> Date: Mon, Feb 2, 2015 at 7:12 PM Subject: Re: Add d3d11_CreateDeviceAndSwapChain To: Stefan Dösinger <stefandoesinger(a)gmail.com> Whoops that sent without my comments In the d3d code we use use 8 byte extran indentation for continued lines: > > void function() > { > <4> FIXME("bla long text bla\n", > <4> <8> param1, param2); > } > I have sent an updated patch to reflect this. I'm curious, does this improve the behavior of some application? E.g. game > X now falls back to d3d9 without crashing due to the stub? > My main focus for writing this was for the mingw-w64 project that imports the headers and libs from wine. We were just casually missing 1 of the 3 most important functions so I sent in this patch :) There are 2 ways to create a device and swapchain however. You can do them seperatly or this function does them both at once. I assume that this returns the correct error like CreateDevice so that if the application has a fallback it can use it. So thats highly possible. Kind Regards Martell On Mon, Feb 2, 2015 at 7:06 PM, Martell Malone <martellmalone(a)gmail.com> wrote: > Hi Stefan, > > On Mon, Feb 2, 2015 at 6:33 PM, Stefan Dösinger <stefandoesinger(a)gmail.com > > wrote: > >> Hi, >> >> I'm curious, does this improve the behavior of some application? E.g. >> game X now falls back to d3d9 without crashing due to the stub? >> >> > +HRESULT WINAPI D3D11CreateDeviceAndSwapChain(IDXGIAdapter *adapter, >> D3D_DRIVER_TYPE driver, HMODULE swrast, UINT flags, >> > + const D3D_FEATURE_LEVEL >> *feature_levels, UINT levels, UINT sdk_version, >> > + const >> DXGI_SWAP_CHAIN_DESC *swapchain_desc, IDXGISwapChain ** swapchain, >> > + ID3D11Device **device, >> D3D_FEATURE_LEVEL *feature_level, ID3D11DeviceContext **context) >> > +{ >> > + FIXME("stub: adapter %p, driver_type %s, swrast %p, flags %#x, >> feature_levels %p, levels %#x, sdk_version %d, " >> > + "swapchain_desc %p, swapchain %p, device %p, feature_level >> %p, context %p\n", adapter, debug_d3d_driver_type(driver_type), swrast, >> > + flags, feature_levels, levels, sdk_version, swapchain_desc, >> swapchain, device, feature_level, context); >> > + return E_OUTOFMEMORY; >> sdk_version is an UINT, you need to print it with %u. >> >> In the d3d code we use use 8 byte extran indentation for continued lines: >> >> void function() >> { >> <4> FIXME("bla long text bla\n", >> <4> <8> param1, param2); >> } >> >> Cheers, >> Stefan >> >> >

Feb. 2, 2015

Re: Add d3d11_CreateDeviceAndSwapChain

by Stefan Dösinger

Hi, I'm curious, does this improve the behavior of some application? E.g. game X now falls back to d3d9 without crashing due to the stub? > +HRESULT WINAPI D3D11CreateDeviceAndSwapChain(IDXGIAdapter *adapter, D3D_DRIVER_TYPE driver, HMODULE swrast, UINT flags, > + const D3D_FEATURE_LEVEL *feature_levels, UINT levels, UINT sdk_version, > + const DXGI_SWAP_CHAIN_DESC *swapchain_desc, IDXGISwapChain ** swapchain, > + ID3D11Device **device, D3D_FEATURE_LEVEL *feature_level, ID3D11DeviceContext **context) > +{ > + FIXME("stub: adapter %p, driver_type %s, swrast %p, flags %#x, feature_levels %p, levels %#x, sdk_version %d, " > + "swapchain_desc %p, swapchain %p, device %p, feature_level %p, context %p\n", adapter, debug_d3d_driver_type(driver_type), swrast, > + flags, feature_levels, levels, sdk_version, swapchain_desc, swapchain, device, feature_level, context); > + return E_OUTOFMEMORY; sdk_version is an UINT, you need to print it with %u. In the d3d code we use use 8 byte extran indentation for continued lines: void function() { <4> FIXME("bla long text bla\n", <4> <8> param1, param2); } Cheers, Stefan

Feb. 2, 2015

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

by Changhui Liu

Hi Jacek: The latest wine can call BeforeNavigate2event now. But on windows the BeforeNavigate2event can be called two times, the first is : "BeforeNavigate2:app:meihua ", the second is: "BeforeNavigate2:res://ieframe.dll/unknownprotocol.htm#app:meihua" I will try to add a handle as you advice. Thank you very much. ------------------ 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. 2, 2015