Thirded. I use AS builds, MSC v6 and nmake v7. I install most modules manually. Downloading the .gz; use gunzip and tar from UnxUtils; then the four part mantra.

Some modules that have particularly complex dependancies on third party modules, GD for example, I have built myself, but it is simply easier to use a PPM if it is available.

The main problem I encounter when building XS modules is unresolvable externals, usually from Perl%x.dll. The source of this problem is that win32 allows the programmer to specify which entrypoints in .dll are exported. This is used on win32 builds to ensure that only those entrypoints that are part of the official PerlApi are exported.

Under *nix using gcc et al. either a) has no way to limit what is exported from an .so; b) there is a mechanism but it isn't used. Either way, the result is that programmers writing XS modules under *nix, frequently use functions from perl58x.so that aren't officially a part of the PerlApi and don't notice because they get resolved and work. But when someone comes to try and build those modules on win32, those unofficial apis won't resolve. The originating authors without access to/interest in win32 simply put the problem down to "windoze" and that's where it ends.

If one #define was changed to allow all the functions in perl5x.dll to be exported, another huge swath of failures would disappear.