lua-users home
lua-l archive

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

On Sat, Sep 18, 2010 at 12:58 PM, Daniel Quintela <> wrote:
>.."Win32 API wrappers"...I decided to "give them up for adoption"...

A few comments on my look through the Win32 library...  It's a small
assortment of thin C API wrappers around common Win32 API functions,
not unlike the Perl library [1].

The choice of functions and scope of this module is somewhat
arbitrary.  Thousands of Win32 functions are omitted, and it doesn't
focus on implementing a complete Windows DLL like kernel32.dll [2] or
a single functional area like the registry (e.g. Perl
Win32::Registry).  It is pragmatic though in that it implements many
of the more common API functions.  An obvious function lacking is
MessageBox, which implements, and maybe the very versatile

There are modules that compete with this.  The Win32 API is low level
and very non-portable.  Sometimes you need it, but on the other hand
you can access it via the C API (as luasockets does) or Alien.   Alien
does much of the same thing more generally though with special calling
conventions.  I had in the past invoked raw Win32 serial API functions
via Alien [3], although more recently I've moved to librs232lua.  The
WinHttp wrapper is interesting, although people typically do that in a
portable way via luasockets.  You can also access WinHttp via LuaCOM
without any additional code, but you will need to bring in LuaCOM.
This module is kind-of like lposix, but it may be more low level--e.g.
it's not a "safe" API that won't crash on passing invalid handles--and
it doesn't wrap on a higher level like MFC/WTL either.  The module
does have the property though that it has no additional dependencies
and it can be picked apart: If you just need a single function and you
copy and paste just that function.

In wrapping a large API, there can be a lot of redundant coding.  I
would prefer a data-driven approach where the Lua binding code is
automatically generated from an API description.  This also makes it
easy to globally change the nature of the binding, such as the error
handling approach, argument checking, and even the implementation
(e.g. targeting C API code or targeting Alien) or the documentation.
The difficulty though is that the Win32 API is not always regular in
calling conventions--e.g. you need to handle string buffers in certain
ways.  GetLastError() is pretty common though.

(BTW, this is not an offer to maintain this module :)  It's just some
comments on how the module fits in the grand scheme of things and the
possible directions that someone who would maintain this could take.)