Win32 Zinf with MingW

Hi,

I been playing around recently with trying to compile the current version=
 =20
of Zinf using MingW and GTK+ on Windows. This is based on the work I did =
=20
last year ([email protected]/zinf--mingw--0.1) along the same=
 =20
lines, except this time I've been modifying the existing Autoconf/Automak=
e =20
build files.

I've now got as far as a usable patch that can build the normal =20
GTK+ player and musicbrowser UI's, with support for WAV/MP3 files.

I've also written up some basic instructions on how to set-up a MingW =20
development environment for Zinf using MSys:
http://www-users.york.ac.uk/~djh123/mingw.txt

The Patch:
http://www-users.york.ac.uk/~djh123/zinf-mingw.diff


There are still serious issues with it at the moment that need cleaning u=
p =20
(it breaks the Linux build, etc.) so this is still very much a work in =20
progress.

Note: To run from the build directory, make sure that "." is in your path=
 =20
and execute ./zinf instead of ./base/zinf


Apart from various bits of tweaking, converting int32 to int32_t, etc., =20
there are two major changes I've had to make to get it too work. The most=
 =20
significant and far reaching of these is the separating of the Zinf base =
=20
executable into zinf.exe and libzinf.dll

This is because Windows doesn't allow shared libraries (ie the plugins) =20
that have undefined symbols in them. Currently we compile the plugins, an=
d =20
don't link them to anything until they are loaded at runtime, when they'r=
e =20
linked to the already running Zinf executable (at least, I think that's =20
how it works). This isn't allowed on Windows, and neither is linking =20
against an executable, so we have to create a library with all the base =20
classes in them so that the plugins can link to it, hence libzinf.

This leads to another significant problem when compiling, libzinf depends=
 =20
on the base I/O classes in the folder io/src. However, all the I/O plugin=
s =20
also in the subdirectory io, depend on libzinf. So a make will build the =
=20
base I/O classes, and then fail attempting to build the I/O plugins. To =20
make successfully we actually have to execute

make; cd base; make; cd ..; make

I'm not really sure there's a good solution to this, without re-organisin=
g =20
the source tree.


The other large change is a threading problem with the GTK+ plugins. On =20
Windows, all accesses to GTK objects have to be from the same thread, =20
which has to be same thread that gtk_main() is called from otherwise GTK =
=20
can't actually draw them. This means that events from the Zinf Event =20
Thread have to be passed to the GTK Main thread before they can be =20
processed.

I've therefore had to add code to allow the Zinf Event Thread to pass =20
messages to the GTK Main thread to execute events. This is currently =20
implemented using g_timeout_add() calls with a zero length timeout.


Obviously the patch still needs a lot of work, but I would appreciate any=
 =20
feedback anyone might have. Please feel free to try this out, as it would=
 =20
be great if we could restore Windows support to Zinf.

Cheers,
David
--=20
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick