Mystery solved: Pharo and Unsupported 16 bit application on Windows
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.
Ah may be what happened to me.... Phil On Wed, 4 Mar 2020, 19:52 Torsten Bergmann, <astares@gmx.de> 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.
Thanks for your analysis.
On 4 Mar 2020, at 19:51, Torsten Bergmann <astares@gmx.de> 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.
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 <astares@gmx.de> 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.
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, tesonep@gmail.com 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 <astares@gmx.de <mailto:astares@gmx.de>> 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 <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.
participants (4)
-
ducasse -
phil＠highoctane.be -
tesonep＠gmail.com -
Torsten Bergmann