Hi,
I just trapped into the same `whitespace` problem. Is there a plan to solve the issue?
Another question - is it a valid workaround to ensure there are no `whitespace only` lines in the bat file?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/277#note_49569
Previously long URI/URLs (> 1024 characters) would cause a stack corruption and crash Wine. After this MR, Wine will no longer crash but the URL is not opened either primarily due to `SHELL_Argify` limitations.
--
v3: shell32: Increase timeout for long URLs
https://gitlab.winehq.org/wine/wine/-/merge_requests/2383
Sorry, i can't get this to work. Maybe i messed something up in between. now got:
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Sigh....
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4143#note_49564
> Yeah, but this isn't necessarily about not trusting Windows apps, i.e. malice or malware, but rather that they can't be designed around it (since they assume Windows environment), so they would have privacy issues without even wanting to. At the very least maybe use
Of course Windows apps can be designed around it. In the Windows environment they'd retrieve a real hardware ID that should be handled with the same care.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49556
On Sat Oct 21 10:27:59 2023 +0000, Jinoh Kang wrote:
> Okay, I've read the prior discussions regarding the rationale.
> Still, I don't think you should change the System UUID for *existing*
> prefixes. Perhaps we could use the registry to detect whether the
> prefix is new, and use the new algorithm for new prefixes. We could
> also record the UUID in the registry "permanently."
Maintaining any way of backward compat on this ID doesn't look feasible. E. g., the current way with a bug reports bios hashtag in serial field on my desktop due to missing fields not being handled. This ID is already non-unique, and maintaining these algorithms backwards would take unreasonable amount of effort (with arguably no gains). Probably more important, /etc/machine-id can be changed anytime by user or system resintall, it is not true hardware id. If anything firmly relies on HW id to persist forever, it is broken already.
Regarding the original discussion, I also don't really understand why we should necessarily obfuscate /etc/machine-id for uuid / serial reporting. App has access to the file anyway, and Wine neither sends the ID anywhere nor tracks the user, it is between the app and the user. On Windows fwiw it will get real motherboard serial and other information like that.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49550
On Sat Oct 21 10:25:18 2023 +0000, Jinoh Kang wrote:
> This changes the system GUID. Some DRMs and copy protections like to
> assume that things like System UUIDs are permanent and never change.
> Changing this will break such apps and the user might have to
> reinstall/re-purchase them again.
Okay, I've read the prior discussions regarding the rationale.
Still, I don't think you should change the System UUID for *existing* prefixes. Perhaps we could use the registry to detect whether the prefix is new, and use the new algorithm for new prefixes. We could also record the UUID in the registry "permanently."
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49548
Jinoh Kang (@iamahuman) commented about dlls/ntdll/unix/system.c:
> system_args.version = system_version;
> system_args.serial_len = get_smbios_string("/sys/class/dmi/id/product_serial", S(system_serial));
> system_args.serial = system_serial;
> - get_system_uuid(&system_args.uuid);
> + derive_machineid_to_uuid(&system_args.uuid);
This changes the system GUID. Some DRMs and copy protections like to assume that things like System UUIDs are permanent and never change. Changing this will break such apps and the user might have to reinstall/re-purchase them again.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49547
Resolves https://bugs.winehq.org/show_bug.cgi?id=9127 . (Some of the named programs in that issue may require additional currently-missing functionality, I didn't check; but if so, that's separate issues.)
Tested with
- winetest on Windows 7
- winetest on Windows 10
- winetest in Wine, of course
- microkiri https://bugs.winehq.org/show_bug.cgi?id=9127#c102
- Wagamama High Spec Trial Edition https://wagahigh.com/download_trial.php#normal (ダウンロード means download)
- Ninki Seiyuu no Tsukurikata Trial https://archive.org/details/sayou_trial
(WMV files in microkiri and Wagamama don't work, but that's separate issues. Also, they need the LC_ALL=ja_JP env, or they throw various goofy errors.)
--
v18: quartz/tests: Add tests for CLSID_CMpegVideoCodec.
quartz/tests: Add tests for new CLSID_MPEG1Splitter functionality.
winegstreamer: Implement CLSID_CMpegVideoCodec.
winegstreamer: Add program stream and video output support to CLSID_MPEG1Splitter.
winegstreamer: Add WG_MAJOR_TYPE_VIDEO_MPEG1 media type.
winegstreamer: Use the new output_compressed property instead of mpegaudioparse in MPEG splitter.
winegstreamer: Add output_compressed parameter to wg_parser_create().
winegstreamer: Implement parts of IAMStreamSelect::Info in CLSID_MPEG1Splitter.
winegstreamer: Implement IAMStreamSelect::Count in CLSID_MPEG1Splitter.
winegstreamer: Improve and clean up some debug logs.
winegstreamer: Include the framerate when converting video format to GstCaps.
winegstreamer: Seek to end of stream instead of to stream duration.
winegstreamer: Clamp QoS events to stay inside the stream's running time.
winegstreamer: Don't read format from unparsed MPEG audio.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938
Resolves https://bugs.winehq.org/show_bug.cgi?id=9127 . (Some of the named programs in that issue may require additional currently-missing functionality, I didn't check; but if so, that's separate issues.)
Tested with
- winetest on Windows 7
- winetest on Windows 10
- winetest in Wine, of course
- microkiri https://bugs.winehq.org/show_bug.cgi?id=9127#c102
- Wagamama High Spec Trial Edition https://wagahigh.com/download_trial.php#normal (ダウンロード means download)
- Ninki Seiyuu no Tsukurikata Trial https://archive.org/details/sayou_trial
(WMV files in microkiri and Wagamama don't work, but that's separate issues. Also, they need the LC_ALL=ja_JP env, or they throw various goofy errors.)
--
v17: quartz/tests: Add tests for CLSID_CMpegVideoCodec.
quartz/tests: Add tests for new CLSID_MPEG1Splitter functionality.
winegstreamer: Implement CLSID_CMpegVideoCodec.
winegstreamer: Add program stream and video output support to CLSID_MPEG1Splitter.
winegstreamer: Add WG_MAJOR_TYPE_VIDEO_MPEG1 media type.
winegstreamer: Use the new output_compressed property instead of mpegaudioparse in MPEG splitter.
winegstreamer: Add output_compressed parameter to wg_parser_create().
winegstreamer: Implement parts of IAMStreamSelect::Info in CLSID_MPEG1Splitter.
winegstreamer: Implement IAMStreamSelect::Count in CLSID_MPEG1Splitter.
winegstreamer: Improve and clean up some debug logs.
winegstreamer: Include the framerate when converting video format to GstCaps.
winegstreamer: Seek to end of stream instead of to stream duration.
winegstreamer: Clamp QoS events to stay inside the stream's running time.
winegstreamer: Don't read format from unparsed MPEG audio.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v21: vkd3d-shader/tpf: Write out 'switch' statements.
vkd3d-shader/hlsl: Add a pass to normalize switch cases blocks.
vkd3d-shader/hlsl: Add a pass to remove unreachable code.
vkd3d-shader/hlsl: Add copy propagation logic for switches.
vkd3d-shader/hlsl: Validate break/continue context.
vkd3d-shader/hlsl: Check for duplicate case statements.
vkd3d-shader/hlsl: Add initial support for parsing 'switch' statements.
tests: Add some tests for the 'switch' statements.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/361
Resolves https://bugs.winehq.org/show_bug.cgi?id=9127 . (Some of the named programs in that issue may require additional currently-missing functionality, I didn't check; but if so, that's separate issues.)
Tested with
- winetest on Windows 7
- winetest on Windows 10
- winetest in Wine, of course
- microkiri https://bugs.winehq.org/show_bug.cgi?id=9127#c102
- Wagamama High Spec Trial Edition https://wagahigh.com/download_trial.php#normal (ダウンロード means download)
- Ninki Seiyuu no Tsukurikata Trial https://archive.org/details/sayou_trial
(WMV files in microkiri and Wagamama don't work, but that's separate issues. Also, they need the LC_ALL=ja_JP env, or they throw various goofy errors.)
--
v16: quartz/tests: Add tests for CLSID_CMpegVideoCodec.
quartz/tests: Add tests for new CLSID_MPEG1Splitter functionality.
winegstreamer: Improve and clean up some debug logs.
winegstreamer: Include the framerate when converting video format to GstCaps.
winegstreamer: Don't read format from unparsed MPEG audio.
winegstreamer: Seek to end of stream instead of to stream duration.
winegstreamer: Implement parts of IAMStreamSelect::Info in CLSID_MPEG1Splitter.
winegstreamer: Implement IAMStreamSelect::Count in CLSID_MPEG1Splitter.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938
The application crashes when attempting to load fonts internally, especially those with watermark functionalities. Reset the installedFontCollection.count field to zero upon release.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4138
A few recent changes broke the macOS build. Unfortunately nobody noticed, because the macOS CI job always fails. :-(
However, we can still fix that. I'm not sure that the last commit is the best approach, would like to have comments from Henri.
--
v2: include: Import vkd3d_d3dcompiler.h instead of redefining D3D_BLOB_PART.
vkd3d-shader: Explicitly cast vkd3d_shader_global_flags to uint64_t.
ci: Allow the artifact copy to fail.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/423
A few recent changes broke the macOS build. Unfortunately nobody noticed, because the macOS CI job always fails. :-(
However, we can still fix that. I'm not sure that the second commit is the best approach, would like to have comments from Henri.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/423
@afrantzis Can't seem to be possible to add you as a reviewer, probably you need to request "Access" to the wine/wine project (near the top of the project page).
What do you think of something like that? It is very different from the current winex11 code, but I believe it will match keyboard layouts in a much more accurate way, and it's also IMO much simpler. If that works well with Wayland, I think it could be a good hint that it might work as well in X11 and make a case for my other MR to use that approach there.
I was a bit annoyed that it doesn't seem possible to retrieve the Xkb "layout:variant" string here, but only the layout description, so I had to use xkbregistry to match it back to the known layouts.
It is mostly only there to provide a more accurate HKL value (which should match the layout langid), and scan to vk mapping table, and custom layouts should still work. The lang would be neutral then, and the scan to vk table is QWERTY by default, which is the most common case, and doesn't enforce any vkey -> unicode mapping anyway. So, if the xkbregistry dependency is an issue we could probably make it optional and dynamically loaded, and skip the langid and scan to vk specialized mappings.
--
v2: winewayland.drv: Implement Xkb composition using ImeProcessKey.
winewayland.drv: Translate Xkb keyboard layouts to KBDTABLES.
win32u: Allow KBDTABLES conversion from CTLR + ALT to WCHAR.
win32u: Force US layout in ToUnicode when CTRL is pressed.
win32u: Introduce KbdLayerDescriptor user driver entry.
win32u: Avoid accessing NULL key name string pointer.
winewayland.drv: Enumerate Xkb layouts and create matching HKL.
winewayland.drv: Handle and parse Xkb keymap events.
win32u: Implement opt-in auto-repeat for WM_(SYS)KEYDOWN messages.
winewayland.drv: Configure win32u keyboard repeat delay and speed.
winewayland.drv: Basic handling of Wayland keyboard events.
gitlab: Install libxkbcommon and libxkbregistry dependencies.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4102
Yeah, but this isn't necessarily about not trusting Windows apps, i.e. malice or malware, but rather that they can't be designed around it (since they assume Windows environment), so they would have privacy issues without even wanting to. At the very least maybe use `sd_id128_get_machine_app_specific` with a unique app ID for Wine? Simple and still better than nothing.
Otherwise, it would probably have to be done per-prefix (registry?), since two processes in the same prefix might want the same ID.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49432
--
v6: user32: Pass real argument to NtUserGetClassName in RealGetWindowClass{A/W}.
win32u: Add support for retrieving real window class ID across processes.
user32: Set real window class ID for user32 static controls.
win32u/tests: Add a test for real window class name retrieval.
comctl32/tests: Add tests for RealGetWindowClass.
user32/tests: Add tests for RealGetWindowClass.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4092
This allows *BSDs to also have a fast path similar to futexes for thread-ID alerts.
Also a kevent with `EV_CLEAR` and `NOTE_TRIGGER` maps perfectly to the thread alertable state, fixing the issue of the current mach-semaphore implementation not correctly waiting in the test case below:
```
NtAlertThreadByThreadId((HANDLE)GetCurrentThreadId());
NtAlertThreadByThreadId((HANDLE)GetCurrentThreadId());
NtWaitForAlertByThreadId(NULL, NULL);
NtWaitForAlertByThreadId(NULL, NULL);
```
I took the liberty to remove this mach semaphore implementation, since all versions of OSX have supported kqueue().
--
v6: ntdll: Implement thread-ID alerts using kqueue/kevent.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4049
Using a dedicated exit jmpbuf and removing the need for assembly
routines.
When Wine handles an exception in unix code, we return to user mode by
jumping to the last syscall frame. This can leave some pthread cancel
cleanups registered, in the pthread internal linked list, and at the
same time later overwrite the stack frame they were registered for.
In the same way, jumping to the exit frame on thread exit or abort, can
also leave some cleanup handlers registered for invalid stack frames.
Depending on the implementation, calling pthread_exit will cause all the
registered pthread cleanup handlers to be called, possibly jumping back
to now overwritten stack frames and causing segmentation faults.
Exiting a pthread normally, by returning from its procedure, or calling
exit(0) for the main thread doesn't run pthread_exit and doesn't call
cleanup handlers, avoiding that situation.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213
### Additional note:
For robustness, we should probably try to execute these cleanup handlers
when unwinding the stack frames, as we would otherwise leave pthread
objects in a potential problematic state (like a mutex locked, etc).
It is however hard to do so when the handlers are registered from some C
code: pthread C implementation is done by calling some internal pthread
functions to register the handlers, and they aren't registered as
standard unwind handlers.
Only pthread_cancel and pthread_exit can unwind and call / unregister
the C handlers, but interrupting that procedure, for instance calling
setjmp / longjmp from withing our own handler isn't supported.
From C++ code, pthread cleanup handlers are registered through C++ class
constructors / destructors, and it would then be possible to partially
unwind and call them at the same time.
--
v10: ntdll: Remove now unnecessary arch-specific exit frame.
ntdll: Avoid calling pthread_exit from abort_thread.
ntdll: Avoid calling abort_thread from the signal stack.
ntdll: Use is_inside_syscall more consistently.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1088
Resolves https://bugs.winehq.org/show_bug.cgi?id=9127 . (Some of the named programs in that issue may require additional currently-missing functionality, I didn't check; but if so, that's separate issues.)
Tested with
- winetest on Windows 7
- winetest on Windows 10
- winetest in Wine, of course
- microkiri https://bugs.winehq.org/show_bug.cgi?id=9127#c102
- Wagamama High Spec Trial Edition https://wagahigh.com/download_trial.php#normal (ダウンロード means download)
- Ninki Seiyuu no Tsukurikata Trial https://archive.org/details/sayou_trial
(WMV files in microkiri and Wagamama don't work, but that's separate issues. Also, they need the LC_ALL=ja_JP env, or they throw various goofy errors.)
--
v15: quartz/tests: Add tests for CLSID_CMpegVideoCodec.
quartz/tests: Add tests for new CLSID_MPEG1Splitter functionality.
winegstreamer: Improve and clean up some debug logs.
winegstreamer: Include the framerate when converting video format to GstCaps.
winegstreamer: Don't read format from unparsed MPEG audio.
winegstreamer: Seek to end of stream instead of to stream duration.
winegstreamer: Implement a little more of IAMStreamSelect in CLSID_MPEG1Splitter.
winegstreamer: Implement CLSID_CMpegVideoCodec.
winegstreamer: Add program stream and video output support to CLSID_MPEG1Splitter.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938
--
v2: d2d1: Don't cast D2D1_THREADING_MODE to D2D1_FACTORY_TYPE in D2D1CreateDevice.
d2d1: Pass interpolation mode as D2D1_INTERPOLATION_MODE to d2d_device_context_draw_bitmap.
d2d1/tests: Use D2D1_INTERPOLATION_MODE constants in DrawImage calls.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4135
Resolves https://bugs.winehq.org/show_bug.cgi?id=9127 . (Some of the named programs in that issue may require additional currently-missing functionality, I didn't check; but if so, that's separate issues.)
Tested with
- winetest on Windows 7
- winetest on Windows 10
- winetest in Wine, of course
- microkiri https://bugs.winehq.org/show_bug.cgi?id=9127#c102
- Wagamama High Spec Trial Edition https://wagahigh.com/download_trial.php#normal (ダウンロード means download)
- Ninki Seiyuu no Tsukurikata Trial https://archive.org/details/sayou_trial
(WMV files in microkiri and Wagamama don't work, but that's separate issues. Also, they need the LC_ALL=ja_JP env, or they throw various goofy errors.)
--
v14: quartz/tests: Add tests for CLSID_CMpegVideoCodec.
quartz/tests: Add tests for new CLSID_MPEG1Splitter functionality.
winegstreamer: Improve and clean up some debug logs.
winegstreamer: Include the framerate when converting video format to GstCaps.
winegstreamer: Don't read format from unparsed MPEG audio.
winegstreamer: Seek to end of stream instead of to stream duration.
winegstreamer: Implement a little more of IAMStreamSelect in CLSID_MPEG1Splitter.
winegstreamer: Implement CLSID_CMpegVideoCodec.
winegstreamer: Add program stream and video output support to CLSID_MPEG1Splitter.
winegstreamer: Fill in video media type a bit better.
winegstreamer: Add WG_MAJOR_TYPE_VIDEO_MPEG1 media type.
winegstreamer: Use the new output_compressed property instead of mpegaudioparse in MPEG splitter.
winegstreamer: Add output_compressed parameter to wg_parser_create().
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v4: vkd3d-shader: Add constant folding for 'floor'.
vkd3d-shader: Add a missing entry to instruction debug print helper.
vkd3d-shader: Add constant folding for 'ceil'.
vkd3d-shader: Add support for floor() on SM1-3.
vkd3d-shader: Add support for ceil() on SM1-3.
vkd3d-shader/tpf: Add support for ceil().
vkd3d-shader/hlsl: Parse ceil() function.
tests: Add some tests for ceil().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/417
We used to have some hack for passing information (mainlyi
module related ones) from dbghelp to WineDbg.
This series:
- reimplements properly the sharing, introducing a Wine
entrypoint to dbghelp (sharing debug formats not handled
by native, no longer decorating module names for sharing
that module was in fact a host module...)
- improves "info share" command in WineDbg with more accurate
information (host module type...)
- improves loading time on MacOs (some system libraries no
longer have their images accessible directly on disk by
standard file operation).
--
v2: dbghelp: Pretend mach-o is present in case of failure.
dbghelp: Expose PE native vs builtin information to winedbg.
dbghelp,winedbg: No longer decorate ELF/Mach-O module names.
dbghelp: Expose some internal information about modules to winedbg.
dbghelp: Remove DMT_ entries for .DBG and .PDB files.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4142
It wasn't Project Kunai. I know that Office 2010 uses SMBIOS values in its activation process and I remember adding support for retrieving the disk serial number through an IOCTL for another app, which is equally sensitive BTW. Like Zeb said, there's no end of measures to be taken if we can't trust the Windows app. It's something better handled outside of Wine.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49386
On Thu Oct 19 14:52:17 2023 +0000, Hans Leidekker wrote:
> sd_id128_get_machine_app_specific() requires cooperation from the app.
> That's not something we can expect from Windows apps. Windows apps
> should treat this information with confidentiality just like Linux apps.
> The game whose name I forgot collected several more or less unique IDs
> and calculated a hash over those values.
I'm referring to Unix apps.
was the game Project Kunai?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49382
typelib has an array size of 2 (eg LibXml_Last), so a lookup
of IID_NULL will result in a lookup of the third index.
--
v2: msxml3: Free IBindCtx on error paths (Coverity)
msxml3: Move tid_NULL out of possible enum values.
msxml3: Dont call qsort if we have no data (Coverity).
https://gitlab.winehq.org/wine/wine/-/merge_requests/4073
On Mon Oct 16 23:45:47 2023 +0000, Zebediah Figura wrote:
> This may be correct (although I'm curious if it actually matters here?)
> but should be a separate patch.
It does matter, gst_pad_push returns GST_FLOW_NOT_NEGOTIATED if I omit it.
Separate commit, sure, if you say so.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49357
On Fri Oct 20 01:24:23 2023 +0000, Zebediah Figura wrote:
> Hi, really sorry about the very late review on this one (I was out for a
> while, and then spent a lot of time catching up on review while I was
> out, and then trying to get some more important Wine work done...)
> 2/7, seeking parts aside, is broadly doing the right thing (from my
> perspective) but I would like to see it arranged differently. What I
> would like to see is something like the following, in a series of
> individual patches:
> * Introduce a wg_parser_create option to use the encoded format; this
> should end up being translated to "chain_decodebins" basically as you
> have it. I would also rename that to something like "output_compressed"
> (with inverted meaning).
> Note that in this case autoplug-continue already does what we want,
> you shouldn't need to set the "caps" property on top of that.
> * Use this property, plus WG_PARSER_DECODEBIN, in the existing frontend
> instead of WG_PARSER_MPEGAUDIOPARSE. Delete WG_PARSER_MPEGAUDIOPARSE.
> * Ideally patch 1/7 should be moved from the beginning of the series to here.
> * Add MPEG-1 system stream support to the quartz frontend.
Yes, IRL stuff is always in the way (from us internet folks' perspective), and code review isn't the most exciting task.
I don't understand the point of that autoplug-continue handler. It looks like it says "yep, I want this" for certain formats, then it turns around and says "no, I don't want this after all, decode it again" in the pad-added signal. I'm sure that complexity exists for some reason, otherwise someone would've deleted it long ago, but...
But I don't need to understand it, as long as someone does.
This took me longer to implement than I expected, didn't expect you to be this thorough. Sure helps to have a pair of fresh eyes on it. Worth the wait (though it would've helped to have known how long it'd take).
I think I fixed everything (except those with follow-up questions), but some changes are pretty big and/or not exactly what you were thinking of, so I suspect you'll have another set of remarks.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49356
On Mon Oct 16 23:45:56 2023 +0000, Zebediah Figura wrote:
> This probably needs to take the filter CS. Same for Info() for that matter.
You sure? There's no reference to filter_cs in dlls/quartz/ or dlls/winegstreamer/, except in VMR; it's mostly used in libs/strmbase/. Is this specific interface different? Or maybe they're all buggy?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49352
On Mon Oct 16 23:45:59 2023 +0000, Zebediah Figura wrote:
> If Windows never sets the sample time for video samples after the first
> then we should probably make this check more restrictive to explicitly
> check that.
It's Complicated™
(Apologies if you know some of this already, better too much information than too little.)
The MPEG video format contains two layers of framing - the program stream tells which bytes are audio and which are video, but it's just arbitrarily arranged bytes, with no relation to video frame boundaries.
Windows' MPEG splitter parses the program stream, reads the first few bytes of the video stream (the codec data) to determine image size, and emits that. Determining the frame boundaries is the video codec's job.
GStreamer's mpegpsdemux doesn't read the codec data because why would it. To make the splitter's media type contain image size, I needed to put the mpegvideoparse on this side.
Which means that, unlike Windows, each submitted packet is exactly one frame.
```
Windows
video0 hr=00000000 len=1214
audio0 hr=00000000 len=2037
audio1 hr=00000000 len=2037
audio2 hr=00000000 len=2025
audio3 hr=00000000 len=2025
audio4 hr=80040249 len=653
Wine
video0 hr=00000000 len=859
audio0 hr=00000000 len=1253
video1 hr=80040249 len=195
audio1 hr=00000000 len=1254
video2 hr=80040249 len=84
audio2 hr=00000000 len=1254
video3 hr=80040249 len=76
audio3 hr=00000000 len=1254
audio4 hr=00000000 len=1254
audio5 hr=00000000 len=1254
audio6 hr=00000000 len=1254
```
Yes, it's messy, but I don't think we can do any better unless I move the mpegvideoparse into the codec object. Which would be more accurate to native, but it would require writing my own decoder for the codec data, would require reintroducing <https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_46588>, and would improve nothing except our test suite.
That said, the VFW_S_NO_STOP_TIME check catches nothing. I'll drop it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49353
On Mon Oct 16 23:46:01 2023 +0000, Zebediah Figura wrote:
> Shouldn't we get an exact number of frames here? Or is that not
> consistent somehow?
Yes, it's inconsistent. Wine emits two frames; native only emits one, probably because the graph is paused.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49354
On Mon Oct 16 23:46:02 2023 +0000, Zebediah Figura wrote:
> Can you please also check (at least the return value of)
> IMediaSample::GetMediaType()? I'm rather curious if it's updated or not.
It just returns S_FALSE every frame (which means unchanged since previous sample).
Sure, let's test it, no reason not to.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49355
On Mon Oct 16 23:46:06 2023 +0000, Zebediah Figura wrote:
> Usually enum values are capitalized; also, _t is usually reserved for
> typedefs. That said, do we even want this enum? Is there any instance
> where we shouldn't just iterate over the whole array?
> Two of these formats are todo, but I think something like "todo_wine_if
> (i == 1 || i == 8)" would be fine.
Turns out that no, we don't. Every piece either should test every supported format, or uses only one format and doesn't care which, so it might as well use (or copy) the hardcoded YUY2 one. (Except the RGB8 check in init_video_mt, but I can just switch that to check something else.)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49351
On Mon Oct 16 23:46:01 2023 +0000, Zebediah Figura wrote:
> Wait, so is the data here generated with ffmpeg or GStreamer?
Both. ffmpeg to generate a black video, then GStreamer to demux it and emit only the video elementary stream.
Guess I should rewrite it to GStreamer only.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49350
On Mon Oct 16 23:45:52 2023 +0000, Zebediah Figura wrote:
> We have amt_from_wg_format(), that should be usable here.
Good point. It fills in a few fields in unexpected ways, but most are correct, so it's an improvement. And some of the incorrect fields look like omissions in that function, which are better fixed there.
I tried running some tests locally, to check if something depends on the previous definition, but one failed because I compiled Wine without SChannel, another hit an assertion because I compiled without Vulkan, and several of them create windows all over which steal focus and make it hard to do anything else on the computer. I'll just leave that check for the CI. (And hope I don't miss it between the flaky tests already in master.)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49348
On Mon Oct 16 23:45:45 2023 +0000, Zebediah Figura wrote:
> This is correct, I think, but also orthogonal to the purpose of this
> patch. Can you please split this out into a separate patch?
I hope it doesn't mess with the decodebin chaining thing. But the mpegsplit and mpegvideo tests pass, so probably no big deal.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49344
On Mon Oct 16 23:45:46 2023 +0000, Zebediah Figura wrote:
> Isn't this redundant with the same logic done in wg_parser_stream_seek()?
Only if wg_parser_stream_seek has access to the duration.
Which, uh, it does, so let's just force push that and pretend it didn't happen.
(On a totally related note, GST_ERROR/etc shouldn't end with \n. I'll go clean that up too.)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49345
On Mon Oct 16 23:45:56 2023 +0000, Zebediah Figura wrote:
> Does the application actually use IAMStreamSelect::Info()? If so we
> should have tests for it. Also, ideally this'd be a separate patch.
> If not I'd just drop this hunk.
Does "it calls the function, but doesn't really do anything with the result" count? https://github.com/krkrz/krkr2/blob/dec49af97e174d31059c3ccd7efc700ba3c6b78…
It would be satisfied if IStreamSelect::Count was a semi-stub that just returns zero, but I suspect that's not the best idea.
But tests, yes, absolutely.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49346
On Mon Oct 16 23:45:47 2023 +0000, Zebediah Figura wrote:
> That doesn't seem right. What is this doing?
It silences these warnings from the Wagamama demo:
```
(wine:1578450): GStreamer-CRITICAL **: 01:44:15.602: gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
0:00:00.608062458 1578450 0x7f9190049ef0 ERROR WINE dlls/winegstreamer/wg_parser.c:486:wg_parser_stream_notify_qos: Failed to create QOS event.
(wine:1578450): GStreamer-CRITICAL **: 01:44:15.602: gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
```
But like the format change thing, it doesn't seem to do any actual harm. And I agree it is a weird solution. I guess it's safest to remove it and leave it for later.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49347
On Mon Oct 16 23:45:45 2023 +0000, Zebediah Figura wrote:
> This is overestimation because we can't do any better, right? In that
> case it probably deserves a comment just to clarify that's what's happening.
Yeah, that entire function is confusing. It's supposed to return the max size of a compressed frame, but I don't think there is any real upper bound for that, you can cram in as many optional extensions as you want.
So yes, it's guessing decompressed size as an upper bound. It'll break for 1x1 videos (can't fit the MPEG headers in three bytes), and videos crammed full of junk data, but let's just not care about those.
But comments, sure, can do. And the Cinepak branch's comment is suspicious at best - what does biSizeImage have to do with compressed size?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49343
On Thu Oct 19 13:43:21 2023 +0000, Francisco Casas wrote:
> Oh no, you are right, compiling with the native compiler and running on
> Windows we get those broken results, so it is not a problem of the
> compiler itself.
Repeating what we concluded via chat. The reason this test is giving broken results is that, even if `u` is `int4`, the SM1 backend expects to receive it formatted as an IEEE Standard 754 float, so the shader runner should pass it formatted that way.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/417#note_49315
--
v5: user32: Pass real argument to NtUserGetClassName in RealGetWindowClass{A/W}.
win32u: Add support for retrieving real window class ID across processes.
user32: Set real window class ID for user32 static controls.
win32u/tests: Add a test for real window class name retrieval.
comctl32/tests: Add tests for RealGetWindowClass.
user32/tests: Add tests for RealGetWindowClass.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4092
On Thu Oct 19 14:27:02 2023 +0000, eric pouech wrote:
> should have embedded it inside **sd_id128_get_machine_app_specific**
> (removing the machine-id parameter)
> you mean derive by keeping readable a field explicitely marked as non
> public !!!
sd_id128_get_machine_app_specific() requires cooperation from the app. That's not something we can expect from Windows apps. Windows apps should treat this information with confidentiality just like Linux apps. The game whose name I forgot collected several more or less unique IDs and calculated a hash over those values.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49305
On Thu Oct 19 14:27:02 2023 +0000, Hans Leidekker wrote:
> What should applications have used if /etc/machine-id wasn't readable?
> I think it's fine to derive the missing fields from machine-id.
should have embedded it inside **sd_id128_get_machine_app_specific** (removing the machine-id parameter)
you mean derive by keeping readable a field explicitely marked as non public !!!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49304
The PE build uses FlsAlloc(), which for our purposes makes no difference vs TlsAlloc(), and allows the use of a destruction callback.
--
v6: vkd3d: Replace the descriptor object cache with a thread-local implementation.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/384
On Thu Oct 19 13:35:46 2023 +0000, Francisco Casas wrote:
> I see. So the `probe` part may be deserving of a `todo(sm<4)`.
> I made patches for that on the second part of !418, but I think that for
> now it is okay to leave the requirement.
Oh no, you are right, compiling with the native compiler and running on Windows we get those broken results, so it is not a problem of the compiler itself.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/417#note_49297