Log in

View Full Version : Windows 10 long path support development


stax76
12th September 2020, 11:05
I've looked at a ffmpeg build made by Patman (media-autobuild_suite based I think) using Resource Hacker and it contains a manifest without long path support enabled.

My question is where is this manifest added? I've searched the ffmpeg and media-autobuild_suite source codes and couldn't find any manifest file. :confused:

https://github.com/staxrip/staxrip/issues/338

LoRd_MuldeR
12th September 2020, 11:17
The compiler/linker generates the manifest.

If you use MSVC, you can find some options in the project settings, at "Linker" → "Manifest File". Also, you can add .manifest files to the project and set the "Item Type" to "Manifest Tool", which will then merged your custom .manifest file into the auto-generated manifest. As far as GCC/MinGW is concerned, I think "modern" Mingw-w64 (e.g. via MSYS2) also generates a manifest by default. You could probably add your own manifest as a resource via windres (https://users.informatik.haw-hamburg.de/~krabat/FH-Labor/gnupro/5_GNUPro_Utilities/d_The_GNU_Binary_Utilities/windres.html) tool.

Anyhow, you can always edit the resources in an EXE file, including the manifest, with a tool like good ol' Resource Hacker:
http://www.angusj.com/resourcehacker/

Having said that, enabling "long path support" requires that the actual program code is prepared for that! If anywhere in the code there is an assumption that paths are no longer than MAX_PATH characters – which is a macro that expands to exactly 260 at compile-time, i.e. MAX_PATH is absolutely not detected at run-time – then enabling "long path support" probably is a great way to create buffer overflow vulnerabilities :scared:

stax76
12th September 2020, 11:26
So long path support has to be requested from the mabs project and not directly from the ffmpeg project?

https://github.com/m-ab-s/media-autobuild_suite

LoRd_MuldeR
12th September 2020, 12:05
First of all, you have to make sure that FFmpeg, all libraries used by FFmpeg (as far as they might be concerned with path strings) as well as the MinGW runtime libraries are "safe" for use with paths longer than MAX_PATH.

Then, in order to actually enable "long path support" via the manifest, the build process needs to be adjusted in order to generate a custom manifest file and add that to the EXE file as a resource, via the windres (https://users.informatik.haw-hamburg.de/~krabat/FH-Labor/gnupro/5_GNUPro_Utilities/d_The_GNU_Binary_Utilities/windres.html) tool – assuming you are building with the GCC/MinGW toolchain. To my understanding, "media-autobuild_suite" is just a bunch of helper scripts that make it easier to build FFmpeg on Windows, but it still uses the build files (Makefiles, configure scripts, etc.) provided by the original projects. Consequently, it would be preferable to adjust the build files directly in the FFmpeg project, so you don't have to patch in "long path support", every time you want to build FFmpeg on Windows.

stax76
12th September 2020, 12:27
First of all, you have to make sure that FFmpeg, all libraries used by FFmpeg (as far as they might be concerned with path strings) as well as the MinGW runtime libraries are "safe" for use with paths longer than MAX_PATH.

ffmpeg works with long path prefix \\?\ so it's probably already supported and only the manifest is missing.


mabs request:

https://github.com/m-ab-s/media-autobuild_suite/issues/1806


staxrip issue:

https://github.com/staxrip/staxrip/issues/338

lvqcl
12th September 2020, 14:47
Current ffmpeg sources still have MAX_PATH in a few places. For example, inside win32_dlopen() function.