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

[Hendrik Leppkes]

On Tue, Apr 26, 2022 at 9:08 AM Tobias Rapp <t.rapp at noa-archive.com> wrote:
>
> On 23/04/2022 22:56, Nil Admirari wrote:
> > 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.
> >
> > Application must be prepared to handle filenames greater than MAX_PATH.
> > 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 where:
> > 1. filename length was restricted to MAX_PATH
> > 2. files were opened using ANSI functions.
> >
> > On older versions of Windows, the newly added manifest has no effect.
> > ---
> >   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
> >
> > 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"/>
>
> What is the effect of the version attribute here? Would it be meaningful
> to replace the static dummy value with something more realistic like
> "5.1.n" or similar?
>
> Just asking as I'm not very familiar with manifest resources.
>

The assembly version does not have any important meaning, not for
assemblies used in this manner. It would only matter if you were to
reference other assemblies across files, which is not done for these
application settings - and even then the only real importance would be
to increment it when its changed in an incompatible manner, not
necessarily linked to the application version, which is stored in a
resource file instead of the assembly.

- Hendrik