Hi Rich, don't worry, I wasn't to introduce threading _within_ the driver or the lib. My major idea was to: - compile the code into a lib (in fact, already got a DLL) - make the necessary functions external, that need to be called in order to start a calculation. This would involve extracting the necessary initialization code from main() etc. (again here, got the first MFC based prototype running) - Regarding threads. I was to introduce a 'worker thread', but not within the driver or lib, but the controlling app, usually, the model works like: - main thread: always runs, controls the GUI and other threads - worker thread: calls libfractint-functions to do calcs (this can be interrupted by pressing a 'virtual' key) Maybe I should look into to winfract source... Still can't get a hold of a DOS compiler (I think TC 2.01 is too old..). I'll try the MSDN as you suggested... I set up a local CVS server so I can keep track of my changes pretty well (trying not to rework the code too much). Florian
-----Original Message----- From: fractdev-admin@mailman.xmission.com [mailto:fractdev-admin@mailman.xmission.com]On Behalf Of Rich Sent: Saturday, March 08, 2003 10:07 PM To: fractdev@mailman.xmission.com Subject: Re: [Fractdev] Idea 'libfractint'
In article <000101c2e567$595aa4a0$017ba8c0@snoopy>, "Florian Kolbe" <flo@fkolbe.de> writes:
I'm working on a concept that will try to run calcfract without the 'big while loop'. One could put that in a worker thread and the GUI would still be able to react while the worker thread is calculating. One can cleanly stop the worker thread by pressing a virtual 'key'.
I would definately hold off on introducing any threading into the fractint source base just yet. The whole goal of this 'driver model' project was to bring a single fractint source base to a wider variety of platforms. The problem with threading is that its wildly different on every platform. Rather than introduce another platform dependency, I would suggest that we stick with the code the way it is right now and get it working as-is on the different platforms.
Always try and keep the code working with as small a change as possible.
The only major change was to remove XFRACT in favor of DOS. It's much easier to keep the DOS specific parts in #ifdef DOS-Brackets, than #ifndef XFRACT, because XFRACT does not necessarily mean all the other derivatives. I introcuded _HAVE_ALLEGRO, _HAVE_X11 and such in order optionally compile the different drivers.
I can go along with that.
I now downloaded Turbo C 2.01 from http://community.borland.com/museum/, so I can try to compile the DOS part (though not yet moved to d_dos.c). Can this compiler handle it? I don't know where to get another one (though I am even willing to buy one, just someone let me know which one I should get).
I don't know anything about DOS compilation environments as I've only ever compiled on Windows. I think somewhere in my MSDN Universal subscription I have an old version of MS C that can compile 16-bit code though. -- "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> _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev