हम Node.js से जावास्क्रिप्ट के साथ विंडोज एपीआई फ़ंक्शन (और सी में लिखे गए किसी भी अन्य फ़ंक्शन) को कॉल करते हैं

कल से, सज्जनों, आप इस स्क्रिप्ट को लिख सकते हैं:

//    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 ); 

और इसे विंडोज पर चल रहा है, वांछित परिणाम प्राप्त करें - विंडोज संवाद बॉक्स।

यह संभव हो गया था क्योंकि नोड-एफएफआई मॉड्यूल (उस असामान्य रूप से उपयोगी लिबेफी लाइब्रेरी के चारों ओर एक आवरण , जिसका उपयोग कम से कम आठ अन्य भाषाओं में सी लाइब्रेरी को कॉल करने के लिए किया जाता है) को कल विंडोज पर पोर्ट किया गया था।

यह निश्चित रूप से, याद रखना चाहिए कि Windows API UTF-16 स्ट्रिंग्स का उपयोग करता है , और Node.js UTF-8 में जावास्क्रिप्ट स्ट्रिंग्स को संग्रहीत करता है । इस अंतर का अवतार, मेरे उदाहरण में, TEXT ( ... ) कनवर्टर MSDN में वर्णित उसी नाम के मैक्रो का एक एनालॉग है ।

यह स्पष्ट है कि विंडोज एपीआई ने अभिसरण नहीं किया था: नोड-एफएफआई मॉड्यूल का उपयोग सी में लिखी गई किसी भी लाइब्रेरी को कॉल करने के लिए किया जा सकता है या कॉलिंग फ़ंक्शन के सी तरीके का अनुसरण कर सकता है (उदाहरण के लिए, सी ++ में यह एक्सटर्नल "सी" निर्देश द्वारा प्राप्त किया गया है। )।

Node.js सुविधाओं के विकास में इस कदम का क्या मतलब है?

मैं आपको एक महीने से भी कम समय पहले की गई भविष्यवाणी की याद दिलाता हूं - १६ दिसंबर, २०११:

वर्तमान में, Node.js का भविष्य अभी भी काफी उज्ज्वल नहीं है, क्योंकि केवल ½1 future महीने के लिए यह इंजन न केवल लिनक्स के तहत, मैक के तहत और सोलेरका के तहत, बल्कि विंडोज के तहत भी मौजूद है।

हमें उस समय एक शक्तिशाली सहक्रियात्मक धक्का की उम्मीद करनी चाहिए जब Node.js मॉड्यूल के लिए कोड उन जावास्क्रिप्ट डेवलपर्स द्वारा भी लिखा जाएगा जिनके पास अपने काम करने वाले कंप्यूटर पर विंडोज है। मेरे अनुमान के अनुसार, यह विंडोज के लिए अकेले Node.js इंजन को पोर्ट करने के लिए पर्याप्त नहीं है; कम से कम यह भी आवश्यक है:

• Npm पैकेज मैनेजर का सुचारू संचालन। विशेष रूप से, यह मॉड्यूल डेवलपर्स के लिए win32 और win64 के लिए पूर्व संकलित मॉड्यूल की आपूर्ति करने में सक्षम होने के लिए बेहद उपयोगी होगा: आप इस तथ्य पर भरोसा नहीं कर सकते कि प्रत्येक अंतिम उपयोगकर्ता के पास विकास उपकरण हैं (उदाहरण के लिए, विजुअल स्टूडियो 2010 एक्सप्रेस)। यह स्पष्ट है कि मॉड्यूल डेवलपर्स को ध्यान में रखना चाहिए, और यहां तक ​​कि एनपीपी स्थापित ज़िप कमांड को टारबॉल के अंदर एक सिमलिंक पर ठोकर के बिना विंडोज के तहत प्रस्तुत नहीं किया जा सकता है। (या स्क्रिप्ट लेखक npm / lib / utils / tar.js इससे बेहतर कल्पना कर सकते थे।)
  
• एक मनमाना सिस्टम लाइब्रेरी को स्क्रिप्ट करने की क्षमता। (यह विंडोज के लिए नोड-एफएफआई को पोर्ट करने के बाद, संभवतः, दिखाई देगा।) केवल यहां से जीयूआई बनाने का मार्ग खिंचाव होगा।
  
• डेटाबेस फ़ाइल (क्लाइंट-सर्वर के बजाय) प्रकार के साथ काम करने की क्षमता का उद्भव। ( नोड- sqlite3 को विंडोज में पोर्ट करने के बाद, संभवतः दिखाई देगा।)

और एक महीना भी नहीं बीता, क्योंकि इन तीन बिंदुओं में से दूसरे का एहसास हुआ था। किसी भी पुस्तकालय को जावास्क्रिप्ट के साथ लिपिबद्ध किया जा सकता है। तदनुसार, सिस्टम API की पूरी शक्ति विंडोज के लिए Node.js अनुप्रयोगों के लिए उपलब्ध हो गई, और क्रॉस-प्लेटफ़ॉर्म एप्लिकेशन क्रॉस-प्लेटफ़ॉर्म लाइब्रेरीज़ को उनके साथ खींचे बिना एक्सेस कर सकते हैं।

इन तीन बिंदुओं में से पहला (जो मेरे साथ केवल पुस्तकालयों को खींचने से संबंधित था) उस रूप में लागू नहीं किया गया था जिसमें मैंने इसके बारे में सपना देखा था: एनपीएम पैकेज प्रबंधक अभी भी केवल संकलित कोड को वितरित करने की क्षमता प्रदान नहीं करता है जो एक विशिष्ट प्रणाली की आवश्यकता है। लेकिन मुझे आशावाद के लिए एक नया कारण मिला जब मैंने देखा कि नोड-एफएफआई मॉड्यूल के डेवलपर्स इस तरह के अवसर की कमी को दरकिनार करने में सक्षम थे। उनके मॉड्यूल में आधा दर्जन विभिन्न प्लेटफार्मों के लिए संकलित समान कोड शामिल हैं:

 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 

और lib / bindings.js स्क्रिप्ट नोड-ffi मॉड्यूल को लागू करते समय चारों ओर देखती है, यह पता लगाती है कि यह कहाँ से मिली और आवश्यक बाइनरी कोड उठा रही है:

 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 ) 

जाहिर है, यह कोई बुरा काम करता है; "संकलित" फ़ोल्डर में बस comp700 किलोबाइट होते हैं, लेकिन वर्तमान डिस्क आकार और नेटवर्क गति के साथ, आप इसके बारे में भूल सकते हैं।

तो, आपको बस SQLite तक पहुंचने के लिए इंतजार करना होगा - और विंडोज के लिए Node.js जावास्क्रिप्ट में कई वास्तव में उपयोगी अनुप्रयोगों को विकसित करने के लिए उपयुक्त एक मंच बन जाएगा। लेकिन पूर्वगामी को ध्यान में रखते हुए, हम मान सकते हैं कि आवरण मॉड्यूल के क्रॉस-प्लेटफॉर्म विकास को सरल बनाया गया है; इसलिए, हमें SQLite के आसपास रैपर के लिए लंबे समय तक इंतजार नहीं करना पड़ा, और कई अन्य प्रसिद्ध क्रॉस-प्लेटफॉर्म लाइब्रेरी के साथ Node.js को एकीकृत करने के लिए मॉड्यूल की उपस्थिति।