diff mbox series

[FFmpeg-devel,v9,5/6] fftools: Enable long path support on Windows (fixes #8885)

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

Checks

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

Commit Message

Nil Admirari April 15, 2022, 8:07 a.m. UTC
---
 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

Comments

Martin Storsjö April 20, 2022, 11:46 a.m. UTC | #1
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
Nil Admirari April 23, 2022, 9:21 p.m. UTC | #2
> 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 mbox series

Patch

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"