On Mon, Dec 18, 2017 at 04:50:29PM -0500, Phil B wrote:
> Dave,
> 
> I have been trying using a built classic VM (which works fine with 3.x
> images but hangs on startup on every 1.x or 2.x image I've tried).  I last
> built it from sources a year ago or more so I'll try downloading the latest
> sources and try again.

Yes please try it again. The enhancements to support older images with the
classic VM were done in January 2017.

> 
> It would be great to have this as an option for old images as the shipped
> VMs from that time period seem have an annoying transparent window issue on
> recent Linux distros so unless I put a black window behind the Squeak
> window, it's very difficult to see what's going on (screenshot attached to
> illustrate.).  Should anyone recalling the specifics of the VM builds back
> then be reading: is this because true color depths weren't common back then
> or is something else going on?
> 

The change history is in http://source.squeak.org/VMMaker in package 'VMMaker',
so you can browse the history with a Monticello browser.

The recent updates that pertain to older image support are:

===

Name: VMMaker-dtl.392
Author: dtl
Time: 12 January 2017, 8:34:22.25 pm
UUID: 7c31d31d-9de0-4f45-89e2-6caa1886f12f
Ancestors: VMMaker-dtl.391

VMMaker 4.16.3

Support very early images in which method context copy fails due to stack
pointer not yet adjusted to position. For these images, disable stack limit
bounds check. Based on SqueakJS implementation as described below.

From: Bert Freudenberg <bert at freudenbergs.de>
Date: Wed, 11 Jan 2017 17:10:24 +0100
To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Backward image and VM compatibility

Some early images fill the context stack before advancing its stack pointer.
I have a flag to allow that, it's pretty certainly used in primitive 61.
Normally the VM does not allow access beyond the SP because there is garbage
there (stack pops do not nil out the context slot):

https://github.com/bertfreudenberg/SqueakJS/search?q=allowAccessBeyondSP

But since the regular VM does not allow it, no image (except the really old
ones) ever does it, so I just leave the flag enabled whenever "oldPrims" is
in effect ;) Would be better if we could come up with a better way to identify
these images.

===

Name: VMMaker-dtl.391
Author: dtl
Time: 5 January 2017, 7:35:14.1 pm
UUID: eb3fd060-b323-4a7d-9b06-b4b23f599fc8
Ancestors: VMMaker-dtl.390

VMMaker 4.16.2

Old image support: Rescue five sound primitive assignments for updatePrimitiveTable
for primitives that should be loaded from SouondGenerationPlugin, not from SoundPlugin.

The following ancient primitives are still not loadable into the primitiive
table for old image support:

  #primWaveTableSoundmixSampleCountintostartingAtpan
  #primFMSoundmixSampleCountintostartingAtpan
  #primPluckedSoundmixSampleCountintostartingAtpan
  #primSampledSoundmixSampleCountintostartingAtpan
  #oldprimSampledSoundmixSampleCountintostartingAtleftVolrightVol

In addition #primitiveReadJoystick does not load from JoystickTabletPlugin
when running on Linux, but this is confirmed to be an artifact of the function
loader, which abandons the attempt to load a module if #initialiseModule
answers false, as is the case in the Unix stub code implementation (so it
should work on platforms that do support the joystick plugin).

===

Name: VMMaker-dtl.390
Author: dtl
Time: 2 January 2017, 8:52:00.539 pm
UUID: 1fb628a6-18d2-4d86-b651-dc3b3d0cce69
Ancestors: VMMaker-dtl.389

VMMaker 4.16.1 - Support older Squeak images back to version 1.13 (circa 1996)

This set of updates is based on SqueakJS as a reference implementation that
supports a full range of images from Squeak 1.13 through the latest Spur images.

Numbered primitives are identified in the primitive table, established by the
implementations of #initializePrimitiveTable in the various images. Class
PrimitiveTableHistory has been added to document known versions of the
primitive table.

Background: In general, primitives that originated as numbered primitives in early
Squeak versions have been reimplemented as named primitives in the base
interpreter and in various interpreter plugins. The goal is to reduce or eliminate
use of numbered primitives. Support for old images therefore amounts to reassiging
the old primitive numbers to named primitives where necessary to support
running an older image.

Strategy: Check if the current image #hasClosures based on the image format
number, then provide an older set of numbered primitives suitable for a range of
pre-closure images dating back to Squeak 1.13. Do this by starting with the
default primitive table, checking at entry to interpreter() to see if this is a
pre-closure image, then installing old primitives as needed in #updatePrimitiveTable.

Interpreter primitives that require a primitive number for older images are
added to the primitive table with #installPrimitive:at: and primitives that are now
implemented in interpreter plugins are loaded and installed in the primitive
table with #installPrimitive:from:at:.

===

Name: VMMaker-dtl.389
Author: dtl
Time: 21 December 2016, 6:31:30.057 pm
UUID: 3cce2df0-2d06-46f6-bed2-8946fb48c878
Ancestors: VMMaker-dtl.388

VMMaker 4.15.11

Fix the interpreter for running images of the Squeak 3.6 and 3.8 era. Several
obsolete primitives were removed in VMMaker-dtl.387, but these are still
required for older images.

For this update, the primitive table initialiation is unchanged, but a run
time update is done for the ContextInterpreter to restore the old primitive
assignments. It is not clear if this will be a good strategy but for now add
InterpreterPrimitives>>installPrimitive:at: and use it to update the table
on first entry to the interpret() loop.

Possible future updates could support run time fixup to the primitive table
for Squeak 3.2 and earlier images.

===

Dave