Hi Leong, > -----Original Message----- > From: Chung Leong [mailto:cleong...@gmail.com] > Sent: Wednesday, April 23, 2014 4:07 AM > To: Anatol Belski > Cc: pecl-dev@lists.php.net > Subject: Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg > > 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 > > > > Yeah, lets ignore that stupid docs :)
However user32.dll is a system component, and it exports some functions. So you talk about a standard OS library. Many OSS projects use this approach in hope it'll work, but they at least don't mix CRT. Many other OSS projects use the same approach we do - but that should to be consistent. Best regards Anatol -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
