Hello All, Wednesday, December 16, 2015, 11:36:17 PM, you wrote:
IU> Hello Derek, IU> Wednesday, December 16, 2015, 8:24:33 PM, you wrote: DB>> On 12/16/2015 4:29 PM, Roger Pack wrote: >>> Still mulling over why this would be needed...hm.... DB>> It makes sense that CP_OEMCP is needed for device names, in my mind, DB>> after reading https://support.microsoft.com/en-us/kb/108450 - however, DB>> I don't think changing the generic functions in cmdutils.c is correct DB>> here. IU> The actual implementation of these functions for Windows platform looks buggy. IU> Are will work right only for ASCII characters subset. IU> It is hard to imagine what the reason was to use CP_UTF8 in windows-related code. IU> Windows never use UTF8 in command line and in other places here only 8 bit IU> OEM code pages or 16 bit unicode are possible. IU> So using CP_OEMCP looks much more appropriate and correct. IU> But suggested patch looks incomplete, it is quite strange when dup_wchar_to_utf8() IU> function internally performs an action which does not match with the IU> function name. :-) IU> So dup_wchar_to_utf8() should be also renamed to dup_wchar_to_oem() for example. After some more deep thinking I should to take all my words back. :-) Using OEMCP in suggested patch will break uncode files processing. So it is necessary to resolve the issue from an opposite end: it is necessary to convert device name to UTF8 and do no touch existing functions. -- Best regards, Ivan mailto:ivan.us...@nablet.com _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
