> Well, I target the parts where the folders are created, where else could I handle it? I currently don't see a better way to do this. Mind pointing me into the direction of a better design?
I don't mean the code, I mean the UI design.
As you point out, this can be configured from winecfg. So why do we need a separate mechanism, with an ad-hoc environment variable? Why is it only usable at prefix creation? Is there a way to unify the features, or make them easier to use? How is it different from `winetricks sandbox`? etc. etc.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3259#note_52155
Add plumbing to server to prevent the server from making rawinput from INPUT_MOUSE and INPUT_KEYBOARD events so a graphics driver can inject its own INPUT_HARDWARE events. This will allow a graphics driver to be fully in charge of rawinput.
--
v6:
https://gitlab.winehq.org/wine/wine/-/merge_requests/4356
> What's the use case for configuring folders individually?
TBH, I just need all of them at once. But I figured I could also just make it fully configurable just in case someone needs that. I didn't see any harm in making it fully configurable from the start, just in case.
> How are we going to ensure that prefix updates to the right thing?
Sorry, I don't understand what you mean. Mind elaborating? The logic only runs when the folder doesn't exist. Unless I missed something, updates shouldn't be a problem.
> How can it be enabled/disabled after prefix creation?
The logic I changed only runs when the folder doesn't exist, you can always link/unlink the folders using winecfg.
> How is it going to handle inability to open Unix files (fonts etc.)
Well, it's not different from disabling the Z:\ link in winecfg. If someone doesn't know what they're doing, they can run into problems with that as well. This MR would only add on option to disable the link automatically when creating a new WINEPREFIX.
> This needs a lot more thought and a proper design.
Well, I target the parts where the folders are created, where else could I handle it? I currently don't see a better way to do this. Mind pointing me into the direction of a better design?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3259#note_52152
Here's a list of usages of `base.outer_window` that may be impacted by the change and my analysis/fixes. Note that I specifically did not look for `document->outer_window` since that one was already holding it forever, so it's out of scope for this MR (whether it's correct or not, the behavior is the same after this MR).
I also didn't consider some cases that already **did not check** for it being NULL or not, because they would have crashed earlier before anyway (they'd still crash now if outer window gets killed, but it's out of scope of the MR as I said). For those that says "Handled" it means I've added checks so that the behavior is same as before, i.e. detached inner windows behave as if outer window is NULL.
* `htmldoc.c/HTMLDocument_get_mimeType`: Changed so it doesn't rely on outer window.
* `htmldoc.c/HTMLDocument7_get_defaultView`: This is actually fixed by these patches.
* `htmlform.c/HTMLFormElement_submit`: Handled.
* `htmlstorage.c/send_storage_event`: Fixed in a separate patch with tests, since it follows the outer window.
* `htmlwindow.c/check_target_origin`: This (along with many other methods) can't have it NULL anymore or detached, since the caller must hold a ref to the outer window, and they're not called from our objects holding ref to inner window only.
* `htmlwindow.c/HTMLWindowSP_QueryService`: This uses the outer window to obtain the browser and the doc obj, so it's fine.
* `mutation.c/set_document_mode`: Handled.
* `navigate.c/BindCallbackRedirect_Redirect`: Handled.
* `navigate.c/nsAsyncVerifyRedirectCallback_OnRedirectVerifyCallback`: Handled.
* `navigate.c/nsChannelBSC_init_bindinfo`: Uses the outer window to obtain the browser and doc obj to set a flag, so it's harmless and probably correct this way.
* `navigate.c/handle_navigation_error`: Handled.
* `navigate.c/handle_extern_mime_navigation`: Handled.
* `omnavigator.c/OmHistory_get_length`: This is actually fixed by these patches.
* `script.c/ActiveScriptSite_GetItemInfo`: Handled.
* `script.c/ActiveScriptSiteWindow_GetWindow`: Handled.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4380
This serie adds a couple of test for CreateProcess around
std handles inheritance, depending on several options (cui/gui,
use (or no use) of STARTF_USESTDHANDLES, type of handles...).
This requires revisiting the existing tests to allow for more
flexibility in implementing the new tests (and potentially
others if needed).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4378
On Mon Nov 13 14:56:51 2023 +0000, Yuxuan Shui wrote:
> > not supported
> not sure what you mean by that? I can build it fine with mingw-w64-g++
> and it runs.
> > cancellation does not work
> this is not true. callback could still be called after MFCancelWorkItem
> returns success, the
> [documentation](https://learn.microsoft.com/en-us/windows/win32/api/mfapi/nf…
> says as much.
> and the thing is, more than this "hit race" case, our current rtworkq
> implementation triggers a assert in threadpool that says exactly what i
> predicted (callback is running when you try to close it). and that's
> exactly the race I am trying to avoid here.
> what more proof do you want?
i hope you understand the problem here. the problem is not the assert, so doesn't matter if the TP implementation handles this case.
the problem is if the `scheduled_item_cancelable_callback` is running when we reaches `queue_cancel_item`, we will double release the work item.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4243#note_52137
> not supported
not sure what you mean by that? I can build it fine with mingw-w64-g++ and it runs.
> cancellation does not work
this is not true. callback could still be called after MFCancelWorkItem returns success, the [documentation](https://learn.microsoft.com/en-us/windows/win32/api/mfapi/nf… says as much.
and the thing is, more than this "hit race" case, our current rtworkq implementation triggers a assert in threadpool that says exactly what i predicted (callback is running when you try to close it). and that's exactly the race I am trying to avoid here.
what more proof do you want?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4243#note_52135
It's possible that a state object pointer not in the topology node collection gets passed to
session_get_node_object(). Instead of returning the last node when the object is not found, we
should return a NULL so that the state of the last node is not changed by mistake.
--
v9: mf/tests: Test IMFMediaSession::Start().
mf: Support seeking while a session is running.
mf/tests: Add a create_test_topology() helper.
mf: Add a session_flush_nodes() helper.
mf: Make session_get_node_object() more robust.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3572