Lua for Windows Platforms

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Lua for Windows Platforms

Michael T. Richter
I'm building a set of Lua libraries as Win32/WinCE DLLs.  I want to start
making little applications for the WinCE platform and want a useful, but
small, "glue" language to use.  Lua fits the bill perfectly.

Is there any interest in rolling in the changes necessary for this into the
Lua main distribution?

As a precis, I add the following to lua.h for the basic library:

#ifdef _WIN32
#define EXPORT __declspec(dllexport)
#else
#define EXPORT
#endif

After that I prepend "EXPORT" in front of all function definitions in
lua.h which are supposed to be exported in the DLL.  This should be
platform-neutral (i.e. it shouldn't break UNIX builds).  I will be doing
the same to the other libraries' headers as I get around to them.

When I complete and test the source changes and the project files, is
there any interest in any or all of the following?:

1) The modified source necessary to compile cleanly in Win32 environments
for DLLs. 
2) The DLLs as binaries (for Win32 and for various WinCE platforms).
3) The project files necessary to build Lua 3.1 as Win32/WinCE DLLs.
4) Updated versions of lua and luac which bind to DLLs instead of bringing
in the whole library.
-- 
Michael T. Richter    <[hidden email]>    http://www.igs.net/~mtr/
          PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows Platforms

Gang Wang
>As a precis, I add the following to lua.h for the basic library:
>
>#ifdef _WIN32
>#define EXPORT __declspec(dllexport)
>#else
>#define EXPORT
>#endif
>
>

A few weeks ago, I downloaded Lua 3.1. Built a dll project using MSVC++ 4.2
dll wizard, and included all the *.c files in the offical release, defined
EXPORT as exactly what you did. No changes on any *.c file. Everything just
works fine. Lua is great.

Gang Wang

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows Platforms

Michael T. Richter
>>As a precis, I add the following to lua.h for the basic library:

>>#ifdef _WIN32
>>#define EXPORT __declspec(dllexport)
>>#else
>>#define EXPORT
>>#endif

> A few weeks ago, I downloaded Lua 3.1. Built a dll project using MSVC++
> 4.2 dll wizard, and included all the *.c files in the offical release,
> defined EXPORT as exactly what you did. No changes on any *.c file.
> Everything just works fine. Lua is great. 

One caveat: when using the DLLs and headers there is a slight modification 
needed to the above otherwise some things just don't quite work.  
(Specifically, some exported variables don't work out.)

The modifications are:

#ifdef _WIN32
 #ifdef DLL
  #define EXPORT __declspec(dllexport)	/* building DLL, exported */ 
 #else  
  #define EXPORT __declspec(dllimport)	/* using DLL, imported */ 
 #endif 
#else 
 #define EXPORT
#endif

If you don't do this, some things won't compile if you include debug 
support.  If you do this, you need to #define DLL (either in source or on 
the command line) when building the DLL(s) and make sure it is undefined 
when using the DLLs.
-- 
Michael T. Richter    <[hidden email]>    http://www.igs.net/~mtr/
          PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows Platforms

Antonio Scuri
In reply to this post by Michael T. Richter
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
start
>making little applications for the WinCE platform and want a useful,
but
>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
wish to.

scuri

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows Platforms

Roberto Ierusalimschy
>  (*) 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.

They will be there. Probably, these variables will be moved to lua_state,
so these functions will be the only way to manipulate them.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows Platforms

Michael T. Richter-2
At 10:41 AM 04/02/99 , you wrote:
>>  (*) 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.

>They will be there. Probably, these variables will be moved to lua_state,
>so these functions will be the only way to manipulate them.

Have we got a (very rough, non-binding) time frame for v3.2?
--
Michael T. Richter    <[hidden email]>    http://www.igs.net/~mtr/
          PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows Platforms

Michael T. Richter-2
In reply to this post by Antonio Scuri
> 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.

Doh!

I should have know that, too!  The problem is that I usually do C++
programming where .DEF files are... impractical (to put it politely).
Because of this I'm now conditioned away from doing anything even remotely
.DEF-related in ALL projects.

Expensive mistake, that.  Oh well, live and burn.

> (*) 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.

Good catch.  Depending on when v3.2 comes out I may wait before trying to
do Lua for Win32(/CE)

> DLLs generation are not similar between compilers. The other suggested
>approach seems not to work on Borland C++.

That's correct.  I never bothered considering Borland's compiler, however,
since I don't use it.  :-)

> 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.

Done.  That is probably the most important MSVC setting and by default it
doesn't use that.  Microsoft boneheads!

> 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.

Unicode is a huge headache from the portability perspective.  It goes
deeper than

> 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
>wish to.

I have the same problem: I don't have the time to patch up Microsoft's
omissions.  (Whether warranted or not, they are omissions.)  For $US50.- I
can get a stdio.h for WinCE.  I'll probably get it at the same time as I
deal with the next revision of Lua.  Or I'll bite the bullet and clean-room
a stdio.h for CE and give it out for free.

--
Michael T. Richter    <[hidden email]>    http://www.igs.net/~mtr/
          PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8

Reply | Threaded
Open this post in threaded view
|

Re: Lua for Windows Platforms

Roberto Ierusalimschy-4
In reply to this post by Michael T. Richter-2
> Have we got a (very rough, non-binding) time frame for v3.2?

Less than a month for an alpha (or beta) version. Among other things:

* lua_linehook, lua_callhook and lua_debug inside lua_state (that will be
  the only incompatibility with 3.1)
* no more limit of 64K "things" in a single function (new limit is 2^24)
* new library for debug (that is, you will access the debug API from Lua)
* assignment as expressions, so you can write

  local i = 0
  while (i=i+1)<=N do ... end

or

  while (line=read()) do ... end

(we hope this will solve the "for" quest)

* some new functions (e.g. sort)

-- Roberto