--
v5: mshtml: Validate builtin host functions in IE9+ using prototype_id rather
mshtml: Store the prototype_id of the last member that contains the needed
mshtml: Define "create" from XMLHttpRequest constructor as a jscript prop
mshtml: Consolidate the functional constructors into a common struct
mshtml: Rename struct constructor to stub_constructor.
mshtml: Use get_constructor in window's get_XMLHttpRequest.
mshtml: Move Option constructor to the window rather than the prototype.
mshtml: Move Image constructor to the window rather than the prototype.
mshtml: Don't expose "create" from Option constructor in IE9+ modes.
mshtml: Don't expose "create" from Image constructor in IE9+ modes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7779
Over the past several weeks I've been working on and off on this. I didn't track the hours but I'm sure that I've spent 80+ hours on the feature. I've tested and retested all known scenarios and it seems to be working as expected.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843
Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/7815, for https://gitlab.winehq.org/wine/wine/-/merge_requests/7226, this only split the sync ops to a separate vtable and let objects delegate theirs to a separate object.
This starts using a event-like interface for most objects, leaving the decision regarding if/how to split sync themselves / integrate inproc syncs for later.
--
v2: server: Use an event as debug event sync.
server: Use an event as file lock sync.
server: Use an event as process startup info sync.
server: Use an event as thread context sync.
server: Use an event as thread apc sync.
server: Use an event as fd sync.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7848
Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/wayland_pointer.c:
> }
> else if (!needs_relative && pointer->zwp_relative_pointer_v1)
> {
> + pointer->accum_x = pointer->accum_y = 0;
I was thinking... if we perform the initialization/zeroing just before enabling relative motion in the if clause above, we reduce (although we do not completely eliminate) the window for the data race mentioned in a previous comment (i.e., some handler running concurrently). This also takes care of the lack of explicit initialization of the accum_x/accum_y members during wayland_pointer init.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7806#note_101383
This serie finishes the migration of the remaining types from TPI
stream (function signature, struct/class/union, enum) to new PDB
backend.
And it removes dual allocation of symt_* in old PDB backed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7849
Componenets installed by winetricks have "deadbeef.manifest" trailer
in their manifests, so it's not clear that filtering logic works. On
the other hand when manifests for versions 1.2.3.4 and 1.2.3.10 are
installed and application exe needs version 1.2.0.0 and later uses
LoadLibrary() to load a plugin.dll that needs 1.2.3.7, version 1.2.3.4
gets loaded with an .exe (because manifest for version 1.2.3.10 is
ignored) and version 1.2.3.10 gets loaded with a plugin.dll, and
this leads to crashes.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7028
For https://gitlab.winehq.org/wine/wine/-/merge_requests/7226
This MR introduces a new wineserver "sync" entity, to be used by objects to implement the signal/wait operations. Later, the server sync implementations will be reduced as much as possible to event/mutex/semaphore/queue[^1]. I think it will then make the integration of ntsync cleaner, with inproc syncs being a separate flavor from the traditional server-side syncs.
Unlike how the fd struct have been implemented, I chose not to derive these syncs from the object base, because it seemed inconvenient to have to declare all the unused ops. Still they are refcounted, to allow us to share a sync between multiple objects, which will later benefit the console objects use cases, maybe others.
This makes me thing that the fd struct could also benefit from being lightweight entities as well, as it doesn't seem they really use most of the object vtable ops, and arguably we could have a common "light" refcounted/dumpable base for all fds, syncs and objects, but I didn't want to jump into that rabbit hole and it could be implemented later.
[^1]: And server-only async/completion waits, which maybe can be changed to use events too, but I'm not familiar enough.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7815
This MR modifies winegstreamer to match Windows behaviour in that:
1. the video decoders will output the PTS and duration of the input sample (if provided); and
2. the WMV decoder will set any value not provided to zero
It also adds support for supplying a DTS value to the MFTs.
I've marked this as draft as it fixes the tests in MR !7563 (in addition to fixing some existing `test_wmv_decoder` tests). Also, as demonstrated in MR !7569, our demuxers output different timestamps to Windows. This change will result in those different timestamps being forwarded from the decoder. So we may also want to address that difference prior to accepting this MR.
--
v7: winegstreamer: Use provided PTS and duration in video_decoder.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7623
This MR modifies winegstreamer to match Windows behaviour in that:
1. the video decoders will output the PTS and duration of the input sample (if provided); and
2. the WMV decoder will set any value not provided to zero
It also adds support for supplying a DTS value to the MFTs.
I've marked this as draft as it fixes the tests in MR !7563 (in addition to fixing some existing `test_wmv_decoder` tests). Also, as demonstrated in MR !7569, our demuxers output different timestamps to Windows. This change will result in those different timestamps being forwarded from the decoder. So we may also want to address that difference prior to accepting this MR.
--
v6: winegstreamer: Use provided PTS and duration in video_decoder.
mf/tests: Add negative timestamp tests for h264.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7623