Thanks for your analysis.
> On 4 Mar 2020, at 19:51, Torsten Bergmann <[email protected]> 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. > > >
