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.

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.