Mystery solved: Pharo and Unsupported 16 bit application on Windows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Mystery solved: Pharo and Unsupported 16 bit application on Windows

Torsten Bergmann
Hi,

just wanted to share this story of a Windows problem + possible cause so others could be aware:


As Pablo announced a new VM version this week I used the VMManager within PharoLauncher to update the VM executables.
Unfortunately afterwards several things got broken:

When I started a fresh Pharo 9 image from Launcher the underlying Windows OS lamented about Pharo.exe being an "Unsupported 16 Bit application ..."
leaving me with a big question mark.


So I thought there is trouble within the new VM executable. But things got even more crazy when I deleted and redownloaded even fresh Pharo 8 and Pharo 7
VMs and images using the Launcher. Same issue here - but I was totally sure that it worked before without any problem.

I was not able to start ANY Pharo.exe version on this Windows machine anymore (except Launcher itself) - which was really mysterious. Even after
reinstalling Pharo Launcher the problem did not go away.

What I found strange was that on another second Windows machine it was working perfect - same combination of Launcher and any other.
So I digged deeper in finding out.


Meanwhile I know the difference:

 - on the machine where it was not working I recently installed CYGWIN toolset to be able to compile the Pharo VM
   that means in the PATH environment I have an "unzip.exe" in d:\cygwin64\bin\unzip.exe

 - I also activated the Unix subsystem for Windows (maybe that also gives a unzip.exe)

As PharoLauncher typically checks if an unzip.exe is available and (if found) it is really using it to speed things up.
Just evaluate

    PhLVirtualMachineManager canUseSytemZip

in an PharoLauncher image. If it is not found it is using the regular "ZipArchive" class to extract - which is slower.

So it looks like when the external "unzip.exe" from Cygwin (or possibly also others) are found and used then the CI built ZIPs of
VM executables are not properly extracted and this leads to such effects of having a non-proper executable on Windows. The OS loader
then thinks it is an old unsupported 16 bit application.

Checking the version on command line for unzip exe tells me:

   UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.

When I rename that executable I found another one telling me

   GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood.

A simple workaround is to enable developer mode in PharoLauncher and switching #canUseSytemZip to return false.
Slower - but the Pharo code is more reliable here.

Just wanted to let you know in case this problem (of which I heard several times already) is still on other peoples machine
still unsolved or reappearing.

Side note:
=========
It is a little bit similar to what was found in https://github.com/pharo-project/pharo-launcher/issues/349
but a side effect of having Cygwin and other providers of unzip.exe on your machine in combination with Pharo(Launcher).


Have fun
T.



Reply | Threaded
Open this post in threaded view
|

Re: Mystery solved: Pharo and Unsupported 16 bit application on Windows

philippeback
Ah may be what happened to me....

Phil

On Wed, 4 Mar 2020, 19:52 Torsten Bergmann, <[hidden email]> wrote:
Hi,

just wanted to share this story of a Windows problem + possible cause so others could be aware:


As Pablo announced a new VM version this week I used the VMManager within PharoLauncher to update the VM executables.
Unfortunately afterwards several things got broken:

When I started a fresh Pharo 9 image from Launcher the underlying Windows OS lamented about Pharo.exe being an "Unsupported 16 Bit application ..."
leaving me with a big question mark.


So I thought there is trouble within the new VM executable. But things got even more crazy when I deleted and redownloaded even fresh Pharo 8 and Pharo 7
VMs and images using the Launcher. Same issue here - but I was totally sure that it worked before without any problem.

I was not able to start ANY Pharo.exe version on this Windows machine anymore (except Launcher itself) - which was really mysterious. Even after
reinstalling Pharo Launcher the problem did not go away.

What I found strange was that on another second Windows machine it was working perfect - same combination of Launcher and any other.
So I digged deeper in finding out.


Meanwhile I know the difference:

 - on the machine where it was not working I recently installed CYGWIN toolset to be able to compile the Pharo VM
   that means in the PATH environment I have an "unzip.exe" in d:\cygwin64\bin\unzip.exe

 - I also activated the Unix subsystem for Windows (maybe that also gives a unzip.exe)

As PharoLauncher typically checks if an unzip.exe is available and (if found) it is really using it to speed things up.
Just evaluate

    PhLVirtualMachineManager canUseSytemZip

in an PharoLauncher image. If it is not found it is using the regular "ZipArchive" class to extract - which is slower.

So it looks like when the external "unzip.exe" from Cygwin (or possibly also others) are found and used then the CI built ZIPs of
VM executables are not properly extracted and this leads to such effects of having a non-proper executable on Windows. The OS loader
then thinks it is an old unsupported 16 bit application.

Checking the version on command line for unzip exe tells me:

   UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.

When I rename that executable I found another one telling me

   GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood.

A simple workaround is to enable developer mode in PharoLauncher and switching #canUseSytemZip to return false.
Slower - but the Pharo code is more reliable here.

Just wanted to let you know in case this problem (of which I heard several times already) is still on other peoples machine
still unsolved or reappearing.

Side note:
=========
It is a little bit similar to what was found in https://github.com/pharo-project/pharo-launcher/issues/349
but a side effect of having Cygwin and other providers of unzip.exe on your machine in combination with Pharo(Launcher).


Have fun
T.



Reply | Threaded
Open this post in threaded view
|

Re: Mystery solved: Pharo and Unsupported 16 bit application on Windows

ducasse
In reply to this post by Torsten Bergmann
Thanks for your analysis.



> On 4 Mar 2020, at 19:51, Torsten Bergmann <[hidden email]> wrote:
>
> Hi,
>
> just wanted to share this story of a Windows problem + possible cause so others could be aware:
>
>
> As Pablo announced a new VM version this week I used the VMManager within PharoLauncher to update the VM executables.
> Unfortunately afterwards several things got broken:
>
> When I started a fresh Pharo 9 image from Launcher the underlying Windows OS lamented about Pharo.exe being an "Unsupported 16 Bit application ..."
> leaving me with a big question mark.
>
>
> So I thought there is trouble within the new VM executable. But things got even more crazy when I deleted and redownloaded even fresh Pharo 8 and Pharo 7
> VMs and images using the Launcher. Same issue here - but I was totally sure that it worked before without any problem.
>
> I was not able to start ANY Pharo.exe version on this Windows machine anymore (except Launcher itself) - which was really mysterious. Even after
> reinstalling Pharo Launcher the problem did not go away.
>
> What I found strange was that on another second Windows machine it was working perfect - same combination of Launcher and any other.
> So I digged deeper in finding out.
>
>
> Meanwhile I know the difference:
>
> - on the machine where it was not working I recently installed CYGWIN toolset to be able to compile the Pharo VM
>   that means in the PATH environment I have an "unzip.exe" in d:\cygwin64\bin\unzip.exe
>
> - I also activated the Unix subsystem for Windows (maybe that also gives a unzip.exe)
>
> As PharoLauncher typically checks if an unzip.exe is available and (if found) it is really using it to speed things up.
> Just evaluate
>
>    PhLVirtualMachineManager canUseSytemZip
>
> in an PharoLauncher image. If it is not found it is using the regular "ZipArchive" class to extract - which is slower.
>
> So it looks like when the external "unzip.exe" from Cygwin (or possibly also others) are found and used then the CI built ZIPs of
> VM executables are not properly extracted and this leads to such effects of having a non-proper executable on Windows. The OS loader
> then thinks it is an old unsupported 16 bit application.
>
> Checking the version on command line for unzip exe tells me:
>
>   UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.
>
> When I rename that executable I found another one telling me
>
>   GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood.
>
> A simple workaround is to enable developer mode in PharoLauncher and switching #canUseSytemZip to return false.
> Slower - but the Pharo code is more reliable here.
>
> Just wanted to let you know in case this problem (of which I heard several times already) is still on other peoples machine
> still unsolved or reappearing.
>
> Side note:
> =========
> It is a little bit similar to what was found in https://github.com/pharo-project/pharo-launcher/issues/349
> but a side effect of having Cygwin and other providers of unzip.exe on your machine in combination with Pharo(Launcher).
>
>
> Have fun
> T.
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Mystery solved: Pharo and Unsupported 16 bit application on Windows

tesonep@gmail.com
In reply to this post by Torsten Bergmann
Thanks for the analysis. It was a really complicated issue.

Maybe we need to add validation of the unzip files or a correct detection of the unzip to use. 

Thanks again. 

On Wed, Mar 4, 2020, 19:52 Torsten Bergmann <[hidden email]> wrote:
Hi,

just wanted to share this story of a Windows problem + possible cause so others could be aware:


As Pablo announced a new VM version this week I used the VMManager within PharoLauncher to update the VM executables.
Unfortunately afterwards several things got broken:

When I started a fresh Pharo 9 image from Launcher the underlying Windows OS lamented about Pharo.exe being an "Unsupported 16 Bit application ..."
leaving me with a big question mark.


So I thought there is trouble within the new VM executable. But things got even more crazy when I deleted and redownloaded even fresh Pharo 8 and Pharo 7
VMs and images using the Launcher. Same issue here - but I was totally sure that it worked before without any problem.

I was not able to start ANY Pharo.exe version on this Windows machine anymore (except Launcher itself) - which was really mysterious. Even after
reinstalling Pharo Launcher the problem did not go away.

What I found strange was that on another second Windows machine it was working perfect - same combination of Launcher and any other.
So I digged deeper in finding out.


Meanwhile I know the difference:

 - on the machine where it was not working I recently installed CYGWIN toolset to be able to compile the Pharo VM
   that means in the PATH environment I have an "unzip.exe" in d:\cygwin64\bin\unzip.exe

 - I also activated the Unix subsystem for Windows (maybe that also gives a unzip.exe)

As PharoLauncher typically checks if an unzip.exe is available and (if found) it is really using it to speed things up.
Just evaluate

    PhLVirtualMachineManager canUseSytemZip

in an PharoLauncher image. If it is not found it is using the regular "ZipArchive" class to extract - which is slower.

So it looks like when the external "unzip.exe" from Cygwin (or possibly also others) are found and used then the CI built ZIPs of
VM executables are not properly extracted and this leads to such effects of having a non-proper executable on Windows. The OS loader
then thinks it is an old unsupported 16 bit application.

Checking the version on command line for unzip exe tells me:

   UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.

When I rename that executable I found another one telling me

   GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood.

A simple workaround is to enable developer mode in PharoLauncher and switching #canUseSytemZip to return false.
Slower - but the Pharo code is more reliable here.

Just wanted to let you know in case this problem (of which I heard several times already) is still on other peoples machine
still unsolved or reappearing.

Side note:
=========
It is a little bit similar to what was found in https://github.com/pharo-project/pharo-launcher/issues/349
but a side effect of having Cygwin and other providers of unzip.exe on your machine in combination with Pharo(Launcher).


Have fun
T.



Reply | Threaded
Open this post in threaded view
|

Re: Mystery solved: Pharo and Unsupported 16 bit application on Windows

ducasse
would it not be better to use the zip library of pharo?
And to fix it if it does not fully work?

S

On 5 Mar 2020, at 09:17, [hidden email] wrote:

Thanks for the analysis. It was a really complicated issue.

Maybe we need to add validation of the unzip files or a correct detection of the unzip to use. 

Thanks again. 

On Wed, Mar 4, 2020, 19:52 Torsten Bergmann <[hidden email]> wrote:
Hi,

just wanted to share this story of a Windows problem + possible cause so others could be aware:


As Pablo announced a new VM version this week I used the VMManager within PharoLauncher to update the VM executables.
Unfortunately afterwards several things got broken:

When I started a fresh Pharo 9 image from Launcher the underlying Windows OS lamented about Pharo.exe being an "Unsupported 16 Bit application ..."
leaving me with a big question mark.


So I thought there is trouble within the new VM executable. But things got even more crazy when I deleted and redownloaded even fresh Pharo 8 and Pharo 7
VMs and images using the Launcher. Same issue here - but I was totally sure that it worked before without any problem.

I was not able to start ANY Pharo.exe version on this Windows machine anymore (except Launcher itself) - which was really mysterious. Even after
reinstalling Pharo Launcher the problem did not go away.

What I found strange was that on another second Windows machine it was working perfect - same combination of Launcher and any other.
So I digged deeper in finding out.


Meanwhile I know the difference:

 - on the machine where it was not working I recently installed CYGWIN toolset to be able to compile the Pharo VM
   that means in the PATH environment I have an "unzip.exe" in d:\cygwin64\bin\unzip.exe

 - I also activated the Unix subsystem for Windows (maybe that also gives a unzip.exe)

As PharoLauncher typically checks if an unzip.exe is available and (if found) it is really using it to speed things up.
Just evaluate

    PhLVirtualMachineManager canUseSytemZip

in an PharoLauncher image. If it is not found it is using the regular "ZipArchive" class to extract - which is slower.

So it looks like when the external "unzip.exe" from Cygwin (or possibly also others) are found and used then the CI built ZIPs of
VM executables are not properly extracted and this leads to such effects of having a non-proper executable on Windows. The OS loader
then thinks it is an old unsupported 16 bit application.

Checking the version on command line for unzip exe tells me:

   UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.

When I rename that executable I found another one telling me

   GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood.

A simple workaround is to enable developer mode in PharoLauncher and switching #canUseSytemZip to return false.
Slower - but the Pharo code is more reliable here.

Just wanted to let you know in case this problem (of which I heard several times already) is still on other peoples machine
still unsolved or reappearing.

Side note:
=========
It is a little bit similar to what was found in https://github.com/pharo-project/pharo-launcher/issues/349
but a side effect of having Cygwin and other providers of unzip.exe on your machine in combination with Pharo(Launcher).


Have fun
T.