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 <j...@darrington.wattle.id.au> Gesendet: Dienstag, 31. August 2021 16:16 An: Quandt, Markus <markus.qua...@gesis.org> Cc: Julia Klausli, Ph.D. <jklausli....@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.