glob-win.c wasn't big, so it was easier to rewrite it. The new version
supports Unicode, handles directories properly, sorts the output and
puts all its allocations in the same talloc context to simplify the
implementation of globfree.
Notably, the old glob had error checking code, but didn't do anything
with the errors since the error reporting code was commented out. The
new glob doesn't copy this behaviour. It just treats errors as if there
were no more matching files, which shouldn't matter for mpv, since it
ignores glob errors too.
To match the other Windows I/O helper functions, the definition is moved
to osdep/io.h.
This is necessary to start mpv without forcing a console window,
but also breaks console usability. A workaround is to call mpv
from a wrapper process that uses the console subsystem and helps
redirecting the standard streams and WriteConsole output to where
they belong.
This is needed so that new processes (created with fork+exec) don't
inherit open files, which can be important for a number of reasons.
Since O_CLOEXEC is relatively new (POSIX.1-2008, before that Linux
specific), we #define it to 0 in io.h to prevent compilation errors on
older/crappy systems. At least this is the plan.
input.c creates a pipe. For that, add a mp_set_cloexec() function (which
is based on Weston's code in vo_wayland.c, but more correct). We could
use pipe2() instead, but that is Linux specific. Technically, we have a
race condition, but it won't matter.
Remove the ifdef hell from mp_find_user_config_file(). Move the win32
specific code (for MinGW and Cygwin) to path-win.c. The behavior should
be about the same, but I can't be sure due to lack of testing and
because the old path.c code was hard to follow. (I expect those who care
about windows will fix things, should issues pop up - sorry.)
One difference is that the new code will always force MPV_HOME. It looks
like the old code preferred the mpv config dir in the exe dir if it
exists.
Also, make sure MP_PATH_MAX has enough space, even if the equivalent
wchar_t string is not 0-terminated with PATH_MAX (because apparently the
winapi doesn't require this). (Actually, maybe we should just kill all
uses of PATH_MAX/MP_PATH_MAX.)
This is a bit "hard", because getenv() returns a static string, and we
can't just return an allocated string. We also want getenv() to be
thread-safe if possible. (If the mpv core is going to be more threaded,
we sure do want the lower layers to be thread-safe as well.)
I have no idea when or how this broke, but _wstati64() is the function
we want anyway (64 bit filesize). Possibly this was a mingw-w64 bug.
It's unknown why "wstat()" just doesn't work in this case, as it's not
defined by MSDN and could be defined by mingw as it needs.
Use the *W variants instead of the implicit *A functions. (One could
define the UNICODE macro to switch the functions without suffix from
A to W, but I'm too lazy to figure out how portable that is, etc.)
Also make sure io.h defines a unicode aware printf().
Windows uses a legacy codepage for char* / runtime functions accepting
char *. Using UTF-8 as the codepage with setlocale() is explicitly
forbidden.
Work this around by overriding the MSVCRT functions with wrapper
macros, that assume UTF-8 and use "proper" API calls like _wopen etc.
to deal with unicode filenames. All code that uses standard functions
that take or return filenames must now include osdep/io.h. stat()
can't be overridden, because MinGW-w64 itself defines "stat" as a
macro. Change code to use use mp_stat() instead.
This is not perfectly clean, but still somewhat sane, and much better
than littering the rest of the mplayer code with MinGW specific hacks.
It's also a bit fragile, but that's actually little different from the
previous situation. Also, MinGW is unlikely to ever include a nice way
of dealing with this.
James Ross-Gowan
wm4
Martin Herkt
Kovensky
wm4