I thought to use the lib_ffi (which is a wrapper that allow script language to call native code ) to allow jscript to call any native functions. However this is a bit laborious to bind with active scripting since nobody seem to have done that before. I'm not sure there is that many functions that would be useful.
This sounds interesting. May be I will try to find out more about it.
You also have the FARR.getObject function available that give you access to the wmi objects.
I guess if I understood WMI better I might find this attractive
Perhaps it is worth learning more about.
You also have sockets in the recent version. You could implement the functionnalities in a server and communicate via sockets.
Hmm, may be -- I don't suppose you have some sample code?
You could also use another script language that come with libraries that allow many more things than the jscript allow.
This was my original leaning, but the main problem w/ this in my opinion is that the attractive languages to me would be Python, Perl, or Ruby (possibly a few others) -- but none of them ship w/ Windows. That seems to imply one of:
- users installing the languages
- providing plugins that contain code created w/ things like py2exe, perl2exe, rubyscript2exe, and the like
The former I can say from experience working on another FARR-like project that it doesn't tend to work out so well. The latter I am guessing tends to create rather large plugins (and possibly bloating FARR's runtime footprint?).
I'd be glad to be wrong about using other scripting languages -- may be there is something I'm missing.