[gst-devel] Gstreamer WIN32 status

[Michael Smith]

On Sun, 2006-04-09 at 20:44 +0200, Sébastien Moutte wrote:
> HI Gstreamer !!
> 
> It's time to report the WIN32 status of gstreamer packages. Now a lot
> of plugins build successfully with MSVC 6.0 and the ones i have tested
> work really good :)

Sounds good!

> 
> Here is a summary of the common build errors i'm still getting on some
> plugins:
> 1) Some plugins use not supported socket functions (inet_aton,
> socketpair ...). I'll search for a free implementation of the missing
> functions for WIN32 or try to remove this function calls. Does
> somebody know an existing solution ?

Some of these are easy, some are not. inet_aton is easy - if you have
inet_pton(), you can just use a trivial #ifdef, if you don't, an
implementation of it is pretty simple. Anyway, I expect windows has some
roughly-equivalent function that you can use.

socketpair is particularly hard. It's used to enable interruptable
selects() with a self-pipe, which simply can't be done on windows. 
The right solution for windows is probably something using
WaitForMultipleObjects() and some sort of object that you can signal
from another thread - I don't know enough windows to know what. A lot of
the plugins do things like this, so it'd be nice to abstract it out into
another library somewhere...

> 2) Some plugins use rint (audioresample, videobalance). I've found and
> used #ifdef WIN32 #define rint(x) (floor((x)+0.5)) #endif. Is it
> correct  ?

Not strictly correct, but probably close enough for what these plugins
need.

> 3) Some plugins need regex.h which is not on WIN32 dev environment.

There are regexp implementations available for windows, perhaps it's
best to simply use one of those?

> 4) Some plugins (realmedia, qtdemux) use void * in a lot of
> operations. MSVC doesn't support that, it generates error because it
> doesn't know the size of void then it can't move the pointer. I guess
> we can simply replace void * used in operations by byte * or char *,
> can i do that safely ?

This is using a gcc extension (void pointer arithmetic) which we
shouldn't be (it will certainly cause problems on non-windows platforms
too!). These should be considered outright bugs. Using 'char *' or
'unsigned char *' is usually the intended/correct thing.

Mike