The Windows api function MFCreateSourceResolver has moved from Mf.dll in Vista to Mfplat.dll in Windows 7, we have to soft link. See https://msdn.microsoft.com/en-us/library/windows/desktop/ms697433(v=vs.85).aspx
Created attachment 247115 [details] Patch
Comment on attachment 247115 [details] Patch I don't think I understand this patch. If this function is in MFplat.dll on Windows 7, and MF.dll on Vista, don't we need to soft link against both functions, and then use whichever one is available on the current OS?
(In reply to comment #2) > Comment on attachment 247115 [details] > Patch > > I don't think I understand this patch. If this function is in MFplat.dll on > Windows 7, and MF.dll on Vista, don't we need to soft link against both > functions, and then use whichever one is available on the current OS? According to the documentation, they've put a stub function in Mf.dll on Windows 7, which calls into Mfplat.dll, so I think it will be sufficient to soft link with the one in Mf.dll, if that was what you meant?
Is there a log of which dlls are being loaded, and which functions are not found when loading them? The Win32 API documentation says that there is always at least a stub implementation in MF.dll, which leads me to believe that this is not what is failing.
(In reply to comment #4) > Is there a log of which dlls are being loaded, and which functions are not > found when loading them? The Win32 API documentation says that there is > always at least a stub implementation in MF.dll, which leads me to believe > that this is not what is failing. I don't remember the exact dialog error message on Vista, but I think it was something like "the function MfCreateSourceResolver cannot be found in Mfplat.dll". I assume we then have linked against the one in the Mfplat library.
(In reply to comment #5) > (In reply to comment #4) > > Is there a log of which dlls are being loaded, and which functions are not > > found when loading them? The Win32 API documentation says that there is > > always at least a stub implementation in MF.dll, which leads me to believe > > that this is not what is failing. > > I don't remember the exact dialog error message on Vista, but I think it was > something like "the function MfCreateSourceResolver cannot be found in > Mfplat.dll". I assume we then have linked against the one in the Mfplat > library. But it's strange that we didn't originally link with the one in Mf.dll, since we are building with an older SDK than Win7 ...
Try removing mfplat.lib from WebKitLibraries/win/tools/vsprops/WinCairo.props. Maybe we shouldn't link with that directly.
(In reply to comment #7) > Try removing mfplat.lib from > WebKitLibraries/win/tools/vsprops/WinCairo.props. Maybe we shouldn't link > with that directly. Thanks, will try that :)
(In reply to comment #7) > Try removing mfplat.lib from > WebKitLibraries/win/tools/vsprops/WinCairo.props. Maybe we shouldn't link > with that directly. I tested this, but then MFStartup and MFShutdown were unresolved, so it seems we should link with Mfplat.lib, unless we want to softlink more functions.
Created attachment 247240 [details] Patch
(In reply to comment #10) > Created attachment 247240 [details] > Patch An alternative to this would be to soft link more, or all, of the Media Foundation functions.
Yep, that's a problem. This looks like a good solution, then, except what indicates that MFCreateSourceResolver is the only function that needs this, and how would we effectively test to make sure no other functions have this problem?
(In reply to comment #12) > Yep, that's a problem. This looks like a good solution, then, except what > indicates that MFCreateSourceResolver is the only function that needs this, > and how would we effectively test to make sure no other functions have this > problem? Good point, and to be honest, I don't know the answer. But I guess we can say for sure that with the MF functions currently used, there are no more cases on Vista, since WinLauncher is starting on Vista for me with this patch. I haven't tested WinXP though, there might be similar cases there.
Created attachment 247254 [details] Patch
(In reply to comment #14) > Created attachment 247254 [details] > Patch The Mac build failed for some reason, trying again :)
Created attachment 247341 [details] Patch
(In reply to comment #16) > Created attachment 247341 [details] > Patch I tested on WinXP, which had similar problems, so I just soft linked everything.
Thanks for reviewing :) Btw, why are we compiling with WINVER == 0x0502 (Windows Server 2003)? Should we be using WINVER == 0x05010300 (WinXP SP3)?
Comment on attachment 247341 [details] Patch Clearing flags on attachment: 247341 Committed r180641: <http://trac.webkit.org/changeset/180641>
All reviewed patches have been landed. Closing bug.
(In reply to comment #18) > Thanks for reviewing :) > > Btw, why are we compiling with WINVER == 0x0502 (Windows Server 2003)? > > Should we be using WINVER == 0x05010300 (WinXP SP3)? I'm not sure. Look at the svn blame. Maybe we don't need to any more.