about how Microsoft have a great understanding of binary
compatibility. Actually they have an appalling record on
binary compatibility and/or proper library versioning. And
several of their critical updates have made Windows
installations unbootable because of this. And worse, they
won't even admit such problems until they've got the next
version out weeks later.

href=”http://gtkmm.sourceforge.net/docs/gtkmm-faq.html”>Gtk–
FAQ. Hopefully this one will be maintained.

RogueWave's DBTools. So I have std::string, QString,
DOMString, and RWCString. Joy.

spurred me to get Gtk– 2 moving along, but it's hard going
without kenelson, who seems to be having
some connectivity problems.

Microsoft in the only areas in which they are vulnerable -
technical competency, rate of development, cost, and
possibly technical support. In the real world, I suspect
that its major advantage for Ximian will be as a way to
secure extra funding by associating themselves with this
quarter's big thing.

Admittedly, I haven't bothered to investigate .NET, but
after
in-depth […]

asked me to
clarify my whingeing about the QT API in my previous entry.
Here's what I told
Guillaume. He said that most of these points weren't
significant, not really to my satisfaction. I'd post his
comments, but it was a person-to-person email thread.

> > I suppose you're mostly thinking of the containers here,
as the widgets API is quite orthogonal […]

supposedly clear API and documentation that
Guillaume thought was so great. All I see
is non-orthogonal crufty interfaces, inadequate
functionality, and a complete lack of awareness of prevalent
standards.

though I'm really beginning to hate having to use the
eccentric Sniff+ to generate all of our makefiles. This is
just silly, but in the isolated world of this development
department this is actually more standard than the gnu auto*
tools. In particular it has a real problem coping with QT's
moc prepocessor, handily proving my point that non-standard
stuff messes […]