glib-tml-980819-0.patch is the renewed version of my GLib patch for
Win32. Now only the glib.h file contains those uglyish GLIBAPI
declarations, they aren't needed in the .c files.

(Maybe that GLIBAPI stuff isn't too bad on Unix, either, with them you
can see which functions are intended as the public API, and which are
just for glib's internal use?)

The Watcom compiler and linker (version 10.6, which admittedly isn't
the latest) doesn't handle having several object modules within a DLL
compiled with _declspec(dllexport) declaration for the same variable,
even if just one module contains the actual definition. Because of
this I have to use separate declaration macros (GLIBVAR1 and GLIBVAR2
in GLib's case) for exported variables. These macros then expand as
__declspec(dllexport) when compiling the source file containing the
definition, and as extern when compiling other glib files (and as
__declspec(dllimport) when compiling code that uses glib.dll).

Luckily there aren't many of these variables (and not in gdk or gtk
either).

Microsoft's compiler apparently uses a better object file format
(COFF?) (at least I think that's the reason) and doesn't have this
problem. Don't know about Borland (er, Imprise), or other Win32
compilers.

In gmessages.c:g_log_default_handler I use AllocConsole to open a
console window if one isn't open, and write the messages with
WriteConsole. I don't know if this is the right approach, though, as
IO redirections from the command line won't affect WriteConsole.

BTW, I have now compiled and linked gdk and gtk. I ran the _simple_
program this morning and it even opened a window called "hello world".
But it speweed out lots of errors about unrecognized objects and color
allocation failures... Still, progress.