Lance Birch wrote in message <368c0c62.0@news.povray.org>...
>It might take some re-writing, but it should be possible, because after all
>you could just compile the Dlls functions into the main program and then
>nstead of calling the Dll, you just call the function.  So yeah, guess so.
>
>--
>Lance.
>
>
>---
>For the latest MAX plug-ins, images and much more, go to:
>The Zone - http://come.to/the.zone
>
>

Here's a different look: why not write a pov-ray SPECIFIC library. IE. place
the files in, and using a customized interface, povray reads the library.
Who says anything about making it a DLL? Why not make a simple binary format
that povray can read crossplatform? I mean.. look at TTF fonts. Just because
they don't work _as fonts_ in any other OS but windows, doesn't mean pov-ray
can't read them. You can read windows TTF fonts on the amiga, for the TTF
object. Amigas don't use TTF fonts in any way, yet the file itself is still
readable.  Why not go from that as a starting point?

twyst

Post a reply to this message

Yes you can add the functions as normal code, however there
are some functions you can do with DLL's that isn't
part of regular functions in iso_surface. But wouldn't be to
hard to even add those. In general new iso_surface functions
can be added with 2 lines + function code itself.

Nieminen Mika wrote:
> 
> Mike <Ama### [at] aolcom> wrote:
> : He said that just the DLL part would have to be removed:
> 
> : "Also some of the features
> : will be modified or eliminated.  For example cross-platform
> : portability is a major design priority and the iso-surface patch makes
> : use of DLLs that are not portable.  We will likely eliminate that part
> : of the patch."
> 
>   I wonder if it's absolutely impossible to make the same code without
> the dlls. What's so special with the dlls anyways?
> 
> --
> main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
> *_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Mick Hazelgrove heeft geschreven in bericht <368b6033.0@news.povray.org>...
>
>Once again THANKS Pov team - the only sad news is the probably loss of the
>iso patch - can we keep some of it, the non Dll part? I espeacially like
>using it to create mathmatical surfaces, normal and color patterns.


I was engaged in the development of FORTRAN programs that were both
user-extendable and had one and the same source code for a variety of
platforms. The trick we played was that we included a number of 'slots' in
the code, where we called dummy subroutines. The user could include his own
features by replacing one of those dummies and then re-linking the program
from the .lib files we supplied along with the .exes. The re-linking was not
considered a problem since the user needed to have a compiler and a linker
for his platform anyway.

This technique may provide a way to allow users to extend POV without
compromising on platform independence.

Happy new year to all of you.

Frans

Post a reply to this message

On Thu, 31 Dec 1998 17:23:16 -0700, "Twyst" <twy### [at] twystednet> wrote:

>Here's a different look: why not write a pov-ray SPECIFIC library. IE. place
>the files in, and using a customized interface, povray reads the library.
>Who says anything about making it a DLL? Why not make a simple binary format
>that povray can read crossplatform? 

Because the code in the current isosurface DLLs is compiled C, in the
form of processor-specific instructions, and would thus be useless to
the average Amiga user (and possibly even the average DOS user).  You
could write an entire virtual machine and make the 'libraries' contain
p-code, but there would be a bit of a performance hit over just
compiling the functions into the source directly.

>I mean.. look at TTF fonts. Just because
>they don't work _as fonts_ in any other OS but windows, doesn't mean pov-ray
>can't read them. You can read windows TTF fonts on the amiga, for the TTF
>object. Amigas don't use TTF fonts in any way, yet the file itself is still
>readable.  Why not go from that as a starting point?

TTFs, except for some hinting rules in a documented pseudocode, are
just big tables.  There isn't any native executable code in one.

Post a reply to this message

Lance Birch wrote:
> 
> Dlls are only supported by the Windows operating system... Dynamic Link
> Libraries.  The function calls necessary to use a Dll simply don't exist in
> other operating systems. (They have their own special ways of doing things)

Actually, Linux and other unix-like OSs have DLLs, though maybe not
normally called by that name.  In 1988 (ten years ago) I read a manual
for SunOS version 3.something and it described DLLs.  That was before I
heard of Microsoft Windows.     For Linux and most other unixes, the
resulting DLL files are named not like wonderful.dll but like
libwonderful.so.   

I have used isosurfaces on Linux, and it was easy, though I don't see
how a non-programmer could use it. 

What I don't know is which OSs *don't* support DLLs (by any name)?

I have some thoughts on implementing isosurface w/o any kind of DLLs -
see the programming newsgroup.
-- 
Daren Scot Wilson
dar### [at] pipelinecom 
www.newcolor.com
----
"A ship in a harbor is safe, but that is not what ships are built for"
                                            -- William Shedd

Post a reply to this message

Daren Scot Wilson <dar### [at] pipelinecom> wrote:
: What I don't know is which OSs *don't* support DLLs (by any name)?

  DOS.
  (I know, I know, DOS is not an operating system...)

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Yeah, that's what I meant.  Even if they aren't called Dlls, the
instructions in each operating system are still there to use a dynamically
linked library.  The only problem is that it would get annoying having to
convert the method of programing for each operating system.  For instance,
I'm sure Windows has a different Dll entry method than Linux or Unix does.
What I was thinking is to incorporate the Dll into the actual program (so
it's no longer linked).  That way access to it would be faster also and it
would save rewriting the Dll entry point for each OS.

Just a thought anyway.

--
Lance.


---
For the latest MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

On Sat, 02 Jan 1999 13:19:23 +0000, Daren Scot Wilson
<dar### [at] pipelinecom> wrote:

>What I don't know is which OSs *don't* support DLLs (by any name)?

I assume you mean "operating systems currently supported by POV-Ray."
I can name at least one: MS-DOS.  I think Macs don't support dynamic
libraries, as well, but I'm probably mistaken.  AmigaDOS supports 
dynamic linking, as does OS/2.  Many unices don't support dynamic 
linking.  I think perhaps VMS doesn't support dynamic linking, though 
I suspect there's no longer an official VMS version (if there ever 
was.)

Post a reply to this message

Well, if people really needed cross-platform 'dll's, you could always go
the route of setting up JNI hooks and writing the 'dll' in Java. That way
you'd have bytecodes that would run on many platforms. (Or maybe...
POV-Ray could be made to call a Java method. That Java method could be
set up to in turn call a platform-specific native module via JNI, or just
fall back to a pure Java implementation, and could even switch
dynamically at run-time. Arrrggghhh! No.....! Stop!!! my head hurts....)

Of course, with the speed factor and all, especially with raytracing, I
would definitely say don't do that. Just stick to good clean C.


Ronald L. Parker wrote:

> On Sat, 02 Jan 1999 13:19:23 +0000, Daren Scot Wilson
> <dar### [at] pipelinecom> wrote:
>
> >What I don't know is which OSs *don't* support DLLs (by any name)?
>
> I assume you mean "operating systems currently supported by POV-Ray."
> I can name at least one: MS-DOS.  I think Macs don't support dynamic
> libraries, as well, but I'm probably mistaken.  AmigaDOS supports
> dynamic linking, as does OS/2.  Many unices don't support dynamic
> linking.  I think perhaps VMS doesn't support dynamic linking, though
> I suspect there's no longer an official VMS version (if there ever
> was.)

Post a reply to this message

Jon A. Cruz wrote:

> Well, if people really needed cross-platform 'dll's, you could always go
> the route of setting up JNI hooks and writing the 'dll' in Java. That way
> you'd have bytecodes that would run on many platforms. (Or maybe...
> POV-Ray could be made to call a Java method. That Java method could be
> set up to in turn call a platform-specific native module via JNI, or just
> fall back to a pure Java implementation, and could even switch
> dynamically at run-time. Arrrggghhh! No.....! Stop!!! my head hurts....)
>
> Of course, with the speed factor and all, especially with raytracing, I
> would definitely say don't do that. Just stick to good clean C.
>

To quote Chris Young concerning Pov a Jave:

WHAT LANGUAGE TO USE?  WHEN?  HOW?
        As I mentioned earlier, we originally planned that our next
release would be a major rewrite in C++ however we had lots of input
from users and team members that a compiled Java rewrite might be a
good alternative.  In the 18 months since that debate, Java has not
fulfilled its promise to unite the world in the peaceful harmony of a
single, portable language.  The whole industry (not just Microsoft) is
doing things to ruin Java.  Enough politics... Java is out.  We're
sticking with our original plan for C++.

--
Ken Tyler

tyl### [at] pacbellnet

Post a reply to this message