[flac-dev] [PATCH 5/5] win_utf8_io: Avoid forbidden functions when building for WinRT/UWP

Hugo Beauzée-Luyssen hugo at beauzee.fr
Fri Jan 6 14:56:56 UTC 2017


On 01/06/2017 03:37 PM, lvqcl.mail wrote:
> Hugo Beauzée-Luyssen <hugo at beauzee.fr> wrote:
>
>> ---
>>  src/share/win_utf8_io/win_utf8_io.c | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/src/share/win_utf8_io/win_utf8_io.c
>> b/src/share/win_utf8_io/win_utf8_io.c
>> index c61d27f3..1437b41e 100644
>> --- a/src/share/win_utf8_io/win_utf8_io.c
>> +++ b/src/share/win_utf8_io/win_utf8_io.c
>> @@ -34,6 +34,7 @@
>>  #endif
>> #include <windows.h>
>> +#include <winapifamily.h>
>
> According to
> <http://stackoverflow.com/questions/9509166/what-is-winapifamily-h>
> winapifamily.h is only available since MSVS 2012, so build will fail in
> older
> versions of Visual Studio (and in some older versions of MinGW).
>
>>  #include "share/win_utf8_io.h"
>>  #include "share/windows_unicode_filenames.h"
>> @@ -164,11 +165,13 @@ size_t strlen_utf8(const char *str)
>>  int win_get_console_width(void)
>>  {
>>      int width = 80;
>> +#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
>
> Apparently these preprocessor defines are from winapifamily.h
> so it won't work in older MSVS and MinGW.
>
>>      CONSOLE_SCREEN_BUFFER_INFO csbi;
>>      HANDLE hOut = GetStdHandle(STD_OUTPUT_HANDLE);
>>      if(hOut != INVALID_HANDLE_VALUE && hOut != NULL)
>>          if (GetConsoleScreenBufferInfo(hOut, &csbi) != 0)
>>              width = csbi.dwSize.X;
>> +#endif
>>      return width;
>>  }
>> @@ -176,6 +179,7 @@ int win_get_console_width(void)
>> static int wprint_console(FILE *stream, const wchar_t *text, size_t len)
>>  {
>> +#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
>
> Again, doesn't work with older MSVS and MinGW.
>
>>      DWORD out;
>>      int ret;
>> @@ -202,6 +206,11 @@ static int wprint_console(FILE *stream, const
>> wchar_t *text, size_t len)
>>      if (ret < 0)
>>          return ret;
>>      return len;
>> +#else
>> +    (void)stream;
>> +    OutputDebugStringW(text);
>> +    return len;
>> +#endif
>>  }
>
> Why OutputDebugStringW? MSDN says in
> <https://msdn.microsoft.com/en-us/library/windows/desktop/aa363362(v=vs.85).aspx>:
>
> "Sends a string to the debugger for display. [...] If the application
> has no debugger, the system debugger displays the string if the filter
> mask allows it. [...] If the application has no debugger and the system
> debugger is not active, OutputDebugString does nothing. [...] Applications
> should send very minimal debug output and provide a way for the user
> to enable or disable its use."
> ...it doesn't look like a function that simply prints some output from a
> program.
>

You won't have a console per-se in WinRT. The closest thing I can think 
of is an attached debugger's output/console

>
> And what's the goal of this patch? To create flac.exe/metaflac.exe that
> can work in WinRT? Or to remove build errors, and flac/metaflac are allowed
> to work incorrectly?

Fixing the build for WinRT. So far, building the utf8 convenience 
library is mandatory as it's part of noinst_LTLIBRARIES
The correct fix (as far as I'm concerned, but that's because I'm only 
aiming at building libflac) would be to skip building libraries in 
flac/share, as described in the cover letter.
Building anything else than the libflac/libflac++ is bound to fail 
anyway (you might get an executable, but it won't run)

Regards,


More information about the flac-dev mailing list