Message ID | 20220415080748.18517-5-nil-admirari@mailo.com |
---|---|
State | New |
Headers | show |
Series | [FFmpeg-devel,v9,1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi | expand |
Context | Check | Description |
---|---|---|
yinshiyou/make_loongarch64 | success | Make finished |
yinshiyou/make_fate_loongarch64 | success | Make fate finished |
andriy/make_x86 | success | Make finished |
andriy/make_fate_x86 | success | Make fate finished |
On Fri, 15 Apr 2022, Nil Admirari wrote: > --- > fftools/Makefile | 5 +++++ > fftools/fftools.manifest | 10 ++++++++++ > fftools/manifest.rc | 3 +++ > 3 files changed, 18 insertions(+) > create mode 100644 fftools/fftools.manifest > create mode 100644 fftools/manifest.rc I think the change here is fine, but the commit message absolutely needs to explain the full situation about what this does, how, etc. As far as I've understood Windows long path support, it'd be something like this: ---8<--- Newer versions of Windows (Windows 10 1607 and newer) can support path names longer than MAX_PATH (260 characters). To take advantage of that, an application needs to opt in, by including a small manifest as a resource. Additionally, the path length limitation is only lifted for file APIs that pass paths as wchar_t. Therefore, the preceding patches have refactored a few remaining cases to internally open files with wchar_t path name functions. On older versions of Windows, the newly added manifest has no effect. ---8<--- Does that sound like the correct explanation of the situation? // Martin
> Does that sound like the correct explanation of the situation?
Yes, thanks. I altered the suggested message a bit.
New version of the patch: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295571.html.
diff --git a/fftools/Makefile b/fftools/Makefile index 81ad6c4f..105ae5cc 100644 --- a/fftools/Makefile +++ b/fftools/Makefile @@ -15,6 +15,11 @@ OBJS-ffmpeg += \ fftools/ffmpeg_mux.o \ fftools/ffmpeg_opt.o \ +# Windows resource files +OBJS-ffmpeg-$(HAVE_GNU_WINDRES) += fftools/manifest.o +OBJS-ffplay-$(HAVE_GNU_WINDRES) += fftools/manifest.o +OBJS-ffprobe-$(HAVE_GNU_WINDRES) += fftools/manifest.o + define DOFFTOOL OBJS-$(1) += fftools/cmdutils.o fftools/opt_common.o fftools/$(1).o $(OBJS-$(1)-yes) $(1)$(PROGSSUF)_g$(EXESUF): $$(OBJS-$(1)) diff --git a/fftools/fftools.manifest b/fftools/fftools.manifest new file mode 100644 index 00000000..30b7d8fe --- /dev/null +++ b/fftools/fftools.manifest @@ -0,0 +1,10 @@ +<?xml version="1.0" encoding="UTF-8" standalone="yes"?> + +<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> + <assemblyIdentity type="win32" name="FFmpeg" version="1.0.0.0"/> + <application xmlns="urn:schemas-microsoft-com:asm.v3"> + <windowsSettings xmlns:ws2016="http://schemas.microsoft.com/SMI/2016/WindowsSettings"> + <ws2016:longPathAware>true</ws2016:longPathAware> + </windowsSettings> + </application> +</assembly> diff --git a/fftools/manifest.rc b/fftools/manifest.rc new file mode 100644 index 00000000..e436fa73 --- /dev/null +++ b/fftools/manifest.rc @@ -0,0 +1,3 @@ +#include <windows.h> + +CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "fftools.manifest"