Re: Lua for Windows Platforms

["Michael T. Richter" <mtr@...>]

> 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    <mtr@ottawa.com>    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