I have to agree with nearly everything Rich said (though I don't share either his skill or enthusiasm for Windows, though I respect him for both). There's a huge amount of development and debugging work captured in Fractint that is easy to underestimate. The minute one starts to re-architect the code in a significant way, a whole lot of functionality is immediately lost. The past ports that were successful made preserving current functionality and code-base compatibility a high priority. Echoing Rich, this is not to discourage anyone who wants to try. Just know that the work is measured in man-years. Go right ahead! There is a way forward. Major architectural changes can be made incrementally with the program actually working each step of the way. One giant step has already been taken: fractint runs in a 32 bit memory environment, namely X/Linux. The assembler and integer code have already been removed. We need to start there. Fractint internally already has some abstraction. That's why it has successfully been ported to 16 bit windows and X/linux. (For example internal routines for reading/writing pixels/lines -- different ports just implement these worker routines differently and things just work.) Everybody agrees that a lot more abstraction of the graphics/interface layer is needed. Rich made a big start in that, but had to drop it before he was finished. I believe Jonathan tried to pick up Rich's changes, but I don't know where that effort stands. My suggested roadmap forward would be: 0. Repackage existing DOS developer version as a new version. This would be the end of the road for development of the DOS version. As long as someone wants to work with the DOS version, obviously, they could. I think it could live a long time using FreeDOS if we could compile it with the now-free Watcom compiler. Right now only Jonathan and I seem to have the development enviuronment for this version! However, the rest of these comments assume that maintaining a common source base with the DOS version would be dropped. The project would fork, and one branch of the fork would leave DOS behind. 1. Start with float-only Xfractint. Complete merging Rich's changes, which were directed at separating the graphics from the underlying engine. Unless Jonathan reports one of his efforts is a better starting point, I'd do this with Xwindows. 2. The next priority is to find a way to get a parallel version working on Windows. There's more than one way to do this, but native X is not the way to go. a. wxwindows interface for both Linux and Windows - ports pretty much as-is to windows. Advantage is unified code base. b. separate Windows interface, leveraging the now-better separation of the engine from interface. c. Both a. and b. - these options are not mutually exclusive. 3. A whole lot of other improvements that can be done incrementally (some of them before or in parallel with 2.), including, but not limited to: a. memory allocation. All those fixed arrays eliminated. b. global variable cleanup c. somewhere along the way, merge in Paul's truecolor support. d. Since fractint already makes heavy use of function pointers, I think the grand scheme of how everything hangs together could be radically redesigned. We've done this before, we could do it again using a more object-oriented approach. I have some ideas about this. This is a feasible way forward. Platform would be C language or possibly C++. Orientation is more conservative than many would like, aimed at preserving 80% or so of the legacy functionality, but providing an improved design that would facilitate new features and growth. Tim