Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Programming and Hacking > Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 12th September 2020, 11:05   #1  |  Link
stax76
Registered User
 
Join Date: Jun 2002
Posts: 6,489
Windows 10 long path support development

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.

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

Last edited by stax76; 12th September 2020 at 12:31.
stax76 is offline   Reply With Quote
Old 12th September 2020, 11:17   #2  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,146
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 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
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 12th September 2020 at 11:30.
LoRd_MuldeR is offline   Reply With Quote
Old 12th September 2020, 11:26   #3  |  Link
stax76
Registered User
 
Join Date: Jun 2002
Posts: 6,489
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
stax76 is offline   Reply With Quote
Old 12th September 2020, 12:05   #4  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,146
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 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.
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 12th September 2020 at 12:24.
LoRd_MuldeR is offline   Reply With Quote
Old 12th September 2020, 12:27   #5  |  Link
stax76
Registered User
 
Join Date: Jun 2002
Posts: 6,489
Quote:
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-auto...te/issues/1806


staxrip issue:

https://github.com/staxrip/staxrip/issues/338
stax76 is offline   Reply With Quote
Old 12th September 2020, 14:47   #6  |  Link
lvqcl
Registered User
 
Join Date: Aug 2015
Posts: 143
Current ffmpeg sources still have MAX_PATH in a few places. For example, inside win32_dlopen() function.
lvqcl is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:39.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.