clipka <ano### [at] anonymousorg> wrote:
> Am 18.07.2021 um 17:24 schrieb HKarsten:
> > By the way, I fully support Leroy at this point: PovRay is an old program. I am
> > using it since 1991! And there are a lot of tools, running under DOS, Win95,
> > Win2K.
> > So what if you can run PovRay on Vista, or Win7 up to Win10 or Win11 only?
> > Do you like to run an emulator within an emulator to run your tools one day?
>
> The problem is that as time goes on, there comes a point where we want
> to add new features that we can't implement without breaking
> compatibility with (a) those old operatings systems and/or (b) even the
> newest build tools we can find that still target those operating systems.
>
> One day, the Visual Studio 2017 toolkit will no longer be supported by
> Microsoft, and some time thereafter we will no longer have access to a
> sufficiently secure build environment featuring that piece of software.
> When that happens, that'll be the day when we will definitely have to
> cease supporting XP for good.
>
> You just can't expect to forever have access to the latest and greatest
> new POV-Ray features on the oldest and coldest operating systems.
>
>
> So what's the solution to continue to use those old tools? Well, use a
> matching POV-Ray version, obviously. One from those olden golden days.
>
> That, or indeed run those tools under DOS-Box. I'm not sure how that
> emulator works, but it surely will have ways to export and import files
> from it, right?
>
>
> But the point has been taken: There are still POV-Ray users out there
> who want XP support, so we'll see what we can do.
>
> That's why we've asked.

I am surprised, we are not even talking about dropping windows XP or 32 bits
compatibility, right?

"
Note that the choice between XP-compatibility and performance is a
matter of the build tool used (Visual Studio 2010 will generate
XP-compatible binaries, while Visual Studio 2015 will generate faster
ones), so 64-bit XP-compatible binaries /can/ still be built from the
source code, as can faster 32-bit binaries.
"

And even if we were: So many other software have just recently made much bolder
moves with successfull results:  Blender dropped 32 bits support, Python even
dropped Windows 7 support! Don't get me wrong. I don't mean POV should just do
what others do, and as a user I love being able to compile POV on as many
platforms as possible. But if it slows down the overall innovation, which in
turns prevents from attracting many potential users and developers. that's not
the safest bet, because more users would then anyway be able to port, adapt,
test (and re-iterate) the sources to more platforms, legacy included.

Correct me if I'm wrong, but the POV core team contingent, does not seem so
close from being as numerous and ressourcefull of a community as these ones. So
it sounds reasonable to lower such maintenance burdens on existing developers
temporarily to allow for a later regrowth of ubiquity which is indeed POV's
strongest "selling points". If it does have to happen one day, Now is also a
better time than ever to do such very mild support drops, one at a time, before
POV 4 gets on the rails and too many breakage at once may feel hard.

Post a reply to this message

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

Am 22.07.2021 um 15:16 schrieb Mr:

> I am surprised, we are not even talking about dropping windows XP or 32 bits
> compatibility, right?
...
> Correct me if I'm wrong, but the POV core team contingent, does not seem so
> close from being as numerous and ressourcefull of a community as these ones. So
> it sounds reasonable to lower such maintenance burdens on existing developers
> temporarily to allow for a later regrowth of ubiquity which is indeed POV's
> strongest "selling points". If it does have to happen one day, Now is also a
> better time than ever to do such very mild support drops, one at a time, before
> POV 4 gets on the rails and too many breakage at once may feel hard.

The point is, currently there is no truly pressing need to ditch XP 
support (or 32 bit, for that matter).

What we can do, for example, is to proceed as follows:

- Use VS 2019 for the binaries we distribute with the regular 
installers, in hopes that it will give us the best in terms of 
performance. This would make those binaries require at least Windows Vista.

- Use VS 2017 (which is the last version of Visual Studio that should be 
capable of building XP-compatible binaries) for a separate set of 
XP-compatible binaries, to be distributed in a separate installer.


Right now, we've encountered nothing more than a road bump trying to 
compile cmedit.dll in an XP-compatible fashion.

Had the feedback to our question regarding XP been "...(crickets)...", 
we might just have left it at that and not bothered to investigate any 
further. Or maybe only later, after the official v3.8.0 release.

I'm sure it's not a major obstacle, just something somewhere not 
entirely set up properly. Nobody has tried building the cmedit.dll since 
v3.7.0.0, so it might just be something we happen to have borked in the 
meantime.


Even if the problem should turn out to be something larger, there are 
enough other options we could try. In the worst case, there's a clear 
path of having XP users deal with a minor inconvenience most probably 
wouldn't even notice, or possibly mistake for a feature.


(As a side note, the v3.8.0.beta.1 has been compiled with VS 2015, due 
to some other road bump encountered also with respect to cmedit.dll)

Post a reply to this message

As a side note:

Those of you running XP could do us a favor and try what happens if you 
run the installer anyway.


While the NSIS docs claim that the installers we're creating with that 
tool should be compatible with any 32-bit version of Windows all the way 
back to Windows 95. it might be worth verifying nonetheless.


Of course the binaries won't run properly, but that's an entirely 
different matter.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 19.07.2021 um 05:22 schrieb HKarsten:

[...]
> We prefer targeting multiple build tools, to increase support.
[...]

Hello,
I think you should consider the 'CMake' tool. It is used in more and more
projects, and with its scripting language allows the user to choose the building
process, that can be (not exhaustive):
-Compile the project with a Makefile under Windows or Linux
-Compile the project under Windows with a Visual Studio Solution.
-Other compilations solutions...
-Setup some files (else than the generated binaries) in the standard directories
of differents OSes, /usr/local/share or C:\Program Files\'project dir' for
example.

All you need to do is to write one or several files named 'CMakeLists.txt' and
use the CMake script language. I use CMake in my games projects, it is present
in many Unix standard repositories and is of course available for Windows and is
free.

One good point is that you must write only one 'CMakeLists.txt' file per
binary/project even if you target several OSes.

Post a reply to this message

Am 06.08.2021 um 21:04 schrieb Warren:

> I think you should consider the 'CMake' tool. It is used in more and more
> projects, and with its scripting language allows the user to choose the building
> process, that can be (not exhaustive):
> -Compile the project with a Makefile under Windows or Linux
> -Compile the project under Windows with a Visual Studio Solution.
> -Other compilations solutions...
> -Setup some files (else than the generated binaries) in the standard directories
> of differents OSes, /usr/local/share or C:\Program Files\'project dir' for
> example.
> 
> All you need to do is to write one or several files named 'CMakeLists.txt' and
> use the CMake script language. I use CMake in my games projects, it is present
> in many Unix standard repositories and is of course available for Windows and is
> free.
> 
> One good point is that you must write only one 'CMakeLists.txt' file per
> binary/project even if you target several OSes.

The not so good point is that we must write one `CMakeLists.txt`.

Since we're primarily developing on Windows using Visual Studio 
(specifically VS 2015), that's not a thing that is directly supported by 
our primary IDE.

Most notably, _each and every_ change to the set of files that make up 
the POV-Ray source code (be it the addition of a new file, the removal 
of an obsolete one, or the renaming or moving of a file) since the 
release of POV-Ray v3.7.0.0 was done from the seat of a Visual Studio 
jockey.

And as things stand at the moment, VS is the _only_ place we need to 
maintain _any_ such lists of files that need compiling: The current 
Autotools-based process generates its own list on the fly using a fully 
automatic system. (Unless you get a *NIX-specific source tarball, in 
which case that step has already happened).

 From what I've seen of CMake on the other hand, it seems to be 
incapable(*) of such stunts, which I find extremely disappointing for a 
supposedly modern build system. To have a directory sub-tree entirely 
devoted to the software's source code, such that every file in there is 
to be compiled, seems such a trivially common use case to me that I find 
it ridiculous that a modern build system doesn't address it.

(*While there are workarounds that promise to accomplish something like 
that, the CMake authors themselves explicitly state that those 
workarounds don't actually... work.)


Also, I may be misunderstanding things, but I presume CMake does not 
natively cater to a project that has, in some sense, completely 
different applications for different target platforms, which "only" 
share a common core.


All in all, I don't see CMake solving _any_ problem we might currently 
have, while at the same time it would be moving any necessary day-to-day 
maintenance to a place where it is less accessible to us.

Things might change if we add an official third "incarnation" (as I like 
to call them) besides POV-Ray for Windows and POV-Ray for Unix, such as 
a Qt-based portable GUI version of POV-Ray, a Mac-specific one, or 
whatever. But until then, switching over to CMake seems to be more pain 
than gain.


At any rate, CMake won't do anything to help with the original topic of 
this thread, namely XP compatibility.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 06.08.2021 um 21:04 schrieb Warren:
>

> Also, I may be misunderstanding things, but I presume CMake does not
> natively cater to a project that has, in some sense, completely
> different applications for different target platforms, which "only"
> share a common core.

You can mark out parts in a 'CMakeLists.txt' file like for example:

if( UNIX )
//Do these things only for Unix OSes
endif( UNIX )

if( WIN32 )
//Only for Windows OSes
endif( WIN32 )

And you also can make sub project like I do for the games I'm currently
developping like in this tree example: (directory based interpretation)

CMakeLists.txt in main project directory
|
|--'editor' sub directory that contains also a 'CMakeLists.txt' file that
generates an executable based partly on some others static libraries below, to
edit levels for the game
|--'inGame' sub directory that contains a 'CMakeLists.txt' that will build a
static library which is the game core
|--sdl2_wrapper : another static library that wraps the well known SDL2 library
so that it becomes RAII / RFID compliant ( C++ )
|--'game' generates the game excutable based on other libraries

That said I agree with you when you say CMake for now, can't generate a build
process based on a directory that may contains all the sources. But I make up
for that with a couples of commands in Ubuntu in a script shell:

#!/bin/bash
#List the sources and headers of 'inGame' directory
#
find ../sources/inGame -type f -name "*.h" > lists/inGameHeaders.txt
find ../sources/inGame -type f -name "*.cpp" > lists/inGameSources.txt
#
sed 's#../sources/inGame/#\t\t#g' -i lists/inGame*.txt

The last sed command adds two tabulation chars ('\t') so that when I paste the
txt file content , I have a suitable indentation.
And as concrete example here is a simple CMakeLists.txt :

cmake_minimum_required(VERSION 3.8)

project("game_${SQUARE_SIZE}" LANGUAGES CXX)

if(UNIX)
 include(GNUInstallDirs)
endif(UNIX)

set(HEADERS
  sources/generic/loadings/makeTextTextures.h
  sources/levels/contexts/demoLevel.h
  #This is a comment
  #Other files there
)

set(SOURCES
  sources/generic/loadings/makeTextTextures.cpp
  sources/levels/contexts/level.cpp
  #This is a comment
  #Other files there
)

add_executable( ${PROJECT_NAME}
    WIN32
    ${SOURCES}
    ${HEADERS}
    ${INC_DIRS}
)

target_include_directories(${PROJECT_NAME}
        PUBLIC ${SDL2_INCLUDE_DIRS}
        PUBLIC ${SDL2_IMAGE_INCLUDE_DIRS}
        PUBLIC ${SDL2_TTF_INCLUDE_DIRS}
        PUBLIC ${SDL2_MIXER_INCLUDE_DIRS}
        PUBLIC sources
        PUBLIC ../commonFiles/sources
        PUBLIC ../generic/sources
        PUBLIC ../inGame/sources
)

target_link_libraries( ${PROJECT_NAME}
      ${SDL2_LIBRARIES}
      ${SDL2_IMAGE_LIBRARIES}
      ${SDL2_TTF_LIBRARIES}
      ${SDL2_MIXER_LIBRARIES}
      "mercenaries_common_${SQUARE_SIZE}"
      "mercenaries_generic_${SQUARE_SIZE}"
      "mercenaries_inGame_${SQUARE_SIZE}"
)

set_target_properties( ${PROJECT_NAME}
      PROPERTIES
      CXX_STANDARD 20
      CXX_STANDARD_REQUIRED YES
      CXX_EXTENSIONS ON
      LINKER_LANGUAGE CXX
)

if( UNIX )
 math(EXPR SCREENWIDTH "${SQUARE_SIZE} * 20" OUTPUT_FORMAT DECIMAL )
 install(TARGETS ${PROJECT_NAME}
  RUNTIME DESTINATION
"/media/antoine/projetsLinux/final/MercenariesProject/Mercenaries${SCREENWIDTH}"
 )
endif(UNIX)

//-----------------End of CMakeLists.txt file
If you wonder what '${SQUARE_SIZE}' stands for, this is the logical size of a
tile in my game. In fact I use a combination of bash script files and povray to
make all textures in my game according to a given size of Tiles textures (the
size is passed to every shell scripts that compute the final size of the povray
image size that renders). Only one script to run and then some hours later, all
the textures I want are created. All I have to do then is to compile the
binaries with the same tile size that I give while running 'cmake' in command
line later.

Post a reply to this message