Paul,

If we can find a way to segment the task, I'd love to be part of it. I have done a lot of work with ManpWIN which is based heavily on the original WINFRACT code. I have developed true colour modules and animation scripting and would love to share these with you. I can provide the full source if anyone is interested. It's not in particularly good shape as I'm always playing with it :) This stream has deviated quite a bit from FRACTINT and uses PNG to allow true colour file saving.

Help with this would be greatly appreciated. My current dilema is that I have no clue how to figure out where the GPF is occurring. And, I spent way too much time on this project Saturday and Sunday. (So need to not look at it for a day or two) I've looked at your source in the past, and my understanding of the workings of Windows programs has only marginally increased since then. I am reading (when not programming) Charles Petzold's "Programming Windows 3.1", but there is only so much time in a day. Jonathan

Hi Jonathan, Please let me try to compile the source that you have created. I will use VC++ v6.0 and it has a great debugger. There are a number of differences between 16 bit and 32 bit message structures and this could be a key to the problem. Regards, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=telstra.com@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=telstra.com@mailman.xmission.com] On Behalf Of Jonathan Osuch Sent: Tuesday, 7 February 2006 11:40 AM To: Fractint developer's list Subject: RE: [Fractdev] Fractint for Windows status Paul,

If we can find a way to segment the task, I'd love to be part of it. I have done a lot of work with ManpWIN which is based heavily on the original WINFRACT code. I have developed true colour modules and animation scripting and would love to share these with you. I can provide the full source if anyone is interested. It's not in particularly good shape as I'm always playing with it :) This stream has deviated quite a bit from FRACTINT and uses PNG to allow true colour file saving.

Help with this would be greatly appreciated. My current dilema is that I have no clue how to figure out where the GPF is occurring. And, I spent way too much time on this project Saturday and Sunday. (So need to not look at it for a day or two) I've looked at your source in the past, and my understanding of the workings of Windows programs has only marginally increased since then. I am reading (when not programming) Charles Petzold's "Programming Windows 3.1", but there is only so much time in a day. Jonathan _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev

I think you guys are going down two different paths, at least for the moment. Which is not to say Jonathan couldn't change directions. (I'm not making a judgement her about the direction anyone *should* go, I'm just trying to shed some light ... :-) 1. Jonathan is trying to merge Bert's Winfract with the latest DOS sources using the same compiler we use for the medium model DOS fractint. This approach is theoretically possible because Winfract is a Windows 3.1 program which uses the same medium memory model as the DOS fractint. 2. Paul is using a newer compiler and will therefore have to eliminate all vestiges of the medium memory model (mostly the assembler code.) Of course Paul has been down this path before with his own program which is derived from Fractint. The almost certain reason Jonathan is getting protection faults is that fractint is way too big to fit into the medium memory model without overlays. The current DOS version works with the medium model only because we gave a whole lot of thought and shoe-horned it in. Bert had to do something similar with Winfract, but it was easier then because Fractint was smaller. But when Jonathan merged the current sources, Bert's overlay scheme probably broke. As Rich pointed out, if Paul or anyone wants to make as literal a port of Fractint as possible to Windows with a newer compiler, the Xfractint version is a better starting point because it has already got the flat memory model - but there's a lot of work stripping out the Xwindows GUI and replacing it with a Windows API. Neverless I was excited to see Jonathan attempting to merge Winfract with the current DOS version. If you look up Fractint in wikipedia, it is cited as one of the oldest open source programs still maintained (thanks to Jonathan). The other two mentioned are Emacs and NetHack. Tim

In article <002e01c62c56$132d3fe0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:

There is a LOT of work... to be done. It is huge and if we can segment the task somehow, it would work. I tried starting with the XFract code and got horribly lost. It is well worth the effort if we can achieve it somehow.

I did it once, but my changes were never re-merged back into the trunk.

We are not sure how to proceed.

The way I proceeded was to print out *all* the sources to fractint and study them. That gave me an overview of the entire beast. From there, I took the xfractint sources and refactored the X Window stuff into its own "device". My intention was to introduce a device and platform abstraction by having a structure of function pointers. All the calls to the global UI functions were instead redirected through the current device structure. This also would let you change the device on the fly (for things like switching between fullscreen DirectX and windowed Win32). Overall I still think this is the way to go, whether or not my code ends up being used is immaterial. I just never found enough cycles to drive it to 100% of completion. Its probably best to do that push all by one person. Its tedious, not hard. After that is done 100% then adding new devices is easy. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

Jonathan wrote:

I don't see any evidence of an overlay scheme, but I could just not > know where to look. My brief reading on the subject seems to indicate that with the medium model, Windows takes care of the overlay functions.

As always, I opine confidently on things I know nothing about <g!> But knowing how carefully we had to tune the overlays to get fractint to work, I have trouble believing that a Windows automatic overlay feature could do as well. So even if there's no explicit overlay scheme, that still might be the cause of your problem. Or not. <g!> Tim

Rich,

AFAIK VC does not do "automatic overlays" -- if you think about it, it can't possibly know what you're going to need in the overlay. I thought that it worked all this out from the linker commands, not attempting to do it automatically. It may have a way of dumping out information that lets you easily decide how much code you can fit into an overlay though, by dumping out the size of the routines after compiling the .obj files.

Each source code module is put in its own code segment, or overlay, that can be moveable and discardable. There should be no problem as long as each module is less than 64KB. Looking at the winfract.map file, this appears to be the case (meaning, no modules are greater than 64KB). There could be a problem with far data, however. I thought I read that Windows puts all the far data into a single segment. From the winfract.map file, it doesn't look like this is happening. But, we have more than 64KB of far data. This was done to save near space in the DOS world. Jonathan

Tim, I have completed compiling and fixing the warnings/errors generated with the /W3 setting. Winfract now runs! I updated the zip file in the experimental directory (No, the executable is not included). Jonathan

Jonathan,

I have completed compiling and fixing the warnings/errors generated > with the /W3 setting. Winfract now runs!

You are a genius! It compiled effortlessly. Wow! What was the segfault problem and how did you overcome it? Now exactly what do we have? It looks like you have merged Bert's old interface with the new code, so not necessarily everything works (e.g. not hooked up to the interface). I'm really curious to see what it can and cannot do. For example, does the command line support all the same commands? I'll have to try some parameter files. Now if you want some help on this we have a problem, unless the old C compiler is on Rich's developer CD. Who besides you and me has the tools to build it? I think it would be really cool to release a new Fractint and corresponding winfract that had the same feature set as the DOS. How far are we from that? (I'm guessing fairly far). Tim

Tim,

You are a genius! It compiled effortlessly. Wow! What was the segfault problem and how did you overcome it?

Never found the segfault problem. I suspect that it was the call to SecondaryWndProc in mainfrac.c, but have no proof. After I cleaned up mainfrac.c and profile.c, it started to work. Much to my surprise (and delite).

Now exactly what do we have? It looks like you have merged Bert's old interface with the new code, so not necessarily everything works (e.g. not hooked up to the interface).

True, and there are things that are still broken from the old code. For example, the Cellular type doesn't display in the window, although it seems to run.

I'm really curious to see what it can and cannot do. For example, does the command line support all the same commands? I'll have to try some parameter files. Now if you want some help on this we have a problem, unless the old C compiler is on Rich's developer CD. Who besides you and me has the tools to build it?

One path to take may be to push on to the 32-bit compiler.

I think it would be really cool to release a new Fractint and corresponding winfract that had the same feature set as the DOS. How far are we from that? (I'm guessing fairly far).

Yes, fairly far and yes, really cool. The arbitrary precision math doesn't switch in. The types that load a file, such as formula, lsys,.. cause a segfault. The winfrac docs are hopelessly out of date. Numerous menus need to be added or updated. We need to put the sstools.ini file in another spot. NT/W2000/XP users without administrative rights will have problems with putting it in the %Windows% directory. I've started removing the single line comments that I added. I think I'd like to modify the Make file such that it more closely matches the DOS version (in that we can turn off global optimization where it causes trouble). Then perhaps a merge into CVS so it will be easier to keep from breaking things in the other versions.

OK, I see that various DOS screens are there. Is there any way to get to the main DOS menu?

I have *no* idea. LOL

By the way, I see no harm in putting this out for people to play with. It's well marked as a developer version. Having people play with it might help.

It might help to have a list of what is broken. At least, once it all isn't broken. BTW, I'm starting a new job tomorrow at the local nuclear plant doing the same thing I've been doing for the last five months, but as a utility employee. This should add some stability. Jonathan

Hi Guys, Once we have a 32 bit working version, I would like to upgrade it to true colour and add all my colour management libraries. I have already changed form GIF to PNG for ManpWIN. I would also like to add the animation scripting libraries as well. This is exciting. Together we will make this work. Thanks guys, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com] On Behalf Of Tim Wegner Sent: Monday, 20 February 2006 10:38 AM To: Fractint developer's list Subject: Re: [Fractdev] Fractint for Windows status Jonathan wrote:

One path to take may be to push on to the 32-bit compiler.

I agree, but in my experience it usually is best to push one dimension at a time (e.g. bring Winfract 16 bit up to snuff before going to 32 bits). Since you have made such tremendous progress on merging Winfrac, it might pay to complete that. On the other hand, there's really not much to be said for the Windows menus Bert made. But neither would it be hard to add what is missing.

...

I think it would be really cool to release a new Fractint and corresponding winfract that had the same feature set as the DOS. How far are we from that? (I'm guessing fairly far).

Yes, fairly far and yes, really cool. The arbitrary precision math doesn't switch in.

I noticed that.

The types that load a file, such as formula, lsys,.. cause a segfault. The winfrac docs are hopelessly out of date. Numerous menus need to be added or updated.

I suggest working just with the DOS style menus until everything possible works. The keystrokes that use ctrl (e.g. evolver) don't work, I'm guessing that is easily fixed.

Then perhaps a merge into CVS so it will be easier to keep from breaking things in the other versions.

Have you had to fork the shared files from the DOS versions?

...

OK, I see that various DOS screens are there. Is there any way to get to the main DOS menu?

I have *no* idea. LOL

The only thing the main menu accomplishes is to tell you what keystrokes are available. It's probably easy to make it work.

...

By the way, I see no harm in putting this out for people to play with. It's well marked as a developer version. Having people play with it might help.

It might help to have a list of what is broken. At least, once it all isn't broken.

Exactly, I think we could solicit volunteers to tell us what doesn't work.

BTW, I'm starting a new job tomorrow at the local nuclear plant doing the same thing I've been doing for the last five months, but as a utility employee. This should add some stability.

That's good news!! How long is this good for? I'm OK for the time being, but my company's fortunes are tied to the Space Shuttle which is headed for end of life before my retirement. If I'm lucky I'll get involved in some of the new NASA work either with my company, or if they don't get the work, another compamy. I can't promise, but if I could just get some traction where I could help with fractint/winfract I'd love to do it. The fact that I can actually compile your winfract is a big plus. And I have all the printed docs and a Petzold book. I don't think we should spend a lot of time on the old Winfract, but if we could get most things working, that would be a good milestone to reach, and worth a few months of effort. Tim _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev

Great news, guys! Now that it's possible to buy computer monitors with resolutions of 2048x1536 and even some higher (including widescreen 16:9 monitors), will it be possible to use a full screen mode in Windows with these resolutions (I think the highest VESA mode was 1600x1200) instead of having to use disk video in order that one can watch the high resolution images generate and do interactive palette editing on them like you still can do 1600x1200 under Windows 98 and DOS? Lee

Tim,

The keystrokes that use ctrl (e.g. evolver) don't work, I'm guessing that is easily fixed.

Similar to what is in framain2.c, it requires testing for the key stroke(s) and then performing the required task. I would like to put the tasks in framain2.c into separate procedures so that we could call them directly from the Winfract code instead of reproducing it as is now the case. The key stroke test is easy, the evolver code is harder because the main loop changes. Although, with the above change, things may be easier.

...

Then perhaps a merge into CVS so it will be easier to keep from breaking things in the other versions.

Have you had to fork the shared files from the DOS versions?

I know I made minor changes in parser.c, line3d.c, lorenz.c, prototyp.h, and fractint.h. But, I will check any with a recent modification date.

...

BTW, I'm starting a new job tomorrow at the local nuclear plant doing the same thing I've been doing for the last five months, but as a utility employee. This should add some stability.

That's good news!! How long is this good for?

It's as permanent as it gets these days. Jonathan

Was doing some recent reading on a development issue and ran across this article which may be of interest to some within this group: Safe Integer Arithmetic in C < http://go.microsoft.com/?linkid=4544887 > Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html http://www.Nahee.com/Fractals/

Jonathan, how is the new job??? You wrote:

I fixed the problem with the formula/lsystem/ifs selection screens. Also twiddled with the make file a bit and got rid of some of the warnings associated with routines being too big for global optimizations.

Great! I tried starting it to force arbitrary precision with debugflag=3200, and the zoom box wouldn't work. Probably Bert's windows zoom box code is not connected up to the arbitrary precision corners arrays. This probably is not too hard to fix. Winfract seems slow. This makes me think that it is only of historical interest, and won't be that usable even if we fix the problems. That doesn't mean I'm not willing to help bring Winfract and Fractint in synch if we can do it in a finite amount of time. It would be nice to have synched up versions of Fractint, Xfractint, and Winfract if it doesn't take too long. Have you seen the program gnofract4d? The home page is http://gnofract4d.sourceforge.net. This is an amazing open source program written in python and C++ using GTK+. It parses both fractint and ultrafractal formula files to C, and then loads the C and runs. It runs only under Linux at present. I had no trouble installing it under Mandrake. Given the existence of at least two, and maybe three outstanding fractal programs (Gnofract4d, Ultrafractal, and Xaos), as I find my interest picking up again I also find myself asking this question: what is a worthwhile goal for a further development of Fractint given the existence of those (each in their own way) more advanced programs? Xaos is the notably different program because it is focused on animated zooming. I noticed that that program had a 6 year hiatus, and the team only recently resumed work on it. Goes to show you it can happen. Looks like the Windows port hasn't been refreshed yet. Gnofract4d and Ultrafractal both are based on fractint concepts but have extended them in different ways, and on two different platforms, and with two different development models (open and closed source). Interesting that Gnofract4d has implemented a clone of Ultrafractal's parser (which in turn started as a clone of fractint's parser.) The simplest answer to my question about a goal would be to extend fractint's life by porting to 32 bits as we have discussed. I still favor using WxWindows rather than Windows API so we could have an easy Linux port. I'm looking into various compiler choices. I figure I have enough in me to learn one new thing, maybe two, and I wonder if a good choice would be WxWindows and maybe C++ for a more literal port of Fractint (legacy code would remain in C). I'm also interested in learning more about Gnofract4d and what can be accomplished with Python and C++. Tim

Jonathan wrote:

Same desk, same computer, same logon.

Ah so, it's really the same job! I had the same thing happen to me. After MITRE folded here in Houston (they're still alive and well in Washington and Boston) I tried writing books for a while. When it was clear that I couldn't support the family that way, I went back to NASA and signed on with Unisys, who subcontracted with Rockwell, the big shuttle contractor. When the United Space Alliance was formed by Rockwell and the NASA contract was redone, one week before the contract was to begin, Unisys was told they weren't going to be given a subcontract. We all exchanged our Unisys badges for U.S.A badges. as you said, "Same desk, same computer, same logon.", and even, in my case, the same first-line management.

Do you have pixel-by-pixel update set? If so, unset it!

That's it. Geesh!! That changes my whole attitude toward Winfract. That means if we complete the merging you started it could actually be a usable program.

This *is* a hobby, after all. The goal is to give you something to think about that isn't work related.

That's one goal, and an important one. In my case I've been with the project for so long (about 17 years!!!, and if memory serves you've been on it just about as long) I have another purpose. Fractint is one of the longest running open source programs ever, and if it can continue to be usable and provide pleasure to people, I take a certain pride in that. In addition, I one of the big

Sadly, I can see the day where we have to leave the DOS code and only develop WinFract and Xfractint. Once we implement png support, for example.

That wouldn't make me sad. The medium memory model is a huge constraint that holds us back, as is the fact that we use old software tools nobody has (though I'll bet it could be ported to Open Watcom, which has a medium memory model). What would make me sad is leaving behind any significant functionality, or having the program be rendered unusable by the onrushing of technology, which quite frankly I expected a long time ago, but it hasn't quite happened yet.

What has occurred to me, which may be incorrect, is that to go to WxWindows will require a complete rewrite of the WinFract Windows code.

Something I would like to do, now that I've looked at the Windows source, is to rewrite the main loop in Xfractint in a similar fashion.

If the main loop is done correctly, we'll have a lot more freedom to implement different GUIs. Tim

Tim,

I am currently restructuring the WinFract source to match what is in CVS. The brain dead nmake is getting in the way. It doesn't handle recursive calls very well. You are supposed to be able to use the /V option to make it remember the macro definitions, but it doesn't work. Ideally, what I want to have is one make file that is called from two different batch files (makefrac.bat and makewin.bat). The problem comes in with the subdirectories. I'm having to fight the same battles I had to get the code to compile originally. Which doesn't make sense since it's the same source files put in different directories. And, strangely, I didn't change the original file, so the problem has to be in a header file or the compilation settings.

Got it working. The make files are a bit ugly, but the directory structure now matches (with an added win directory). I'll clean it up a bit more before I put it in the CVS repository. Jonathan

Tim,

My plans to work on this got sidetracked by a cold. Nothing serious, though I may miss work tomorrow. On Saturday I did compile and run the earlier Winfract you had posted a few days ago.

It's now in the CVS repository. WinFract doesn't like the directory structure, so you need to manually put files like defaultw.map in the same directory as the executable. I'll look at fixing that next. I somehow managed to commit the all-maps.zip file in the extra directory as ASCII and it is corrupt. I'll see if I can find the original. If not, I'll have to recreate it. Jonathan

Rich wrote:

At the moment I can't seem to find the other VS.NET 2003 copies that I thought I had. I might have given the last ones away already.

I'll do that, thanks for the offer of your copies, even if it didn't work out. My immediate need is to compile Manpwin which I could probably do with my older compiler, but I'd rather use the newer one. What Rich is referring to is that microsoft does have some compilers that are free until October 2006, so this might be a good time to get them. Tim

Jonathan wrote:

It's now in the CVS repository.

There's a permission problem that prevents me from writing a lock in the win directory. I think it's that the win directory has group jonathan rather than group fractint. There may be other permission problems if I'm going to update. Safest would be if fractint group has all the permissions that jonathan has. Tim

Jonathan wrote:

Although, the problem with the win directory may be that it doesn't > have a cvs subdirectory.

CVS update worked OK, so your fix worked. Tim

Jonathon wrote:

For some reason I wasn't able to ftp into the repository from Windows. Odd. It works fine from Linux and it has worked before from Windows.

I suggest using winscp instead of FTP. Besides, it's more secure. See winscp.net. I was able to build Winfract from a cvs sandbox. Tim

I just noticed that the sstools.ini file in the sandbox gets updated when you run Winfract.

We need a script to copy the executable or some other way to have a working directory other than the sandbox. Tim

That would work. I find that I sometimes recompile so often that it would become inconvenient.

Maybe the simplest solution is your idea to keep two copies of sstools in CVS and not take the one in the executing directory seriously.

The arbitrary precision math is now working. No, I didn't fix it. The Lorenz types are also working. Again, I didn't fix them.

I can only conclude that your subconscious mind is a better programmer than your conscious mind <grin!> One thing that can't work is the rotated/skewed zoom box. I'm back in commission. I am a pretty healthy guy who sometimes goes years at a time with no missed work, but some garden variety virus levelled me Saturday afternoon. I only went back to work today. Tim

Tim,

But if you start winfract with debug=3200, the default fractal is calculated using what the tab screen claims is arbitrary precsion, but the zoom box can't change the magnification. Not serious - debug=3200 isn't official, probably some malfuntioning error correction logic.

I've actually noticed some anomalies with the zoom box. And the zoom bar is broken. I have the dialogs that get formula/ifs/lsystem/map/par files working like I want them. I have not yet updated the repository. I'll do that tomorrow. Jonathan

Jonathan,

...

I have the dialogs that get formula/ifs/lsystem/map/par files working like I want them. I have not yet updated the repository. I'll do that tomorrow.

I've updated the repository with my latest changes. The executable is in the experimental directory.

just FYI, not knowing if it's a bug or a current state of the merge process: when using this executable, I get a "floating-point error: stack underflow" crash at the moment of choosing any menu item while an l-system is being calculated.. unrelated, I noticed you got Fractint up to run under Cygwin a while ago, is that version available anywhere please? /charlie/

Jonathan,

Hmm, mine works okay. I'm probably doing it wrong. 8-)) Could you provide a list of steps that recreates this on your machine?

the machine (at work) runs MsWin2K and those steps are: 1) run WinFract (default Mandelbrot renders) 2) <t> choose l-system type 3) <F6> choose snoopy.l (http://fractint.oblivion.cz./snoopy.l) 4) pick "!.FractInt" entry 5) set order to 4 <Enter> 6) while it computes pick any menu item 7) -> crash btw, I can't figure out how to stop the calculation, <Esc> didn't work..

Considering the age difference between the two sets of source code, it's amazing that the updated WinFract runs at all. There is still a long way to go before it's ready for prime time.

amazing and pleasant, especially when the win coding needs are far beyond my imagination.. and even beyond interests.. do you consider this merge to be a kind of a port or a migration?

Those changes are in the next patch. I'll try to get it out this weekend. I will probably not generate diff's anymore. Especially for this one, which will include all the WinFract source. Since I don't ever hear any complaints about the diff's, I doubt anybody is using them.

i'm looking forward to that, for i wasn't able to switch to a linux so far, and cygwin is another way to go.. ad diffs, if I were able to apply a diff, I would have used them, but it's a lot easier for me to get the whole new source package.. with nowadays bandwidths.. /charlie/

...

we should be moving away from all the old acceleration keystrokes. Or, maybe not. I kind of like them. <<

Me, too! Please keep them. Lee Skinner

Rich,

...

Yes, I've found that irritating already. However, WinFract is a Windows program and we should be moving away from all the old acceleration keystrokes. Or, maybe not. I kind of like them.

There's nothing that says that Windows accelerator keys *have* to be Ctrl/Alt+<whatever>, its just the UI guidelines that recommend this. Its perfectly fine, for instance, to have a menu item whose accelerator is ESC or 'X' or whatever.

At this point, it is just a matter of adding a check for ESC and having the main menu display. I believe most of the other accelerator keys are already coded. Do you know if the resource compiler (for Win 3.1) can handle drop down lists in dialog boxes? I tried to add the additional passes methods to the current dialog box using the checkbox scheme already in place and mucked it up. I would prefer drop down lists anyway, so would like to know how it's done. I don't seem to have much info on rc. Haven't tried to google the info yet. That's next. Jonathan

Tim, Have you done an update from the repository lately? I moved some directories around and had trouble getting the win_menu directory created under Linux. Yes, I know, it isn't used. Part of my problem was that I had to switch from gCVS to LinCVS because gCVS wouldn't run or compile in my 64-bit environment. LinCVS appears to be maintained, unlike gCVS. If you look at the latest code in the repository, you'll see an initial stab at fixing the Basic Options screen. I don't like it because I'd rather have comboboxes with drop down lists. I am working on getting a combobox to work, but all the examples I have to look at are so convoluted I can't figure out how to make a simple combobox work. Jonathan

Tim, I've hooked the evolver and browser code into Winfract. Neither works. As an aside, I installed Vmware under Windows instead of Linux, Then I was able to install Linux and move all my files into the new installation. I would have preferred to do it the other way around, but that would have required re-installing Windows onto a virtual hard disk. That was way more work than I wanted to attempt, with no guarantee of success. At least now I don't have to reboot to check my email. Jonathan

Rich,

For what its worth, I've installed Windows (2000 Server/Advanced Server, XP, 2003 Server) onto VMWare lots of times with no problems.

It was a matter of not wanting to purchase another copy of XP. I have my doubts that the version that came with the laptop would load and run properly under VMWare because the hardware seen by XP would be different. Jonathan

Tim, I've fixed the code Winfract uses to create PAR entries. Take a look and see if I missed anything. 8-)) I also added in hooks for the evolver and browser. These bring up the Fractint menus, but since the code that actually does the work for these features is in framain2.c, they don't currently do anything useful. I've updated the executable in the experimental directory. Jonathan

Charlie,

the machine (at work) runs MsWin2K and those steps are: 1) run WinFract (default Mandelbrot renders) 2) <t> choose l-system type 3) <F6> choose snoopy.l (http://fractint.oblivion.cz./snoopy.l) 4) pick "!.FractInt" entry 5) set order to 4 <Enter> 6) while it computes pick any menu item 7) -> crash

This looks like a memory/stack problem. The l-system type is recursive and appears to be running out of memory. If you don't select a menu item (let the image complete), you'll see that you still get the error and that the image is not finished. Once we switch to a 32-bit environment this problem should go away. I'll keep it in mind. Jonathan

Jonathan Osuch wrote:

Tim Wegner wrote:

...

I'm really curious to see what it can and cannot do. ...... Now if you want some help on this we have a problem, unless the old C compiler is on Rich's developer CD. Who besides you and me has the tools to build it?

One path to take may be to push on to the 32-bit compiler.

If you really wanted more individuals helping this along, you should consider going with an environment that the majority have access to and use regularly, such as Microsoft Visual C++ 6.0 or higher. And it would probably allow WinFract to get converted quicker to 32-bit, or even 64-bit.

We need to put the sstools.ini file in another spot. NT/W2000/XP users without administrative rights will have problems with putting it in the %Windows% directory.

It should be in the same directory path as the executable, which is where I have mine. Unless you wish each user to be able to have their own unique settings. Then it probably will need to be in: C:\Documents and Settings\[user-logon]\Application Data\ Most users are likely already the Administrator of their own PC, seeing how it will rarely be loaded on computers in a business or work environment.

...

By the way, I see no harm in putting this out for people to play with. It's well marked as a developer version. Having people play with it might help.

It might help to have a list of what is broken. At least, once it all isn't broken.

Always the best way to find problems: let people play with it. This tactic works well for all the major apllcation software companies. ;-} Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html http://www.Nahee.com/Fractals/