[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua and unicode with visual studio
- From: "D Burgess" <dburgess@...>
- Date: Sat, 24 Jun 2006 07:11:55 +1000
One option, and I think a better one, would be to always call
LoadLibraryW and use MultiByteToWideChar() to convert
UTF-8 to Unicode. This means that stock Lua can load any
DLL without too much trauma. Equally if the error mesages
are returned as UTF-8 then the application that is using Lua
can easily convert to Unicode if required. It gets rid of the
comppile time choice and makes it a runtime choice.
The second issue of the order of header inclusion:
I have read (somewhere) in the MS docs that windows.h
should always be included before any RTL headers. Indeed
my slightly patched version of loadlib.c needs this change so
that it will compile.
On 6/24/06, Mike Pall <firstname.lastname@example.org> wrote:
Roberto Ierusalimschy wrote:
> You can make these corrections in luaconf.h:
> #if defined(loadlib_c) && defined(UNICODE)
> #define GetModuleFileName GetModuleFileNameA
> #define FormatMessage FormatMessageA
> #define LoadLibrary LoadLibraryA
I doubt this will work. Because <windows.h> is included after
"luaconf.h" and because GetModuleFileName and the other variant
API calls _are_ already macros. The Windows system DLLs only
provide the *A/*W symbols.
I've checked the oldest Win95 kernel32.dll I could find and it
has both variants for all relevant symbols. I still think it
makes sense to directly use the *A variants in loadlib.c (but see
http://lua-users.org/lists/lua-l/2006-04/msg00466.html for Wim's
position on this).