Hi andreas

You have certainly more thought about it that I. In fact, I do not care 
if the vm is named Squeak.exe or Squeak3.4.exe but not Squeak3.2.b8.

Also what I see with my wife and her school is that she have to ask a 
guy not knowing too much about computers to install Squeak. I tried to 
convince him to just use a bundle with everything inside for all the 
machines there. This was not without energy because
people like network and shared stuff putting the vm in one place and 
images in another one....

So to conclude, for me the solution is that teachers and other that do 
not have the time
to really get into it do not have Squeak3.2 VM getting executed when 
clicking on a 3.4 image if this breaks.

So I thought that having a consistent naming would be good for them.

> Nitpick: Most people new to Squeak who do not know about the 
> significance of
> the "image" will double click the executable and NOT the image. 
> Therefore it
> is mostly not the image that "looks for a file name" but rather the VM 
> (and
> I went to some length to make this work in a way that the VM will - 
> unless
> it is ambigious - find the "right" image).
>
> Secondly, even many people who do know about "images" probably do not 
> have a
> persistent association between "image" files and the executable in 
> which
> case they are likely to use DnD for starting Squeak.

I think that starting with Drag and Drop is a really secure way. One 
experienced teacher told me that....I never thought about that before.

> Only if they have an association between .image and a Squeak VM the 
> system
> will go digging for it. And here, the file name of the VM matters only
> insofar as that there are no real choices - the registry only says 
> "start
> C:\Foo\Bar\Squeak.exe when the user double clicks on an image". (so 
> there
> are no choices for *all* of the images).
>
> The latter is partly why I like naming the VM just "Squeak.exe" for 
> all but
> the most experienced Squeakers. It encourages them to think about the 
> VM as
> "essentially the same" across all versions (which is true - you can run
> everything back to Squeak 1.1 on the latest VMs) and (for the largest 
> part)
> not to worry about "uh... now this is Squeak 3.4 VM ... will this work 
> if I
> try to start Squeak3.2.image with it???"

I can agree this is much better than Squeak3.2b5... (I'm not talking 
about not public release here). Every times john makes a new version I 
like with the numbering so I can identify which one I'm working with 
(thanks for your job John;)).

stef