RE: Lua and system integration

>>I'm not entirely sure what you mean here. A programmer in C can very easily
>>register functions with the Lua VM so that Lua can call out to C, and
>>it's even easier to look up Lua functions and call them from C.
I understand what you ment now, I came up to the relevant topic in Lua book.

>>I know it is possible to call COM objects in a generic manner and I'm reasonably sure there's a .net interface.

LuaCOM sounds interesting, might help in some decisions. dotNet is out of question. It is not appropriate for system tools, as of low speed, start up time and memory foot.

>>But is this necessary to write a Windows window manager?
>>I know that at least on Unix, a window manager is a standalone application that
>>communicates with its child apps via message passing.
>>That may not be true for Windows (I know that if a Windows app stops responding, you
>>suddenly find yourself unable to move its windows, irritatingly enough).

Windows users would know what was it about. FYI, WIndows is similar to *nix platforms especialy in VISTA. There is no such thing as window manager though, but there are other ways to do it, more or less supported by Win architecture ( a.k.a. themes). When the app stops responding, it may happen in its main thread that also process GUI messages so that explains why "refreshing" messages
are not handled, thus window is freezed. If you, at design level, separated your problematic sections in another thread, that will not happen. Also windows communicate to processes using messages the only difference from *nix to be, AFAIK, that it is not capable to differentiate user messages from software generated messages (app doesn't know if I click a button or I made a progy to click it).

Here, the only problem is how to register all API functions to be used within LUA. I know now that I can write my own set of C functions and register them, but is it possible to run c functions WITHOUT registration? If not, I would have to wrap all Win API functions and there are hundreeds of them.

DLLs in windows are mapped to address space of callling application if not already there (i.e. system dlls) on the call to LoadLibrary API.
Windows reference counts it, and release this dll from the memory once no other application need it. It can obtain the function from the given dll by using yet another function supplying the name or the oridnal. After that, it uses is as normal function pointer.