Windows ("Dodo") GUI Project

[Wade Fagen]

Hey all --

Just wanted to send the greater pidgin community a quick e-mail saying
"hello" and letting you all know what I'm up to with GSoC and Pidgin
(I've spoken to a number of you in IRC and a few others by e-mail).
I'm a Ph.D. student at The University of Illinois and my proposal for
a Windows GUI was accepted as a SoC project for Pidgin.  You can read
a few broad details about it on the pdigin GSoC wikiarea [1].

After getting all the monotone stuffs set up and looking through the
code, I thought compiling libpurple under a native Windows compiler
(read: visual studio) would be nice.  I quickly found that it's been
tired many, many times before, and some of the most complete efforts
have resulted in unmanaged DLLs [2] that can't be ran in the VS
debugger.  Part of the problem ends up being dependencies, but I
haven't yet personally looked into seeing of those dependencies (eg:
glib) have ways to get a working native VS-compiled "managed DLL".
...is this worthwhile?   ...it isn't necessary for a Windows GUI to
have the underlying DLL be compiled, but it would made development
(and debugging) a lot easier.

The other path I've explored was relying on the libpurple that is
MinGW-compiled and making [DllImport("libpurple.dll")] calls to the
DLL in C# to begin working on getting just a very basic
proof-of-concept-type GUI up on my own.  Using the 'free' version of
VS [3], I found some lovely details out that it wasn't going to be as
simple and straightforward as I would like the process to be.  I'll
update my GSoC page later today with specific details, but the 'free'
version of VS won't let you set the "x86 only flag" of the executable
it generates so if you're running on a native x64 Windows box -- you
end up with .NET trying to load libpurple as a 64-bit DLL rather than
the 32-bit DLL that it was compiled as (resulting in a "An attempt was
made to load a program with an incorrect format."
BadImageFormatException).
...using the command line compiler, you can set specific flags to
avoid this ("/platform:x86"), but this would result in any developer
using x64 Windows wouldn't be able to compile/run the project in VS
unless they have the full version of VS.
...this may make the VS-compiling more important, but I'm unsure if
there have been any attempts at compiling a 64-bit DLL for Windows?
Any errors in that process would likely creep into a native VS-compile
of libpurple.

Sorry for the long e-mail -- I'll be hopefully catch many of you in
IRC or the XMPP channel (where I'm 'utopianheaven').  I've kept
missing my GSoC pidgin mentor, Sadrul, in there, but I think I've got
it all set up where I should be actively camping the channel and will
know when my name's actually said.

I'd love to hear any insight on anything I'm missing, on any wheels
I'm reinventing, and what you feel is worthwhle.
- wade


[1]: http://developer.pidgin.im/wiki/GSoC2009/WindowsGUI
[2]: http://pidgin.im/pipermail/devel/2008-August/006634.html
[3]: http://www.microsoft.com/Express/