[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua for Windows Platforms
- From: "Michael T. Richter" <mtr@...>
- Date: Thu, 04 Feb 1999 11:14:53 -0500
> 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.
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
> 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
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 <firstname.lastname@example.org> 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