Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options
--
v19: timeout: add minimal test suite
timeout: Windows 10 introduce the timeout command
https://gitlab.winehq.org/wine/wine/-/merge_requests/6869
I've seen some cases where the X server is a bit slow to start, and I suspect it could be a reason for some rare spurious test failures. Not 100% sure but at least this should be harmless and better than leaving it to chance.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6880
On Fri Nov 22 16:13:26 2024 +0000, Gabriel Ivăncescu wrote:
> What about just using `IHTMLCommentElement2` for CharacterData's
> interface, since it exposes the exact same props that it has? I mean
> instead of the custom interface.
Sounds better but should `QI(IHTMLCommentElement2)` succeeded on text nodes?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88536
On Fri Nov 22 16:09:59 2024 +0000, Jacek Caban wrote:
> The ugly part of forwarding to `IHTMLDOMTextNode2` is that you need to
> implement `IHTMLDOMTextNode2` in an object that's not a text node
> (comment node).
> With a private interface, we could give it a proper set of properties,
> so no hooks would be needed, and just forward to it from both
> `IHTMLDOMTextNode*` and `IHTMLCommentElement*` interfaces. We could even
> share its entire implementation with something like:
> ```
> struct HTMLCharacterData {
> IHTMLCharacterData IHTMLCharacterData_iface;
> DispatchEx *dispex; // used to forward IDispatch to comment's or
> text node's dispex
> nsIDOMCharacterData *character_data; // used for the actual implementation
> };
> ```
> You could then embed it both in both comment and text node structs and
> just use the single `IHTMLCharacterData` implementation.
What about just using `IHTMLCommentElement2` for CharacterData's interface, since it exposes the exact same props that it has? I mean instead of the custom interface.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88535
On Fri Nov 22 15:47:04 2024 +0000, Gabriel Ivăncescu wrote:
> Other than this, only CSS-related styles/stylesheets have a similar case
> like this, but those are more convoluted.
> I also don't see how introducing a private interface helps to simplify
> it. We'd still have to expose it (and forward) in comment elements, but
> now we'd also have to expose and forward it in text nodes, making it
> actually less simple, IMO.
> But is my forwarding a good idea?
The ugly part of forwarding to `IHTMLDOMTextNode2` is that you need to implement `IHTMLDOMTextNode2` in an object that's not a text node (comment node).
With a private interface, we could give it a proper set of properties, so no hooks would be needed, and just forward to it from both `IHTMLDOMTextNode*` and `IHTMLCommentElement*` interfaces. We could even share its entire implementation with something like:
```
struct HTMLCharacterData {
IHTMLCharacterData IHTMLCharacterData_iface;
DispatchEx *dispex; // used to forward IDispatch to comment's or text node's dispex
nsIDOMCharacterData *character_data; // used for the actual implementation
};
```
You could then embed it both in both comment and text node structs and just use the single `IHTMLCharacterData` implementation.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88534
On Fri Nov 22 15:44:33 2024 +0000, Jacek Caban wrote:
> Yeah, it shows that those interfaces do not reflect prototypes. In a
> sense, `IHTMLDOMTextNode2` is as bad for `CharacterData` as
> `IHTMLCommentElement2`. Do we have a lot of cases like that? I'm
> wondering if we need to change the mechanism or could we just introduce
> a private `IHTMLCharacterData` interface.
Other than this, only CSS-related styles/stylesheets have a similar case like this, but those are more convoluted.
I also don't see how introducing a private interface helps to simplify it. We'd still have to expose it (and forward) in comment elements, but now we'd also have to expose and forward it in text nodes, making it actually less simple, IMO.
But is my forwarding a good idea?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88530
On Fri Nov 22 15:40:33 2024 +0000, Gabriel Ivăncescu wrote:
> On second thought maybe just forwarding to `IHTMLCommentElement2` would
> be enough, but we still need the `IHTMLDOMTextNode2` so the prototype
> works right?
Yeah, it shows that those interfaces do not reflect prototypes. In a sense, `IHTMLDOMTextNode2` is as bad for `CharacterData` as `IHTMLCommentElement2`. Do we have a lot of cases like that? I'm wondering if we need to change the mechanism or could we just introduce a private `IHTMLCharacterData` interface.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88529
On Fri Nov 22 15:39:38 2024 +0000, Gabriel Ivăncescu wrote:
> Interesting, but I'm not sure. The issue here is that these are in the
> `CharacterDataPrototype`, not in the comment element itself. So, won't
> they fail if we don't handle `IHTMLDOMTextNode2` when called on the
> comment element? Since it's looked up by IID/DISPID pair, not name.
> `IHTMLCommentElement2` might be used for legacy modes though, I guess I
> will need to test it from C code to know.
On second thought maybe just forwarding to `IHTMLCommentElement2` would be enough, but we still need the `IHTMLDOMTextNode2` so the prototype works right?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88528
Probably caused by some winehq.org HTTP server update, it now supports HTTP/2 and sends "Upgrade, Keep-Alive" connection strings (was "Keep-Alive" before).
--
v3: wininet: Parse multi-token Connection strings for Keep-Alive.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6882
On Fri Nov 22 15:33:09 2024 +0000, Jacek Caban wrote:
> Shouldn't it be `IHTMLCommentElement2` instead?
Interesting, but I'm not sure. The issue here is that these are in the `CharacterDataPrototype`, not in the comment element itself. So, won't they fail if we don't handle `IHTMLDOMTextNode2` when called on the comment element? Since it's looked up by IID/DISPID pair, not name.
`IHTMLCommentElement2` might be used for legacy modes though, I guess I will need to test it from C code to know.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88525
Probably caused by some winehq.org HTTP server update, it now supports HTTP/2 and sends "Upgrade, Keep-Alive" connection strings (was "Keep-Alive" before).
--
v2: wininet: Parse multi-token Connection strings for Keep-Alive.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6882