"Mark Arrasmith" <arr### [at] worldnetattnet> wrote:

>Ok.  I'll try to get povwin to compile without the editor and ztimer
>library.  Is there anything else I should look for?  And, any hints on
>replacements?

You don't need ztimer unless you want to do scene profiling. There's not
likely to be a replacement for the editor that will be easy to integrate.

Post a reply to this message

povray.org admin team wrote in message
<35553d06.26038110@news.povray.org>...
>>What should have been done was an ActiveX./DLL
>
>'Should' by your standards perhaps. Active X didn't exist at the time (as
you
>should well know) and we won't use a DLL because it allows POV-Ray's
renderer
>to be too easily subverted by leechware.
>
>Really, if you want a DLL-based renderer, why don't you simply write your
own ?

I've same feelings about ActiveX than you : not portable.
But shared libraries or at least static ones, exists on every plateforms /
compilers. And highly portable at source level.

Why a "DLL would allows POV-Ray's renderer to be too easily subverted by
leechware" ?

A library version of PovRay, shared or not, still could display legal
informations at STARTUP_POVRAY() and/or FINISH_POVRAY().
From User's point of view (UPOV?), he would see a POV-Ray startup screen
just after clicking on "Render now" button of his application. And then the
preview / final window on these application displaying result.
Exactly like today with Moray for Windows, Breeze Designer, Calimax or
Texture Magic...
But from these applications developers, a better "technically" integration
of POV-Ray renderer could be made, with callbacks for preview and final
rendering, rendering messages, pre and post traitment of output, in place of
pooling image output file and log files...

Okay, we could write our own DLL-based POV-Ray renderer. I actually trying
to do this for Win32.
But I want this DLL-based version to be thread-safe. Because of globals
variables and some others code's stuffs, I've to rewrite many modules.
And what a pain to do this, again, for future versions !

But perhaps I miss something about "subverted by leechware" ?

Phil.

Post a reply to this message

>But perhaps I miss something about "subverted by leechware" ?

You'd have to go back a few years, and be aware of some of the history of v2.0.
It's not really worth digging that up now ; all I'll say is that experience
with v2 heavily influenced a v3 decision we made to not make it too easy to
integrate with.

POV-Ray for Windows was originally intended to be just what was suggested - two
parts, a rendering engine and a front-end. The rendering engine was to be
written in portable C. This is why, even to this day, POV-Ray for Windows has
the name 'PVENGINE.EXE' and has most of its UI written in C (apart from the
editor). It was really intended to only be a very simple rendering engine that
was called from another application. We didn't really want to have a UI in it.

Additionally, (history again), it was originally written under Win32s (Windows
3.1) which didn't have threads. When '95 came alone, we added some Win32
support, but it still has a lot of its heritage from the Win32s days.

So, what we have today is the result of a number of compromises, since Win 3.1
was still a very viable platform at the time, plus a deliberate decision made
by the team as a whole (not just one person) to limit the ways that an external
program can use our renderer.

There is work afoot on a new version of POVWIN which will be split up (a team
member alluded to this a few weeks ago in an IRC chat with Twyst) but I can say
at this time that, again, the rendering portion will not be a DLL or ActiveX
control. Comms will be via TCP/IP (using a well-known port number already
allocated to POV-Ray by the IANA). It will not support Windows 3.1x. It will
support distributed network rendering. There is no date set. It may not even be
this year. Please don't bug us about it.

Again, however, we shall be taking steps to prevent subversion of our software
by unscrupulous developers who want a free ride. (Yes, such persons exist, like
it or not). This may make it difficult for others who do respect our software,
but that, as they say, is life. Please respect our wishes in this respect by
not hassling us over it.

Post a reply to this message

povray.org admin team <new### [at] povrayorg> wrote in article
<3555b828.55938845@news.povray.org>...

I've started using POV with the 3.0 versionn, so thanks you for development
history. 
Compromise is another name for (software development?) life.

> There is work afoot on a new version of POVWIN which will be split up (a
team
> member alluded to this a few weeks ago in an IRC chat with Twyst) but I
can say
> at this time that, again, the rendering portion will not be a DLL or
ActiveX
> control. Comms will be via TCP/IP (using a well-known port number already
> allocated to POV-Ray by the IANA). It will not support Windows 3.1x. It
will
> support distributed network rendering. There is no date set. It may not
even be
> this year. Please don't bug us about it.

Great. Going directly to Client-Server architecture is better than a just
modular (DLL & Co...) version.
I can totally wait for a such official client-server version ! 
Even for years...

Phil.

Post a reply to this message

Mathias Broxvall <mbr### [at] swipnetseNOSPAM> wrote in article
<1d8### [at] dialup150-2-39swipnetse>...
> Philippe Houdoin <phi### [at] ouest-francefr> wrote:
> 
> > Perhaps a welcomed next major version (4.0?) rewritten code will help
this
> > particular point.
> 
> Another small problem is that (I read somewhere) povray version 4.0 will
> be written in C++ which makes it a little bit more difficult to make
> sharedlibraries of it on some plattforms. The reason for this is that
> there is no widely addopted standard for how the name mangling should
> be performed. Ie my MrC compiler and my Codewarrior compiler creates
> different symbols (for the linker) for the same function. I would expect
> this to be a problem also on other plattforms. Am I right?
> I know that this is easy to overcome (Mix C and C++), but in a portable
> way?
> 

	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.

-- 
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

>       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 */
  ...
}

Post a reply to this message

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