On Tue, 22 May 2018, Alecos Papadopoulos wrote: Yes, and subsequent versions of Windows continue to provide this. Yes, it's relevant. Since you selected the Greek code page, that means that filenames including both Roman and Greek characters can be represented correctly in the active Windows code page, and so would be passed correctly to gretl as command-line arguments. In other words -- as you have said -- our recent API gymnastics were not necessary for such filenames to "work" in your case! The problem case we've been trying to address is that of filenames that are "out of code page". This includes using Greek characters when your code page is not set to Greek, or (as in the example Sven gave) using Russian (Cyrillic) characters when the active code page is not Russian. In principle "exotic" filenames (to coin a phrase) can be handled OK, provided that gretl accesses the Unicode (UTF-16) representation of the command line, which is made available by a special Windows API. We now do that, and as far as I'm concerned it's all now fixed in git and the latest snapshots. I believe that anyone who's still seeing a problem is not using the current snapshot. Just as a little "by the way": this problem is non-existent on Mac and Linux since, like most of the rest of the world (and over 90 percent of web pages), they use the UTF-8 version of Unicode. Then you don't need any regional "code pages": filenames (as exotic as you like) can be passed correctly -- in the ordinary way without special APIs -- to programs such as gretl, written in the C programming language. Allin