[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua for Windows Platforms
- From: "Antonio E. Scuri" <scuri@...>
- Date: Thu, 04 Feb 1999 12:34:48 -0200
At 18:34 06/10/98 +0000, Michael T. Richter wrote:
>I'm building a set of Lua libraries as Win32/WinCE DLLs. I want to
>making little applications for the WinCE platform and want a useful,
>small, "glue" language to use. Lua fits the bill perfectly.
I know that this is an old message, but I noticed that many developers are
doing the same vicious modification to the Lua source code. This probably
happens because the Visual C++ Help tell us to do so...
The way we build Lua DLLs do not have to modify any of the source or
header files(*). We just create a ".DEF" with an "EXPORT" section on it,
listing the Lua exported functions.
(*) But There are exported variables declared (lua_debug, lua_linehook,
and lua_callhook) that must have a control function declared (lua_setdebug,
lua_linehook, and lua_setcallhook), similar to the lua_setstate function. I
do not recommend using the variables directly. These new functions is a
strong suggestion to version 3.2.
DLLs generation are not similar between compilers. The other suggested
approach seems not to work on Borland C++.
Another very important setting is to use the run time library as a DLL (in
Visual C++ on your Project Settings select C/C++ Tab/Code Generation/Use
run time library and select Multhreaded DLL. This avoids many copies of the
C libraries on your application. Sure you have to make the same choice for
other DLLs you create for your application.
(This is also compiler dependent, Borland C++ use it own C run time library)
The problem related to Unicode characters is more complicated. And It is
not so simple as using float instead of double. If there is a standard
library that handles Unicode, so It is viable to change Lua code to support
Unicode. But making lots of if/defs in the code is not a very good approach
when smooth portability is desired. BTW, I like the idea of having an
Unicode version of the library.
The FILE I/O problem in Windows CE seems to be easy to solve creating an
equivalent stdio/lib replacement. This should be done by Microsoft... In
fact, I do not have much time to dedicate my self to Windows CE, although I