[squeak-dev] Older VM's won't start the latest beta images

David T. Lewis lewis at mail.msen.com
Sat Jun 25 18:16:03 UTC 2022


On Sat, Jun 25, 2022 at 10:30:54AM -0700, Eliot Miranda wrote:
> On Sun, 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.
> >
> 
> So given that older VMs supported the bytecode set and have (as do all Cog
> VMs) a VM parameter flag bit to indicate this, what's the rationale for the
> image format number including whether the image chooses to use the bytecode
> set or not?
> 

To the best of my recollection, it's something that we all agreed on a
few years ago. The commit notice in ImageFormat-dtl.37 refers to our
oversight board meeting of 2019-05-15. You were part of that discussion.

Getting the update into the VM took longer than originally anticipated.

Dave



More information about the Squeak-dev mailing list