Call the Windows API functions (and any other functions written in C language) using javascript from Node.js

Since yesterday, gentlemen, you can write a script like this:

//    JavaScript (UTF-8)  UTF-16 function TEXT(text){ return new Buffer(text, 'ucs2').toString('binary'); } var FFI = require('node-ffi'); //   user32.dll var user32 = new FFI.Library('user32', { 'MessageBoxW': [ 'int32', [ 'int32', 'string', 'string', 'int32' ] ] }); //   var OK_or_Cancel = user32.MessageBoxW( 0, TEXT(', !'), TEXT(' '), 1 ); 

and running it in Windows, get the desired result - the dialog box Windows.

This was possible because the node-ffi module (a wrapper around that unusually useful libffi library that is used to invoke C libraries in at least eight other languages) was ported to Windows yesterday.
')
It goes without saying that the Windows API uses UTF-16 strings , and stores Node.js javascript strings in UTF-8. The embodiment of this difference is in my example the TEXT ( ... ) converter - an analogue of the macro with the same name, described in MSDN .

It is clear that the light did not come together with the Windows API: the node-ffi module can be used to call any library written in C or follow the C method of calling functions (for example, in C ++, this is achieved by the directive extern "C" ).

What does this step in the evolution of Node.js features mean?

Let me remind you of the prediction I made less than a month ago - December 16, 2011:

At present, the future of Node.js is not yet radiant enough, since only ≈1½ months ago this engine exists not only under Linux, under Mac and under Solarium, but also under Windows.

You should expect a powerful synergistic impulse at the moment when the developers of JavaScript who have Windows on their work computer will also start writing the code for Node.js modules. According to my estimates, it’s not enough to port only the Node.js engine itself to Windows; It will also take at least this:

• Smooth operation of the npm package manager. In particular, the appearance of the possibility for developers to deliver pre-compiled modules for win32 and win64 will be extremely useful: you cannot rely on the fact that each end-user has development tools (for example, Visual Studio 2010 Express). It is clear that the developers of the modules should take up their wits, or even the npm install zip command cannot be submitted under Windows without stumbling on the symlink inside the tarball. (Or the author of the npm / lib / utils / tar.js script could better provide for this.)
  
• The emergence of the ability to scramble an arbitrary system library. (It will probably appear after porting node-ffi to Windows.) It is only from here that the path to the creation of the GUI will stretch.
  
• Appearance of the opportunity to work with the database file (and not client-server) type. (It will probably appear after porting node-sqlite3 to Windows.)

And a month has not passed, as the second of these three points was realized. Any library can be scripted by javascripts. Accordingly, applications on Node.js for Windows have become available to all the power of the system API , and cross-platform applications can apply to cross-platform libraries indiscriminately, dragging them with them.

The first of these three points (referring just to dragging libraries with it) did not materialize in the form in which I dreamed about it: the npm package manager still does not provide the ability to deliver only the compiled code that a particular system needs. But I had a new reason for optimism after I saw that the developers of the node-ffi module managed to circumvent the lack of such an opportunity. Their module contains the same code compiled under half a dozen different platforms:

 compiled/darwin/x64/ffi_bindings.node compiled/linux/ia32/ffi_bindings.node compiled/linux/x64/ffi_bindings.node compiled/sunos/ia32/ffi_bindings.node compiled/win32/ia32/ffi_bindings.node 

and the script lib / bindings.js during the call to the node-ffi module looks around, figuring out where it went, and selects the desired binary code:

 var join = require('path').join , bindings = 'ffi_bindings.node' function requireTry () { var i = 0 , l = arguments.length , n for (; i<l; i++) { n = arguments[i] try { var b = require(n) b.path = n return b } catch (e) { if (!/not find/i.test(e.message)) { throw e } } } throw new Error('Could not load the bindings file. Tried:\n' + [].slice.call(arguments).map(function (a) { return ' - ' + a }).join('\n')) } module.exports = requireTry( // Production "Release" buildtype binary join(__dirname, '..', 'compiled', process.platform, process.arch, bindings) // Release files, but manually compiled , join(__dirname, '..', 'out', 'Release', bindings) // Unix , join(__dirname, '..', 'Release', bindings) // Windows // Debug files, for development , join(__dirname, '..', 'out', 'Debug', bindings) // Unix , join(__dirname, '..', 'Debug', bindings) // Windows ) 

As you can see, it works no worse; the “compiled” folder only occupies ≈700 kilobytes, but with the current disk volumes and network speeds, this can be forgotten.

So, it remains to wait for access to SQLite - and Node.js for Windows will become a platform suitable for developing in JavaScript a set of actually useful applications. But with this in mind, we can assume that the cross-platform development of wrapper modules has been simplified; therefore, we do not have much time left to wait for the wrapper around SQLite, and the emergence of modules for integrating Node.js with a number of other well-known cross-platform libraries.