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?

> An obvious and portable one (except for MacOS!?) is a little command line
> shell. 

You can make shell tools for the Mac too. Either for a real shell like
MPW (which many Mac developers use) or use a simple library
to simulate a shell in your program. (Ie creates a simple window and 
routes stdio,stdout and stderr to it without a single line of program
code).

/ Mathias Broxvall

Post a reply to this message

>If I remember right the problem was with a dll or maybe several dll's that
>were not available under the AlphaNT platform.  A Borland Delphi dll I
>think.

The DLL you are referring to is the Editor. It is not essential to the programs
operation.

Post a reply to this message

>I'm starting work on an ActiveX version of PoV just for the purpose of
>easy integration to front ends.  I think the Window's version of PoV is
>bloated-  who wants to download a 4M rendering engine that should
>be ~1M.

Get your facts right. Most of that 4m is docs and misc files. PVENGINE itself
is 1.4m total. Your claim that the 'rendering engine' is 4m is misleading and
could put people off using POVWIN if they haven't already tried it.

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

Post a reply to this message

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?

Mark

povray.org admin team wrote in message
<35543cdd.25997502@news.povray.org>...
>>If I remember right the problem was with a dll or maybe several dll's that
>>were not available under the AlphaNT platform.  A Borland Delphi dll I
>>think.
>
>The DLL you are referring to is the Editor. It is not essential to the
programs
>operation.

Post a reply to this message

"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