In article <00db01c74501$41df3720$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
Does X11 have any connection with the Windows version or are you doing 2 parallel developments?
The existing DOS code base has #ifdefs for WINFRACT and XFRACT. These indicate code for the Windows 3.11 version of the code and the Xfractint version of the code. So you modify the DOS code, then hack the #ifdef branch for WINFRACT to incorporate it into the Windows 3.11 version and then hack the #ifdef branch for XFRACT to incorporate it into the X11 version of the code. The branch looks at things differently. There is no DOS anymore on the branch. The WINFRACT code is there for reference (and theft of useful code!), but isn't the code path used on Windows -- instead the Win32 disk or GDI driver handles that. The XFRACT code will go the same way -- it will be an X11 driver that can be compiled into FractInt. (You could even compile an X11 driver on Windows -- there is no reason you can't have X11 client programs running on a Windows machine and displaying their graphics on a local or remote X server.) Once I've done the X11 driver for unix, then I'll have a better idea of which parts of the driver are really OS/platform considerations and which are driver considerations. There will probably be a little bit of cleanup in separating out what is "os" and what is driver. For instance, anything to do with times and dates or anything to do with the file system is an OS/platform issue and not a driver issue. There aren't many routines of this nature and they don't need to be dynamically switched like an output driver, so you can just compile one set of routines for an OS and link it in to resolve the issue. So if you wanted to port this code to a new machine, like the Mac, you would need to supply one set of "os" routines and a driver. -- "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/>