May 2024 - Wine-gitlab - list.winehq.org

Re: [PATCH v8 0/11] MR5444: jscript: Do not allocate dispex_prop_t for indexed props.
by Gabriel Ivăncescu 30 May '24

30 May '24

> Meantime, I noticed that we could prepare MSHTML for the change better by completing dispex refactoring (and document objects split), see https://gitlab.winehq.org/jacek/wine/-/commits/mshtml-dispex/ for a draft. Unfortunately, it needs a few more vtbl entries, but the unification seems worth to me. On top of that, you wouldn't need to have a dedicated new interface implementation for document node and the window variant should be easier as it could be just a forwarder. What do you think? Looks fine to me. I'm not a fan of all the new vtbl methods, but it's better than what we have currently, so it's fine. This will definitely simplify it, but at the same time, I still want to know if is there something wrong with this MR I should change? I'd like to get it moving, considering it doesn't have much to do with this, these changes would come later ofc. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5444#note_71791

1 0

Re: [PATCH v8 0/11] MR5444: jscript: Do not allocate dispex_prop_t for indexed props.
by Gabriel Ivăncescu 30 May '24

30 May '24

> The problem with `func_info_t` is that it carries information specific to the instance (like hooks), not only abstract things like the signature, so you can't just apply "current style" function info to "style" object without some additional refactoring. It's hard to comment in more details without the code. But this `func_info_t` (rather than IID) is used for storing/creating the function object itself (like create_builtin_function but for proxies), not tied to any object, and such function object contains all the "code" of the function not just the signature, so isn't that actually more correct, idiomatically at least? If this builtin mshtml function were to be implemented in pure jscript somehow, it would contain all its code there, including hooks and everything else. It doesn't feel that right to me to "look up" the function on a specific object when calling it in such case, which may end up with the wrong function if we're not careful. > I'm still hoping to see how the interface capable of handling prototype chains looks like. There are no interfaces added to deal with prototype chains, unless you mean the new method I added for `func_info_t`? It's basically like this: ```idl HRESULT BuiltinFuncCall([in] void *func_ctx, [in] BOOL setter, [in] DISPPARAMS *dp, [out, optional] VARIANT *ret, [out] EXCEPINFO *ei, [in] IServiceProvider *caller); ``` and then it's called here: ```c static HRESULT ProxyFunction_call(script_ctx_t *ctx, FunctionInstance *func, jsval_t vthis, unsigned flags, unsigned argc, jsval_t *argv, jsval_t *r, IServiceProvider *caller) { ProxyFunction *function = (ProxyFunction*)func; DISPPARAMS dp = { NULL, NULL, argc, 0 }; IWineJSDispatchHost *proxy_target; VARIANT buf[6], retv; EXCEPINFO ei = { 0 }; IDispatch *this_obj; jsdisp_t *jsdisp; HRESULT hres; unsigned i; if(flags & DISPATCH_CONSTRUCT) return E_UNEXPECTED; if(argc > function->function.length) argc = function->function.length; if(is_undefined(vthis) || is_null(vthis)) this_obj = lookup_global_host(ctx); else if(!is_object_instance(vthis)) return E_UNEXPECTED; else this_obj = get_object(vthis); jsdisp = to_jsdisp(this_obj); if(jsdisp) { if(!(proxy_target = get_proxy_target(jsdisp))) return E_UNEXPECTED; IWineJSDispatchHost_AddRef(proxy_target); }else if(FAILED(IDispatch_QueryInterface(this_obj, &IID_IWineJSDispatchHost, (void**)&proxy_target)) || !proxy_target) return E_UNEXPECTED; if(dp.cArgs <= ARRAY_SIZE(buf)) dp.rgvarg = buf; else if(!(dp.rgvarg = malloc(dp.cArgs * sizeof(*dp.rgvarg)))) { hres = E_OUTOFMEMORY; goto fail; } for(i = 0; i < dp.cArgs; i++) { hres = jsval_to_variant(argv[i], &dp.rgvarg[dp.cArgs - i - 1]); if(FAILED(hres)) goto cleanup; } V_VT(&retv) = VT_EMPTY; hres = IWineJSDispatchHost_BuiltinFuncCall(proxy_target, function->func_ctx, function->setter, &dp, r ? &retv : NULL, &ei, caller); if(hres == DISP_E_EXCEPTION) disp_fill_exception(ctx, &ei); else if(hres == E_NOINTERFACE) hres = E_UNEXPECTED; else if(SUCCEEDED(hres) && r) { hres = variant_to_jsval(ctx, &retv, r); VariantClear(&retv); if(SUCCEEDED(hres)) hres = convert_to_proxy(ctx, r); } cleanup: while(i--) VariantClear(&dp.rgvarg[i]); if(dp.rgvarg != buf) free(dp.rgvarg); fail: IWineJSDispatchHost_Release(proxy_target); return hres; } ``` nothing special or complicated, and of course the `func_ctx` is stored by PropGetInfo rather than the IID (and we check it for NULL to see whether it's a func/accessor or a proxy prop). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5444#note_71782

1 0

[PATCH v2 0/7] MR5753: win32u: Introduce a helper to set the window surface clipping region.
by Rémi Bernon 30 May '24

30 May '24

-- v2: win32u: Use a helper to set the window surface clipping, within the lock. wineandroid: Remove now unnecessary set_surface_region calls. server: Update window surface regions when the window is shaped. win32u: Intersect the clipping region with the window shape region. server: Merge get_surface_region / get_window_region requests together. server: Split update_surface_region into get_window_region helper. win32u: Initialize window surfaces with a hwnd. https://gitlab.winehq.org/wine/wine/-/merge_requests/5753

2 10

[PATCH 0/1] MR5755: vkd3d: Import upstream release 1.12.
by Alexandre Julliard (＠julliard) 30 May '24

30 May '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/5755

4 6

[PATCH v3 0/2] MR5633: win32u: Fallback to default script if vert/vrt2 is not found.
by Akihiro Sagawa (＠sgwaki) 30 May '24

30 May '24

Also added and prioritized `DFLT` as the default script tag, with `dflt` as a secondary option. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56658 -- v3: win32u: Use the first vertical alternates table regardless of script. gdi32: Add tests for script-independent vertical glyph lookup. https://gitlab.winehq.org/wine/wine/-/merge_requests/5633

3 4

[PATCH 0/7] MR5753: win32u: Introduce a helper to set the window surface clipping region.
by Rémi Bernon 30 May '24

30 May '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/5753

2 9

[PATCH v4 0/2] MR5692: shell32: Fix ShellExecute for non-filespec paths
by Yuxuan Shui (＠yshui) 30 May '24

30 May '24

I was going to reimplement path resolution in ShellExecute, but half way through I realized that's very unnecessary. Since what I wanted is a version of `PathResolve` that behaves differently _only_ for filespec paths, I ended up duplicating a lot of code, then I realized I can still pass filespec paths onto `PathResolve` and only deal with non-filespec paths. -- v4: shell32: Fix ShellExecute for non-filespec paths. https://gitlab.winehq.org/wine/wine/-/merge_requests/5692

3 3

[PATCH v5 0/3] MR5692: shell32: Fix ShellExecute for non-filespec paths
by Yuxuan Shui (＠yshui) 30 May '24

30 May '24

I was going to reimplement path resolution in ShellExecute, but half way through I realized that's very unnecessary. Since what I wanted is a version of `PathResolve` that behaves differently _only_ for filespec paths, I ended up duplicating a lot of code, then I realized I can still pass filespec paths onto `PathResolve` and only deal with non-filespec paths. -- v5: debug CI failure https://gitlab.winehq.org/wine/wine/-/merge_requests/5692

2 3

Re: [PATCH v8 0/11] MR5444: jscript: Do not allocate dispex_prop_t for indexed props.
by Jacek Caban (＠jacek) 30 May '24

30 May '24

> The IID would have the IHTMLStyle3 interface (which is correct), but when looking the "zoom" prop up on HTMLCurrentStyle via DISPID, it would get the one from CSSStyleDeclaration, which has different behavior. Yes, it's weird as hell, and my explanation isn't that great either. It seems to me that we could just use `IHTMLCSSStyleDeclaration` to expose `zoom` for applicable compat modes. It's implemented by both style and current style. What are other examples? Note that for some cases we may use some private interface, like we already need to in other a few cases. > Instead I'm now using a mixed approach where I have a new method (but a normal method in the vtbl like PropInvoke rather than a function pointer callback) that uses a "func_ctx" which is basically the `func_info_t` (it's opaque to jscript, it doesn't care). The problem with `func_info_t` is that it carries information specific to the instance (like hooks), not only abstract things like the signature, so you can't just apply "current style" function info to "style" object without some additional refactoring. It's hard to comment in more details without the code. > Anyway, this is not very related to this MR, is there something I can do to get this moving? I'm still hoping to see how the interface capable of handling prototype chains looks like. Meantime, I noticed that we could prepare MSHTML for the change better by completing dispex refactoring (and document objects split), see https://gitlab.winehq.org/jacek/wine/-/commits/mshtml-dispex/ for a draft. Unfortunately, it needs a few more vtbl entries, but the unification seems worth to me. On top of that, you wouldn't need to have a dedicated new interface implementation for document node and the window variant should be easier as it could be just a forwarder. What do you think? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5444#note_71748

1 0

Re: [PATCH v3 0/1] MR5719: vbscript: fix test error clear
by Alexandre Julliard (＠julliard) 30 May '24

30 May '24

Please use your full name in your Gitlab profile and in the commit info. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5719#note_71747

1 0