In fact, it was some years ago that I first successfully compiled MissionComputer for Windows. I’ve never bothered releasing it, though, because it can’t actually open files. Sure, the Welcome screen and about box are nice, but not that nice.
(Actually, at one point in the late 3.x series it could even open files, and didn’t crash until you tried to edit a resource, but the improvements in version 4 broke this again.)
As it stands right now, MissionComputer is entirely dependent on Macintosh system features. Even when you’re editing a .rez file, it’s handled by converting it to standard resources and then gaining access using the Resource Manager. There are plenty of other places where Macintosh features are called, but they’re trivial compared to the file-access routines. As long as this works the way it does, there’s no way that it could run usefully on Windows.
However, my mid- to long-term plans involve replacing this system with something called RFBlock, which is already present in MissionComputer 4, but inactive because of a few editors that don’t yet support it. RFBlock is essentially an alternative to the Resource Manager that stores the entire file in memory rather than using a cached copy. Back when I was designing the current model for MissionComputer 1.4, this would have been desirable, but impossible because of system limitations.
My main reason for pursuing this is that it makes the file-handling routines much more elegant, and gets rid of a number of the problem spots where I’ve had data loss occur in the past (though with version 4 I think I’ve got it pretty stable). One side-effect, however, is that a file can go from .rez to RFBlock and back without ever passing through the Resource Manager, and so it would therefore be possible to edit .rez files (but not Macintosh plug-ins) on a non-Macintosh system. So, once RFBlock comes on-line, I’ll test the Windows version again, and see how much work it would be to bypass the other parts (PICT and snd come to mind) where MissionComputer uses Mac OS code.