lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Hello! I'm interested in your port of Lua to WinCE. I am working on that
myself. I'd like to help out. Are the diffs of your port available for
download, please?

I've taken a first crack at stripping down the w32 extension to support
the stuff you can do in Windows CE, but there are a bunch of other
functions I'd like to add as well. Most of the drudge work was
converting back and forth between lua 8 bit strings and WinCE's wide
character strings, and freeing the temporary strings. SWIG is great at
doing that tedious stuff for you (you just write a typemap which SWIG
applies to all the wrapper parameters automatically), so maybe it would
be easier to make a SWIG interface to Win32/WinCE, instead of wrapping
it by hand.

I'm using SWIG to wrap C++ objects and libraries, for the Windows CE
version of Lua (I use SWIG a lot for Python, on Linux and Windows too).
I had to tweak the SWIG lua back-end a bit to get it to support linking
together multiple SWIG interfaces to different (separately SWIGged)
modules at once. A few identically named functions needed to be declared
static so they didn't collide, and I needed to take the parens out of a
macro that put parens around the type name whe applying the "new"
operator to a type name: "new (int)[10]" confuses the compiler, but "new
int[10]" works. Now I've got SWIG wrapping C++ classes that use STL
string parameters, and multiple modules work together nicely with Lua.
If you're interested, just ask, and I'll send you diffs for the
modifications I made to SWIG's Lua back-end.

To integrate SWIG with Microsoft Visual Studio version 8, I made a
"custom build rule" to support running SWIG on .i files. But I had to
resort to ugly hacks to get it to work. I made a build rule for .i
files, but it insisted on trying to apply the build rule not only to the
.i files, but also to the project itself, when I tried to (get this)
deploy it in the emulator after it built. That caused an error that
aborted the debugging process. Very weird -- something's Rotten in
Redmond. So I added a customizable parameter to the build rule called
"Disabled" that puts an "echo" in front of the swig command, and used it
to disable the top level swig rule on the project (since I could not
figure out any other way to disable or delete it, and the documentation
is horrible). But then of course the custom build rules on the .i files
inherited the "Disabled: true" parameter, so I had to manually override
them to enable them... Does anybody understand how custom build rules
are supposed to work? It seems like the Microsoft supplied ones don't
have this problem of trying to apply it to the project when you deploy,
but the one I wrote does. If you're interested, just ask, and I'll send
you the XML file for the custom build rule.

I'd like to wrap a bunch of the Win32 telephony and other APIs that are
unique to pocket pc phones. I'd also like an ActiveX interface that lets
you easily integrate ActiveX / OLE Automation objects with Lua. The
"jsdb" project does that for JavaScript, so I'm sure it could be done
for Lua. The tricky part (that jsdb's ActiveX intergration doesn't
support) is receiving ActiveX events and sending them to Lua
(IConnectionPointContainer et al). Python's win32com module does all
that stuff, and it's extremely useful. I'd love that for Lua on Windows
and Windows CE.


jason zhang wrote:
> The previous mail is held by the maillist because it is bigger than 40k
> I attach a new package. It only include the files which only exists in
> CE version.
>     ----- Original Message -----
>     *From:* jason zhang <>
>     *To:* Lua list <>
>     *Sent:* Tuesday, August 29, 2006 1:09 PM
>     *Subject:* WinCE porting for Lua5.1
>     I ported the Lua5.1 to WinCE, base Pedro Miller Rabinovitch's
>     porting for Lua5.0
>     This version can be compiled under both WinCE and other generic
>     platforms. I tested
>     it on mingw,EVC4,Cygwin and VC6.
>     Free for using and I hope the official version of Lua5.1 can
>     support WinCE natively.
>     Thanks.
>     ps. there is a 'diffs' file in the package, which is compared with
>     the original Lua5.1 sourcecode.