<div dir="ltr"><div dir="ltr">Hi Sven,</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 16, 2019 at 2:37 AM Sven Van Caekenberghe <<a href="mailto:sven@stfx.eu">sven@stfx.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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.<br>
<br>
So this is really complex.<br>
<br>
Do we want to hide this in some obscure VM C code that very few people can see, read, let alone help with ?<br>
<br>
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
> On 16 Jan 2019, at 10:59, Guillermo Polito <<a href="mailto:guillermopolito@gmail.com" target="_blank">guillermopolito@gmail.com</a>> wrote:<br>
> <br>
> Hi Nicolas,<br>
> <br>
> On Wed, Jan 16, 2019 at 10:25 AM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
> 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.<br>
> I made progress recently in this area, but we should finish the job/test/consolidate.<br>
> <br>
> I'm following your changes for windows from the shadows and I think they are awesome :).<br>
>  <br>
> If someone bypass the VM and use direct windows API thru FFI, then he takes the responsibility, but uniformity doesn't hurt.<br>
> <br>
>  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.<br>
> 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 :).<br>
> <br>
> But this could be for a 7.1.0, and if you like I can surely give a hand on this.<br>
> <br>
> Guille<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>