[MPlayer-dev-eng] [PATCH] unrarlib on AMD64

Jindrich Makovicka makovick at kmlinux.fjfi.cvut.cz
Sun Apr 17 17:35:18 CEST 2005


Rich Felker wrote:
> On Sun, Apr 17, 2005 at 04:37:32PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> 
>>On Sunday, 17 April 2005 at 11:37, Jindrich Makovicka wrote:
>>
>>>Rich Felker wrote:
>>>
>>>>>diff -Naur MPlayer-20050416/unrarlib.h MPlayer-20050416-patched/unrarlib.h
>>>>>--- MPlayer-20050416/unrarlib.h 2005-04-15 20:48:03.000000000 +0200
>>>>>+++ MPlayer-20050416-patched/unrarlib.h 2005-04-16 18:17:38.000000000 +0200
>>>>>@@ -97,13 +97,13 @@
>>>>>#ifdef _WIN_32
>>>>>typedef unsigned char    UBYTE;             /* WIN32 definitions            */
>>>>>typedef unsigned short   UWORD;
>>>>>-typedef unsigned long    UDWORD;
>>>>>+typedef unsigned int    UDWORD;
>>>>>#endif
>>>>>
>>>>>#ifdef _UNIX                                /* LINUX/UNIX definitions       */
>>>>>typedef unsigned char    UBYTE;
>>>>>typedef unsigned short   UWORD;
>>>>>-typedef unsigned long    UDWORD;
>>>>>+typedef unsigned int    UDWORD;
>>>>>#endif
>>>>
>>>>
>>>>The correct solution is:
>>>>typedef uint32_t UDWORD;
>>>
>>>What about adding an (optional) support for rar executable, instead of
>>>unrarlib? Recent rars cannot be read by unrarlib anyway.
>>
>>Because we strive not to require proprietary libs/tools. Though unrar
>>source is available, the license is not GPL compatible. No rar3 support
>>is planned in unrarlib, so we just have to live with it or write rar3
>>decompression routines ourselves.
> 
> 
> i propose the latter, and adding rar3 compression routines while we're
> at it. :)

another option is to ditch rar support, import decompression routines
from bzip2 and provide migration scripts :) bzip2 compresses vobsubs
better anyway.

-- 
Jindrich Makovicka




More information about the MPlayer-dev-eng mailing list