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

[Tobias Rapp <t.rapp@noa-archive.com>]

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

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".