[vorbis-dev] Ports

[Michael Smith]

>>>It's not that big a deal though, I've attached the dl for OS/2 code I wrote
>>>just to show how simple it is. I could write one for Win32 just as easily.
>>
>>Yes - it isn't hard or complex, it's just messy to have a whole bunch of
implementations. Not a big problem - going with platform-specific code is
probably better (at least for now). The code looks fine, so I'll commit it
once you've sent along the rest of the code (for libao os/2 output).
>
>Ok, I've attached the full ao diff.

Thanks. I'll apply it soon. By the way, your mail client appears to not be
line wrapping correctly (I won't come down too hard on you for this - mine
did the same earlier this week ;)
>
>>I just tested it (on a file from www.vorbis.com), and it works fine
(well, it skipped a few times, because of the lack of buffering, but that's
not a surprise). 
>>
>>Make sure your local webserver is specifying the correct mime type
(application/x-ogg, I think) - some systems will break if it isn't set.
That's my only guess for what's causing problems. Does OS/2 inherit the DOS
stupidity of text/binary files? That would cause this if you don't have a
mime type set.
>
>The "text/binary" file thing has nothing to do with DOS, it's about
>different line terminators. Any system that doesn't use the unix style LF
>line terminator (pretty much anything non-unix) must translate text files.
>DOS, OS/2 and Win32 all use CR/LF. Macs use CR. So it's necessary, not
>stupid.

Understand that. The stupidity is in having text files be fundamentally
different from binary files in the first place. There was never a good
reason for this. 

>
>So yes, C libraries on OS/2 have text/binary file modes but I've checked
>that ogg123 reads the http stream in binary mode. The fdopen in http_open()
>specifies binary mode.

You said you were running the server on the same machine - I suspect that,
though it's receiving in binary mode, it's being corrupted on send. I saw
this exact problem (on several occasions) when servers were misconfigured
in some way.

>
>A few notes about the patch:
>- in ao_wav.c the "#include <sys/types.h>" is to define off_t.
>- I've added support for an optional AO_PLUGIN_PATH environment variable
>allowing the plugin directory to be specified at runtime, making
>distribution of binaries practical. I'm not sure if this is a good idea for
>unix (setuid hole perhaps?).
>- I've switched to using gcc instead of Watcom C as its more widely
>available & free. It's also the only OS/2 compiler that supports fdopen()
>on a socket, necessary for streaming.

Sounds good. Though it's probably a setuid hole, that's not an issue. I can
guarantee that there would be a LOT more holes there than just that.
libogg, libvorbis, libao, and ogg123 have all not been audited, and are not
intended to be run setuid. 

Is using gcc a problem? (i.e. would you prefer to use watcom?) ogg123 is
being largely rewritten at the moment, I suspect it'd be possible to not
have it do fdopen() at all (it's a bit of a messy way to do socket stuff).

Michael

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.