[PD-dev] UTF-8 problems on Windows

[Hans-Christoph Steiner]

Thanks for spotting that. The replacement, _wsopen_s(), does not seem available in MinGW.  From what I know, Microsoft doesn't ever remove functions from their APIs, but just marks them as deprecated.

.hc

On Dec 8, 2012, at 12:08 AM, PSPunch wrote:

> Hi Hans,
> 
> I found an article mentioning that _wopen() is deprecated..
> http://msdn.microsoft.com/en-us/library/z0kc8e3z%28v=vs.80%29.aspx
> 
> 
> Well, the reason I thought of doing a quick search on this was that I recall Microsoft C/C++ functions beginning with underscores recommended to be called with substitute macros to keep the code portable between architectures, but that is according to my rusted memory..
> 
> -- 
> David Shimamoto
> 
> 
> (2012/12/07 12:06), Hans-Christoph Steiner wrote:
>> 
>> I am pretty sure I found the root cause of it.  Windows uses UCS-2 as its character encoding, but Pd is all UTF-8 internally.  Tcl is also all UTF-8, so that works nicely.  I believe that GNU/Linux and Mac OS X use UTF-8 for filenames as well.
>> 
>> It looks like the solution is converting the filenames from UTF-8 to UCS-2 (16-bit wchar_t) whenever there is an open() call, and using _wopen() instead.
>> 
>> http://stackoverflow.com/questions/3298569/difference-between-mbcs-and-utf-8-on-windows
>> 
>> .hc
>> 
>> On Dec 6, 2012, at 2:37 PM, Roman Haefeli wrote:
>> 
>>> Hi Hans
>>> 
>>> I probably have nothing useful to add, but just last week I got a report
>>> from someone using a patch of mine on Windows, experiencing troubles
>>> with opening certain sound files. It turned out, that it was also
>>> related to non-ASCII characters in the name of those files. Pd didn't
>>> crash, though, but the sound files didn't load. I hadn't have the
>>> opportunity to look at it myself yet (no access to a win comp), but I'm
>>> glad to see it confirmed. I'd be happy to see it fixed, though probably
>>> my only contribution would be limited to testing.
>>> 
>>> Roman
>>> 
>>> 
>>> On Mit, 2012-12-05 at 23:14 -0500, Hans-Christoph Steiner wrote:
>>>> There is a problem on Windows that has me stumped.  If you open a file with a non-ASCII character in the name or path using "pd -open" it works fine.  If you open it using File -> Open, then it freezes Pd.  If you print the filename to the Pd window right before its sent to Pd, it prints properly:
>>>> 
>>>> C:/Documents and Settings/pd/Desktop/comma,coüüümma.pd
>>>> 
>>>> But running "pd.com -d 3" shows:
>>>> 
>>>> pd open comma\,co├╝├╝├╝mma.pd C:/Documents\ and\ Settings/pd/Desktop;
>>>> open: C:/Documents and Settings/pd/Desktop/comma,co├╝├╝├╝mma.pd: No such file or directory
>>>> comma,co├╝├╝├╝mma.pd: No such file or directory
>>>> 
>>>> So somewhere in the network receiving the unicode is going wrong, but only on Windows.  Its a bad bug for anyone who uses non-ASCII letters on Windows. Any ideas?
>>>> 
>>>> .hc
>>>> _______________________________________________
>>>> Pd-dev mailing list
>>>> Pd-dev at iem.at
>>>> http://lists.puredata.info/listinfo/pd-dev
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Pd-dev mailing list
>>> Pd-dev at iem.at
>>> http://lists.puredata.info/listinfo/pd-dev
>> 
>> 
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>> 
> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev