Okay, I tried loading the FFmpeg DLLs manually. It turns out that it's impossible to avoid loading MSVCRT.DLL into the process. FFmpeg imports from ADVAPI.DLL and USER32.DLL. Those system DLLs in turn will bring in MSVCRT.DLL. Even if we link statically or rebuild FFmpeg in VC, MSVCRT.DLL will still get loaded.
While I see some value in not loading an extra C runtime, if it's going to be there irregardless, I don't think it's worth the trouble avoiding it. The likelihood of MSVCRT.DLL working for FFMPEG.EXE but somehow failing when the same code is used in a PHP extension is exceedingly low. I just don't see how that can happen. On Tue, Apr 22, 2014 at 9:53 PM, Anatol Belski <anatol....@belski.net>wrote: > On Tue, April 22, 2014 20:22, Chung Leong wrote: > > If loading msvcrt.dll is considered harmful, I guess I could just load > > the DLLs manually and redirect imports of functions in msvcrt.dll to the > > current CRT. It's never advisable to go that deep into an OS's internals > > but that's the only practical solution I see. > > > > I don't really think loading mscvrt is such a serious issue. I know how > > things can go haywired when you start passing file handle and malloc'ed > > memory from one CRT to another. As long as the CRT's don't interact, > > there should be no problem. The CRTs must be able to co-exist for Windows > > to work at all. I just did a scan of my SysWOW64. A total of 1416 DLLs > > imports mscvrt.dll, including such critical files as comdlg32.dll and > > usp10.dll. > > > > > > On Tue, Apr 22, 2014 at 6:37 PM, Anatol Belski > > <anatol....@belski.net>wrote: > > > > > >> Jan, Leong, > >> > >> > >> On Tue, April 22, 2014 17:09, Jan Ehrhardt wrote: > >> > >>> Pierre Joye in php.pecl.dev (Tue, 22 Apr 2014 16:47:29 +0200): > >>> > >>> > >>>> On Tue, Apr 22, 2014 at 4:28 PM, Jan Ehrhardt <php...@ehrhardt.nl> > >>>> wrote: > >>>> > >>>> > >>>>> There is hardly any way to avoid that. The extension will only be > >>>>> useable, if it produces at least MP4 (x264) output. This means > >>>>> ffmpeg has to be compiled with x264 support. And you cannot > >>>>> compile libx264 with native MSVC: > >>>> > >>>> Which means it links against the default crt, which is sadly the > >>>> VC6 > >>>> one, available by defatult on all windows install. > >>> > >>> True. But I do not see another possibility if you want to include > >>> libx264, except for exec() calls to ffmpeg.exe. If the FFmpeg API is > >>> straightforward that should not be a problem. > >>> > >>> The extension links to VC9 / VC11 libs that are created by dumpbin > >>> /exports, which enables the extension to call the publicly available > >>> functions of the libav*.dll's. A call to msvcrt.dll on the backend of > >>> the libav*.dll does not really matter, AFAIK. > >>> > >> It might look unavoidable and doable, but indeed it is a bad thing. You > >> can read more here > >> http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx . > >> Such things are not done on any other platforms, like on Linux there is > >> always one libc instance for all the packages. That is for example the > >> reason why we don't use the sqlite binaries produced by sqlite.org, see > >> bug #66968. I would never recommend something like that for > >> production, as you never know where it will bang. > >> > >> Best regards > >> > >> > >> Anatol > >> > >> > >> > >> -- > >> PECL development discussion Mailing List (http://pecl.php.net/) > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > >> > Yep, they also say on that page > > "The msvcrt.dll is now a "known DLL," meaning that it is a system > component owned and built by Windows. It is intended for future use only > by system-level components." > > and neither PHP nor ffmpeg are system-level. So that is not an issue for > components built by windows itself, but it can be it very much for > everything else. And that's what they say and you confirm :) msvcrt.dll > will be different on every different platform/edition and so on. Yes, > you're right - as long as they don't interact, it should work. But, > doesn't it sound somehow ... too freaky? I mean that's fine as a thing to > experiment with, but ... would you do the same on unix? Would you > recommend people to use it in production because "it should work despite > they say we shouldn't do it"? Maybe at least try some static build, or > build with visual studio? > > Best regards > > Anatol > > >
