search for: cp_utf8

That's how I understand how flac.exe works with unicode under Windows: There's a flag win_utf8_io_codepage that is equal either to CP_ACP or to CP_UTF8. Initially it's equal to CP_ACP. Then flac.exe/metaflac.exe call get_utf8_argv() that do some things and sets win_utf8_io_codepage to CP_UTF8 on success. This is the only way to set this flag to CP_UTF8. The programs continue to work only if get_utf8_argv() succeeds, so we know that win_utf8_i...

...,0,0,70].pack(''ISSCCCCCCCC'') def initialize(server, host = Socket.gethostname) @server = server @host = host clsid = 0.chr * 16 dispatch = 0.chr * 16 # I''m not sure what hr = CLSIDFromProgID(multi_to_wide(server, CP_UTF8), clsid) if FAILED(hr) hr = CLSIDFromString(multi_to_wide(server, CP_UTF8), clsid) if FAILED(hr) raise Error, "unknown OLE server ''#{server}''" end end # Fails here hr = CoCreateInsta...

src/share/utf8/utf8.c mentions that "On NT-based windows systems, we could use WideCharToMultiByte()/MultiByteToWideChar(CP_UTF8), but MS doesn't actually have a consistent API across win32". flac/metaflac don't support Win98 since ver. 1.3.0, so it's possible to use system routines to convert to/from UTF-8. I removed all fprintf(stderr...) code from the win32 code because non-windows code in utf8.c doesn...

...8n world! > We, Japanese, has got suffered for multibyte charset for 20 years. > > I have added a comment in http://llvm.org/bugs/show_bug.cgi?id=10348 . > Of course I know, I don't think it would be a practical resolution. > > FYI, it seems clang can retrieve mbcs path with s/CP_UTF8/CP_ACP/g. > > E>bin\clang.exe -S なかむら\たくみ.c > なかむら\たくみ.c:4:2: error: #error > #error > ^ > 1 error generated. > > Though, you should know, MBCS still has an issue; > > E>bin\clang.exe -S 表はダメ文字\表はダメ文字.c > clang: error: no such file or directory: '表はダメ文字\表...

...- Would it be not enough in somewhere? I suspect clang still might be pathv1-dependent. (I guess, pathv1 would assume ansi) - raw_ostream does not handle utf8, but ansi, on win32. I would like to propose; - converting utf8 and utf16 may move to llvm/lib/Support. - we may get rid of CP_UTF8 with Win32 API. It must be trivial. ps. excuse me, I might respond you more, later. (oops lunch time was over...) ...Takumi

...in the FLAC solution. is this configuration supported? I ask because such configuration breaks support of non-ASCII filenames. Both flac.exe and libFLAC_dynamic.dll were staically linked to different copies of win_utf8_io_static.lib, then flac.exe sets its copy of win_utf8_io_codepage variable to CP_UTF8, and the copy of this variable inside libFLAC_dynamic.dll is always equal to CP_ACP. As a result flac sends UTF8-encoded strings to libFLAC, and libFLAC treats them as ANSI-encoded.

...;m accessing a legacy database with tables still in use by an IIS driven classic asp webapp that has data in windows-1252 encoding while the rails app itself is completely using UTF-8 for it''s newer own tables. and to properly read the legacy table data i set WIN32OLE.codepage = WIN32OLE::CP_UTF8 which enabled me to read the old tables properly. with the odbc driver this doesn''t work because it''s not using win32ole. is there any way to fix that memory leak without switching to odbc and manually Iconv''erting all data from the old tables? -- Posted via http://ww...

...Blibopus%201.0.2%5D.opus" Now when trying to open a unicode file with op_open_url(...) the access log is not showing an access attempt, the function call returns too fast and the error is set to -129 (OP_EFAULT). I am converting the wchar_t to a MBCS UTF-8 string (using ::WideCharToMultiByte(CP_UTF8,...) like I do for my old stream thread) before passing it on to op_open_url with the thinking that it would process it the same way I do. Am I doing it wrong or is it a limitation in libopusurl?

...welcome to the too weird i18n world! We, Japanese, has got suffered for multibyte charset for 20 years. I have added a comment in http://llvm.org/bugs/show_bug.cgi?id=10348 . Of course I know, I don't think it would be a practical resolution. FYI, it seems clang can retrieve mbcs path with s/CP_UTF8/CP_ACP/g. E>bin\clang.exe -S なかむら\たくみ.c なかむら\たくみ.c:4:2: error: #error #error ^ 1 error generated. Though, you should know, MBCS still has an issue; E>bin\clang.exe -S 表はダメ文字\表はダメ文字.c clang: error: no such file or directory: '表はダメ文字\表はダメ文字.c' clang: error: no input files Note, &qu...

Hi, I''ve got a preliminary version of the pure Ruby version of win32-dir in CVS. However, I was hoping to work out the Unicode issue. Run this: from = "C:\\test" to = "?????" Dir.mkdir(from) unless File.exists?(from) Dir.create_junction(to, from) It works, but my explorer (and dos) window shows the name garbled. I don''t think it''s a font

AFAIK Clang internals do assume utf8, and llvm::sys::path converts strings to utf16 on windows and calls W API functions. If somebody would like to take a look at my changes and comment on them. Here's a brief explanation of what I did: - Convert argv to utf8 using current system locale for win32 (this is done as soon as possible inside ExpandArgv). This makes the driver happy since calls to

I spent some more time on this. My idea was to use functionality from llvm::sys::fs like file_status instead of stat struct, but as it turns out this is not really possible. file_status structure is not a replacement for stat, nor are there functions inside llvm::sys::fs that can replace calls to ::stat and ::open. The only solution I can see is to create wrappers around ::stat, ::open, etc. and

...); You may want to test the consistency of this approach from the original with regards to backslashes and quotation marks, if for no other reason than documenting it. CommandLineToArgvW calls them out in the documentation. + for (int i = 0; i != argc; ++i) + { + int len = ::WideCharToMultiByte(CP_UTF8, 0, wargv[i], -1, NULL, 0, NULL, NULL); + argv[i] = new char[len]; You should check the return value of WideCharToMultiByte. I don't expect it to fail, but better safe than sorry. I would guess an assert would be acceptable. I couldn't see it from the patch, but are all the calls to Op...

On Wed, Sep 7, 2011 at 12:20 AM, Nikola Smiljanic <popizdeh at gmail.com> wrote: > So what are you exactly saying? Somebody proposed using GetCommandLine > instead of using argv directly. And what about my other points about ::open > and ::stat? Because of the way Windows works, the only fully correct solution is to never touch the native charset, and keep everything in UTF-8/16