I just had a glance at Nix/Win32Environment NB calls, and nearly cried... (context: http://www.youtube.com/watch?v=Um41DPPs5ZA&list=SP843D1D545F9F52B6&index=15&... ) Which got me thinking, maybe an extra opt (possibly non-static, ref database libraries string encodings) if Strings are expected as parameters should be mandatory, for specifying the expected encoding of the library being called? (oh yes, MANDATORY, if you don't know what is required, you shouldn't be passing in Smalltalk strings in the first place) You'd then be able to cut out ALL the manual cruft in the video's getEnvironmentVariableW: wrapper call basically needed for any current call to a method accepting Strings. (assuming you're not ok with mysterious failures once parameter/return is outside ascii range) Might it work with a few choice assembly implementations of encoders (utf8 + utf16) along the lines of NBUTF8StringExample (expanded to handle both Wide- and ByteString arguments/returns), as well as a fallback (or just) using callback which employs in-image converters? (Such a preamble would also be a good place to do embedded 0 character checks for args expected to be c strings: http://www.hakipedia.com/index.php/Poison_Null_Byte) This have some other implications as well of course; -NBExternalAddress readString/writeString should be removed or made encoding aware. In the current form, they are dangerous/useless outside of pure ascii⦠- How to handle char * parameters. Perhaps parameter-specific validity checks? a) NBExternalAddress - Assume correctly manually encoded contents if allowExternalAddressOpt or whatever its called is set? b) ByteArray - Assume correctly manually encoded contents? c) String - Same as above, either encoding opt set, or return error Cheers, Henry