"Andreas Raab" <andreas.raab at gmx.de> wrote:
> To be honest, I don't like this particular idea at all. If we assume that
> the VMs must support a variety of encodings then it makes the implementation
> even more complex for no clear gain. While I can see that for some interim
> period the VM may indeed support multiple encodings I don't really see that
> as a long-term viable option. There's just too much work involved with no
> clear benefit.


I don't see why it would be hard for the VM's to support two encodings,
especially if it's a one-direction switch to go from the old MacRoman to
the new UTF-8.  The primitive would be something like:


	void sqPlatform_startUsingUnicode() {
		iconv_free(squeakToPlatformEncoder);
		squeakToPlatformEncoder = iconv_new("utf-8", platform_encoding);

		iconv_free(platformToSqueakEncoder);
		platformToSqueakEncoder = iconv_new(platform_encoding, "utf-8");
	}
	/* the above code doesn't have correct function names; check the man
page */


If we decide that even this is too much effort, then it seems better to
have no compatibility and simply fork the VM.  Old images use old VM's
and new images use new ones.  In that case, is there anything but UTF-8
we'd want to use for the  new VM's ?  


Lex