AW: no more PSPP for Windows?

[Quandt, Markus]

John, thanks a lot for the detailed response, this is appreciated. I appreciate 
even more the work put into PSPP, and didn't intend to criticize the state of 
things, nor the decision not to invest more time into maintaining the Windows 
builds. I was just asking because I don't have the skills to easily do the 
build myself. 

If it were a practical option for me, I would indeed have switched to a Linux 
platform long ago, but as these things go, my employer only supports Windows 
clients...

Cheers, M.

PS: If anyone with the right skill set finds this exchange motivating to look 
into becoming the new maintainer for the Windows PSPP binaries business: be 
assured of my gratitude 😊.

-----Ursprüngliche Nachricht-----
Von: John Darrington <john@darrington.wattle.id.au> 
Gesendet: Dienstag, 31. August 2021 16:16
An: Quandt, Markus <Markus.Quandt@gesis.org>
Cc: Julia Klausli, Ph.D. <jklausli.ips@divinemercy.edu>; pspp-users@gnu.org
Betreff: Re: no more PSPP for Windows?

On Tue, Aug 31, 2021 at 01:17:22PM +0000, Quandt, Markus wrote:

  It has in my experience a nasty problem with the Windows output interface 
sometimes being very unresponsive, if you produce large outputs, but works fine 
for most every-day analyses and teaching, I would say. All Windows versions I 
ever used had the same problem, by the way, IIRC.


Any operation on PSPP which takes a long time is going to make the GUI 
unresponsive for the time it takes to complete.  For example, processing a very 
large number of cases, or generating very large ouput.

From time to time we get requests to "fix" this.  Whilst might be possible to 
provide a fix which would allow the GUI to remain responsive whilst processing, 
the following caveats would still apply:

1. Until the procedure has completed, it would still not be possible to start 
any new procedure.

2. Allowing the GUI to respond, would slow down the total time it takes for the 
procedure to complete.

3. Such a change would not be simple and would take a lot of developer time.

For these reasons, such a fix has not been considered high priority.
Having said that, if anybody wishes to contribute such a fix then it'll 
probably be accepted.

Also, although the problem exists on all systems (not only Windows) PSPP runs 
magnitudes faster on GNU/Linux than on Windows, so I would suggest that you try 
that instead.


     
  This being said, I was wondering myself whether there is a perspective for 
the pre-compiled Windows versions being brought up to date again. There 
definitely are some fixes and features missing in the Windows version by now.

Harry (who used to provide the Windows builds) has said that he doesn't intend 
to do this any more.  However, I think his last build includes the the most 
recent release 1.4.1  - any changes after that are not released, and like any 
unreleased software you should think twice before using it.

So far as whether any pre-compiled Windows binaries will be made publically 
available depends on whether anyone volunteers to do the job.  Performing the 
builds is not too onerous, but maintaining such a public service is harder than 
one might imagine.  For a start, it is not just a build for "Windows".
Today there is Windows7, Windows10, WindowsCE ... then for each variant of 
Windows there is today not only intel architectures to consider, but i386, AMD, 
ARM and possibly others.  Then Harry found there was demand for debug and non 
debug versions...  So that's 3 x 3 x 2 = 18 different binaries for each release.

At the end of the day, if you want a pre-compiled binary, it is far easier to 
let OS vendor do it for you.  However, whereas most vendors are happy to 
include PSPP in their distribution (see https://pkgs.org/download/pspp) I 
suspect that if you wrote to Microsoft asking "Please include PSPP in the next 
release of Windows" you probably would not receive a reply.

PSPP is a GNU project, and so supporting the GNU system comes first.  Other 
free systems come second, and non-free systems such as Windows have the lowest 
priority.