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

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

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.

> +  <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"

Regards,
Tobias

On Tue, Apr 26, 2022 at 9:08 AM Tobias Rapp <t.rapp@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

On 26/04/2022 09:29, Hendrik Leppkes wrote:
> On Tue, Apr 26, 2022 at 9:08 AM Tobias Rapp <t.rapp@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.

Alright then, thanks for the clarification.

Regards, Tobias

> 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?

Version is a required attribute, see https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests. It does not have any meaning, but some value has to be provided, and "1.0.0.0" is as good a value as any (version must be in major.minor.build.revision format: https://docs.microsoft.com/en-us/windows/win32/sbscs/assembly-versions).

"5.1.n.m" must be either manually updated or regenerated with something like "ffmpeg/tools/gen-rc". Both approaches are more laborious than just "1.0.0.0".