On Wed, Jan 16, 2019 at 2:37 AM Sven Van Caekenberghe <
sven@stfx.eu> wrote:
Still, one of the conclusions of previous discussions about the encoding of environment variables was/is that there is no single correct solution. OS's are not consistent in how the encoding is done in all (historical) contexts (like sometimes, 1 env var defines the encoding to use for others, different applications do different things, and other such nice stuff), and certainly not across platforms.
So this is really complex.
Do we want to hide this in some obscure VM C code that very few people can see, read, let alone help with ?
The image side is perfectly capable of dealing with platform differences in a clean/clear way, and at least we can then use the full power of our language and our tools.
Agreed.�� At the same time I think it is very important that we don't reply on the FFI for environment variable access.�� This is a basic cross-platform facility.�� So I would like to see the environment accessed through primitives, but have the image place interpretation on the result of the primitive(s), and have the primitive(s) answer a raw result, just a sequence of uninterpreted bytes.
VisualWorks takes this approach and provides a class UninterpretedBytes that the VM is aware of.�� That's always seemed like an ugly name and overkill to me.�� I would just use ByteArray and provide image level conversion from ByteArray to String, which is what I believe we have anyway.
> On 16 Jan 2019, at 10:59, Guillermo Polito <guillermopolito@gmail.com> wrote:
>
> Hi Nicolas,
>
> On Wed, Jan 16, 2019 at 10:25 AM Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
> IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion because the purpose of a VM is to provide an OS independant fa��ade.
> I made progress recently in this area, but we should finish the job/test/consolidate.
>
> I'm following your changes for windows from the shadows and I think they are awesome :).
>��
> If someone bypass the VM and use direct windows API thru FFI, then he takes the responsibility, but uniformity doesn't hurt.
>
>�� So far we are using FFI for this, as you say we create first Win32WideStrings from utf8 strings and then we use ffi calls to the *W functions.
> I don't think we can make it for Pharo7.0.0. The cycle to build, do some acceptance tests, and then bless a new VM as stable is far too long for our inminent release :).
>
> But this could be for a 7.1.0, and if you like I can surely give a hand on this.
>
> Guille