ftp.xmission.com/2014.06.ftp.xmission.com.tar/ftp.xmission.com/pub/lists/fractdev/archive/fractdev.199902

Internet Message Format | 1999-02-24 | 50KB

From: Phil McRevis <[e-mail]>
Subject: (fractdev) flat-memory model port
Date: 21 Feb 1999 22:00:14 -0700

OK, this last round of discussion about fractint and the limits of the
medium memory model has jostled me out of my sloth :-).

I am willing to make a pass through fractint's code to remove all the
overlay and "far ptr"isms of the medium memory model.  I have Borland
C++ Builder (which can compile regular C code just fine from the
command line), and I'm willing to download gcc/djgpp to make sure I'm
using any Borlandisms in the effort.

What I would like from Tim and other developers here is what exactly
do I need to do in order to do the port?

Here is what I had in mind:

    o remove all "near/far" isms with respect to pointers and data --
    as I understand it the "far" isn't needed in a flat memory model,
    because a pointer is a pointer is a pointer.

    o remove all overlay mechanisms -- these are just #pragmas in the
    source code, aren't they?

    o use C code from xfractint for the assembler portions -- in other
    words, I'm not attempting to rewrite the assembler code.  That may
    come later, but the primary thrust is to get to a flat memory
    model.

    o try to group data with its associated functions instead of
    having it lurking as a global.  Its my understanding that the
    reason there is so much of this in the fractint source is because
    of the memory model.

Now given that I'm going to remove the assembly and use C instead,
that leaves me with one hole: video I/O.  My inclination is to use the
same solution that XaoS uses -- dgjpp/Allegro.  See
<http://www.talula.demon.co.uk/allegro/readme.html> for information on
Allegro.  What's interesting about that (and I only just learned this
upon reading that URL :-) is that Allegro supports DOS, Win32 via
DirectX and the X Window System.  Rather than homebrewing our own GUI
layer, perhaps we could just write to Allegro and be done with it?  Of
course, that still leaves the Mac in the lurch, but perhaps someone is
already working on an Allegro port for the Mac.

Please respond soon, before I lose my nerve to tackle this project :)
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
          <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) flat-memory model port
Date: 21 Feb 1999 22:05:13 -0700


In article <[e-mail]>,
    Phil McRevis <[e-mail]>  writes:
> [...] I'm willing to download gcc/djgpp to make sure I'm
> using any Borlandisms in the effort.

That should be "make sure I'm *not* using any Borlandisms"... silly me
:)
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) flat-memory model port
Date: 22 Feb 1999 00:19:23 -0500 (EST)

On Sun, 21 Feb 1999, Phil McRevis wrote:
> Here is what I had in mind:
>
>     o remove all "near/far" isms with respect to pointers and data --
>     as I understand it the "far" isn't needed in a flat memory model,
>     because a pointer is a pointer is a pointer.

You could perhaps do this with #define.
#define near
#define far

>     o remove all overlay mechanisms -- these are just #pragmas in the
>     source code, aren't they?

If so, you don't need to remove them.

> Now given that I'm going to remove the assembly and use C instead,
> that leaves me with one hole: video I/O.  My inclination is to use the
> same solution that XaoS uses -- dgjpp/Allegro.  See
> <http://www.talula.demon.co.uk/allegro/readme.html> for information on
> Allegro.  What's interesting about that (and I only just learned this
> upon reading that URL :-) is that Allegro supports DOS, Win32 via
> DirectX and the X Window System.  Rather than homebrewing our own GUI
> layer, perhaps we could just write to Allegro and be done with it?  Of
> course, that still leaves the Mac in the lurch, but perhaps someone is
> already working on an Allegro port for the Mac.

I don't think you can use Allegro with C++Builder, but I do not know.

I think there are some licensing restrictions having to do with
building with djgpp; in particular, I think the C run-time library is
GPLed.  This is incompatible with Fractint's license, which prohibits
redistribution for profit.

I hope you can preserve the original DOS interface to some degree.
It's wonderful in DOS, but terribly painful in xfractint.  (I think
I've never used any program with as good a UI as DOS Fractint.)

> Please respond soon, before I lose my nerve to tackle this project :)

Thank you for your nerve :)

--
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- [e-mail]


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) flat-memory model port
Date: 21 Feb 1999 22:50:31 -0700


In article <[e-mail]>,
    [e-mail] (Kragen Sitaker)  writes:
> You could perhaps do this with #define.
> #define near
> #define far

Yes, the xfractint .h file already does this.  However, with emacs and
grep, its quite simple to remove all "far" and "near" qualifiers on
pointers.  (M-x grep, followed by M-x next-error is a wonderful thing
for large source base modifications.)  If we are giving up the medium
memory model, these qualifiers are just cruft that should be removed.

> If so, you don't need to remove them.

See above.  When stuff isn't used anymore, its best to remove it
rather than leave it laying around.  For instance, do you delete
unused code from your projects or do you just comment it out?  With
the latter approach, you end up with all this code that isn't relevant
anymore, but a new programmer can't tell that and will wonder why it
is commented out instead of deleted.  On a shared-body project like
fractint, this is even more important since you have no idea who
commented out the code and/or why its commented out.  I've worked on
commercial code where people developed this habit of #ifdef/commenting
out unused code and it quickly led to a maintenance nightmare.
Maintenance issues are even more critical for open-source software.

> I don't think you can use Allegro with C++Builder, but I do not know.

Me neither.  I just brought it up as a possbility for the video I/O.
Fractint needs _some_ kind of abstraction to remove itself from
platform dependencies with graphics I/O.  Rather than reinvent the
wheel, I figure we could use something like Allegro which handles
those details.  Especially since I don't have any desire to port the
assembly code.  (Although since I upgraded my C++Builder I now have
TASM so I can do assembly code.)

> I think there are some licensing restrictions having to do with
> building with djgpp; in particular, I think the C run-time library is
> GPLed.  This is incompatible with Fractint's license, which prohibits
> redistribution for profit.

Hmm... as I understand it, the GPL only says that you have to provide
the source code, which is completely compatible with fractint's
open-source model.

> I hope you can preserve the original DOS interface to some degree.

No changes to the interface are planned; with my C++Builder upgrade, I
did get a coupon to obtain Borland's 4.02 C++ compiler, which can
build 16bit applications.  I may just start seeing if I can build DOS
fractint with that, but then I'd have to obtain that compiler first (I
haven't used the coupon yet), which would mean waiting.
Alternatively, I can eliminate all the medium memory model stuff and
just use xfractint.

> It's wonderful in DOS, but terribly painful in xfractint.

Yes, well that is one reason why we have been saying fractint needs a
UI layer.  Under X, fractint's UI should be native (as well for the
Mac, Win32, BeOS, etc.).  But, first things first.  Every time we have
this discussion we come around to the conclusion "yes, but we need to
remove the memory model limitations first."

> (I think I've never used any program with as good a UI as DOS Fractint.)

Ahem.  I've used plenty of programs with a better UI than DOS fractint
:-).  Not to say that fractint's UI is poor; just that I find the video
mode switching very annoying and it suffers from the limitation of
trying to fit everything into 24x80 for some of its dialog screens.

Cut & paste into the text boxes is nearly impossible, or if it is
possible it is painful. If you think about it, almost every text screen
in fractint is what they call a "modal dialog" in UI terminology.
Given that fractint's dialogs are all originally implemented in a
text-only world, providing some simple functions to implement them in a
graphically rich environment shouldn't be hard.  Xfractint tries to do
it with curses, which is OK I guess, but you end up having an xterm
window and the graphics window, both of them trying to control the
application somewhat.  I never really liked it that much.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) flat-memory model port
Date: 22 Feb 1999 08:20:12 -0500 (EST)

On Sun, 21 Feb 1999, Phil McRevis wrote:
> In article <[e-mail]>,
>     [e-mail] (Kragen Sitaker)  writes:
> > You could perhaps do this with #define.
> > #define near
> > #define far
>
> Yes, the xfractint .h file already does this.  However, with emacs and
> grep, its quite simple to remove all "far" and "near" qualifiers on
> pointers.  (M-x grep, followed by M-x next-error is a wonderful thing
> for large source base modifications.)  If we are giving up the medium
> memory model, these qualifiers are just cruft that should be removed.

I was just thinking that it might be useful to be able to compile
fractint either way.  Perhaps it's too much to ask.

> See above.  When stuff isn't used anymore, its best to remove it
> rather than leave it laying around.

Agreed.

> Maintenance issues are even more critical for open-source software.

Fractint is not open-source software.  Don't go around saying that, or
you'll get sued by the Open Source Initiative.

> > I don't think you can use Allegro with C++Builder, but I do not know.
>
> Me neither.  I just brought it up as a possbility for the video I/O.
> Fractint needs _some_ kind of abstraction to remove itself from
> platform dependencies with graphics I/O.  Rather than reinvent the
> wheel, I figure we could use something like Allegro which handles
> those details.

Fractint has such an abstraction already -- it's just that all the
video drivers are included in Fractint.  For PC video cards, the wheel
has already been reinvented.

> Especially since I don't have any desire to port the
> assembly code.

Heh :)  I don't blame you :)

> Hmm... as I understand it, the GPL only says that you have to provide
> the source code, which is completely compatible with fractint's
> open-source model.

It also says you can't impose any further restrictions, such as "no
commercial distribution".  Many pieces of open-source software (notably
BSD and Mozilla) are not allowed to use GPLed libraries because their
licenses conflict with the GPL.   Also, the Open Source Definition
requires that users be free to do commercial distribution of the
software; software licenses that do not allow this, such as the
Fractint license, are not in compliance with the OSD.  Open Source is a
registered trademark of the OSD, which was founded by the guy who
invented the term last March.

Now, I'm not saying Fractint should change its license; I'm just saying
that presently, it is not open source, and should not be advertised as such.

I *would* like to allow Fractint to be commercially distributed -- I
think a lot more people would use it if it came on the Red Hat CD --
but then again, I didn't write it, so who am I to say?  :)

> > It's wonderful in DOS, but terribly painful in xfractint.
>
> Yes, well that is one reason why we have been saying fractint needs a
> UI layer.  Under X, fractint's UI should be native (as well for the
> Mac, Win32, BeOS, etc.).

Ohhh, OK.  You weren't talking about an abstraction layer for drawing
graphics -- you were talking about an abstraction layer for the
commands, help, and settings parts of the UI.

> Ahem.  I've used plenty of programs with a better UI than DOS fractint
> :-).  Not to say that fractint's UI is poor; just that I find the video
> mode switching very annoying and it suffers from the limitation of
> trying to fit everything into 24x80 for some of its dialog screens.

The video mode switching is a little annoying.

> Cut & paste into the text boxes is nearly impossible, or if it is
> possible it is painful.

In MS-DOS it is simply impossible.  :)

> If you think about it, almost every text screen
> in fractint is what they call a "modal dialog" in UI terminology.

Modal dialogs are a blight on the world of UIs in a GUI context.  But
in a text context, they aren't nearly as bad.

> Given that fractint's dialogs are all originally implemented in a
> text-only world, providing some simple functions to implement them in a
> graphically rich environment shouldn't be hard.  Xfractint tries to do
> it with curses, which is OK I guess, but you end up having an xterm
> window and the graphics window, both of them trying to control the
> application somewhat.  I never really liked it that much.

Neither did I.  (But I like it in MS-DOS.)

What I like is that (a) it was easy for me to use early on -- unlike
the Unix command line -- and (b) it was fast for me to use later --
unlike most GUI programs.  And I could see what was happening most of
the time.

--
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- [e-mail]


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) flat-memory model port
Date: 22 Feb 1999 09:25:38 -0700


In article <[e-mail]>,
    [e-mail] (Kragen Sitaker)  writes:
> I was just thinking that it might be useful to be able to compile
> fractint either way.  Perhaps it's too much to ask.

If you want 16bit code, then you compile older versions of fractint
:-).

> Fractint is not open-source software.  Don't go around saying that, or
> you'll get sued by the Open Source Initiative.

What?  Of course fractint is open-source software.  What makes you
think otherwise?

> Fractint has such an abstraction already -- it's just that all the
> video drivers are included in Fractint.  For PC video cards, the wheel
> has already been reinvented.

Right, and those video drivers are coded in assembly.

> > Hmm... as I understand it, the GPL only says that you have to provide
> > the source code, which is completely compatible with fractint's
> > open-source model.
>
> It also says you can't impose any further restrictions, such as "no
> commercial distribution".  [...]

Well I'll let Tim call the shot on that one... Tim?

> Ohhh, OK.  You weren't talking about an abstraction layer for drawing
> graphics -- you were talking about an abstraction layer for the
> commands, help, and settings parts of the UI.

Well there are two issues here.  Handling the low-level graphics
(which is currently done in assembly), and the UI portability (which
currently is kludged :).  The low-level graphics can remain in
assembly for the purposes of a flat-memory model port, but then the
assembly will have to be ported.  Since I'd rather not do any assembly
work, I was hoping to plug something else in there.  I think the
assembly video drivers were coded in order to get the maximum speed
from the video card.  Nowadays, these low-level details are best left
to the OS if possible (i.e. DirectX), but that is a very long-term
wish for fractint.  The question is what to do *now* with respect to
the 16bit assembly code that does video I/O.

> Modal dialogs are a blight on the world of UIs in a GUI context.  But
> in a text context, they aren't nearly as bad.

Well, like any tool sometimes its misused.  I've seen every UI
component misused at one time or another.  When a GUI application
*must* have more information from the user in order to continue a
requested operation, just what do you propose it should do?  That's
the situation modal dialogs were invented for.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) flat-memory model port
Date: 22 Feb 1999 13:29:40 -0500 (EST)

On Mon, 22 Feb 1999, Phil McRevis wrote:
> In article <[e-mail]>,
>     [e-mail] (Kragen Sitaker)  writes:
> > Fractint is not open-source software.  Don't go around saying that, or
> > you'll get sued by the Open Source Initiative.
>
> What?  Of course fractint is open-source software.  What makes you
> think otherwise?

I answered that down below; I assume you asked the above question
before you read that part of my reply.  Let me know if I was unclear.

--
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- [e-mail]


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) flat-memory model port
Date: 22 Feb 1999 12:50:11 -0600

Kragen,

 - [snippage re: GPL, Open Source (R), BSD, and FractInt]

Thanks for the info. It is food for thought.

 - I *would* like to allow Fractint to be commercially distributed -- I
 - think a lot more people would use it if it came on the Red Hat CD --
 - but then again, I didn't write it, so who am I to say?  :)

Interesting notion.

 - > Cut & paste into the text boxes is nearly impossible, or if it is
 - > possible it is painful.
 -
 - In MS-DOS it is simply impossible.  :)

In a DOS box running inside Windows, though, it isn't; it's just highly
inconvenient.

 - Modal dialogs are a blight on the world of UIs in a GUI context.

I have heard this notion advanced from time to time. While it is true that
many programs use modal dialogs excessively, it is ALSO true that in many
cases, designing the software so that modeless dialogs make sense
contradicts the way users are expecting to use the program. And if you
require users to change their work habits to fit the needs of software,
aren't you missing the point? Software is a tool for people, not the other
way around. When confronted with software that doesn't work as they expect,
users either (a) find other software that works like they want, (b) become
unproductive with the software they have, or (c) go postal and waste the
sysadmins that forced such software on them. :-)

However, in support of your point, it's certainly possible for fractal
software (such as a future FractInt) to be primarily focused on a modeless
approach. One recent GUI-based fractal program makes extensive use of
modeless property dialogs and shows one way in which modality can be
reduced substantially. Prior to its release, I also examined another
fractal program in development which, while oriented towards modeless
dialogs, was inconvenient to use. Simply making dialogs modeless isn't in
and of itself enough.

I'm not sure I would call modal dialogs a "blight". For a lot of users, it
fits with their "one thing at a time" mentality. Just because you and I are
able to multitask more effectively doesn't mean everybody else can. :-)

Damien M. Jones   \\
[e-mail]  \\  Fractalus Galleries & Info:
                    \\  http://www.fractalus.com/

Please do not post my e-mail address on a web site or
in a newsgroup.  Thank you.

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: (fractdev) 'open source'
Date: 22 Feb 1999 13:10:00 -0700

Hmm... I just read over the definition of "open source" on
<http://www.opensource.org> and I don't see how fractint conflicts
with what they are requiring in order to call something 'open source'.

What specifically are you saying is the conflict?  At any rate, I will
continue to use the term 'open source' in email however I want :-).

All opensource.org is saying with their trademark is that you can't
"market" software under that rubric without complying with their
terms.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
          <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) 'open source'
Date: 22 Feb 1999 15:24:36 -0500 (EST)

On Mon, 22 Feb 1999, Phil McRevis wrote:
> Hmm... I just read over the definition of "open source" on
> <http://www.opensource.org> and I don't see how fractint conflicts
> with what they are requiring in order to call something 'open source'.

Section 1, Free Redistribution, begins:
    The license may not restrict any party from selling or giving
    away the software as a component of an aggregate software
    distribution containing programs from several different
    sources.

Fractint's license prohibits most people from selling it, unless I
misremember it.

> What specifically are you saying is the conflict?  At any rate, I will
> continue to use the term 'open source' in email however I want :-).

Well, I don't suppose I can stop you.

> All opensource.org is saying with their trademark is that you can't
> "market" software under that rubric without complying with their
> terms.

That's an interesting theory about trademark law, and you might be
right.  The recent Dilution Act suggests otherwise, though, at least in
the US.

--
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- [e-mail]


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) 'open source'
Date: 22 Feb 1999 13:57:20 -0700


In article <[e-mail]>,
    [e-mail] (Kragen Sitaker)  writes:
> Fractint's license prohibits most people from selling it, unless I
> misremember it.

You know, I looked through the source and I couldn't find the license
specifically... Tim?  Hello, Tim?  Where are you? :-)

> > What specifically are you saying is the conflict?  At any rate, I will
> > continue to use the term 'open source' in email however I want :-).
>
> Well, I don't suppose I can stop you.

Nope, you can't.  And neither can opensource.org, because although
they have trademarked the term, that doesn't give them the right to
control how people use the term in conversation or in correspondence.

> > All opensource.org is saying with their trademark is that you can't
> > "market" software under that rubric without complying with their
> > terms.
>
> That's an interesting theory about trademark law, and you might be
> right.  The recent Dilution Act suggests otherwise, though, at least in
> the US.

If they have the term trademarked, that gives them the right to
control how that term is used in the marketing and distribution of
software, but that's where their rights end.  For instance, "kleenex"
is a trademark, but it is also used in general conversation and indeed
has become synonymous with "facial tissue".  Whoever owns the
trademark of "kleenex" can prevent someone else from marketing a
product using that trademark, but they can't prevent anyone from
saying "would you hand me a kleenex, please?" even when the product
they are pointing to wasn't marketed under the name "kleenex".

Admittedly, I haven't studied the details of trademark law since the
early 80s, but I think I'm on the mark here.  Do you disagree?
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) 'open source'
Date: 22 Feb 1999 16:11:45 -0500 (EST)

On Mon, 22 Feb 1999, Phil McRevis wrote:
> In article <[e-mail]>,
>     [e-mail] (Kragen Sitaker)  writes:
> You know, I looked through the source and I couldn't find the license
> specifically... Tim?  Hello, Tim?  Where are you? :-)

It's not stated in legalese.  But there are definitely copying
conditions in there.

> > Well, I don't suppose I can stop you.
>
> Nope, you can't.  And neither can opensource.org, because although
> they have trademarked the term, that doesn't give them the right to
> control how people use the term in conversation or in correspondence.

Well, actually . . .

> > That's an interesting theory about trademark law, and you might be
> > right.  The recent Dilution Act suggests otherwise, though, at least in
> > the US.
>
> If they have the term trademarked, that gives them the right to
> control how that term is used in the marketing and distribution of
> software, but that's where their rights end.  For instance, "kleenex"
> is a trademark, but it is also used in general conversation and indeed
> has become synonymous with "facial tissue".  Whoever owns the
> trademark of "kleenex"

Kimberly-Clark.

> can prevent someone else from marketing a
> product using that trademark, but they can't prevent anyone from
> saying "would you hand me a kleenex, please?" even when the product
> they are pointing to wasn't marketed under the name "kleenex".
>
> Admittedly, I haven't studied the details of trademark law since the
> early 80s, but I think I'm on the mark here.  Do you disagree?

The Dilution Act was just passed in the last couple of years; it does
indeed give trademark owners broad powers to shut people up.  It is
somewhat disturbing, and I hope that it is struck down in court.

What you say is correct with regard to the Lanham Act.  I think.  I am
also not a lawyer.

--
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- [e-mail]


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) 'open source'
Date: 22 Feb 1999 14:16:40 -0700


In article <[e-mail]>,
    [e-mail] (Kragen Sitaker)  writes:
> The Dilution Act was just passed in the last couple of years; it does
> indeed give trademark owners broad powers to shut people up.  It is
> somewhat disturbing, and I hope that it is struck down in court.

Bummer.  Sounds like another welfare program for lawyers.

I will still say 'kleenex' and 'open source' though.  Maybe they will
sue me, but I doubt it :-).
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: (fractdev) flat-memory model
Date: 22 Feb 1999 16:40:31 -0700

OK, I've made my first pass through the code with the following
changes:

1. removed all near/far/huge qualifiers on pointers
2. removed the far_str* references in favor of str* (strcpy, strcmp, etc.)
3. removed the far_mem* references in favor of mem* (memcpy, memcmp, etc.)

In general.asm, there are a bunch of routines for manipulating far
memory.  I could remove these, but I'm focusing on the C code right
now and not the assembly.

Ther are also some routines for manipulating extended memory and
expanded memory.  These need to be switched to flat-memory model
routines as well, but I'm not so sure how they are used and would like
a little guidance from the developers out there that are familiar with
this.

Note that I haven't attempted to compile any code yet, just making
systematic modifications to the source code.  I'm using CVS, so I can
backup after any disastrous changes :-) as well as easily generate
context diffs.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
          <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) 'open source' (fwd)
Date: 23 Feb 1999 11:10:15 -0500 (EST)



--
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- [e-mail]

---------- Forwarded message ----------
Cc: [e-mail]

Kragen Sitaker writes:
 > > All opensource.org is saying with their trademark is that you can't
 > > "market" software under that rubric without complying with their
 > > terms.
 >
 > That's an interesting theory about trademark law, and you might be
 > right.  The recent Dilution Act suggests otherwise, though, at least in
 > the US.

Hi, Kragen.  ESR has delegated mark misuse issues to me.  There's not
much I can do about heresay.  If they have a web page, or made usenet
postings claiming Open Source, I can whack them.  But on a private
mailing list, there's not much I can do.

--
-russ nelson <[e-mail]>  http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok |   There is good evidence
521 Pleasant Valley Rd. | [phone] voice |   that freedom is the
Potsdam, NY 13676-3213  | [phone] FAX   |   cause of world peace.


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) 'open source' (fwd)
Date: 23 Feb 1999 10:27:41 -0700


Gee, thanks for reporting me to the trademark police! Sheesh.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) 'open source' (fwd)
Date: 23 Feb 1999 13:38:05 -0500 (EST)

You said:
> Gee, thanks for reporting me to the trademark police! Sheesh.

I didn't mean it as an unfriendly gesture.  I don't think of them as
police.

--
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- [e-mail]


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Jonathan Osuch <[e-mail]>
Subject: Re: (fractdev) flat-memory model
Date: 23 Feb 1999 20:46:59 -0500

>> In general.asm, there are a bunch of routines for manipulating far
memory.  I could remove these, but I'm focusing on the C code right
now and not the assembly. <<

The Xfractint source code contains a file called general.c, which address=
es
this issue.

>> There are also some routines for manipulating extended memory and
expanded memory.  These need to be switched to flat-memory model
routines as well, but I'm not so sure how they are used and would like
a little guidance from the developers out there that are familiar with
this. <<

The extended and expanded memory routines aren't required.  The Xfractint=

code includes two defines for them which effectively turns any calls for
extended and expanded into ordinary memory calls.  This statement will ma=
ke
(more) sense if you are working with the developer's version where the
memory routines have been consolidated.  In the version 19.6 source, the
expanded and extended routines are #ifdef'd out for Xfract.

Jonathan

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) flat-memory model
Date: 23 Feb 1999 19:55:41 -0700


In article <[e-mail]>,
    Jonathan Osuch <[e-mail]>  writes:
> The Xfractint source code contains a file called general.c, which address=
> es
> this issue.

Well not really.  That general.c file addresses the issue of video I/O
for *unix*, which doesn't really help for a flat-memory model
conversion for the DOS version of fractint.  Maybe I will just have to
convert the assembly to 32-bit after I get all this memory model stuff
removed.  I'm upgrading to BCB4 anyway and it includes TASM and
Borland's C++ compiler v5.02 in the box.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) 32 bit port
Date: 24 Feb 1999 21:05:00 -0600

Rich wrote:

> Tim?  Hello, Tim?  Where are you? :-)

I'm back, wading through my mail ... I was in Minnesota Saturday
through Tuesday night.

We should get you caught up with the later developer version
before you get too far, probably too late! I shall endeavor to upload
some sort of synch soon.

I have Borland C++ Builder 3, and am not planning to upgrade. I
think a djgpp version would give us the most bang for the effort. In
fact what I'd love for starters would be a djgpp version with the
identical interface as Fractint.

The initial problem we need to solve is how to do menus and
graphics. Xfractint has already solved far pointers etc. with defines.

Then we could consider making that the "official" DOS version, and
could massively rearchitect the fractint internals without diverging
from our official version.

Tim




Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) 32 bit port
Date: 24 Feb 1999 20:18:48 -0700


In article <[e-mail]>,
    "Tim Wegner" <[e-mail]>  writes:
> We should get you caught up with the later developer version
> before you get too far, probably too late! I shall endeavor to upload
> some sort of synch soon.

Yes, that would be good.  Just send me a URL where I can obtain it.  I
am using CVS/RCS so I can generate diffs and apply them to the code
and/or just use emacs again to remove all the near/far/huge
qualifiers.

> I have Borland C++ Builder 3, and am not planning to upgrade.

(There is a coupon in BCB3 for the Borland C++ 5.02 compiler; just
that its easier with BCB4 since it comes in the box and you don't have
to send away for it.  The coupon lets you obtain it for free, and I've
just been lazy.  BCB3 also has TASM support; I didn't mean to imply
that BCB4 would be required in order to obtain either of those
features.)

> I
> think a djgpp version would give us the most bang for the effort. In
> fact what I'd love for starters would be a djgpp version with the
> identical interface as Fractint.

That's what I was thinking to.

> The initial problem we need to solve is how to do menus and
> graphics. Xfractint has already solved far pointers etc. with defines.

See my earlier message about maintenance as to why I don't think
#defining the qualifiers away is a good idea.  Of course that's just
my personal taste, but since I'm doing the work, you'll all have to
live with that :-).  (I don't expect any objections; moving to 32-bit
is more than just removing the qualifiers and if you really want
16bit, then you just compile the 19.x source.)

Here are my thoughts for the evolution:

    o modify code to 32-bit, flat-memory model

    o make a pass through the code to shuffle the data declarations
    that were done in weird ways in order to cope with limited memory
    space in 16bit mode.  (strings declared static rather than just as
    literals and so-on.)  This should make understanding the code
    easier for new developers because they can focus on the
    _algorithm_ rather than memory model straightjackets.

    o GUI/graphics abstraction, but keeping the same DOS UI.  This is
    largerly there, but the big change is just moving to an
    event-based architecture rather than a polling architecture.

After that, adding new "front ends" (graphics + GUI) to support other
platforms should be MUCH easier.  Then we can get on with ideas for
Win32/X/MacOS/DirectX methods of doing the graphics & GUI.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) 32 bit port
Date: 25 Feb 1999 15:35:29 -0300 (EST)

On Wed, 24 Feb 1999, Phil McRevis wrote:

> > I
> > think a djgpp version would give us the most bang for the effort. In
> > fact what I'd love for starters would be a djgpp version with the
> > identical interface as Fractint.
>
> That's what I was thinking to.

    Hi Everyone,

    I just got back from vacations and I'm getting up to date w/ the
fractdev list.

    By what is being dicussed I thik we should really take advantage of the
unixisms of djgpp or even a dos version of the new egcs (if both can compile the
new version of frcatint it would be great). The commercial DOS alternatives to
32 bit aren't so nice because they have many differences in comparasion to the
traditional gcc.

    By what we have discussed in the past there is much of the 32 bit
porting work done in the XFractint wich only needs the adition of a graphical
interface to a 32bit DOS app. My opinion is the same of Phil: use the Allegro
library (the way it was used in XaoS really made me optimist, it compiles
in DOS (djgpp+allegro) and unix (gcc+allegro).

    So Just to add a practical 2cents here:

    What if we made the following (this means you Phil since you started it
first):

    - Check the solution djgpp+allegro and how it was used (lin in KaoS)

    - Modify only the parts needed to get a running version of fractint in
djgpp WITH all the #defines and such in place since they already comment out
what is nedded and include the C code where nedded.

    - After it compiles and runs ok, try the same unde Linux (for instance)
with allegro pointing to, say, SVGALib. (I can test this)

    - With this running we (now not only Phil) can clean up the code to
release an official (developers?) version of the 32Bit fractint. (clean up means
only taking out the #defines and comments that are useless).

    - Now every interested developper can check it's algorithm and i guess
Tim may give a general direction in adjusting the datastructures and such to use
better the flat memory model.

    Ideas? Comments?

    []'s

    Humberto R. Baptista
    [e-mail]

Insite - Solucoes Internet                         http://www.insite.com.br


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Tim Gilman <[e-mail]>
Subject: (fractdev) Re: 32 bit port - graphics API
Date: 25 Feb 1999 10:47:17 -0800

>* ([e-mail]) unpacked this on 2/24/99 7:18 PM:
>After that, adding new "front ends" (graphics + GUI) to support other
>platforms should be MUCH easier.  Then we can get on with ideas for
>Win32/X/MacOS/DirectX methods of doing the graphics & GUI.

>> "Tim Wegner" <[e-mail]>  writes:
>> The initial problem we need to solve is how to do menus and
>> graphics. Xfractint has already solved far pointers etc. with defines.

I've run across a strange bug that might open up some discussion on
graphics.  The MacOS's graphics engine (QuickDraw) allows a programmer to
syncronize a pixel map of values 0-255 with the index (of range 0-255) of
a color palette, such that palette-animation/color-cycling can occur on
devices that normally don't have such indices (such as monitors set to
32-bit depth).  Devices like this become a problem for users who try to
color-cycle a fractal on a monitor set to 32-bit depth while other
color-hungry applications (like photoshop) are open.

So, to allow this sort of color-cycling, I exploited a hardly documented
feature of QuickDraw.  Doing this allowed color-cycling *while* changing
monitor bit-depths, and at the same time preserved the way each color
looked on the monitor.  Through beta-feedback, I've discovered that
certain Mac OS clones contain 3rd party video cards that don't support
QuickDraw's hardly documented feature of index-to-palette
synchronization, and the way they don't support it is through crashing
the machine!

This problem only happens on probably 5% of Mac OS running machines, but
it's large enough to demonstrate Fractint's need for a graphic's API that
is supported across a variety of software platforms (axing
MacOS/QuickDraw and Win32/DirectX), and has enough hardware support to
actually keep Fractint fast *and* color-cycling.  I'm not sure if there
is such an API, but I'm doing some more research on OpenGL to figure out
if it's capable of supporting indexed-on-a-direct-device color-animation.

Does anyone have any opinions on these sorts of issues?

=- Tim Gilman


  "There is no truth, in which passing through awareness, does not lie.
   Yet we chase after it all the same."           - J. Lacan


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"