Hi Dave, Hi Jaromir,

> On May 29, 2022, at 7:03 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> On Sun, May 29, 2022 at 08:06:59AM +0000, Jaromir Matas wrote:
>> Hi,
>> I wonder what?s changed that the images starting from Squeak6.0beta-21772-64bit on won?t start with the previous release VM (squeak.cog.spur_win64x64_202003021730) or even with pre-release new VMs (e.g. version 3154).
>> 
>> I?m on Win10, the process explorer (windows) shortly runs WerFault.exe and than the Squeak process is closed/disappears.
>> 
> 
> The change is here:
> 
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-May/220660.html
> 
> The current release candidate image does not have this, but it will be
> applied as soon as you update that image, and it expected to be part of
> the final release. The update applies a new image format number to the
> saved image files (stored in the first 4 bytes of the image file) when
> multiple bytecode set support is required from the VM. Effectively, the
> means that the image is using the Sista bytecode set. Older VMs can
> run the Sista bytecodes but do not yet have the code for recognizing
> the additional image format number.
> 
> Dave

I don’t think that’s the reason.  Older VMs have supported the Sista bytecode set fir several years.  However, older VMs lack the new suspend primitives.  These have only been in the vm for about three months.

Jaromir, you should be able to run the vm turning on the send trace and see where an image starts to crap out.  See the -trace argument.  The documentation on the flag bits is (alas) in a VMMaker.oscog method on Cogit. (This I should fix)

Eliot,
_,,,^..^,,,_ (phone)