POV-Ray : Newsgroups : povray.beta-test : Windows XP compatibility Server Time
28 Mar 2024 07:26:43 EDT (-0400)
  Windows XP compatibility (Message 5 to 14 of 17)  
<<< Previous 4 Messages Goto Latest 10 Messages Next 3 Messages >>>
From: clipka
Subject: Re: Windows XP compatibility
Date: 18 Jul 2021 12:47:27
Message: <60f45b1f$1@news.povray.org>
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.


Post a reply to this message

From: HKarsten
Subject: Re: Windows XP compatibility
Date: 18 Jul 2021 23:25:00
Message: <web.60f4efe2d5a68e3bcc54a410ad2d5cff@news.povray.org>
Hi clipka :)

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

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.

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?

Best rgds,
Holger


Post a reply to this message

From: jr
Subject: Re: Windows XP compatibility
Date: 19 Jul 2021 05:20:00
Message: <web.60f542ecd5a68e3b5e0fed26cde94f1@news.povray.org>
hi,

"HKarsten" <nomail@nomail> wrote:
> ...
> If you can't use all this within one system, it's going to become something
> between difficult to freaky.

that's an impressive list of POV-Ray's you've got.  somewhat disagree with yr
argument(s) though.  Windows Server 2003 was "put out to pasture" ten years ago,
and the world has kept turning.  if you used VmWare (for example), you could
turn your existing machine into a VM, and yr Win2003 becomes just "another"
window on yr desktop.


regards, jr.


Post a reply to this message

From: HKarsten
Subject: Re: Windows XP compatibility
Date: 19 Jul 2021 14:50:00
Message: <web.60f5c8dcd5a68e3bd47798fead2d5cff@news.povray.org>
Hi jr, :)
If I would have a system, small enough, this would be an option.
Several times I tried to virtualized my System. Sometimes the drivers are poor
and  my 3D-Programms, like 3DS-Max, or Maya does not run properly or other
things happened.
And I still didn't find a host-system, small enough for not being in the way.
So: as long as my System can run natively, it turned out to be the best way.
BTW: my 2003 is a pure offline System. It never was connected to the internet
for even a fragment of a second, and it never will be.

For being connected, I an using Puppy-linux:
distrowatch.com/table.php?distribution=puppy

Its running from RAM, so if it's going to be compromised, next time booting it
has forgotten all about it.

For my 3D-Printer the sclicer is not running on XP for example, and I have to
use my Linux for it. It's pain in the as to do a reboot just for slicing!

Having a PovRay as plain-static cygwin-exe would be the much nicer way, instead
of rebooting the machine.

Best rgds,
Holger


Post a reply to this message

From: Bald Eagle
Subject: Re: Windows XP compatibility
Date: 19 Jul 2021 18:40:00
Message: <web.60f5ff14d5a68e3b1f9dae3025979125@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:

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

So, just thinking out loud:

This whole legacy workflow / tool-chain that he's got going as an example of why
it would be nice to have a growing collection of analogous in-house tools to
perform the scene-building part of the workflow, instead of parting-it-out to
whatever third-party external software things might be available.

I remember Sam Benge posted a very nice pile of rocks/grains that he made using
a dataset generated with Voro++.  It would be nice to have the crackle pattern
points and knobs exposed to the SDL so we had something like that - since making
piles of rocks is something people invariably try to do in POV-Ray.

Chris Cason was generous enough to purchase the rights to Moray so that someday
we can have a GUI modeler for the things that modelers are good for.  And a
modeler like Moray is irrefutably desireable and (in)directly used in
raytracing.

I know that the current paradigm is that "POV-Ray is a raytracer", but creating
the things that will be raytraced by POV-Ray I think is an integral part of the
POV-Ray experience.  And the more "pieces" we own in our own little toolbox, the
less will be lost to changes in OS's, 3rd-party blackbox software, licensing
changes, and other links in the scene-creation chain.

I know that I have suggested a few things in the past that at first glance
"don't have much relation to raytracing", but I do hold firm in my opinion that
they would be valuable scene-creation and modification tools. There are many
people who are, or were, enthusiastic POV-Ray enthusiasts, and would likely be
happy to donate/license the use of their already-written code for various
algorithms to use in future distributions.

Some might even be winding down their careers in computer science and related
fields, and would find contributing new features to the POV-Ray codebase an
enjoyable and rewarding activity.


Post a reply to this message

From: jr
Subject: Re: Windows XP compatibility
Date: 20 Jul 2021 08:10:00
Message: <web.60f6b992d5a68e3b5e0fed26cde94f1@news.povray.org>
hi,

"HKarsten" <nomail@nomail> wrote:
> Hi jr, :)
> If I would have a system, small enough, this would be an option.
> Several times I tried to virtualized my System. Sometimes the drivers are poor
> and  my 3D-Programms, like 3DS-Max, or Maya does not run properly or other
> things happened.

persist.  ;-)  VmWare definitely, and VirtualBox etc likely too, "can do".


> And I still didn't find a host-system, small enough for not being in the way.
> So: as long as my System can run natively, it turned out to be the best way.
> BTW: my 2003 is a pure offline System. It never was connected to the internet
> for even a fragment of a second, and it never will be.

good policy.  even for current systems, in some cases.


> For being connected, I an using Puppy-linux:
> distrowatch.com/table.php?distribution=puppy
>
> Its running from RAM, so if it's going to be compromised, next time booting it
> has forgotten all about it.

yes, I like (the development of) "live" distributions, they all share that
advantage.


> For my 3D-Printer the sclicer is not running on XP for example, and I have to
> use my Linux for it. It's pain in the as to do a reboot just for slicing!
>
> Having a PovRay as plain-static cygwin-exe would be the much nicer way, instead
> of rebooting the machine.

I probably misunderstand, but why then not compile that "slicer" (and or povray)
under cygwin?



regards, jr.


Post a reply to this message

From: Mr
Subject: Re: Windows XP compatibility
Date: 22 Jul 2021 09:20:00
Message: <web.60f96fadd5a68e3b16086ed03f378f2@news.povray.org>
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

From: clipka
Subject: Re: Windows XP compatibility
Date: 24 Jul 2021 13:08:43
Message: <60fc491b$1@news.povray.org>
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

From: clipka
Subject: Re: Windows XP compatibility
Date: 24 Jul 2021 13:39:15
Message: <60fc5043$1@news.povray.org>
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

From: clipka
Subject: Re: Windows XP compatibility
Date: 24 Jul 2021 13:48:16
Message: <60fc5260$1@news.povray.org>
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

<<< Previous 4 Messages Goto Latest 10 Messages Next 3 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.