On Tue, 16 Dec 2014, Martin Storsjö wrote:
On Tue, 16 Dec 2014, Hendrik Leppkes wrote:
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?
It already does a link check, but for "Windows Store" builds, you have the
same link libraries as for the full desktop API set, so when building
there's no way of knowing that you shouldn't use this function, short of
running WACK telling you that you're using a restricted function.
Windows phone has got a separate "SDK" with separate include/libs, but
"store" shares the include/libs with the normal windows - only the msvcrt
libs directory is separate for the "store" configuration.
That's why I think this function (and probably a bunch of other ones)
should be limited in the headers as well, if we aren't supposed to use
them.
I'll push this one soon unless there are different suggestions on how to
deal with it.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
