Re: PSPP-BUG: Problem running Version pspp-20200905-daily-64bit

[Harry Thijssen]

Hi Peter

Op vr 19 feb. 2021 om 15:19 schreef Peter Jauernig <peter.jauernig@chello.at>:

Hi Harry,

thank you for showing up. When you say you have stopped building new versions for windows, does this mean that from now on there will be no windows builds until someone else catches up?

Unfortunately I guess that is correct.

Meaning, is there still somebody I can talk to with regard to my findings?

You can do it in the bug-gnu-pspp forum.  Maybe somebody is able to figure out how to make new MSWindows build.

 

Best regards,

Peter

Stay safe 

On 18 Feb 2021 at 19:30, Harry Thijssen wrote:

Hi Peter

For MSWindows7 use the 32 bits version of PSPP4Windows. This version works on 32 and 64 bits MSWindows versions as far as I know. 

As Friedrich pointed out, the modules used are provided by other parties. I have no control how they do it and I doubt they will change them as MSWindows 7 is end-of-live for over a year now. For the time being I  see little drawbacks for you to use the 32 bits version on a 64 bits MSWindows 7.

As PSPP is no longer compatible with my build procedures, I am not able to build new versions.  If somebody else starts building, maybe he/she can solve the problem for running the 64 bit version on MSWindows 7 too.

Stay safe

Op do 18 feb. 2021 om 14:15 schreef Friedrich Beckmann < friedrich.beckmann@gmx.de >:

Hi Peter,

thanks for digging into this. Harry does the windows builds. The windows builds are crosscompiled with a Suse build system. All the build dependencies are managed via mingw packages:

https://github.com/fredowski/pspp-buildbot/blob/master/prepare_win.sh

I do not know how the libraries you mention are handled but there has been a discussion and it is known that there is a problem with windows 7 and 64/32 Bit.

Thanks

Friedrich


> Am 18.02.2021 um 13:13 schrieb Peter via Bug-gnu-pspp <bug-gnu-pspp@gnu.org >:
>
> Hello Friedrich,
>
> thanks for answering.
>
> Meanwhile I found out that the reason for this might have to do with what Microsoft says about the use of "ScriptIsComplex" routine:
> 
> https://docs.microsoft.com/en-us/windows/win32/api/usp10/nf-usp10-scriptiscomplex
>
> According to them the ScriptIsComplex function determines whether a Unicode string requires complex script processing.
>
> And it is IMPORTANT to know that in order to maintain the ability to run on
> Windows 7, a module that uses Uniscribe must specify Usp10.lib before
> gdi32.lib in its library list.
>
> So it seems to me to be a problem that can be solved by the people who "build" the windows version of PSPP. They seem to make the build from a system later than Windows-7 and so never came across this "bug".
>
> How can I reach out to those people? Do they read this bug-tracker?
>
> Many thanks
> Peter
>
> PS: I am new to the use of bug-gnu-pspp. I just replied to your post by using the "reply via email to" - button on the webpage. Since I would like this email to be posted on the web too I put bug-gnu-pspp@gnu.org in the CC-field. Am I doing this right?