Do we really need mpv.com on Windows? about mpv

[kasper93]

No, we cannot retire mpv.com. It is age old topic. There are workarounds, and we are using the best one. It is not supported use-case by Windows kernel. https://devblogs.microsoft.com/oldnewthing/20090101-00/?p=19643

It is explained here why it is bad idea to use GUI mode always. #13011 (comment)

Alternatively it is bad idea to use Console mode always, as best we can do is to hide console window in this case and this produces annoying flicker.

I have dilemma to choose between launching mpv.exe and mpv.com: the former hits the breakpoints, but can't print any log message to the terminal, while the latter does the opposite.

Change subsystem to console and always use mpv.exe

diff --git a/meson.build b/meson.build
index 1a89094df0..fd4efb1f20 100644
--- a/meson.build
+++ b/meson.build
@@ -1803,7 +1803,7 @@ if get_option('cplayer')
     install_data('etc/mpv-symbolic.svg', install_dir: join_paths(hicolor_dir, 'symbolic', 'apps'))

     mpv = executable('mpv', main_fn_source, objects: libmpv.extract_all_objects(recursive: true), dependencies: dependencies,
-                     win_subsystem: 'windows', install: true)
+                     win_subsystem: 'console', install: true)

     # Older meson versions generate this in the player subdirectory.
     if win32 and meson.version().version_compare('>= 1.3.0')

[CrendKing]

Thanks for the links. If I understand correctly, the main limitation of Windows over Linux is the lack of API to not only attach but take full control of parent process' console. And the console wrapper solution is good because it can use its own console to override the parent console, and wait out the wrapped sub-process.

If that's really the only reason, I'm a bit surprised why Windows can't offer such an API, provided that they have a otherwise fairly complete plethora of console manipulation utilities. But if Visual Studio itself has to use a .com trick, I guess the reason must be deep.

Thanks again. Closing.