This workaround, unfortunately, requires that apps directly link to a set of
Win32-style cursor resource files (that contain a transparent cursor image).
Copies of suitable resource files are in src/core/winrt/, and should be
included directly in an app's MSVC project.
A rough explanation of this workaround/hack, and why it's needed (and
seemingly can't be done through programmatic means), is in this change's code.
This allows us to set an explicit stack size (overriding the system default
and the global hint an app might have set), and remove all the macro salsa
for dealing with _beginthreadex and such, as internal threads always set those
to NULL anyhow.
I've taken some guesses on reasonable (and tiny!) stack sizes for our
internal threads, but some of these might turn out to be too small in
practice and need an increase. Most of them are simple functions, though.
Martin Gerhardy
Just a minor thing, but a huge outcome. All the other jni related functions already have those flags, but the nativeInit function lacks them - so it might be stripped away.
Jonas Kulla
src/main/windows/SDL_windows_main.c:137:
cmdline = SDL_iconv_string("UTF-8", "UCS-2-INTERNAL", (char *)(text), (SDL_wcslen(text)+1)*sizeof(WCHAR));
I'm trying to compile an SDL2 application for windows using the mingw-w64 32bit toolchain provided by my distro (Fedora 19). However, even the simplest test program that does nothing at all fails to startup with a "Fatal error - out of memory" message because the mingw iconv library provided by my distro does not support the "UCS-2-INTERNAL" encoding and the conversion returns null.
From my little bit of research, it turns out that even though this encoding is supported by the external GNU libiconv library, some glibc versions (?) don't support it with their internal iconv routines, and will instead provide the native endian encoding when "UCS-2" is specified.
Nonetheless, I wonder why the native endianness is considered in the first place when Windows doesn't even run on any big endian archs (to my knowledge). And true enough, 'WIN_StringToUTF8' from core/windows/SDL_windows.h is used everywhere else in the windows backend, which is just a macro to iconv with "UTF-16LE" as source. Therefore it would IMO make sense to use this macro here as well, which would solve my problem (patch attached).
Pablo Mayobre
When generating a signed app with SDL 2.0.3 an issue comes up, watching at the Error Log points out that the issue lies in the src/main/android/SDL_android_main.c where the process name is defined as "SDL_app", this name turns into an erroneous name so it should be changed to "app_process"
SDL 2.x recently accepted patches to enable OpenGL ES 2 support via Google's ANGLE library. The thought is to try to eventually merge SDL/WinRT's OpenGL code with SDL-official's.
This can break builds of existing SDL/WinRT apps. To fix, remove the reference to SDL_winrt_main.cpp, then add a reference to the renamed file, SDL_winrt_main_NonXAML.cpp. If you get a build error about a missing .winmd file, enable the /ZW compiler flag for that one file (at minimum).
