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. > On 16 Jan 2019, at 10:59, Guillermo Polito <guillermopol...@gmail.com> wrote: > > Hi Nicolas, > > On Wed, Jan 16, 2019 at 10:25 AM Nicolas Cellier > <nicolas.cellier.aka.n...@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
