[FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object sharing issue on Windows

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Martin Storsjö
> Sent: Wednesday, April 20, 2022 2:48 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object sharing
> issue on Windows
> 
> Hi,
> 
> I just became aware of the av_fopen_utf8 function - which was
> introduced
> to fix path name translations on Windows - actually has a notable
> design
> flaw.

Hi Martin,

I just became aware that somebody would be compiling ffmpeg like 
this on Windows and I'm curious regarding the whereabouts..

> Background:
> 
> On Windows, a process can contain more than one C runtime (CRT); the
> system comes with two shared ones (UCRT and msvcrt.dll) and in MSVC
> builds, each DLL/EXE can have one statically linked in instead of
> linking
> against a shared library CRT (and that's actually the default
> configuration when building with MSVC).

The default configuration for both, EXE and DLL projects is to link
to the C runtime dynamically (crt dll).

> This means that CRT objects (file descriptors from open(), FILE*
> opened
> with fopen/fdopen) mustn't be shared across DLLs; such an object must
> be
> opened, accessed and closed within the same DLL.

This only happens when you explicitly modify the build configuration
to statically link to the CRT. 
It is generally discouraged to mix (or have multiple) CRTs in a single
process, but it's surely valid and there can be very good reasons to
do so. Yet, such reasons are typically about achieving a certain level
of independence between libraries and their dependencies and 
interdependencies.
What's probably a bit more unusual is to build libraries like the
ffmpeg libs which are very closely related and dependent in a way
that each of them has its own static copy of the CRT compiled into it.

I'm curious about two things:

Why are you compiling it this way?
Your earlier patch is from 2013, so you seem to be doing so for
quite a while.


Is the file API the only case where you had any trouble?

I don't have experience with that kind of setup, but I would have
thought that with separate CRTs, you could already get into trouble
when you would allocate a string in the main application which 
you pass to any of the DLL's APIs and which might get freed by
the DLL at a later time - doesn't that fail?

Kind regards,
softworkz