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

[nil-admirari at mailo.com]

> Yes, because there is no realistic case in which ffmpeg will need
> to load any dll from a long path.
> I've asked you multiple times to give an example.

Managed to find time to actually test: https://postimg.cc/F1C64nq1.
Windows 10 21H2 LTSC, long paths are enabled and 8.3 paths are disabled
via group policy.

CMD is capable of starting applications from long paths: test app prints get_module_filename().
As can be seen from the output, module path is an actual long path, not 8.3 short name.
Windows is clearly capable of running apps from long paths. Always was
via the first argument to CreateProcess, prefixed with your favourite \\?\.
This facility is no longer esoteric and is available to end users via CMD.

FFmpeg in its current form doesn't work when started from a long path,
even with these patches. It prints nothing and just returns a non-zero exit code.
That's a problem with FFmpeg. Something in FFmpeg startup breaks down
when running from a long path, though it's not clear exactly what.

You're talking about realistic use cases as if someone made a careful analysis
of use cases before putting the limit in place. No one did, the limit came from the OS.
OS no longer has this limit, so neither should FFmpeg.

> So, ffmpeg should implement something that doesn't work without a
> registry change in order to "pressure Microsoft" to change it at
> some point in the future?

Things are implemented in order to provide features, not to pressure someone.
You still have to abide by API's contract, however. Long paths are enabled
by a registry tweak, and that's how things are.

> I apologize when I have created the impression that ffmpeg should
> be left as is and users should continue adding the long path prefix
> themselves. I'm not opposed to adding support for long paths, I'm
> just opposed to the method.

As a matter of fact, you are. Your alternative method implies ploughing
through hundreds of C files normalising path handling across the entire application,
and then fixing numerous regressions introduced along the way. No one is doing that,
just too much work. Manifest is the only practically implementable solution,
and if it's not accepted, FFmpeg stays as it is and users are forced to continue
to manually prefix all paths.

Of course, if you think so strongly that \\?\ is the right way to go,
then how about writing the necessary patches yourself?

And even then I have some bad news for you. MAX_PATH-sized buffers simply do not work
with long paths, even the ones that start with \\?\. You will still have to replace
them with dynamically allocated buffers. And that's what the majority of this patch-set
is about, not about the manifest. Manifest is just a single patch.

> Implementing long path support by adding the prefix is not
> a "workaround". Those kinds of paths are part of OS functionality
> since Windows NT and will still work in Windows 20 or whatever
> may come.

It is and always was. \\?\ support none of the usual path handling
such as relative paths, slash-collapsing, removal of . from paths etc.

> Because with the first, you cannot rely that long paths are
> working, you would be stuck needing to continue prefixing paths
> manually "forever".
> (to also cover cases where it's not working)

No one is prefixing the paths. Neither end users, nor application writers.
If it doesn't work without a prefix, it doesn't work at all, and you end up
without any long path support whatsoever.

> IIRC this code is handling code paths relative to the executable path,
> and the executable doesn't run from a long path anyway.

Because it's broken in FFmpeg, not because you cannot run an app from a long path.
See above.

> > This patchset does not provide reliable behavior.
> ...
> You know what I meant: it's not activated by default.

Not active by default is not the same as not reliable.

> What is in the hands of ffmpeg though, is requiring a change which
> needs administrative privileges or not.

It doesn't require administrative rights. It requires a registry tweak.
If you don't have admin rights but still need the feature, you can ask
your system administrator.

> I don't want to argue about the term lottery.

You're perfectly willing to use it.

> What I'm saying is that a solution is preferable which doesn't have
> an "Otherwise it doesn't" part.

As Thomas Sowell has put it: "There are no solutions. There are only trade-offs."
Do not pretend that \\?\ is even practical, considering the scope of changes required
to implement it.