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 >>>> [email protected] >>>> http://lists.puredata.info/listinfo/pd-dev >>> >>> >>> >>> _______________________________________________ >>> Pd-dev mailing list >>> [email protected] >>> http://lists.puredata.info/listinfo/pd-dev >> >> >> _______________________________________________ >> Pd-dev mailing list >> [email protected] >> http://lists.puredata.info/listinfo/pd-dev >> > > > _______________________________________________ > Pd-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
