[Vm-dev] [squeak-dev] Apple starting to alert users that it will end 32-bit app support on the Mac

tim Rowledge tim at rowledge.org
Thu Apr 12 22:28:53 UTC 2018



> On 12-04-2018, at 2:02 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 

> That's right.  All this is trivial form the command line.  Prompt the user with "the image is X bits.  The VM is Y bits.  Do you want to convert?" form the launch script and do the dirty if asked.  From the app its a bit more difficult because we have to at least prompt the user in the GUI domain.  Ideally the converter would be one and the same image.  When run from the command line the converter would be launched headless and interrogate the user through stdio.  When run from the app it would use its own GUI and then relaunch.  If at all possible this should all be written in Smalltalk apart from the VM launching the converter image.  Some fragment of ckformat.c could be compiled into the VM to see if the image conversion was appropriate and to launch the converter image in the right mode.

We already have the image format checking in checkImageVersionFromstartingAt(), though currently it only reports whether the bytes need swapping. We could extend it to return more values if the 32-64 conversion were needed. (Indeed, one might consider dropping the byteswap from the normal vm code and delegating that to a convertor as well, presuming it runs fast enough at some point)

At that point, in readImageFromFileHeapSizeStartingAt() we could then divert to open and load the known-location convertor image instead, which would be able to find the original image filename because we would have used recordFullPathForImageName() previously.

The probably more painful part is after the conversion is completed and the new image file created. We'd have to do whatever is required to clean up all allocations and handles (ie essentially quit() ) and then re-commence the readImageFromFileHeapSizeStartingAt(). We would have the advantage of knowing absolutely that the image did not need any further checking. I suppose conceptually one might even be able to do magic(™) and keep the convertor object memory allocation, move the fixed image data down to memory base and "just start executing". There's a bit of hand-waving there I suspect...

Rather more mundanely (boo, hiss) we could extend the checkImage... so that the VM could exit with an error telling surrounding scripts that the conversion is required and thus trigger whatever.

Should the auto-conversion write a new image file? Should it query the user about where to put any such new file, or default somehow? How small can we make the convertor image - after all almost everything could be removed if we can be bothered. Do we make a single convertor image that can do all the jobs (I'm imagining doing byteswapping, 32->64, 64->32, etc) or separate ones for each junta? Should it be chocolate flavoured?

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
A paperless office has about as likely as a paperless bathroom.




More information about the Vm-dev mailing list