Tim, What I have right now doesn't link yet :-). However, I notice where things are disabled for XFRACT that don't seem to be tied to assembly language, so I don't disable them with the #if. I'm trying to drag over anything that isn't assembly language and refactoring out the I/O. As we've discussed before, the engine is agnostic about its environment as long as it can do things like "put a pixel of a certain color here". One thing I just bumped into is in the multiple precision math code. There is a dependency on an assembly language routine, d2MP086, for which there is no corresponding C equivalent. That routine is coupled to code in mpmath_c.c, namely all the code that's commented out by the XFRACT declaration. The XFRACT path seems to comment out all the lStkXXX (L_MATH) and mStkXXX (M_MATH) math routines. For now, I'm going to follow suit, but it sounds like this is one of those things you would like brought over from the fractint side into a Windows application. Is there still some benefit to running L_MATH and M_MATH routines on a modern processor? If so, we need a C version of that assembly routine, at least for porting. We can work out a way to get the 32-bit assembly equivalent later if we need it in assembly for speed. (Although to be honest, if we were really going to write modern assembly for speed we should consider MMX/SSE style assembly for higher performance integer and floating-point.) -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>