Re: RE: manpwin source?
Hi Florian,
Hi Paul! thanks for your trust in me! ;)
Not a problem. Let's work together.
I got a couple of questions: - Can i rework the code a bit? Are you working on it or is anyone else?
Please feel free to change it any way you like. Just send me the modified files and a short description of the changes and I will merge it into the main product.
- How to you handle multiple developers on the same code?
Right now it's just you and me. There are not a lot of WINDOWS programmers working on fractal code that I know of.
- i've got this crash after selecting a truecolor-file, that I am trying to fix. Have you had similar problems?
My error detection may be a bil lacking. Send me the offending file and I will debug.
- What is the 'roadmap'? I hear fractint is becoming float-only?
Yes, FRACTINT is now float only because the PCs are now fast enough to handle the floating point arithmetic.
Is your plan to keep the branch 'manpwin' or do you want to merge with fractint at some point?
I am not sure whether it is easier to keep ManpWIN as a separate stream or to merge it with FRACTINT. After several attempts at merger, I keep getting lost in the user interface. FRACTINT loops are not easy to merge with large WINDOWS loops. I am tempted to compile all the non UI stuff into a library which is easy to maintain by keeping up with the FRACTINT float only code and using ManpWIN to call the library routines. Any comments? By the way, what compiler do you use? All my stuff is built with straight Windows SDK and no MFC for maximum compatibility with FRACTINT and other compilers. I use Microsoft Visual C++ version 4.0. Regards, Paul. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: http://www.deleeuw.com.au ABN 72 360 822 562 ----------------------------------------------------------
Hi Paul and others, first of all I apologize If I pose FAQs (just joined the list), but so far I could not find any of this in the mailing list archives: Here are two more questions to list: 1. how about moving the projects FRACTINT and MANPWIN to sourceforge? This way we could co-develop using a central cvs server. 2. where there any thoughts on rewriting the gui with a free, portable c/c++ based GUI layer such as GTK+ ? -> we would have the same GUI for Unix and Windows GIMP is a good example for such a project. Qt also comes to mind, but its not free under windows... Task would be to strictly separate the code between backend calculus and GUI.
-----Original Message----- From: fractdev-admin@mailman.xmission.com [mailto:fractdev-admin@mailman.xmission.com]On Behalf Of pdeleeuw Sent: Sunday, February 02, 2003 10:04 PM To: flo@fkolbe.de Cc: fractdev@mailman.xmission.com Subject: [Fractdev] Re: RE: manpwin source?
Hi Florian,
Hi Paul! thanks for your trust in me! ;)
Not a problem. Let's work together.
I got a couple of questions: - Can i rework the code a bit? Are you working on it or is anyone else?
Please feel free to change it any way you like. Just send me the modified files and a short description of the changes and I will merge it into the main product.
- How to you handle multiple developers on the same code?
Right now it's just you and me. There are not a lot of WINDOWS programmers working on fractal code that I know of.
- i've got this crash after selecting a truecolor-file, that I am trying to fix. Have you had similar problems?
My error detection may be a bil lacking. Send me the offending file and I will debug.
- What is the 'roadmap'? I hear fractint is becoming float-only?
Yes, FRACTINT is now float only because the PCs are now fast enough to handle the floating point arithmetic.
Is your plan to keep the branch 'manpwin' or do you want to merge with fractint at some point?
I am not sure whether it is easier to keep ManpWIN as a separate stream or to merge it with FRACTINT. After several attempts at merger, I keep getting lost in the user interface. FRACTINT loops are not easy to merge with large WINDOWS loops. I am tempted to compile all the non UI stuff into a library which is easy to maintain by keeping up with the FRACTINT float only code and using ManpWIN to call the library routines. Any comments?
By the way, what compiler do you use? All my stuff is built with straight Windows SDK and no MFC for maximum compatibility with FRACTINT and other compilers. I use Microsoft Visual C++ version 4.0.
Regards,
Paul.
---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: http://www.deleeuw.com.au ABN 72 360 822 562 ----------------------------------------------------------
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
Florian wrote:
1. how about moving the projects FRACTINT and MANPWIN to sourceforge? This way we could co-develop using a central cvs server.
Strange as it sounds, since we've been open source from the beginning, our license is not "open source" according to any of the definition at http://www.opensource.org/. Therefore we can't use sourceforge. It's not as easy as you might think to change our license since we are not in contact with most of our contributors. If we get into a big rewrite, we can systematically go to a new license, probably GPL, the sourceforge would be an option.
2. where there any thoughts on rewriting the gui with a free, portable c/c++ based GUI layer such as GTK+ ? -> we would have the same GUI for Unix and Windows GIMP is a good example for such a project. Qt also comes to mind, but its not free under windows...
Task would be to strictly separate the code between backend calculus and GUI.
This just needs a developer to do it. It has been proposed many times. Brave talk is cheap :-) Tim
Tim, Paul, I've looked into the source, my goal is to have the same code base for fractint/DOS and a new 'platform', say 'libfractint'. My idea is to differentiate like with the define XFRACT just like Tim suggested to Paul de Leeuw (->manpwin). I could try to eliminate most of the asm code by using the xfract c-replacements. For the graphics part, there will be an abstraction layer so the different GUIs can base on that (such as 'getpixel' et al). This way we would have a 20.2.04-based 'backend' apart from the asm-stuff where there are no replacements (lyapunov et al), right? The 'libfractint' variant would be the base for a new, portable GUI. Here are my questions: - what do you think of this approach? - I'm using Visual Studio 6.0 (could also make sure it doesn't break unix), so I won't be able to compile the 'original' fractitn/DOS because VS 6.0 lacks 16 Bit support. Will someone be willing to test my code so it still compiles for DOS? - is someone willing to port the missing asm-modules (the ones not replaced by xfract) to C or 32-bit ASM? Cheers, Florian
-----Original Message----- From: fractdev-admin@mailman.xmission.com [mailto:fractdev-admin@mailman.xmission.com]On Behalf Of Tim Wegner Sent: Monday, February 03, 2003 1:46 AM To: fractdev@mailman.xmission.com Subject: Re: [Fractdev] sourceforge, Rewrite portable GUI
Florian wrote:
1. how about moving the projects FRACTINT and MANPWIN to sourceforge? This way we could co-develop using a central cvs server.
Strange as it sounds, since we've been open source from the beginning, our license is not "open source" according to any of the definition at http://www.opensource.org/. Therefore we can't use sourceforge.
It's not as easy as you might think to change our license since we are not in contact with most of our contributors.
If we get into a big rewrite, we can systematically go to a new license, probably GPL, the sourceforge would be an option.
2. where there any thoughts on rewriting the gui with a free, portable c/c++ based GUI layer such as GTK+ ? -> we would have the same GUI for Unix and Windows GIMP is a good example for such a project. Qt also comes to mind, but its not free under windows...
Task would be to strictly separate the code between backend calculus and GUI.
This just needs a developer to do it. It has been proposed many times. Brave talk is cheap :-)
Tim
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <000001c2e128$7c6e9ac0$017ba8c0@snoopy>, "Florian Kolbe" <flo@fkolbe.de> writes:
I've looked into the source, my goal is to have the same code base for fractint/DOS and a new 'platform', say 'libfractint'.
Check the archives, this has been talked about many times and I made progress to 90% completion on the task before starting my book. The book has taken up all my spare time, so I haven't revisited the code much but always planned on pushing it to completion. I split the code out into UI and non-UI parts through a 'driver' interface. Jonathan made some progress using this for an Allegro port, but didn't drive it to completion either. Despite this dismal sounding progress report, it really wouldn't take much to push it to 100% complete. For the rest of what you describe, most of it has already been done IIRC. If you want to pursue this, I suggest taking the code from where I last left it and push it to completion. I already cobbled up a DSW/DSP for VC6 that compiles the code. I can upload that to the archive as I haven't done that yet. -- "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>
Hi Rich, thanks for the quick reply, I'd love to see your code, maybe I can finish it. Are there any chances we can merge it back into the main branch? (unfortunately, I'm not very good at merging - only at programming...). Let me know where I can download it, and I'd be eager to work on it. Thanks, Florian
-----Original Message----- From: fractdev-admin@mailman.xmission.com [mailto:fractdev-admin@mailman.xmission.com]On Behalf Of Rich Sent: Monday, March 03, 2003 3:11 AM To: fractdev@mailman.xmission.com Subject: Re: [Fractdev] Idea 'libfractint'
In article <000001c2e128$7c6e9ac0$017ba8c0@snoopy>, "Florian Kolbe" <flo@fkolbe.de> writes:
I've looked into the source, my goal is to have the same code base for fractint/DOS and a new 'platform', say 'libfractint'.
Check the archives, this has been talked about many times and I made progress to 90% completion on the task before starting my book. The book has taken up all my spare time, so I haven't revisited the code much but always planned on pushing it to completion. I split the code out into UI and non-UI parts through a 'driver' interface. Jonathan made some progress using this for an Allegro port, but didn't drive it to completion either. Despite this dismal sounding progress report, it really wouldn't take much to push it to 100% complete.
For the rest of what you describe, most of it has already been done IIRC. If you want to pursue this, I suggest taking the code from where I last left it and push it to completion. I already cobbled up a DSW/DSP for VC6 that compiles the code. I can upload that to the archive as I haven't done that yet. -- "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
In article <000401c2e1d0$161cab60$017ba8c0@snoopy>, "Florian Kolbe" <flo@fkolbe.de> writes:
thanks for the quick reply, I'd love to see your code, maybe I can finish it.
OK, this is the Allegro xfractint branch 20.2.03 that Jonathan pointed me at a while ago. I got it compiling under VC6 and added DSW and DSP files. Beyond that, I didn't take it much farther. <http://www.xmission.com/~legalize/fractals/fractdev/xfract20.2.03.zip> -- "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>
This would be my 'work in progress' on that allegro branch: 2003/03/06 FLK (Florian Kolbe): * Ported to WIN32 (Visual Studio 6) and back to linux (including _HAVE_ALLEGRO, tried with 4.0.0, this crashes in XOpenDisplay?). * Removed the XFRACT define, introduced DOS instead. This way we don't have to define XFRACT for all non-DOS platforms, which is kind of awkward. * Reworked port.h, incorporated unix.h into port.h, don't define 'unix' by ourselves. * Modified d_fract.c so it compiles in WIN32, though all stubs are empty. Added d_template.c for future drivers (not to be compiled). * Made Makefile more configurable. * Renamed HELP_INDEX to FRACT_HELP_INDEX because of clashes. But before I return it (maybe for a merge?) I'd like to try to compile it under DOS. Where can I get a compiler??? MAJOR TASK: would be to move the original 'fractint for DOS' code into d_fract. Anyone interested? The driver approach is nice - but the code still has too much control over the program flow for my taste. I will try and start to implement a new driver now (a test driver). I'll see how the driver interface suits the needs. Florian
-----Original Message----- From: fractdev-admin@mailman.xmission.com [mailto:fractdev-admin@mailman.xmission.com]On Behalf Of Rich Sent: Tuesday, March 04, 2003 6:25 AM To: fractdev@mailman.xmission.com Subject: Re: [Fractdev] Idea 'libfractint'
In article <000401c2e1d0$161cab60$017ba8c0@snoopy>, "Florian Kolbe" <flo@fkolbe.de> writes:
thanks for the quick reply, I'd love to see your code, maybe I can finish it.
OK, this is the Allegro xfractint branch 20.2.03 that Jonathan pointed me at a while ago. I got it compiling under VC6 and added DSW and DSP files. Beyond that, I didn't take it much farther.
<http://www.xmission.com/~legalize/fractals/fractdev/xfract20. 2.03.zip> -- "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
In article <000001c2e4f3$1d0fb630$017ba8c0@snoopy>, "Florian Kolbe" <flo@fkolbe.de> writes:
MAJOR TASK: would be to move the original 'fractint for DOS' code into d_fract. Anyone interested?
I'm fuzzy on d_fract.c; d_dos.c would probably be a better name for it since its a 'DOS driver', not a 'fract driver'.
The driver approach is nice - but the code still has too much control over the program flow for my taste.
Yes, the DOS code is polling-based for the I/O. All windowing systems are event driven. The way that xfractint got around this was that whenever the fractint code would poll, xfractint would poke at the message queue. Its ugly and its a hack, but it (mostly) works. I agree that its distasteful to my sensibilities, however this was "round 1 of code rehabilitation" and wasn't intended to eliminate every wart in the source base. I think its best to get the display driver stuff working again both under X11, 'disk' and under Win32 before tackling the control flow issue. Always try and keep the code working with as small a change as possible. -- "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>
Hi Rich,
[mailto:fractdev-admin@mailman.xmission.com]On Behalf Of Rich
In article <000001c2e4f3$1d0fb630$017ba8c0@snoopy>, "Florian Kolbe" <flo@fkolbe.de> writes:
MAJOR TASK: would be to move the original 'fractint for DOS' code into d_fract. Anyone interested?
I'm fuzzy on d_fract.c; d_dos.c would probably be a better name for it since its a 'DOS driver', not a 'fract driver'.
I'll move it. In fact, the driver name is already 'dos' :)
The driver approach is nice - but the code still has too much control over the program flow for my taste.
Yes, the DOS code is polling-based for the I/O. All windowing systems are event driven. The way that xfractint got around this was that whenever the fractint code would poll, xfractint would poke at the message queue. Its ugly and its a hack, but it (mostly) works. I agree that its distasteful to my sensibilities, however this was "round 1 of code rehabilitation" and wasn't intended to eliminate every wart in the source base. I think its best to get the display driver stuff working again both under X11, 'disk' and under Win32 before tackling the control flow issue.
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'.
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 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). Florian
-- "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
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>
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
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>
On Saturday 08 March 2003 05:39 am, Florian Kolbe wrote:
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.
The original reason for adding the Allegro code to Rich's experimental code was to make it easier to port back to DOS/WIN since Allegro has a port to that environment. I ran into the same need to use a DOS define. I'm currently looking into using autoconfig/automake so that we will be able to run a configure script prior to compiling. It is probably worth the effort to get this well on its way before doing extensive work porting to other environments.
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).
Actually, I would recommend gcc (or is it called djgpp?). It should be possible to use essentially the same utilities under the various environments we are interested in. One of the reasons I chose nasm for porting the assembly language was that it is available for DOS/WIN. The initial port is painful because the syntax is different from the Intel syntax (oper src,dst instead of oper dst,src). Jonathan
I'd rather start a new thread on this. I still have this major problem that I hesitate to change the code as long as: - I can't compile for DOS (16 Bit) - There's no central CVS (see other thread on this) As for the DOS part, the question is whether we should continue to support the different memory models for DOS. If so, we should try and find a freely available DOS compiler to handle this. If not, then we won't be as much in trouble, and we could look at djgpp/ggc for Windoze as Jonathan suggested. If someone is interested, here is a list I found on the usenet ('99): (Post was: http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&selm=9g1l3.2280%24Vb4.1468 5%40tundra.ops.attcanada.net&rnum=6) Freely available C compilers for DOS: These are the major downloadable C compilers that I know of for DOS. NOTE that "freely available" does not necessarily mean FREE. Some of the tools require payment for continued use. Also note, that I do not have extensive experience with these (except for the last one :-)... Some I have used a bit, while others I have barely looked at. My comments are from my observations in those cases where I have used the tools, from feedback from my users, and general comments I have seen posted on the net. None of this should be taken as gospel, and this should not be considered my endorsement of these tools. Additions/Corrections to this list are welcome. DJGPP GCC/GPP GNU 32 bit C/C++ compiler - This is the biggest and most complete free DOS C/C++ implementation - Supports ANSI C and C++ - 32 bit only, requires 386+ and DOS extender - Reported to be difficult for use by Novices - Available for a wide variety of development platforms - Very large user community, well liked by experienced users - Lots of add-on's, libraries, tools are available - Source code is freely available (very large/complex) - Lots of/Good documentation, although hard for novice find/sort through - Restricted by GNU "copyleft" - http://www.delorie.com LCC portable C compiler - Supports ANSI C - Available for a wide variety of development platforms - Well documented via published book, little free docs - Source code is freely available - Not really oriented toward a novice user - "freeware" - copyright but free for personal use - http://www.cs.princeton.edu/software/lcc - http://www.cs.virginia.edu/~lcc-win32 PACIFIC C - Supports ANSI C - 16 bit, runs on 8088+ - Includes nice DOS IDE (like Turbo-C) + command line tools - Well documented via large PDF file (350+ pages) - Commercial versions available for several embedded processors - "freeware" - copyright but free for general use - http://www.hitech.com.au PCC Personal C Compiler - Supports K&R C only - 16 bit, runs on 8088+ - Command line interface only - Does not appear to be under current developemt / support - Well documented (approx 100 page text file) - Shareware - payment required for continued use - I don't have an "official" URL, but you can download PCC*.ZIP from many sites. (try SIMTEL - oak.oakland.edu) MIRACLE C - Supports K&R C with minor ANSI extensions - 16 bit, compiled code runs under DOS - Compiler/IDE requires windows, 386+ - Somewhat documented (approx 30 pages + windows help file) - Compiler source code is available with registration - Shareware - payment required for continued use - http://www.ncf.ca/~bg283 CC386 - I don't know a whole lot about this one, it appears to be a PC adaptation of Matt Brandts CC68k compiler with improvements - Supports K&R C - 32 bit, requires 386+ - Source code is freely available - "freeware", possibly public domain? - http://www.tripod.com/~ladsoft SMALL-C - Minimal K&R C subset, not very suitable for serious work - 16 bit, runs on 8088+, generates fairly poor code - Well documented via published book, little free docs - Versions for 8080(CP/M), 8086(DOS), and a few other processors - Source code is freely available, fairly simple and easy to modify - Exact status varies, original sources by Ron Cain contain no copyright notices, and are accompanied by a statement that it is "free to anyone wishing to use it". Later versions by J.Hendrix contain copyright notices and shareware registration forms - No official URL, but available on many sites (try SIMTEL - oak.oakland.edu) - may be something on www.drdobbs.com as Small-C was first published there. MICRO-C - I am the author, so I am obviously somewhat biased on this one - Subset ANSI with extensions (large subset) - Includes a DOS IDE + command line tools - Well documented (approx 400 pages text files) - Comprehensive PC library (~300 functions), including TSR, Windowing Serial Comms, Graphics -lots more. Library source with registration - Generates tiny executables ("Hello World" = ~500bytes) - Large collection of example programs with registration (over 100) - Commercial versions available for many embedded processors - "freeware" - optional registration (not required for continued use) - www.dunfield.com
-----Original Message----- From: fractdev-admin@mailman.xmission.com [mailto:fractdev-admin@mailman.xmission.com]On Behalf Of Jonathan Osuch Sent: Monday, March 10, 2003 2:27 AM To: fractdev@mailman.xmission.com Subject: Re: [Fractdev] Idea 'libfractint'
On Saturday 08 March 2003 05:39 am, Florian Kolbe wrote:
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.
The original reason for adding the Allegro code to Rich's experimental code was to make it easier to port back to DOS/WIN since Allegro has a port to that environment. I ran into the same need to use a DOS define.
I'm currently looking into using autoconfig/automake so that we will be able to run a configure script prior to compiling. It is probably worth the effort to get this well on its way before doing extensive work porting to other environments.
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).
Actually, I would recommend gcc (or is it called djgpp?). It should be possible to use essentially the same utilities under the various environments we are interested in.
One of the reasons I chose nasm for porting the assembly language was that it is available for DOS/WIN. The initial port is painful because the syntax is different from the Intel syntax (oper src,dst instead of oper dst,src).
Jonathan
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
Come to think of it - is the asm stuff 16 Bit only? Can it be 'ported' to 32 Bit? Or are we going 'float-only' in the future? The question is: can we release ourselves from the asm code completely? Florian P.S. Sorry if these are all FAQs or if this has been discussed before, but maybe recent developments shed a new light on this, so I won't dig up the archives for now...
-----Original Message----- From: fractdev-admin@mailman.xmission.com [mailto:fractdev-admin@mailman.xmission.com]On Behalf Of Florian Kolbe Sent: Monday, March 10, 2003 2:54 AM To: fractdev@mailman.xmission.com Subject: [Fractdev] Compiling for DOS - give up memory models?
I'd rather start a new thread on this. I still have this major problem that I hesitate to change the code as long as: - I can't compile for DOS (16 Bit) - There's no central CVS (see other thread on this)
As for the DOS part, the question is whether we should continue to support the different memory models for DOS. If so, we should try and find a freely available DOS compiler to handle this. If not, then we won't be as much in trouble, and we could look at djgpp/ggc for Windoze as Jonathan suggested.
If someone is interested, here is a list I found on the usenet ('99): (Post was: http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&selm=9g1l3.2 280%24Vb4.1468 5%40tundra.ops.attcanada.net&rnum=6)
Freely available C compilers for DOS:
These are the major downloadable C compilers that I know of for DOS. NOTE that "freely available" does not necessarily mean FREE. Some of the tools require payment for continued use.
Also note, that I do not have extensive experience with these (except for the last one :-)... Some I have used a bit, while others I have barely looked at. My comments are from my observations in those cases where I have used the tools, from feedback from my users, and general comments I have seen posted on the net. None of this should be taken as gospel, and this should not be considered my endorsement of these tools.
Additions/Corrections to this list are welcome.
DJGPP GCC/GPP GNU 32 bit C/C++ compiler - This is the biggest and most complete free DOS C/C++ implementation - Supports ANSI C and C++ - 32 bit only, requires 386+ and DOS extender - Reported to be difficult for use by Novices - Available for a wide variety of development platforms - Very large user community, well liked by experienced users - Lots of add-on's, libraries, tools are available - Source code is freely available (very large/complex) - Lots of/Good documentation, although hard for novice find/sort through - Restricted by GNU "copyleft" - http://www.delorie.com
LCC portable C compiler - Supports ANSI C - Available for a wide variety of development platforms - Well documented via published book, little free docs - Source code is freely available - Not really oriented toward a novice user - "freeware" - copyright but free for personal use - http://www.cs.princeton.edu/software/lcc - http://www.cs.virginia.edu/~lcc-win32
PACIFIC C - Supports ANSI C - 16 bit, runs on 8088+ - Includes nice DOS IDE (like Turbo-C) + command line tools - Well documented via large PDF file (350+ pages) - Commercial versions available for several embedded processors - "freeware" - copyright but free for general use - http://www.hitech.com.au
PCC Personal C Compiler - Supports K&R C only - 16 bit, runs on 8088+ - Command line interface only - Does not appear to be under current developemt / support - Well documented (approx 100 page text file) - Shareware - payment required for continued use - I don't have an "official" URL, but you can download PCC*.ZIP from many sites. (try SIMTEL - oak.oakland.edu)
MIRACLE C - Supports K&R C with minor ANSI extensions - 16 bit, compiled code runs under DOS - Compiler/IDE requires windows, 386+ - Somewhat documented (approx 30 pages + windows help file) - Compiler source code is available with registration - Shareware - payment required for continued use - http://www.ncf.ca/~bg283
CC386 - I don't know a whole lot about this one, it appears to be a PC adaptation of Matt Brandts CC68k compiler with improvements - Supports K&R C - 32 bit, requires 386+ - Source code is freely available - "freeware", possibly public domain? - http://www.tripod.com/~ladsoft
SMALL-C - Minimal K&R C subset, not very suitable for serious work - 16 bit, runs on 8088+, generates fairly poor code - Well documented via published book, little free docs - Versions for 8080(CP/M), 8086(DOS), and a few other processors - Source code is freely available, fairly simple and easy to modify - Exact status varies, original sources by Ron Cain contain no copyright notices, and are accompanied by a statement that it is "free to anyone wishing to use it". Later versions by J.Hendrix contain copyright notices and shareware registration forms - No official URL, but available on many sites (try SIMTEL - oak.oakland.edu) - may be something on www.drdobbs.com as Small-C was first published there.
MICRO-C - I am the author, so I am obviously somewhat biased on this one - Subset ANSI with extensions (large subset) - Includes a DOS IDE + command line tools - Well documented (approx 400 pages text files) - Comprehensive PC library (~300 functions), including TSR, Windowing Serial Comms, Graphics -lots more. Library source with registration - Generates tiny executables ("Hello World" = ~500bytes) - Large collection of example programs with registration (over 100) - Commercial versions available for many embedded processors - "freeware" - optional registration (not required for continued use) - www.dunfield.com
-----Original Message----- From: fractdev-admin@mailman.xmission.com [mailto:fractdev-admin@mailman.xmission.com]On Behalf Of Jonathan Osuch Sent: Monday, March 10, 2003 2:27 AM To: fractdev@mailman.xmission.com Subject: Re: [Fractdev] Idea 'libfractint'
On Saturday 08 March 2003 05:39 am, Florian Kolbe wrote:
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.
The original reason for adding the Allegro code to Rich's experimental code was to make it easier to port back to DOS/WIN since Allegro has a port to that environment. I ran into the same need to use a DOS define.
I'm currently looking into using autoconfig/automake so that we will be able to run a configure script prior to compiling. It is probably worth the effort to get this well on its way before doing extensive work porting to other environments.
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).
Actually, I would recommend gcc (or is it called djgpp?). It should be possible to use essentially the same utilities under the various environments we are interested in.
One of the reasons I chose nasm for porting the assembly language was that it is available for DOS/WIN. The initial port is painful because the syntax is different from the Intel syntax (oper src,dst instead of oper dst,src).
Jonathan
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
I know nothing of the assembly code stuff. I'm hoping we can ditch small memory models on the DOS port and move to a flat model ASAP. My interest is in moving the code base forward to where we can have Win/DirectX support in fractint. -- "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>
On Sunday 09 March 2003 08:00 pm, Florian Kolbe wrote:
Come to think of it - is the asm stuff 16 Bit only? Can it be 'ported' to 32 Bit? Or are we going 'float-only' in the future?
The question is: can we release ourselves from the asm code completely?
I've already ported the assembly code that calculates the Mandelbrot set to nasm, which is 32 bit. Yes, that is an added complication. I have a port of the formula parser assembly code which doesn't crash, but doesn't produce any output either. Because of the Xfractint code base, we can pick and choose the assembly code we port. I'll take a look at the errors I got when I tried compiling xfractint with djgpp. The major problem is the video interface since the video assembly code is useless. Jonathan
On Sunday 09 March 2003 08:40 pm, Jonathan Osuch wrote:
I'll take a look at the errors I got when I tried compiling xfractint with djgpp.
That is ugly! I would like to get away from all the 'ifdef XFRACT' statements (or anything similar) scattered throughout the code. Jonathan
In article <200303102028.32650.osuchj@avalon.net>, Jonathan Osuch <osuchj@avalon.net> writes:
I would like to get away from all the 'ifdef XFRACT' statements (or anyth= ing=20 similar) scattered throughout the code.
I think the way to minimize the extent of #defines throughout the code base is to localize them to a 'platform' layer. (Note that the 'driver' layer I've done is only concerned with keyboard/mouse input and video display.) The 'platform' layer handles all the weird platform stuff that has so far been lumped into #ifdef XFRACT; things like interacting with the file system, interacting with floating-point errors, interacting with variations in include files and system call function prototypes. If you localize all this stuff in a platform layer, then the rest of the code just calls the platform layer for these things instead of having to deal with the variations. That localizies the variations to one place at least. This has been successful in minimizing the #ifdefs on previous projects on which I've worked. -- "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>
Florian asked:
The question is: can we release ourselves from the asm code completely?
To augment Jonathan's answer: The Xfractint port is already completely free of ASM. Jonathan is adding back-ported ASM to Xfractint where it makes sense, but it is still optional. Even in the DOS code, there are user-selectable C alternatives for nearly everything except video. The DOS medium model version has a complete feature set and the best performance, so most users prefer it. When the team believes we have enough developer commitment, we can start with the Xfractint float-only version (or several of it's experimental forks) and use that as a baseline, and start major overhauls that will break medium model support. When it's just Jonathan developing, he's kept up with the DOS version. Makes sense to me. Tim
Florian asked:
As for the DOS part, the question is whether we should continue to support the different memory models for DOS. If so, we should try and find a freely available DOS compiler to handle this. If not, then we won't be as much in trouble, and we could look at djgpp/ggc for Windoze as Jonathan suggested.
At any time we are ready to really have a head of steam on changes, we could stop supporting DOS. But nobody knows how much they are willing to work. Quite recently there was some enthusiasm for major changes, but it suddenly stopped (note: I'm not critical of that person at all.) If we do fork, it would be nice to have some way to run the development version under Windows or DOS. It is probably feasible to start with the float-only Xwindows version, and port to djgpp with the SVGA driver. A free compiler that I would think would fit the bill for supporting the current DOS version is openwatcom. I had a look, and there's clearly some effort needed to make it work, but I believe it supports the medium memory model. See http://www.openwatcom.org/ I see there's a Microsoft C 7.0 available now on Ebay. We know that works :-) Older Borland compilers work. Tim
[mailto:fractdev-admin@mailman.xmission.com]On Behalf Of Tim Wegner Sent: Monday, March 10, 2003 3:00 AM
A free compiler that I would think would fit the bill for supporting the current DOS version is openwatcom. I had a look, and there's clearly some effort needed to make it work, but I believe it supports the medium memory model.
Ok, I downloaded OpenWatcom and installed it. I will try to compile the allegro with it soon... Florian
-----Original Message----- From: fractdev-admin@mailman.xmission.com [mailto:fractdev-admin@mailman.xmission.com]On Behalf Of Tim Wegner Sent: Monday, March 10, 2003 3:00 AM To: fractdev@mailman.xmission.com Subject: Re: [Fractdev] Compiling for DOS - give up memory models?
Florian asked:
As for the DOS part, the question is whether we should continue to support the different memory models for DOS. If so, we should try and find a freely available DOS compiler to handle this. If not, then we won't be as much in trouble, and we could look at djgpp/ggc for Windoze as Jonathan suggested.
At any time we are ready to really have a head of steam on changes, we could stop supporting DOS. But nobody knows how much they are willing to work. Quite recently there was some enthusiasm for major changes, but it suddenly stopped (note: I'm not critical of that person at all.)
If we do fork, it would be nice to have some way to run the development version under Windows or DOS. It is probably feasible to start with the float-only Xwindows version, and port to djgpp with the SVGA driver.
A free compiler that I would think would fit the bill for supporting the current DOS version is openwatcom. I had a look, and there's clearly some effort needed to make it work, but I believe it supports the medium memory model.
See
I see there's a Microsoft C 7.0 available now on Ebay. We know that works :-)
Older Borland compilers work.
Tim
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <200303091927.00630.osuchj@avalon.net>, Jonathan Osuch <osuchj@avalon.net> writes:
One of the reasons I chose nasm for porting the assembly language was tha= t it=20 is available for DOS/WIN. The initial port is painful because the syntax= is=20 different from the Intel syntax (oper src,dst instead of oper dst,src).
Can't this be handled with an awk script? -- "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>
On Sunday 09 March 2003 08:15 pm, Rich wrote:
One of the reasons I chose nasm for porting the assembly language was that it is available for DOS/WIN. The initial port is painful because the syntax is different from the Intel syntax (oper src,dst instead of oper dst,src).
Can't this be handled with an awk script?
That's a thought. I don't have enough experience with it to know for sure. Jonathan
In article <200303101900.36167.osuchj@avalon.net>, Jonathan Osuch <osuchj@avalon.net> writes:
is available for DOS/WIN. The initial port is painful because the syntax is different from the Intel syntax (oper src,dst instead of oper dst,src= ). Can't this be handled with an awk script?
That's a thought. I don't have enough experience with it to know for sur= e.
If its just a simple swapping of dst and src operands, it could easily be done with an awk or sed script. You're basically matching for each op code and doing a regexp replace. For instance sed 's/mov \([^,]*\),\([^,]*\)$/mov \2, \1/' would swap the two arguments of any 'mov' instruction with two arguments. -- "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>
participants (5)
-
Florian Kolbe -
Jonathan Osuch -
pdeleeuw -
Rich -
Tim Wegner