November 2023 - wine-gitlab

[PATCH v3 0/1] MR4523: ntdll: RtlFindExportedRoutine returns NULL on forwarded function.
by eric pouech (＠epo) 28 Nov '23

28 Nov '23

Signed-off-by: Eric Pouech <epouech(a)codeweavers.com> -- v3: ntdll: RtlFindExportedRoutine returns NULL on forwarded entries. https://gitlab.winehq.org/wine/wine/-/merge_requests/4523

3 3

[PATCH v3 0/2] MR4520: Don't let GUI's app write to console.
by eric pouech (＠epo) 28 Nov '23

28 Nov '23

-- v3: uninstall: No longer use console/file output APIs. winecfg: Output with MESSAGE. https://gitlab.winehq.org/wine/wine/-/merge_requests/4520

2 3

[PATCH v2 0/2] MR4520: Don't let GUI's app write to console.
by eric pouech (＠epo) 28 Nov '23

28 Nov '23

-- v2: uninstall: No longer use console/file output APIs. winecfg: Output with MESSAGE. https://gitlab.winehq.org/wine/wine/-/merge_requests/4520

2 2

[PATCH 0/1] MR4529: comdlg32/tests: Use CRT allocation functions.
by Alex Henrie (＠alexhenrie) 28 Nov '23

28 Nov '23

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

3 2

[PATCH v5 0/2] MR497: vkd3d-shader/dxil: Implement DX intrinsic Unary.
by Conor McCarthy (＠cmccarthy) 28 Nov '23

28 Nov '23

-- v5: vkd3d-shader/dxil: Apply metadata attachments to instructions. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/497

2 2

[PATCH v4 0/2] MR497: vkd3d-shader/dxil: Implement DX intrinsic Unary.
by Conor McCarthy (＠cmccarthy) 28 Nov '23

28 Nov '23

-- v4: vkd3d-shader/dxil: Apply metadata attachments to instructions. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/497

2 3

Re: [PATCH v2 0/9] MR4533: winex11: Detach / attach vulkan window surfaces as needed.
by Rémi Bernon (＠rbernon) 28 Nov '23

28 Nov '23

v2: Added the change to put detached surfaces offscreen with XComposite. Call `detach_client_window` directly in `attach_client_window` if client window needs to be swapped. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4533#note_54102

1 0

[PATCH v3 0/2] MR497: vkd3d-shader/dxil: Implement DX intrinsic Unary.
by Conor McCarthy (＠cmccarthy) 28 Nov '23

28 Nov '23

-- v3: vkd3d-shader/dxil: Apply metadata attachments to instructions. vkd3d-shader/dxil: Implement DX intrinsic Unary. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/497

2 2

Re: [PATCH v4 0/8] MR4380: mshtml: Keep inner window's link to the outer window until it's destroyed.
by Gabriel Ivăncescu (＠insn) 28 Nov '23

28 Nov '23

On Mon Nov 27 20:57:03 2023 +0000, Jacek Caban wrote: > My guess is that you wouldn't be able to reproduce that with JS. If > that's the case, then web pages can't depend on that (otherwise we'd > have a way to crash web browser from JS). Do you mean crash on native? I mean it's known to be full of bugs and security exploits, to the point of becoming a meme. I could test it if I can use it from JS (actually, can't event handlers still be called after navigation on the old doc/window?), because it would be a silent "failure" or event not firing which would be insanely hard to debug otherwise, especially since you can see event handlers are registered and all. And "if it works on Windows it must be correct" that devs usually think of. I wouldn't mind trying to test this out, even if it doesn't end up as proper wine tests, I just don't want it to be a waste of time, like it feels right now, even though I was expecting matching native behavior (and fixing potential memory hazards) to be a goal. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4380#note_54096

1 0

Re: [PATCH v4 0/8] MR4380: mshtml: Keep inner window's link to the outer window until it's destroyed.
by Gabriel Ivăncescu (＠insn) 28 Nov '23

28 Nov '23

On Tue Nov 28 14:17:15 2023 +0000, Jacek Caban wrote: > > As for the "hide problems in the future", I actually think the exact > opposite. Right now, we use the document's outer_window in same way, > except it's completely broken and can access invalid memory if the outer > window happens to die, which would be very hard to debug (especially > considering most apps using mshtml are bloated and slow with millions of frameworks). > Yes, it would be nice to fix that. One fix for that is to simply reset > the pointer to NULL. My understanding is that the actual reason we can't > do that is iframe navigation test and we already know that the test > works because on native, the document interface doesn't change. So what > you do is essentially working around that problem, not fixing it. Resetting the point to NULL is the same as using the `doc->window->base.outer_window`, which has potential for a lot more regressions (I don't mean the test). How is that better?!? I don't know why you think this is so risky; as mentioned in the MR's message, those are the only things that would be affected, and they're all either fixed or handled (handled means same behavior as before). I spent time carefully reviewing them, I'd like that not to be a waste and just dismissed like that. Sure I might have missed some, but it's pretty unlikely. I also tested real world apps and it seemed fine. I was hoping a review to "double check" it would provide the extra eyes on it, instead of being dismissed, even though it's correct. Also another argument for it is that, since I suspect it will have to be fixed properly at some point, the sooner we do it, the easier it will be to review, which is now. The more complicated mshtml becomes (necessarily, to implement new features), the harder it will be to revamp this. Why not do it now? It just seems to me that you dismiss it because of potential regressions without actually analyzing what could cause them at all, since my goal with this patch and the MR message was definitely to keep same behavior as before *except* in places where I fixed it (and mentioned in the message). *If* that's not the case everywhere I'd like to know, too, but I did carefully review it. Would you please reconsider? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4380#note_54095

1 0

2025

2024

2023

2022

wine-gitlab November 2023