Re: GTK+ on windows

[jcupitt gmail com]

2009/10/13 Dov Grobgeld <dov grobgeld gmail com>:
> I have created several cross-platform gtk programs, and while it took a
> while to get right the first time, my development is now so trustworthy that
> I can do all my development under Linux and then once it works, just
> generate a windows installer and I know that it will just work.

I agree, after struggling with gcc on Windows, MSVC and even cmake and
jam, I now cross-compile from Linux and it works wonderfully. This
solution has the following nice properties:

*) I have not only a single, cross-platform source tree, I also have a
single build system to maintain.

*) It's very scriptable (my bash is much better than my VBA of
whatever the Windows equivalent is). For example, I have a simple
script that does a nightly build from SVN, updates a website with a
fresh Windows binary, and sends me a mail if there were any problems.

*) It's much faster than mingw on Windows, though I guess that's not
saying much, heh.

I don't build gtk+ myself, I use Tor's zips plus a few other packages
I've had to build myself. I can update parts of the stack by just
dropping an updated zip into the tree, it's about as nice as it could
be without a proper package manager.

> microsoft like you can make it use the intel compiler?) In any case, as gtk
> is a pure c-program, there are no ABI differences between the visual
> compiler and gcc. So why can't you just use the standard gtk distribution
> together with the studio compiler?

My understanding is that there are differences in the C runtime. mingw
links against msvcrt.dll (the runtime from VC6) since this is the one
that's guaranteed to be on almost all Windows machines, so you don't
need to bundle a C runtime, so there's no problem with rights. Almost
all free DLLs are built like this, I believe.

Current VS links against msvcrt80.dll (is that right? can't remember)
which is not present on all machines and needs to be bundled in your
installer, which is a little dubious. Even if you take the IP risk and
bundle it, that's not enough, you really need to run an installer for
it as well and make some registry changes before i18n will work in the
runtime. Erm, I think.

The upshot is that VS projects can't link against GTK DLLs, unless you
fiddle with the VS link stuff to link against msvcrt.dll instead of
the more recent one, which is quite difficult to do, I think. Or this
blog suggests that it is anyway:

http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/

I'm not a Windows person at all though, I've probably got most of that
wrong :( Friends who do serious Windows application development simply
statically link everything to avoid all this pain.

John