The author is not a GAP expert, so the contents of this section should be read with some caution. He is currently preparing a new set of GAP modules which will be designed to work well with MAF and will also allow the user to use KBMAG to perform the same tasks (either via the existing KBMAG package, or by setting an option in the new package), so that users will be able to use either package to verify results produced by the other. However, it is already possible to access MAF from within GAP by using the existing KBMAG package, as the next two paragraphs explain.
KBMAG is published as a GAP package for Unix only. However it is certainly also possible to get it running under GAP 4.4.x on a Windows machine (the author has done this on both Windows 2000 and Windows XP machines). If the binary files in the gap/kbmag/bin/architecture/ directory are replaced with the corresponding files from MAF, then this package continues to work well - at least with all the examples contained in the KBMAG documentation. This is probably the easiest way to use MAF from within GAP. In fact it is probably best initially only to replace autgroup, autcos, kbprog and kbprogcos. In particular he has not tested whether all the FSA utilities common to KBMAG and MAF can be replaced with MAF versions.
A second possibility is to copy the kbmag subdirectory of GAP's pkg directory to maf and again to replace the binary files. In this case you would also need to edit various .g files to get them to refer to MAF rather than KBMAG. But it is probably best to leave function names unchanged, since there is no GAP documentation for MAF. The author can supply suitably modified files if anyone is interested. If this is done it is possible to use either MAF or KBMAG to investigate groups. However, unless you go to the trouble of changing a large number of function names, it is not possible to have both packages loaded at the same time.
One notable difference between the existing KBMAG package and the package the author is developing is that the new interface will use the same generator labels in the rewriting system and FSA as you use in GAP, and will use the case change convention for inverses. Therefore the files produced by the new interface would be more easily usable from outside GAP, and you will therefore be able to save them. This will make it easier to do things like changing the order or names of generators, which is currently error-prone.