Remove the win32 loader - the win32 emulation layer, as well as the
code for using DirectShow/DMO/VFW codecs. Remove loading of xanim,
QuickTime, and RealMedia codecs.
The win32 emulation layer is based on a very old version of wine.
Apparently, wine code was copied and hacked until it was somehow able
to load a limited collection of binary codecs. It poked around in the
code segment of some known binary codecs to disable unsupported win32
API calls to make them work. Example from module.c:
for (i=0;i<5;i++) RVA(0x19e842)[i]=0x90; // make_new_region ?
for (i=0;i<28;i++) RVA(0x19e86d)[i]=0x90; // call__call_CreateCompatibleDC ?
for (i=0;i<5;i++) RVA(0x19e898)[i]=0x90; // jmp_to_call_loadbitmap ?
for (i=0;i<9;i++) RVA(0x19e8ac)[i]=0x90; // call__calls_OLE_shit ?
for (i=0;i<106;i++) RVA(0x261b10)[i]=0x90; // disable threads
Just to show how utterly insane this code is. You wouldn't want even
your worst enemy to have to maintain this. In fact, it seems nobody
made major changes to this code ever since it was committed.
Most formats can be decoded by libavcodecs these days, and the loader
couldn't be used on 64 bit platforms anyway. The same is (probably)
true for the other binary codecs.
General note about how support for win32 codecs could be added back:
It's not possible to replace the win32 loader code by using wine as
library, because modern wine can not be linked with native Linux
programs for certain reasons. It would be possible to to move DirectShow
video decoding into a separate process linked with wine, like the
CoreAVC-for-Linux patches do. There is also the mplayer-ww fork, which
uses the dshownative library to use DirectShow codecs on Windows.
MSWindows-specific code in get_path() declared a stack array
(exedir[]) in an inner scope, then kept a reference to the array
beyond the end of the that scope. Fix. This caused visible breakage
with GCC 4.7.
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.
Rename the BSTR() function to bstr(). The former caused a conflict
with some Windows OS name, and it's no longer a macro so uppercase
naming is less appropriate.
This function was left over from older logic to manipulate the
"codec_path" global variable. Now that variable is fully handled by
the general option system, so that the only effect of the function
was to introduce memory leaks in some circumstances. Delete the
useless function.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32630 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix crash on path without directories.
Regression introduced in r32630. Patch by Yuriy Kaminskiy yumkam at mail ru.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32631 b3059339-0415-0410-9bf9-f77b7e298cf2
Handle correctly paths with mixed '/' and '\' in it.
Patch by Yuriy Kaminskiy (yumkam at mail ru)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32632 b3059339-0415-0410-9bf9-f77b7e298cf2
Handle ':' on systems with DOS paths: it allows paths like C:foo.avi.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32642 b3059339-0415-0410-9bf9-f77b7e298cf2
This keeps the naming of all path-related functions consistent.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30944 b3059339-0415-0410-9bf9-f77b7e298cf2
These files now contain different functions related to path handling.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30943 b3059339-0415-0410-9bf9-f77b7e298cf2
