On Fri, 8 May 1998 08:50:21 -0600, "Jeff Hauswirth" <jha### [at] csnnet>
wrote:

>Is there much interest by other developers for this ActiveX control?
>It would have a bunch of methods/properties that would allow
>you to set the rendering options, fire off the rendering into your window,
>then notify you that its done rendering.

I appreciate your enthusiastic desire to improve POV-Ray however what
you propose is a violation of POVLEGAL.DOC -- the general license
under which everyone is permitted to recompile and/or distribute
POV-Ray.  Specifically we state that you cannot link our code into
other applications.  This includes not only compile-time linkage but
run-time linkage as well.  Therefore turning POV-Ray into a DLL or
ActiveX package is not allowed because it links our engine into your
code.  Further, the license prohibits anything which obscures the fact
that the user is running our freeware renderer.  Creating a DLL makes
it much harder to distinguish which part is our renderer and which
part is the 3rd party product.  Unsuspecting users will pay for
shareware or commercial front-ends thinking they are buying the whole
package when in fact they're getting a simple menu system.

Even if your intent is NOT to unscrupulously make money off of a cheap
front-end and a POV-Ray DLL, it opens the door to anybody to do it.

Although we feel POVLEGAL.DOC already prohibits such practices, we
will probably add language to future versions of our license to make
sure people understand our intent.

As you know, our current POV-Ray for Windows allows the user to
substitute any editor for ours.  It provides GUI-Extension hooks and
operating system shell-outs so that POV-Ray can control other external
stand-alone tasks.  If you have suggestions on how we can improve the
interface without inviting rip-off front-ends, we'll be happy to
consider them.
	Chris Young, POV-Team coordinator.

Post a reply to this message

>
>Although we feel POVLEGAL.DOC already prohibits such practices, we
>will probably add language to future versions of our license to make
>sure people understand our intent.
>


This is a good idea.  The way I read the legal doc was that you
were not allowed to use the source except in custom/unsupported
builds of PoV.  I figured if I built a stand-alone ActiveX control and
then distributed the code/control with the necessary legal notices
it was OK.

POVLEGAL.DOC should be updated as you said to include static/
run-time linking of PoV.

I will then change my way of implementing this connection- for fun, but
maybe for release which just runs a minimized process that I communicate
with.  Much like the Windows version does, but without the GUI frontend-
just a Win32 console based app that can display the necessary legal
info on startup.  I know the future version will have this capability, but
I'm just doing it to learn.

    Jeff

Post a reply to this message

Mathias Broxvall <mbr### [at] swipnetseNOSPAM> wrote in article
<1d8### [at] dialup122-3-36swipnetse>...
> 
> >       Yeah, it easy, you just write the public interfaces in C, rather
than C++,
> > then name mangling doesn't matter as all the mangled names are kept
within
> > the library.
> 
> Great! Sorry if this question isn't realy about programming povray:
> 
> Are there a standard for it? I have seen the following in some
> of my system headers, is it the same on other platform to?
> 
> extern "C" {
>   ...
>   /* All my great C prototypes here */
>   ...
> }

	Yeah, that's the way to do it. I don't know how platform independent it is
though, so you may run into problems and I've a feeling, even if it is part
of the current C++ standard, it may well be dropped when the ANSI C++
standard is finally released, sometime this year (hopefully), but,
hopefully the name mangling problem will be cleared up as well.

-- 
Scott Hill
Sco### [at] DDLinkscouk
Software Engineer (and all round nice guy)

"The best trick the devil ever pulled was convincing people he didn't
exist..."
								- Verbal Kint.

"the Internet is here so we can waste time talking about nothing in 
 particular when we should be working" - Marcus Hill.

Post a reply to this message

Scott Hill wrote:
> 
> Mathias Broxvall <mbr### [at] swipnetseNOSPAM> wrote in article
> <1d8### [at] dialup122-3-36swipnetse>...
> >
> > extern "C" {
> >   ...
> >   /* All my great C prototypes here */
> >   ...
> > }
> 
> Yeah, that's the way to do it. I don't know how platform independent it is
> though, so you may run into problems and I've a feeling, even if it is part
> of the current C++ standard, it may well be dropped when the ANSI C++
> standard is finally released, sometime this year (hopefully),

Extern "C" is still in the standard. The necessity for linking with
other languages will always be there; there's no chance of it ever being
dropped.

> but,
> hopefully the name mangling problem will be cleared up as well.

No chance. The name mangling "problem" is there for a good reason. It's
not the result of an imperfect specification or lack of thought on
anyone's part; the C++ standard quite consciously and intentionally
*encourages* compiler writers to invent incomaptible name mangling
schemes.

The reason is that name mangling isn't the only difference between
compilers. The same class compiled by different compilers can differ in
many ways at the binary level -- different sizes for the primitive
types, different padding between elements, different choices for where
the vptr goes, how it's interpreted, or whether it's used at all. And so
on.

If name mangling incompatibility was "fixed", it wouldn't mean that
object modules compiled with different compilers could be used together.
It would just mean that the incompatibilities showed up as strange
behaviour and unpredictable crashes at run time, instead of (relatively)
clear error messages at link time. This would not be a Good Thing. So
compilers use incompatible name mangling on purpose.

So why didn't the standard fix this by specifying an interface at the
binary level (as Java did)? Because those different compiler conventions
are there for a reason. There is no one best way to build a class;
different binary standards are best for different purposes. Requiring
one binary interface would make the resulting code suboptimal in many
cases. (This is one of several reasons why Java can never match C++ for
efficiency no matter how good the compilers get. Lest I be accused of
language bashing, that doesn't make Java inferior -- it just has
different priorities.)

This problem isn't unique to C++, although many C++ bashers would like
you to think so. It's always been there in C too; what do you think all
those FAR/CDECL/STDCALL/PASCAL/WINAPI/etc prefixes (or the equivalent on
other platforms) are for? They're the equivalent of name mangling,
inserted manually by the programmer instead of automatically by the
compiler, to indicate different calling conventions.

-- 
Ross Smith ..................................... Wellington, New Zealand
<mailto:r-s### [at] ihugconz> ........ <http://crash.ihug.co.nz/~r-smith/>
   "Remember when we told you there was no future? Well, this is it."
                                                         -- Blank Reg

Post a reply to this message