Am 19.07.2021 um 05:22 schrieb HKarsten:

> As far as I understood, you wound use new features in PovRay, that can run under
> Windows only. PovRay will run on Linux, BSD, MACOS and so forth.

(That sentence doesn't parse in my mind; for clarification: I presume 
you meant "... you wouldn't use...")

That's not entirely true. We try to do this for all of the "main" source 
code. However, we provide different front-ends for different run-time 
environments.

All of those front-ends use _some_ features that are not covered by the 
pure ISO/IEC standard C/C++ language and libraries we're currently 
developing for.

> This means,
> 
> 1) you don't need to use a programming-environment that is limited to a hand of
> operating-systems only. If you use an older programming-environment your
> application is till running on newer systems.

Technically, we need to use a programming environment that is limited to 
whatever operating systems it was designed for. So limits always exist.

We prefer targeting multiple build tools, to increase support.

> 2) another option is to compile a new PovRay statically under Cygwin. Statically
> means, cygwin.dll has to be in the same folder, as PovRay's exe-file and it will
> run under XP with no cygwin-environment installed.

I'm not entirely familiar with Cygwin, but it is my understanding that 
it is intended to take software that expects a Unix run-time 
environment, and runs it on a Windows system.

Note that we currently provide a graphical user interface for Windows, 
but none for Unix. So going for Cygwin would mean depriving the Windows 
users of the UI they currently get.

> Is it than impossible to implement new features to PovRay by taking the source
> of PovRay 3.7 and the programming-environment that was compiling it for good and
> just add these features?? What could it be for you, NEED to have a new
> programming-environment for this?

Had the POV-Ray developers for all these 30 years bought into the 
paradigm you are proposing there, the following would have happened:


-- SCENARIO 1 --

(1) The code would have continued to use C, not C++. Probably good old 
ANSI C (aka C89), to be precise.

(2) Development would have been slower. Far slower, I reckon.

(3) Bugs would be far more common, including crashes, memory leaks, and 
cases where the program would just seem to go berserk for no immediately 
apparent reason.

(4) The code would be a pain to read and wrap your head around.

(5) Implementing multi-core support might not have happened.

(6) OpenEXR support might not have happened.

Here's a very short summary of a few reasons why:

* C is a very low-leve language, making it very verbose in practice, 
making it very clunky. There are a lot of things that you need to do 
explicitly in C that you can let the compiler handle for you 
automatically in C++. This is expecially true since the introduction of 
standardized smart pointers - first in boost, later in TR1, and finally 
in C++11 - which have made development a lot easier.

* The verbosity also leads to a lot of room to accidently forget things 
or get things wrong. If you explicitly need to take care of each and 
every little detail, missing it just once may spell disaster for your 
software.

* POV-Ray does a lot of maths on non-trivial and non-standard data 
types, such as 2D and 3D vectors, 3D rays (defined by an origin and a 
direction), RGB colours, RGBFT colours and matrices. C operations on 
such data types look clunky compared to C++. For instance, in C an 
arbitrary piece of code might look something like this:

     colour_add(A, B, C);
     colour_mul(A, 0.5);
     colour_sub(A, D);

Whereas in C++, if you do a bit of homework up front, the same code 
might end up looking like this:

     A = (B + C) * 0.5 + D;

* ANSI C did not provide support for multithreading out of the box. To 
the contrary, several functions of the runtime libraries were inherently 
unsafe for use in threads. To make use of threads, operating system 
specific libraries would have to be used, both for the thread management 
itself, as well as any thread-unsafe functions. And since the 
implementation of those operating system libraries naturally differs, 
the code would have needed to somehow work around that, trying to 
abstract away the implementation details.

* As for OpenEXR, that library is written purely in C++, and requires 
C++ to call. And although it would presumably have been possible to 
write a C/C++ hybrid wrapper around the things we use from that library, 
and POV-Ray is designed to compile without it, this would have given it 
a much different feel: OpenEXR, as it is now, is an integral part of 
POV-Ray, and omitting it would be considered the exception. In a C-based 
POV-Ray, it might be considered more of a purely optional thing, 
something you should generally not rely on being present. And it might 
never have made it into POV-Ray proper for that reason.

As a matter of fact, the most recent versions of OpenEXR not only 
require C++, but at least C++11.


-- SCENARIO 2 --

(1) The code would have continued to use C, not C++. To start with, it 
would probably have been good old ANSI C (aka C89).

(2) The code would have slowly morphed to include newer language 
features, and nobody would have noticed until someone actually tried to 
compile the new code on an onld platform.

(3) Optionally, the code might have slowly morphed into C++ after all, 
without anybody even realizing.

Here's a very short summary of a few reasons why:

* Developers tend to not use the oldest platforms and compilers around, 
and may not be aware of what features were or were not available in the 
older versions of the language.

In other words, it is difficult to develop strictly for a stable old 
platform when you have new tools at your disposal.

* For some time, POV-Ray developers might have almost exclusively used 
Visual Studio for their own development and testing. If my memory 
doesn't deceive me, there was also a time - which might well have 
coincided - when Visual Stidio technically only supported C++, not C, so 
a developer wouldn't have notice they had slipped in the occasional 
pieces of C++, which wouldn't compile on a strict C compiler.


-- SCENARIO 3 --

(1) POV-Ray proper would have died out at least 10 years ago, because 
this is a hobbyist project and nobody enjoys working with clunky old 
languages when there are so much more elegant and almost equally 
performant languages out there.

(2) Optionally, some people might have started a C++ branch of POV-Ray, 
breaking compatibility to enjoy the more elegant code.


-- ALSO --

No, it IS NOT possible to stick to the same build environment used for 
POV-Ray v3.7.0.0. That would have been VS 2010.

I'm not entirely sure it would run on my computer.

I'm sure I currently don't have it installed.

I'm sure it would need a license to install, which I probably still own, 
but might not be able to dig up. If the licensing server would even 
still be available.

I'm sure it would not create binaries for target platforms later than 
Windows 7 or Windows Server 2008 R2, respectively.

I'm sure there will eventually come a time when Microsoft will release a 
Windows version that will exhibit compatibility issues with binaries 
targeting Windows 7 or Windows Server 2008 R2, respectively. At that 
time, both the build environment and binaries created with it will cease 
to run on then-modern systems.


And had peolpe stuck to the build environment they had used back in the 
times of POV-Ray 1.0, my guess is that they would today be in the 
situation that the good old DOS compilers, while presumably still able 
to run from the command prompt, might have difficulty building binaries 
that run on Windows 10 at all - let alone in 64 bit mode. Or making use 
of AVX. And performance may be poor compared to binaries optimized by 
modern compilers.


All this is not to say that we have any intention of abandoning an 
existing user base - but there are reasons why we may have no other 
viable choice.

Eventually.

Not today.

Post a reply to this message