[Vm-dev] Re: [squeak-dev] Criteria For Plugin Compatibility

Ben Coman btc at openinworld.com
Sat Sep 12 08:09:36 UTC 2015


On Sat, Sep 12, 2015 at 5:16 AM, David T. Lewis <lewis at mail.msen.com> wrote:
>
>>
>>
>> On 11-09-2015, at 1:15 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>>>> At the very least we should make sure the version checking that was
>>>> designed specifically to help handle this is actually getting used
>>>> properly.
>>>
>>> That's a good point, although it probably will not help with a many of
>>> these cases. For example, with an interpreter VM the various
>>> permutations
>>> of 32/64 bit host and 32/64 bit object memory are all compiled from a
>>> single identical code base, but the plugins cannot be mixed among them.
>>
>> Sounds like maybe modifying the version system to include some signifier
>> for that might help?
>
> It would be a good thing on general principles to make sure the versioning
> system is sane (I have not paid attention to it). But it can't handle the
> case of mixing 32 and 64 bit compiled modules, because the modules are not
> going to load in the first place (the OS will see to that). I might be the
> only person around who regularly uses the V3 64 bit object memory, so you
> don't need to worry about protecting me from mixing the plugins, I already
> know not to do that ;-)
>
> It might be helpful for protecting against the case of mixing up 32-bit
> compiled Cog and Spur modules.

Just a random idea that may not be practical or worth the effort, you
might have a system where a plugin can be dragged onto the Image
desktop, and something in the binary header not to hard to analyse
could report whether the plugin is compatible and suggest where to put
it.
cheers -ben


More information about the Vm-dev mailing list