On 26 March 2018 at 21:56, Christophe Demarey <christophe.demarey@inria.fr> wrote:

Hi Ben,

Le 23 mars 2018 �� 04:31, Ben Coman <btc@openinworld.com> a ��crit :

P.S.�� I was going to suggest also renaming�� Pharo.exe�� to�� PharoLauncher.exe
but with an empty Documents\Pharo\vms
I get... "Error: Cannot detect Pharo executable in C:\Temp\MyPharoLauncher\PharoLauncher"
in PhLVirtualMachine>>initializeOn:��"File @ C:\Temp\MyPharoLauncher\PharoLauncher"
since "executables := aFolder allChildrenMatching: self class executableName."
is empty since "self class executableName" ==> "Pharo.exe"

It would be nice for that to not be hard coded.

Where would you put this information?

I was thinking the filter could be broader with a wildcard match " *.exe ".

There shouldn't be too many exe files in the folder,��

and any non-Pharo-exe should just fail to match the VM magic numbers

and not affect anything anyway.

On the other hand, perhaps this would cause the user's Image to show up in Task Manager

as being run by PharoLauncher rather than Pharo, which again blurs the line between

the two that I'd like to avoid.�� So I'll back away from that idea.

��

�� I tried digging further but ran out of time.
I am curious it mattered since using "Pharo.exe" the Launcher went on to download a VM anyway.

I use the vm shipped with the launcher when possible (e.g. to determine pharo images version format or run current stable images.
If I cannot find the proper vm, then I download it from files.pharo.org.

P.S.2.
I believe the best path forward for system-wide PharoLauncher installed under "C:\Program Files"
would be to install there only...
* the VM��
*��PharoLauncher.ZIP��
* a tiny non-Pharo wrapper program as the shortcut linked from AllUsers > Start Menu > PharoLauncher��
that extracts PharoLauncher.ZIP to the user's data area and then starts that user specific PharoLauncher.��

Then regardless whether:
* they individually download/extract��PharoLauncher.ZIP
* the system-wide-wrapper��extracts��PharoLauncher.ZIP
its a similar experience for users��which should aid reliability by reducing the number of "different " use cases.

I now install PharoLauncher in user LOCALAPPDATA folder on windows.
Does it solve the issue for you?

Christophe

Using my day-to-day account "Ben" which is a Standard User account, I did the following...

1. Downloaded�� "pharo-launcher-installer-bleedingEdge-2018.03.23-x86.exe"

2. Double-clicked it and got "Windows Defender SmartScreen prevented an unrecognized app from starting." [1]

(btw, I didn't get this with the msi-installer generated from Advanced Installer which I linked above.�� But maybe that was because the msi-installer was created and installed on the same PC, so it was just trusting itself by default.�� The msi wasn't signed, so is the experience different on other people's machine?)

3. Clicked "More Info" which allowed me to click "Run Anyway" and got...

�� "To continue, enter admin user name and password" [2]

so this is not really suited to students doing a user-level install on locked down lab machines.

4. After entering the password for user "Admin" (i.e. not Administrator, just another account in Administrators group)

the install location was (as expected) given as....��

�� "C:\Users\Admin\AppData\Local\PharoLauncher" [3]

which again is not friendly to non-admin users.��

But just for kicks, I changed the install location to...��

�� "C:\Users\Ben\AppData\Local\PharoLauncher"

and clicking on the PharoLauncher icon in the Start Menu

it opened okay, and downloaded a 60539 image and associated VM

and that image ran okay.

So its a step in the right direction, however...

the Start Menu shortcut entry is for All User per its location here...

�� C:\ProgramData\Microsoft\Windows\Start Menu\Programs\PharoLauncher

and the target of the shortcut is...��

�� C:\Users\Ben\AppData\Local\PharoLauncher\Pharo.exe

so it only worked coincidentally because I'm clicking the Start Menu icon as user "Ben"

and it would be broken for a second Standard User.

From my reading it will be a struggle to get NSIS working smoothly

for multiple��use cases��at different privilege levels. i.e. both non-admin and admin users.

cheers -ben