First thing to do, of course, is to install 'dmake.exe' and the MinGW compiler. (Note that nmake can also be used instead of dmake. Nmake15.exe contains an older version of nmake that doesn't provide the milage that dmake delivers - though, depending upon what you build, you may never be bitten by this lack of milage. Recent versions of nmake are fine.)

To install dmake and MinGW, simply run ppm install MinGW

Note: From here on, I'm assuming that dmake is being used. If you're using nmake, then it's just a matter of substituting "nmake" for "dmake" in the commands.

So long as you're running build 815 (or later) of ActiveState Perl, that's theoretically (see the Bugs and Their Fixes section below) all you need to do. Assuming that both MinGW and dmake are in your path, and that neither Microsoft's cl compiler nor nmake can be found in the path, then ActiveState Perl will automatically use dmake and MinGW, and the appropriate %Config values will be loaded. (If cl is in your path, and you want to use gcc, you must either remove cl from the path, or set the ACTIVEPERL_CONFIG_CC environment variable to gcc. If nmake is found in your path, then you can't use dmake - but nmake will work just as well with gcc as it does with cl. See perldoc ActivePerl::Config for details.)
You can then build C/C++-based modules by simply downloading the source tarball from CPAN, extracting it to some location, cd'ing to that location and running:
perl Makefile.PL dmake test dmake install
Or you can do it using the automation provided by

For builds earlier than build 815 (including builds of perl 5.6), it is necessary to also install ExtUtils::FakeConfig in accordance with the instructions found in its README.txt. (Note that one can also use ExtUtils::FakeConfig with builds 815 and later, if one wishes). That done, it's then just a matter of building modules by running:
perl -MConfig_m Makefile.PL dmake test dmake install
It's the '-MConfig_m' that loads EU::FC's (and hence the appropriate %Config values). However, in the building of various perl modules (eg PDL), the Makefile.PL may run 'perl -e' commands that need to be run as 'perl -MConfig_m -e'. In order to ensure that EU::FC's values are loaded every time perl is run, we can just set the perl5opt environment variable to -MConfig_m:
set perl5opt=-MConfig_m
Having done that, we no longer need to specify the -MConfig_m option, so it's back to running:
perl Makefile.PL dmake test dmake install

Bugs and Their Fixes

I don't know of any bugs as regarding version 0.09 (or later) of ExtUtils::FakeConfig, so if you're using its -MConfig_m option to load the appropriate %Config values, then you can ignore what follows. However, if you're relying on the automation provided by ActiveState builds prior to build 821, then there are some areas where ActiveState haven't quite got it right.

At time of original writing, build 820 was the latest ActivePerl build. I know of only one problem with it. $Config{obj_ext} remains set to '.obj' (as can be seen by running perl -V:obj_ext). But it needs to be set to '.o'. To fix, open up perl/lib/, locate the line obj_ext => '.obj', and remove it (or comment it out).

IIRC, builds 815 to 819 insisted on setting $Config{ld} to 'gcc'. Running perl -V:ld will reveal what $Config{ld} is set to. If it reports 'gcc', open up ActivePerl/ which, with builds 815 to 818 is in perl/site/lib, but is in perl/lib with subsequent builds. Find the line that specifies _override("ld",        "gcc"); and change the 'gcc' to 'g++'.

While you've got that file open, check to see what perl -V:lib_ext reports. If it reports that 'lib_ext' is set to '.a', then all is well, but if it reports that 'lib_ext' is set to '.lib' then add _override("lib_ext",        ".a"); to that same list of _override() calls. Also, in the same file (near the top), find the lines:
ldflags libc libs
and change that to:
ldflags libc lib_ext libs
And then, for that change to the $Config{lib_ext} setting to take effect, it is necessary to open perl/lib/, find the line lib_ext => '.lib', and either remove that line or comment it out.

These are the only such bugs I know of - though I've never used build 815 or 818. (Build 816 should be avoided at all costs - for unrelated reasons).

Updates: Altered the advice on how to install dmake and MinGW on the basis of jdporter's comments;
Amended "per5opt" to the correct "perl5opt" - thanks Intrepid
Build 822 of ActivePerl has since been released - no known problems wrt MinGW and dmake.
Changed (again) instructions on the installation of dmake and MinGW, as these can now be installed using ppm.
Corrected info given about how ActivePerl determines which compiler/make to use.