Re: VC8 and GTK development

["Tor Lillqvist" <tml iki fi>]

> But the GTK site says I shouldn't use VC>6 with GTK unless I know
> what I am doing - this has to do with the GTK/win32 runtime libraries
> being tied to the VC6 runtime if I understand right.

Well, they use the msvcrt.dll runtime. Although VC6 was the last
Microsoft compiler to support building against msvcrt.dll (at least as
sold to customers), in my opinion msvcrt.dll should not be called "VC6
runtime" though, as it is shipped as part of Windows, is updated for
each Windows version, and even some (most?) of Microsoft's
applications bundled with Windows use it. At least from a C point of
view, there isn't anything terribly wrong or outdated in it.

> So, can I compile GTK/win32 into a static library with VC8 Express
> and use that?

Probably. Remember, though, that you would also need to build Pango,
atk and GLib, and their dependencies statically. If you don't need
i18n, you can use some dummy libintl that provides no-ops.

> And what are the exact requirements for this?

That is for you to find out;) There are some makefile.msc files
already in the sources, but they might have partially bitrotted. They
could serve as a base, though. Licensewise it means that your
application has to be distributed under the LGPL.

> Or should I rather use precompiled libraries?

That is easier, yes.

> If I do that, I obvously
> must be careful not to malloc/new with VC8 and free with Glib/GTK.
> Is that it, or are worse things lurking?

malloc/free isn't so much a problem, as all dynamical allocations
returned by GTK+ or GLib that you need to free should be freed with
g_free() anyway, not free().

The foremost problem is GTK+ and GLib APIs that take or return C file
descriptors (or FILE pointers). If your code uses a different C
runtime, the int returned by g_open() or the FILE* returned by
g_fopen() won't mean anything to your code. But then, nothing forces
you to use g_open() and g_fopen() in the first place if you think you
won't need to support file names that contain characters outside the
system codepage. (And even if you do, you could of course as well
manipulate the file names in UTF-16 and call _wopen() or _wfopen()
directly in your code.)

--tml