The complaint about typedefs and Win32 is kind of odd. These are style choices that libraries and large projects should be entitled to make.
I used to work at MS and grew very comfortable (and appreciative) of the stylistic choices in the NT kernel (distinct from the Win32 style, one key difference is much less Hungarian notation). But I can jump back into more typical-of-*nix styles with ease. Or the more Win32 style if preferred. I think it's important to see the merits and drawbacks of various style decisions in a non-judgmental fashion, and be able to switch back and forth depending on the code base you're working in. It's a mistake to confuse style and convention with "not being real C". Different doesn't mean not real.
gobject is built on top of glib, not the other way around, and it's mostly there to make it easier to create language bindings, so there's no real reason to use it (gobject) unless you're building a library like GTK. As for the typedefs, they're there for consistency more than anything. A couple of them are legitimately useful for portability reasons, but the rest (like gpointer) are there simply to keep things looking similar in the API.
Say what you will, but I see the book's apparent inclusion of glib as a plus.
I'll second that, I guess I'm biased as I wrote some early gnome stuff back in the day before I started writing graphics device drivers for Precision Insight and VA Linux systems. I rather like glib, even though the gpointer thing isn't something I like too much aesthetically. Everything obviously has its warts and trade offs, nothing is perfect after all. I think glib brings a lot to the table though and with it and a few other choice libraries I can code very complex projects just as fast or faster in C as I do in Java.
Would you care to list your other "choice libraries" ? I'm not familiar with actually programming in C (I can read C somewhat, but have never used it for a real (even small) project).
Could you elaborate on the 'horrible design'? In general, I've found GLib very useful (say, the data structures, mainloops, GError, the G_GNUC_ stuff, ...) . If the biggest problem is some typedef that you can happily ignore, it can't be that bad, or?
GObject is a bit different matter - there's quite a bit of boilerplate, which makes me think twice before adding one. But at the same time, it's quite nice to use them in libraries like GStreamer.
GLib is certainly not perfect, but I found it more pleasant to use than, say, talloc. Are there any specific advantage is APR? (I've never used it) Does it cover the same functionality?
I haven't checked recently, but the problem with APR was for so many years it had (possibly still has) no documentation other than Doxygen. Also, the memory pool design seemed an enormous complication. Have you used it recently and have either of those factors improved much?
Also it leads to GObject abuse which is harmful to the soul.
Ultimately, the moment you bring glib into a project it stops being C, much like the Win32 API does.
I'd rather pull in libapr and apr-util.