June 2022 - Wine-Devel - list.winehq.org

Re: [PATCH] include: Allow making Wine Server requests from C++ code

by Alex Henrie

On Mon, Jun 6, 2022 at 10:12 AM Mahdi Tayarani <tayarani(a)google.com> wrote: > > We have an input processing system which requires us to directly send input update information to the Wine Server. The existing helper methods don't provide what we need. Does that mean that you're porting Wine to a new platform and writing something like winex11.drv for that platform? Could your new code be included in upstream Wine one day? If so, it would probably be better to write it in C instead of C++ because the Wine project does not currently accept C++ code. Or do you mean that you are writing cross-platform software that will run on both Windows and on Wine? If that is the case, how does the code work on Windows? Could the same functions that you call on Windows be improved in Wine to do what you need? > Can you please elaborate why it will be a tough sell? The change provides no sort of functional or behavioural change. It's just making the cast that was already implicitly happening, explicit. Although the change itself is very small, it smells like a hack, and the Wine community really does not like hacks. I think everyone would prefer to identify the underlying problem here and, if possible, resolve it instead of working around it. That said, I am just a volunteer Wine developer trying to be helpful; other developers would be able to speak more authoritatively. -Alex

June 6, 2022

Re: [PATCH v2] vbscript: Implement IsDate().

by Jacek Caban

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com>

June 6, 2022

Re: [PATCH] include: Allow making Wine Server requests from C++ code

by Rémi Bernon

Hi Mahdi, On 6/6/22 18:12, Mahdi Tayarani wrote: > We have an input processing system which requires us to directly send input > update information to the Wine Server. The existing helper methods don't > provide what we need. > > Can you please elaborate why it will be a tough sell? The change provides > no sort of functional or behavioural change. It's just making the cast that > was already implicitly happening, explicit. > I think the "tough sell" is because Wine doesn't expect wineserver requests to be made from non-Wine code, and doesn't provide any guarantee about the protocol compatibility across versions. Though if you're well aware of this I guess it's up to you if you do it nonetheless, and the change can make sense indeed, as you say, it's just making a cast explicit. Then I'm interested to know more about the specific needs you have on input processing, if you can share more detail about it. Like what isn't currently possible to do with __wine_send_input, what you would need, etc. All wine input goes through it, and I'm investigating possible better ways to handle non-joystick devices through the HID stack as well, which may involve changes in that area. Cheers, -- Rémi Bernon <rbernon(a)codeweavers.com>

June 6, 2022

Re: [PATCH] include: Allow making Wine Server requests from C++ code

by Mahdi Tayarani

We have an input processing system which requires us to directly send input update information to the Wine Server. The existing helper methods don't provide what we need. Can you please elaborate why it will be a tough sell? The change provides no sort of functional or behavioural change. It's just making the cast that was already implicitly happening, explicit. On Mon, Jun 6, 2022 at 11:51 AM Alex Henrie <alexhenrie24(a)gmail.com> wrote: > On Mon, Jun 6, 2022 at 8:59 AM Mahdi Tayarani <tayarani(a)google.com> wrote: > > > > We need to include "include/wine/server.h" as it contains the definition > for the SERVER_START_REQ/SERVER_END_REQ macros. Our code (written in C++) > needs to make a Wine Server call so we have to include that header. But by > doing so we run into compilation issues. > > I suspect that this is going to be a tough sell. Why are you trying to > call the Wineserver directly, instead of calling the Windows function > that calls the Wineserver? > > -Alex >

June 6, 2022

Re: [PATCH 4/8] mshtml: Implement onloadstart for XMLHttpRequest.

by Marvin

Hi, While running your changed tests, 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=116316 Your paranoid android. === w7u_el (32 bit report) === mshtml: script.c:644: Test failed: L"/index.html?es5.js:date_now: unexpected Date.now() result 1654521664704 expected 1654521664782" === w1064_2qxl (64 bit report) === mshtml: script.c:3114: Test failed: ReportResult failed: 80ef0001

June 6, 2022

Re: [PATCH] include: Allow making Wine Server requests from C++ code

by Alex Henrie

On Mon, Jun 6, 2022 at 8:59 AM Mahdi Tayarani <tayarani(a)google.com> wrote: > > We need to include "include/wine/server.h" as it contains the definition for the SERVER_START_REQ/SERVER_END_REQ macros. Our code (written in C++) needs to make a Wine Server call so we have to include that header. But by doing so we run into compilation issues. I suspect that this is going to be a tough sell. Why are you trying to call the Wineserver directly, instead of calling the Windows function that calls the Wineserver? -Alex

June 6, 2022

Re: [PATCH] include: Allow making Wine Server requests from C++ code

by Mahdi Tayarani

We need to include "include/wine/server.h" as it contains the definition for the SERVER_START_REQ/SERVER_END_REQ macros. Our code (written in C++) needs to make a Wine Server call so we have to include that header. But by doing so we run into compilation issues. The proposed changes are valid C and C++ syntax so applying them allows us to include the header file without modification. On Sun, Jun 5, 2022 at 1:42 PM Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > > > > Am 03.06.2022 um 19:15 schrieb Mahdi Tayarani <tayarani(a)google.com>: > > > > Using SERVER_START_REQ/SERVER_END_REQ in C++ code calls helper methods > > which need an explicit cast from a void* to __server_request_info*. > > Why do you need this? include/wine/server.h (and pretty much everything in > include/wine/) is a private header that should not be used by external code > (e.g. programs linking to winelib) > >

June 6, 2022

Re: [PATCH 2/8] mshtml: Implement onabort for XMLHttpRequest.

by Marvin

Hi, While running your changed tests, 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=116314 Your paranoid android. === w7u_adm (32 bit report) === mshtml: events.c:1089: Test failed: unexpected call img_onerror events: Timeout === w10pro64 (32 bit report) === mshtml: htmldoc.c:2541: Test failed: unexpected call UpdateUI htmldoc.c:2853: Test failed: unexpected call Exec_UPDATECOMMANDS htmldoc.c:350: Test failed: expected Exec_SETTITLE htmldoc.c:2859: Test failed: unexpected call Exec_SETTITLE === w10pro64_zh_CN (64 bit report) === mshtml: htmldoc.c:2541: Test failed: unexpected call UpdateUI htmldoc.c:2853: Test failed: unexpected call Exec_UPDATECOMMANDS

June 6, 2022

Re: RFC: Allow marking unreliable tests as flaky.

by Francois Gouget

On Wed, 1 Jun 2022, Esme Povirk (she/they) wrote: > It might be better to use something like broken() to encourage more > precision in marking the failures. For example, if something fails > with ACCESS_DENIED sometimes, we'd still like to know if it starts > failing with FILE_NOT_FOUND. So something like this? ok(success || flaky(gle == ACCESS_DENIED), "Call failed: gle=%lu\n", gle); I suspect we'd get a lot of "|| flaky(1)", for instance for all the "always new" error messages. Also the goal is to make the tests more "reliable" but if we are too specific about which unexpected conditions we allow there's a risk we'll spend our time expanding the condition inside the flaky() call. But maybe it would be okay to give it a few tries and fall back to flaky(1). -- Francois Gouget <fgouget(a)codeweavers.com>

June 6, 2022

[PATCH v2 2/2] jscript: Fix iterating through the map while entries are removed.

by Gabriel Ivăncescu

The current entry as well as the next entry may both be removed while iterating. Since we release the entry after the callback, obtaining the "next" entry would be using possibly freed memory. A safe iteration is required, but we need to obtain the next entry after the callback, not at the start of the loop, since it can be removed during it. Signed-off-by: Gabriel Ivăncescu <gabrielopcode(a)gmail.com> --- This is a pre-existing problem. See for example 64-bit Debian VM results here: https://testbot.winehq.org/JobDetails.pl?Key=116313#k2202 dlls/jscript/set.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/dlls/jscript/set.c b/dlls/jscript/set.c index 0ef014b..1d2ced3 100644 --- a/dlls/jscript/set.c +++ b/dlls/jscript/set.c @@ -183,7 +183,7 @@ static HRESULT set_map_entry(MapInstance *map, jsval_t key, jsval_t value, jsval static HRESULT iterate_map(MapInstance *map, script_ctx_t *ctx, unsigned argc, jsval_t *argv, jsval_t *r) { - struct jsval_map_entry *entry; + struct jsval_map_entry *entry, *entry2; IDispatch *context_obj = NULL; HRESULT hres; @@ -200,7 +200,7 @@ static HRESULT iterate_map(MapInstance *map, script_ctx_t *ctx, unsigned argc, j context_obj = get_object(argv[1]); } - LIST_FOR_EACH_ENTRY(entry, &map->entries, struct jsval_map_entry, list_entry) { + LIST_FOR_EACH_ENTRY_SAFE(entry, entry2, &map->entries, struct jsval_map_entry, list_entry) { jsval_t args[3], v; if(entry->deleted) continue; @@ -210,6 +210,9 @@ static HRESULT iterate_map(MapInstance *map, script_ctx_t *ctx, unsigned argc, j grab_map_entry(entry); hres = disp_call_value(ctx, get_object(argv[0]), context_obj, DISPATCH_METHOD, ARRAY_SIZE(args), args, &v); + + /* The callback may have possibly removed the next entry, so grab it here */ + entry2 = LIST_ENTRY(entry->list_entry.next, struct jsval_map_entry, list_entry); release_map_entry(entry); if(FAILED(hres)) return hres; -- 2.34.1

June 6, 2022