[vorbis-dev] Ports

[Brian Havard]

On Wed, 27 Dec 2000 13:39:16 +1100, Michael Smith wrote:

>>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 ;)

It's only messing up quoting your long lines AFAICS.

[...]

>>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.

No, this isn't the case here. The server is Apache for OS/2 which doesn't
to text file translation. I've verified this by using a http download tool
on the same url & the resulting file was perfectly playable.

I really just wanted to know if streaming was working in general so that
I'd know if it was worth bothering with trying to make it work.

>>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. 

Ok, fair enough.

>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).

No, using gcc is not a problem. Watcom just happens to be what I use for
most of my own stuff for its nice features like cross-platform builds (I
can build both OS/2 & Win32 targets without having to boot windoze),
precompiled headers, autodependencies, nice graphical debugger etc. Just
FYI, Watcom is being released as open source at http://www.openwatcom.org/

On the other hand, EMX gcc tends to be far easier for porting unix code as
it emulates a number of unix-isms that aren't supported natively like
fork() & sockets that can be treated like file handles.


-- 
 ______________________________________________________________________________
 |  Brian Havard                 |  "He is not the messiah!                   |
 |  brianh at kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
 ------------------------------------------------------------------------------

--- >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.