Re: GTK+ and my port of AMP for Windows

["carlo bramix libero it" <carlo bramix libero it>]

Hello,
thank you very much for your reply.
Yes, I'm sure that I'm using the precompiled libraries downloaded from GTK+ 
homepage.
I have also tried Process Explorer, I had it already installed.
So I tried it too to be sure and as I expected it is using the official 
binaries.
In addition, the libraries compiled by me are dependant to libintl-8 and 
libiconv-2, while official binaries are not.
I tried to test in a clean virtual machine under VirtualBox, same results.
I tried to test on a different PC with a clean Windows installation, same 
results.
BTW, with another virtual machine in VirtualBox I tried to test on Windows 
2000 and it does not work.
One of the DLL has dependency to functions like freeaddrinfo() in winsock2 (to 
be more precise, it's libgio-2.0-0.dll).
Perhaps you should add somewhere in some include files:

#if defined _WIN32_WINNT && _WIN32_WINNT <= 0x0500
#include <wspiapi.h>
#endif

where winsock2.h is included.
so that if an user wants to avoid the error of missing functions like 
freeaddrinfo(), then he can do it at compile time by simply forcing 
_WIN32_WINNT to 0x0500.
Of course, there are other solutions for fixing this.

Perhaps I'm doing something wrong when compiling my exe file.
In previous email I forgot to write about the generation of the executable.
I'm using this command in a batch file:

gcc test.c -o test.exe -mms-bitfields -Ic:/mingw/include/gtk-2.0 -Ic:
/mingw/lib/gtk-2.0/include -Ic:/mingw/include/atk-1.0 -Ic:/mingw/include/cairo -
Ic:/mingw/include/pango-1.0 -Ic:/mingw/include/glib-2.0 -Ic:/mingw/lib/glib-2.0
/include -Ic:/mingw/include/pixman-1 -Ic:/mingw/include/freetype2 -Ic:
/mingw/include -Ic:/mingw/include/libpng14 -Wl,-luuid -Lc:/mingw/lib -lgtk-
win32-2.0 -lgdk-win32-2.0 -limm32 -lshell32 -lole32 -latk-1.0 -lgio-2.0 -
lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpangoft2-1.0 -lpangowin32-1.0 -lgdi32 -
lfreetype -lfontconfig -lpango-1.0 -lm -lcairo -lgobject-2.0 -lgmodule-2.0 -
lgthread-2.0 -lglib-2.0 -lintl

I took the CFLAGS and the LIBS by quering pkg-config and they are the same 
used by  AMP.
I must say that I do not know what to think... changing the libraries (mine or 
official ones) does not change its behaviour.
So I was thinking about a problem with this executable, I do not know... like 
some alignment differences somewhere... I ignore what it could be wrong with a 
so small source code but able to replicate my problem.

In your message you wrote that there is no point in calling 
gdk_threads_init().
So:

#ifndef _WIN32
gdk_threads_init()
#endif

is this the best solution to apply?
Or, better, is there a macro to check for writing something like this?

#if GDK_THREADS_ARE_SUPPORTED
gdk_threads_init()
#endif

Now I wrote with some fantasy 'GDK_THREADS_ARE_SUPPORTED' but I'm guessing if 
there is one with the same behaviour.
In the Audacious Media Player there are no calls to functions gdk_threads_*, 
there are just some calls to macro GDK_THREADS_ENTER and GDK_THREADS_LEAVE in 
some strategic points.
In other plugins there are some calls to functions gdk_threads_enter() and 
gdk_threads_leave() only.
But I admit I would be happy to know what hangs my executable.

Thank you for the tip for closing completely the programme.
Actually Audacious already quits nicely when I close the main window, so I 
guess there is something like you suggested hidden somewhere.
But there is another thing that the player does but it should not: when I 
launch the programme, a textmode console is opened immediately at startup.
Obviously, this happens when an application is created for working in console 
mode (and I'm surprised on this since entry point of the application is the 
main() function).
With GTK+ compliant code, is there a special care to take for closing it?
Or do I need to do it myself (by hiding the attached console, or creating a 
true startup code Windows with Winmain() that calls the main()?

Thanks a lot for your time.

Sincerely,

Carlo Bramini.




> The window is created and I can interact without problem with it.
> Now, here you are another little test programme that does not work:

It *does* work for me, both when running against GTK+ 2.20.1 and
2.22.0. (The "official" binaries from www.gtk.org, actually hosted on
ftp.gnome.org.)

>  window = gtk_window_new(GTK_WINDOW_TOPLEVEL);

You really should add here:

g_signal_connect_swapped(G_OBJECT(window), "destroy",
                          G_CALLBACK(gtk_main_quit), G_OBJECT(window));

(or something to the same effect; there are several ways to do it) so
that the program ends when the window is closed.

(This is not to be related to the problem you are seeing, the program
worked for me even if I didn't add this, the problem then was just
that when I closed the window the program didn't exit.)

> The window is created, it's visible on the screen but it's "freezed", I 
cannot
> interact with it and its content is never updated (the busy cursor is always
> shown on top of the window).

Sorry, but I don't see this happening.

> Have you an idea about what's wrong with this piece of code?

There is nothing wrong as such, but as you can't use GTK+ from
multiple threads on Windows, so there is no point in calling
gdk_threads_init().

> After some researches, I discovered that all the problems were resolved by
> commenting the call to gdk_threads_init() on top of the main() function.

Well, for me it makes no difference whether it is called or not.

Note that a real, more complex, program that attempts to call GTK+
functions from multiple threads on Windows will certainly not work. It
will deadlock or just not do the right thing. And as you shouldn't be
calling GTK+ from multiple threads if you want the program to work on
Windows, there is no point in calling any gdk_threads_* functions
either.

Note that it's just GTK+ which is problematic from multiple threads on
Windows, GLib functions work as expected from multiple threads.

And in any case, as far as I understand, the majority of experts say
that one shouldn't be using GTK+ from multiple threads even on X11 (in
practice, that means "Linux" for most), because it is so hard to get
right. Instead, use g_idle_add() etc to schedule GTK+ -using functions
to be called from the "main" thread.

> I compiled myself the GLib, GTK+ and all other required libraries.
> Initially, I though there was something wrong in my libs, so I downloaded 
all
> the zip files with precompiled GTK+ for Windows from GTK+ homepage.
> Nothing changed: I got the same results I'm having with my libraries
> (hopefully!).

Are you sure you are really running against the official binaries?
Please double-check, for instance by using Process Explorer from
http://technet.microsoft.com/en-gb/sysinternals/default.aspx , that
the DLLs used by the process are actually the ones you think.

--tml