Smalltalk › Cincom › VisualWorks

$(VISUALWORKS) for multiple versions in Windows

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

askoh

$(VISUALWORKS) for multiple versions in Windows

Administrator

Hi:

I run VW7.8 and VW7.9. How can I set $(VISUALWORKS) to be correct for each version everytime I start the various images in Windows? I don't want to manually check everytime I switch versions.

Thanks in advance,
Aik-Siong Koh

Boris Popov, DeepCove Labs (SNN)

Re: $(VISUALWORKS) for multiple versions in Windows

You don't need to, it uses Windows registry not environment variable to store individual settings for each version.

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of askoh
Sent: Friday, July 26, 2013 3:59 PM
To: [hidden email]
Subject: [vwnc] $(VISUALWORKS) for multiple versions in Windows

Hi:

I run VW7.8 and VW7.9. How can I set $(VISUALWORKS) to be correct for each version everytime I start the various images in Windows? I don't want to manually check everytime I switch versions.

Thanks in advance,
Aik-Siong Koh

--
View this message in context: http://forum.world.st/VISUALWORKS-for-multiple-versions-in-Windows-tp4700989.html
Sent from the VisualWorks mailing list archive at Nabble.com.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Holger Guhl

Re: $(VISUALWORKS) for multiple versions in Windows

Yes, Boris is correct.
The VisualWorks installer adds the required registry entries. When it comes to evaluate
$(VisualWorks), a system variable resolution is started which inquires the environment but also
makes a Windows Registry lookup with keys that are unique for each image version.
Note: If you ever use the VisualWorks Settings tool and on page "System" you change the path at
"VisualWorks home directory", the image writes that value into the Windows Registry at the key for
the image version. So it is not a local effect. You change it for EVERY image of that version. That
is correct only if you moved your installation to another path.

For starting a VisualWorks image you may want to add a file type association "*.im" to
"VisualWorks.exe". Once you do that, Windows always runs VisualWorks.exe (in the path that you
specify for the association) when double-clicking on an image file. VisualWorks.exe reads the
configuration file VisualWorks.ini (in the same path, so make sure to always keep the file in this
path up-to-date after installing new VW versions). This file holds a dispatch table where the key is
the verson specific image header and the value is the concrete executable path of the virtual
machine that matches the header.

- Holger

Am 26.07.2013 19:47, schrieb Boris Popov, DeepCove Labs:

> You don't need to, it uses Windows registry not environment variable to store individual settings for each version.
>
> -Boris
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of askoh
> Sent: Friday, July 26, 2013 3:59 PM
> To: [hidden email]
> Subject: [vwnc] $(VISUALWORKS) for multiple versions in Windows
>
> Hi:
>
> I run VW7.8 and VW7.9. How can I set $(VISUALWORKS) to be correct for each version everytime I start the various images in Windows? I don't want to manually check everytime I switch versions.
>
> Thanks in advance,
> Aik-Siong Koh
>
>
>
> --
> View this message in context: http://forum.world.st/VISUALWORKS-for-multiple-versions-in-Windows-tp4700989.html
> Sent from the VisualWorks mailing list archive at Nabble.com.
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Maarten Mostert-2

Re: $(VISUALWORKS) for multiple versions in Windows

In reply to this post by Boris Popov, DeepCove Labs (SNN)

Its a cool thing, however the problem is that the VM does this also when in runtime mode, which is not really in compliance with Windows certification rules.
Does any one know how to avoid the VM from doing this ?

Regards,

@+Maarten,

Le 26 juil. 2013 à 19:47, "Boris Popov, DeepCove Labs" <[hidden email]> a écrit :

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Andres Valloud-6

Re: $(VISUALWORKS) for multiple versions in Windows

What is *the VM* allegedly doing?

On 7/26/13 1:34 PM, Maarten Mostert wrote:

> Its a cool thing, however the problem is that the VM does this also when in runtime mode, which is not really in compliance with Windows certification rules.
> Does any one know how to avoid the VM from doing this ?
>
> Regards,
>
> @+Maarten,
>
>
> Le 26 juil. 2013 à 19:47, "Boris Popov, DeepCove Labs" <[hidden email]> a écrit :
>
>> You don't need to, it uses Windows registry not environment variable to store individual settings for each version.
>>
>> -Boris
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On Behalf Of askoh
>> Sent: Friday, July 26, 2013 3:59 PM
>> To: [hidden email]
>> Subject: [vwnc] $(VISUALWORKS) for multiple versions in Windows
>>
>> Hi:
>>
>> I run VW7.8 and VW7.9. How can I set $(VISUALWORKS) to be correct for each version everytime I start the various images in Windows? I don't want to manually check everytime I switch versions.
>>
>> Thanks in advance,
>> Aik-Siong Koh
>>
>>
>>
>> --
>> View this message in context: http://forum.world.st/VISUALWORKS-for-multiple-versions-in-Windows-tp4700989.html
>> Sent from the VisualWorks mailing list archive at Nabble.com.
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Niall Ross

Re: $(VISUALWORKS) for multiple versions in Windows

In reply to this post by askoh

Dear Koh and Marten,
the VisualWorks installer, when running on Windows, writes a
VISUALWORKS key to the registry for each release. The first path tried is

HKEY_LOCAL_MACHINE\SOFTWARE\Cincom Systems, Inc.\VisualWorks

to set a value for all users, but if it lacks permissions to write
there, it will instead write to

HKEY_CURRENT_USER\SOFTWARE\Cincom Systems, Inc.\VisualWorks

to set a value for the installing (non-admin) user. Thus if you install
vw7.10 on a 32-bit machine and have or grant admin permissions, then you
will see key VISUALWORKS inside

HKEY_LOCAL_MACHINE\SOFTWARE\Cincom Systems, Inc.\VisualWorks\7.10

pointing at wherever you told the installer to put the vw7.10 installation.

If you are on a 64-bit machine and have or grant admin permissions, the
7.10 installer will set keys in both the main and the redirect-to-32
locations, so you will also see a copy of the above key inside
SysWOW6432. Earlier installers only wrote to the area of their
bit-type: the standard 7.9.1 or earlier installer wrote to the 32-bit
area only, and if you ran the install64.im from 7.9.1 or earlier by
hand, it would write to the 64-bit area only.

If the installer cannot aquire admin permissions, a single VISUALWORKS
key is written within the HKEY_CURRENT_USER area, and both 32 and 64
images of the installing user see that user's personal key.

This key determines the value of the VisualWorks home setting when an
image of a given release is opened. That in turn controls where it will
look for parcels to load, etc.

VM assignment is quite separate from all this. If you have bound a
VisualWorks.exe to the .im filetype then double-clicking on any .im file
makes the VisualWorks.exe look in its colocated VisualWorks.ini file.
It matches image signature bytes to a line in the file to find the VM it
uses to launch the image.

In the latest installers, this file is edited during install to point at
the containing location of where you installed, and it is writable. In
earlier installers, it had hardcoded values like

77 00 c:\Program Files\Cincom\...

and was installed read-only, so you had to make it writable and edit it
to point at any other locations where you might have installed your
various versions of VisualWorks.

Be aware that the
Open with: .... Change
button in the properties dialog of a .im file is useless to rebind to
another VisualWorks.exe. Some idiot Windows programmer made this tool
silently do nothing if the old and new program names are the same,
regardless of whether the old and new programs' containing folders
differ. If you want to make double-clicking on .im files stop launching
e.g.
...\vw7.8.1\bin\win\VisualWorks.exe
and start launching
...\vw7.10\bin\win\VisualWorks.exe
you must open the file type dialog and and edit the pathname in the text
line.

The current bin/win/VisualWorks.exe matches two bytes only. This is
adequate to distinguish VisualWorks releases, but it means that people
in the vw-dev program can find it tricky to make an image in their
installation of the latest dev build launch that dev build's VM instead
of the prior release' VM (this can limit how well their testing helps
us). In
vw7.10\preview\bin
there is VisualWorks-1.15.exe which matches the 4-byte codes listed in
colocated VisualWorks-1.15.ini. Comments in the ini file indicate how
to arrange things so double-clicking launches dev and main release
images with dev and main release VMs.

A. S. Koh wrote:

>I run VW7.8 and VW7.9. How can I set $(VISUALWORKS) to be correct for each
>version everytime I start the various images in Windows? I don't want to
>manually check everytime I switch versions.
>
>
I trust the above answers the question.

Maarten Mostert wrote:
> the VM does this also when in runtime mode, which is
> not really in compliance with Windows certification rules.
> Does any one know how to avoid the VM from doing this ?

Users without admin permissions, and users wanting to have multiple
installations of the same release on their machine, need to be able to
(re)set whichever key they can alter without rerunning the installer.
Doing this carelessly can sometimes allow confusion - believe me, as
developers who routinely have several build installations of a given
release on our machines, we know that. However we feel lack of the
facility would be much worse.

HTH
Niall Ross

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Maarten Mostert-2

Re: $(VISUALWORKS) for multiple versions in Windows

Dear Nial,
Last week I had a vanilla Windows 8 machine on hand.
I first downloaded my (7.8.1 based) application run the installer NSIS no problem.
I then installed dropbox and synced my stuff including my Mac's VW7.9.1 directory.
Didn't run the VW installer I just double clicked the image and indicated the executable.
Run OK but not with the right sources directory.
Then I searched the registry for cincom and found the things you pointed out for both 7.8.1 and the 7.9.1.
I then corrected the registry for 7.9.1 to be in accordance with settings and all worked fine.

No who the hell has been playing with my Windows Registry if it isn't the VM, or the installer ?

Are we sure that there are not some Cincoms goblins out here that do such things ?

The cool thing obviously is that I can sync my VW stuff from my Mac to my Window platforms over dropbox with the only constraint to close my work before taking it on elsewhere.

@+Maarten,

Le 27 juil. 2013 à 19:39, Niall Ross <[hidden email]> a écrit :

> Dear Koh and Marten,
> the VisualWorks installer, when running on Windows, writes a VISUALWORKS key to the registry for each release. The first path tried is
>
> HKEY_LOCAL_MACHINE\SOFTWARE\Cincom Systems, Inc.\VisualWorks
>
> to set a value for all users, but if it lacks permissions to write there, it will instead write to
>
> HKEY_CURRENT_USER\SOFTWARE\Cincom Systems, Inc.\VisualWorks
>
> to set a value for the installing (non-admin) user. Thus if you install vw7.10 on a 32-bit machine and have or grant admin permissions, then you will see key VISUALWORKS inside
>
> HKEY_LOCAL_MACHINE\SOFTWARE\Cincom Systems, Inc.\VisualWorks\7.10
>
> pointing at wherever you told the installer to put the vw7.10 installation.
>
> If you are on a 64-bit machine and have or grant admin permissions, the 7.10 installer will set keys in both the main and the redirect-to-32 locations, so you will also see a copy of the above key inside SysWOW6432. Earlier installers only wrote to the area of their bit-type: the standard 7.9.1 or earlier installer wrote to the 32-bit area only, and if you ran the install64.im from 7.9.1 or earlier by hand, it would write to the 64-bit area only.
>
> If the installer cannot aquire admin permissions, a single VISUALWORKS key is written within the HKEY_CURRENT_USER area, and both 32 and 64 images of the installing user see that user's personal key.
>
> This key determines the value of the VisualWorks home setting when an image of a given release is opened. That in turn controls where it will look for parcels to load, etc.
>
> VM assignment is quite separate from all this. If you have bound a VisualWorks.exe to the .im filetype then double-clicking on any .im file makes the VisualWorks.exe look in its colocated VisualWorks.ini file. It matches image signature bytes to a line in the file to find the VM it uses to launch the image.
>
> In the latest installers, this file is edited during install to point at the containing location of where you installed, and it is writable. In earlier installers, it had hardcoded values like
>
> 77 00 c:\Program Files\Cincom\...
>
> and was installed read-only, so you had to make it writable and edit it to point at any other locations where you might have installed your various versions of VisualWorks.
>
> Be aware that the
> Open with: .... Change
> button in the properties dialog of a .im file is useless to rebind to another VisualWorks.exe. Some idiot Windows programmer made this tool silently do nothing if the old and new program names are the same, regardless of whether the old and new programs' containing folders differ. If you want to make double-clicking on .im files stop launching e.g.
> ...\vw7.8.1\bin\win\VisualWorks.exe
> and start launching
> ...\vw7.10\bin\win\VisualWorks.exe
> you must open the file type dialog and and edit the pathname in the text line.
>
> The current bin/win/VisualWorks.exe matches two bytes only. This is adequate to distinguish VisualWorks releases, but it means that people in the vw-dev program can find it tricky to make an image in their installation of the latest dev build launch that dev build's VM instead of the prior release' VM (this can limit how well their testing helps us). In
> vw7.10\preview\bin
> there is VisualWorks-1.15.exe which matches the 4-byte codes listed in colocated VisualWorks-1.15.ini. Comments in the ini file indicate how to arrange things so double-clicking launches dev and main release images with dev and main release VMs.
>
> A. S. Koh wrote:
>
>> I run VW7.8 and VW7.9. How can I set $(VISUALWORKS) to be correct for each
>> version everytime I start the various images in Windows? I don't want to
>> manually check everytime I switch versions.
>>
> I trust the above answers the question.
>
> Maarten Mostert wrote:
> > the VM does this also when in runtime mode, which is
> > not really in compliance with Windows certification rules.
> > Does any one know how to avoid the VM from doing this ?
>
> Users without admin permissions, and users wanting to have multiple installations of the same release on their machine, need to be able to (re)set whichever key they can alter without rerunning the installer. Doing this carelessly can sometimes allow confusion - believe me, as developers who routinely have several build installations of a given release on our machines, we know that. However we feel lack of the facility would be much worse.
>
> HTH
> Niall Ross
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc