[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Support for Windows unicode paths
- From: Jerome Vuarand <jerome.vuarand@...>
- Date: Wed, 22 Jul 2009 18:18:15 +0200
2009/7/22 Thomas Harning Jr. <firstname.lastname@example.org>:
> On Wed, Jul 22, 2009 at 11:44 AM, David Given <email@example.com> wrote:
>> Bulat Ziganshin wrote:
>>> just adding encoding/decoding layer is probably impossible since
>>> open/popen/... on windows uses OEM/ANSI encoding by default, and
>>> encoding from utf-8 to oem/ansi is lossy
>> It's worse than you think. On Windows, the ANSI file system APIs have a
>> much shorter maximum path length than the UTF-16 ones! Read this:
>> So a naive mapping of the Lua functions to the corresponding Windows ones
>> is not necessarily going to work --- it's entirely possible to be in a
>> situation where just calling getcwd() fails.
>> Ditching the ANSI APIs completely and using the UTF-16 ones entirely is
>> probably the best way to go, unfortunately...
> Yeah, that's what I'd figured I had to do.
> Basically replace all ANSI APIs with the UTF-16 ones, and have an automatic
> conversion from UTF-8 => UTF-16 [and back when pulling data out]
I have a patch (attached) replacing win32 API calls with the wide
versions, with the help of a couple helper functions (lua_towstring,
lua_pushwstring) that convert between utf-8 (Lua side) and utf-16
(win32 side). You can use that as a basis to replace all appropriate
clib calls. I have more complete wstring management functions in
another lib if you're interested (lua_tolwstring, lua_pushlwstring,
I also have a partial win32 binding using the same mechanism (ie.
utf-8 in Lua and wide version of win32 API calls). That could be a
basis to add utf-8 support to Lua standard libraries without patching
the core. It's available as sources there:
Description: Binary data