In article <000301c2e5e6$22501e70$017ba8c0@snoopy>, "Florian Kolbe" <flo@fkolbe.de> writes:
Hi Rich, don't worry, I wasn't to introduce threading _within_ the driver or the lib.
OK, I just want to caution against making huge conceptual changes to the existing source base as its likely to lead you into a frustrating corner :-). The way I came up with the driver interface (which is a big change) was to print out -all- of the fractint/xfractint source and study it for a long time. That let me find all the places where the calculation code was calling to do some "display" style operation or an "input" style operation. That's how I came up with the list of entry points for the driver interface. Fractint is a -huge- amount of source to study, though! A similar studying session will probably be required to refacto the source into an event driven mechanism. The 'engine' is pretty well factored out in the existing source base, but unfortunately there are all those little places where the engine polls for I/O in the middle of a lengthy calculation.
I'll try the MSDN as you suggested...
Note: I was referring to the MSDN subscription CD-ROMs, not the online free stuff. AFAIK, MS makes no free compilers available for C/DOS. However, if you look at the mailing list archives for this list you should find discussions about this. I believe the consensus was that if you're making this significant a change to the source base already, then you should go for a flat-model DOS port with a protected mode extender instead of trying to preserve the existing small memory model code. That means that all the common code is a flat model and the DOS version only has funky code for the platform: I/O, display, etc. I don't see any point in trying to maintain the small memory model DOS code across this architectural change. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>