Ambrosia Garden Archive
    • Mission Computer for Windows


      Could it be done?

      I don't mind working with EVNEW, but I really liked Mission Computer back when I still had a Mac to run it, and it's only gotten better since those days. I know this would be a probably pretty much impossible thing to ask, but could Mission Computer be compiled for Windows? The way that it stores preferences and everything else makes me figure that it can't be done, or would be rather prohibitively difficult so as to make it impossible. I don't have the programming experience to know how difficult it would really be.

    • 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.

    • EVNEW just calls the QuickTime libraries for those resources.
      Also, although the implementation would be system-dependent, it would be worth memory-mapping the files instead of actually loading them.
      As for Mac-format plugins, the format isn't that obfuscated. The documentation is only misleading in one place, the one where the .
      On a semi-related note, I know I haven't delivered anything tangible for RezEditor, but once I do, would it be plausible for you to modify MC to allow invokation of a single editor directly, by passing a file containing just the data for the one resource? The only issue I can think of is how to pass the ID/Name AND allow them to be modified, without creating too much complexity...

    • QUOTE (Nonconventionally Creative @ Jul 8 2009, 03:53 PM) <{POST_SNAPBACK}>

      As for Mac-format plugins, the format isn't that obfuscated.

      Dealing with the Resource Manager has annoyed me on many occasions, once or twice so much that I seriously considered writing a resource-fork parser, but I don’t think that would be any more pleasant.

      As for Windows, I don’t think its users are jumping up and down to edit a file format which can’t really exist on their computers in its proper form, and realistically the Windows version will only ever happen if it doesn’t take too much work beyond what I’m doing for the Macintosh version anyway.

      QUOTE (Nonconventionally Creative @ Jul 8 2009, 03:53 PM) <{POST_SNAPBACK}>

      . . . would it be plausible for you to modify MC to allow invokation of a single editor directly, by passing a file containing just the data for the one resource? The only issue I can think of is how to pass the ID/Name AND allow them to be modified, without creating too much complexity...

      I used to have a plug-in system that did something like this, although it just passed the information about the file, rather than creating a new one. The only use it ever got was for the map editors (which were a separate application for most of the development period); it was rather awkward, and I don't think anything much has changed that would make it less so.

    • Well, I personally wouldn't have any problem with a Windows version of MC that would edit only .rez files. Perhaps support for the other file formats could just be grayed out or deleted from the Windows version, once the other issues have been eliminated? It sounds like the idea is actually not quite as crazy as I thought it might be...

    • QUOTE (krugeruwsp @ Jul 8 2009, 05:51 PM) <{POST_SNAPBACK}>

      Perhaps support for the other file formats could just be grayed out or deleted from the Windows version, once the other issues have been eliminated? It sounds like the idea is actually not quite as crazy as I thought it might be...

      Yes, I would simply hide all Mac-related features. It definitely isn’t a crazy idea; I’ve been exploring it periodically for several years, and should it ever become possible to make a MissionComputer for Windows that isn’t heavily compromised and doesn’t require significant amounts of additional code, I will probably do so.

    • Awesomeness. I hope it happens!