On Tue, Dec 16, 2014 at 8:14 AM, Martin Storsjö <[email protected]> wrote:
>
> On Tue, 16 Dec 2014, Martin Storsjö wrote:
>
> The MoveFileExA is available in the headers regardless which API
>> subset is targeted, but it is missing in the Windows Phone link
>> libraries. When targeting Windows Store apps, the function is
>> available both in the headers and in the link libraries, and thus
>> there is no indication for the build system that this function
>> should be avoided - such an indication is only given by the
>> Windows App Certification Kit, which forbids using the MoveFileExA
>> function.
>>
>> Therefore check the WINAPI_FAMILY defines instead, to figure out
>> which API subset is targeted.
>> ---
>> configure | 2 --
>> libavformat/os_support.h | 19 ++++++++++++++++---
>> 2 files changed, 16 insertions(+), 5 deletions(-)
>>
>> diff --git a/configure b/configure
>> index ed8316f..48669a0 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1466,7 +1466,6 @@ SYSTEM_FUNCS="
>> localtime_r
>> mach_absolute_time
>> MapViewOfFile
>> - MoveFileExA
>> memalign
>> mkstemp
>> mmap
>> @@ -4100,7 +4099,6 @@ check_func_headers windows.h GetProcessAffinityMask
>> check_func_headers windows.h GetProcessTimes
>> check_func_headers windows.h GetSystemTimeAsFileTime
>> check_func_headers windows.h MapViewOfFile
>> -check_func_headers windows.h MoveFileExA
>> check_func_headers windows.h SetConsoleTextAttribute
>> check_func_headers windows.h Sleep
>> check_func_headers windows.h VirtualAlloc
>> diff --git a/libavformat/os_support.h b/libavformat/os_support.h
>> index 4949065..6cc6d9a 100644
>> --- a/libavformat/os_support.h
>> +++ b/libavformat/os_support.h
>> @@ -129,6 +129,18 @@ int ff_poll(struct pollfd *fds, nfds_t numfds, int
>> timeout);
>> #include <windows.h>
>> #include "libavutil/wchar_filename.h"
>>
>> +#ifdef WINAPI_FAMILY
>> +#include <winapifamily.h>
>> +// If a WINAPI_FAMILY is defined, check that the desktop API subset
>> +// is enabled
>> +#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
>> +#define USE_MOVEFILEEXA
>> +#endif
>> +#else
>> +// If no WINAPI_FAMILY is defined, assume the full API subset
>> +#define USE_MOVEFILEEXA
>> +#endif
>> +
>> #define DEF_FS_FUNCTION(name, wfunc, afunc) \
>> static inline int win32_##name(const char *filename_utf8) \
>> { \
>> @@ -180,13 +192,14 @@ static inline int win32_rename(const char
>> *src_utf8, const char *dest_utf8)
>>
>> fallback:
>> /* filename may be be in CP_ACP */
>> -#if HAVE_MOVEFILEEXA
>> +#ifdef USE_MOVEFILEEXA
>> ret = MoveFileExA(src_utf8, dest_utf8, MOVEFILE_REPLACE_EXISTING);
>> if (ret)
>> errno = EPERM;
>> #else
>> - /* Windows Phone doesn't have MoveFileExA. However, it's unlikely
>> - * that anybody would input filenames in CP_ACP there, so this
>> + /* Windows Phone doesn't have MoveFileExA, and for Windows Store
>> apps,
>> + * it is available but not allowed by the app certification kit.
>> However,
>> + * it's unlikely that anybody would input filenames in CP_ACP there,
>> so this
>> * fallback is kept mostly for completeness. Alternatively we could
>> * do MultiByteToWideChar(CP_ACP) and use MoveFileExW, but doing
>> * explicit conversions with CP_ACP is allegedly forbidden in windows
>> --
>> 1.8.1.2
>>
>
> The alternative would be to only use rename() as fallback, for the case
> when someone calls lavf with a non-utf8 filename. The only place where it'd
> (currently) matter would be people calling the segmenting muxers directly
> using the libavformat API, with non-ASCII, non-utf8 filenames, which
> probably isn't a very common usecase (and if it is, those library users
> should start making sure they're using utf8 filenames). So if this patch is
> deemed too ugly, we could go that way as well. But the same mechanism of
> using WINAPI_FAMILY might be needed elsewhere at some point as well.
>
>
Can't configure to a link check instead of just a header check?
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
