[FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi

[nil-admirari at mailo.com]

> 1. Patch 3/6 - Replace LoadLibraryExA with LoadLibraryExW
> What's the point in making changes to library loading? What does it fix?



>From the commit https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295571.html:

... the path length limitation is only lifted for file APIs that pass paths as wchar_t...



> 2. Patches 5/6 and 6/6 - Add Fusion Manifest

> ...

> Both of these manifest attributes are affecting the runtime behavior of
> an application running on Windows - but only starting from a certain 

> OS version.

> ...

> ... you would need to check the operating system version 

> before using to make sure that you are providing parameters in the "right"
> way - I'm not sure whether that would make much sense.



The same can be said about e.g. DirectX 11 hardware acceleration, which is available

only starting with Windows 7; and you have to check OS version before providing

parameters that enable it. Does not mean implementing that feature made no sense,

since it made FFmpeg inconsistent with previous versions of Windows. Consistency

with the greatest common denominator does not make much sense.



Considering that people from yt-dlp and StaxRip projects requested long paths feature,

looks like it does make sense to the users.



> 3. All Patches x/6 - Remove MAX_PATH limit
> The punch line sounds compelling. But how is the current situation and 

> what exactly would be the benefit?



All patches with that line replace MAX_PATH-sized buffers with dynamically-allocated

buffers of potentially arbitrary size. If application continues to use fixed-size buffers,

it's not long path aware, regardless of the manifest.


> As an example, the following command runs without issue on Windows 
> with a normal current ffmpeg build:

It simply moves the burden of long path support from FFmpeg to FFmpeg clients.



> All this is working in a predictable and reliable way on all common Windows

> versions.



It is neither predictable nor reliable. Please check https://googleprojectzero.blogspot.com/2016/02/the-definitive-guide-on-win32-to-nt.html

for things like “I actually exploited this behaviour to create

arbitrary named pipes from the Chrome sandbox awhile back.”

> 1. Windows version needs to be >= 1903
> (for being able to have both attributes in effect)



For all intents and purposes, versions of Windows < 1903 have EOLed. Exceptions:

- Windows 8.1 will EOL in January 2023,

- LTSB/LTSC branches of Windows 10 before 21H2.

None of these exceptions are particularly popular with users.



> 2. Application needs to be compiled with and manifest file as resource



Which is exactly what these patches are doing.



> 3. A registry key or group policy needs to be set on Windows to enable this
> ´ (in both cases, administrative permission/UAC is required to set it)
> 4. Even when registry key or group policy is set, it might still be pending

> a reboot



Is it a big deal to change a registry and reboot?


> On the other side, there's a risk of regressions by adding those manifest

> attributes.



Adding anything risks regressions, how manifest is supposed to be different

from any other patch?


> I wonder whether it wouldn’t be a better idea, to simply auto-add this prefix
> in the ffmpeg file handling code if:



Every command line argument that supplies a path needs to be updated.

Every filter with a file argument needs to be updated.

Code in https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295568.html

normalises a path to use '/' instead of '\\' for whatever reason, and it cannot use \\?\

since it requires backslashes.



How adding a prefix \\?\ is supposed to be simpler than replacing a couple of buffers?



> This would work on all common Windows versions and would be predictable and

> reliable.



See https://googleprojectzero.blogspot.com/2016/02/the-definitive-guide-on-win32-to-nt.html

for predictability and reliability.