Comments 33
весело
Учитывая, что с помощью node.js можно создавать не только сайты, но и всякие логеры/демоны и т.п., то думаю тут невозможно не согласиться с автором о том, что
>Node.js под Windows станет платформою, пригодною для разработки на JavaScript множества фактически полезных приложений.
Всем кто не видел доклад «JavaScript на сервере – node.js на Windows» с HTML5 Camp советую это сделать
>Node.js под Windows станет платформою, пригодною для разработки на JavaScript множества фактически полезных приложений.
Всем кто не видел доклад «JavaScript на сервере – node.js на Windows» с HTML5 Camp советую это сделать
Там докладчик всё же настроен достаточно скептически, и даже на тридцать четвёртой минуте доклада (≈33:27) тоном ha ha only serious признаётся, что презентация о том, почему не надо использовать Node.js.
Понятно, что и разработчики модулей должны взяться за ум, а не то даже команду npm install zip нельзя под Windows подать без того, чтобы наткнуться на симлинк внутри тарболла.
и в чём же проблема симлинков?
Рассказываю: в начале декабря наблюдались какие-то неприятные глюки при распаковке симлинков из тарболла под Windows менеджером пакетов npm, и я немало досадовал на тех разработчиков пакетов, которым это было всё равно: раз уж используют npm, то могли бы и призадуматься над обходом его глюков, так я думал.
Однако, по доброй иронии судьбы, это моё воззрение успело устареть в тот же день 16 декабря 2011 года, когда оно было оглашено. Разработчик менеджера пакетов npm внёс необходимые изменения в код своего продукта. (Правда, выпуск npm с этими изменениями cостоялся несколькими днями позже 16 декабря, если мне память не изменяет.)
Теперь команда npm install zip срабатывает невозбранно, например.
Однако, по доброй иронии судьбы, это моё воззрение успело устареть в тот же день 16 декабря 2011 года, когда оно было оглашено. Разработчик менеджера пакетов npm внёс необходимые изменения в код своего продукта. (Правда, выпуск npm с этими изменениями cостоялся несколькими днями позже 16 декабря, если мне память не изменяет.)
Теперь команда npm install zip срабатывает невозбранно, например.
Запасаемся печенюшками и чаем, по изучению новых разновидностей вирусов :)
Не понимаю, чем спровоцировано это высказывание. Возможности написания вируса на Node.js никак не ограничивались прежним отсутствием работающего модуля node-ffi под Windows. Движок Node.js сам собою может и обращаться к файловой системе, и читать да писать файлы, и лазать в Сеть…
Жирные будут вирусы, тянуть за собой node.exe на пару мегабайт, к нему в придачу еще пару модулей и собственно сам скрипт, хотя наверно все зависит от целевой аудитории, если кул-хацкер ничего не знает кроме JS то возможно толк и будет.
Поправка: node.exe сейчас тянет ужé на 4½ мегабайта.
Ребят, а стоит ли работать на node.js с процессами?
И сложен ли процесс написания? Или достаточно знаний js?
И сложен ли процесс написания? Или достаточно знаний js?
Ребят, а стоит ли работать на node.js с процессами?А «работать с процессами» — это что такое? Task manager написать? Или в собственном скрипте fork() вызвать? Если второе, то не стóит, наверное — проще работать с очередью событий.
И сложен ли процесс написания? Или достаточно знаний js?Знаний JS никак не достаточно — непременно, непременно следует также API изучить, и без этого даже не начинать дела.
Настойчиво рекомендую также окинуть взглядом полный список модулей хотя бы для того, чтобы не начать дело с написания одного из них тогда, когда достаточно начать дело с использования одного из них. Свободного открытого кода очень много.
UFO just landed and posted this here
Я честно вначале не верил в успех ноды на винде…
Но рад что ошибался)
Но рад что ошибался)
Слуште, а виндового враппера для Node.js-скриптов, чтоб делать их полноценными самостоятельными экзешниками, пока на горизонтах не видать?
А для чего вы хотите это использовать?
Делать программки, требующие от пользователей минимальных движений для установки и запуска, пользуясь всеми возможностями языка и библиотек из node.js
14 декабря я донёс эту мысль до разработчиков, но пока что никто не отозвался.
Ну, оно и понятно: на этом этапе развития движка есть замыслы куда более насущные.
Ну, оно и понятно: на этом этапе развития движка есть замыслы куда более насущные.
В чем сложность сделать самому?
Всем, кто дочитал в комментариях до этого места — призовой вопрос.
В настоящее время в модулеnode-ffi код файла ffi.cc вызывает функцию ffi_prep_cif(…) с параметром FFI_DEFAULT_ABI (и всегда FFI_DEFAULT_ABI). Этот параметр управляет выбором двоичного интерфейса приложения (Application binary interface).
В то же времяjs-ctypes (джаваскриптовая обёртка вокруг libffi, используемая браузером Firefox и некоторыми его расширениями) задаёт сразу несколько констант ABI: default_abi, stdcall_abi и winapi_abi — и в примерах рекомендует использовать winapi_abi (а не default_abi) для обращения к MessageBoxW(…). Да и в MSDN функция MessageBoxW(…) вполне недвусмысленно записывается через WINAPI, что подразумевает специальный ABI, как я это понимаю.
А теперь внимание, вопрос. Если вызовфункции MessageBoxW(…) подразумевает использование специального ABI, то почему мой пример вообще сработал в Node.js без проблем? Если же вызов функции MessageBoxW(…) не подразумевает использование специального ABI, то зачем разработчикам браузера Firefox понадобилось эдак «нагородить огород»?
Вопрос предлагается для самостоятельного обдумывания, а не в качестве шарады с известным ответом. Дело в том, что я сам ещё не знаю ответа.
В настоящее время в модуле
В то же время
А теперь внимание, вопрос. Если вызов
Вопрос предлагается для самостоятельного обдумывания, а не в качестве шарады с известным ответом. Дело в том, что я сам ещё не знаю ответа.
int WINAPI MessageBox() в примере на MSDN это макрос из файла WinDef.h:
#define WINAPI __stdcall
или иного ABI — в зависимости от системы.
Зоопарк *_abi, вероятнее всего, из-за обратной совместимости, кривых рук и/или горячих голов. Уверен, что разницы в них никакой нет. Разве что default_abi может являться __cdecl.
#define WINAPI __stdcall
или иного ABI — в зависимости от системы.
Зоопарк *_abi, вероятнее всего, из-за обратной совместимости, кривых рук и/или горячих голов. Уверен, что разницы в них никакой нет. Разве что default_abi может являться __cdecl.
Предположим (и даже с изрядной уверенностью), что default_abi непременно __cdecl. Тогда в чём разница между ним и __stdcall, и почему в вызове функции MessageBoxW(…) эта разница ничем не проявила себя?
Судя по статье в Википедии, единственная разница состоит в работе со стеком. Действуя по соглашению cdecl, вызванная функция оканчивается простым ret, а вызывающий её код очищает стек после вызова, так что вызов выглядит наподобие следующего примера:
Ну а stdcall предполагает, что вызванная функция очищает стек самостоятельно (в вышеприведённом примере оканчиваясь ret 12 вместопростого
ret ), так что нет нужды чистить его (add esp, 12) опосля каждого вызова.
Получается, что если функцию stdcall (такую,как MessageBoxW(…)) вызвали через FFI_DEFAULT_ABI, то стек принуждён отдать вдвое больше данных, чем было в него командами push засунуто.
Остаётся всё равно дивиться тому, что скрипт отработал невозбранно, невзирая на такую скверную работу со стеком. Прозреваю,что где-то есть какой-то компенсаторный механизм на случай ошибки — и механизм этот сработал.
; x = function_name(a, b, c)
push c ; arg 3
push b ; arg 2
push a ; arg 1
call function_name ; jump to function_name's code
add esp, 12 ; pop function args (a, b, c) off the stack
mov x, eax ; fetch function return value
Ну а stdcall предполагает, что вызванная функция очищает стек самостоятельно (в вышеприведённом примере оканчиваясь ret 12 вместо
ret
Получается, что если функцию stdcall (такую,
Остаётся всё равно дивиться тому, что скрипт отработал невозбранно, невзирая на такую скверную работу со стеком. Прозреваю,
> Прозреваю, что где-то есть какой-то компенсаторный механизм
Попробовал вызвать MessageBoxA() через Alien (FFI для Lua, тоже на базе libffi) не указав stdcall как ABI и получил ошибку.
Попробовал вызвать MessageBoxA() через Alien (FFI для Lua, тоже на базе libffi) не указав stdcall как ABI и получил ошибку.
А какую ошибку?
Хм, кажется, я наврал. Сделал с утра что-то не то.
Пытаюсь повторить и не получается. Точнее, всё отлично получается и это очень странно.
MessageBox = alien.user32.MessageBoxA;
MessageBox:types({'int', 'string', 'string', 'int'});
MessageBox(0, 'Hello', 'Hello from Lua!', 1);
и
MessageBox = alien.user32.MessageBoxA;
MessageBox:types({'int', 'string', 'string', 'int', abi = 'stdcall'});
MessageBox(0, 'Hello', 'Hello from Lua!', 1);
Оба работают.
Попробовал вызвать GetWindowTextA и SendMessageA, которые у меня всегда крашили программу, если не указать ABI, но и они работают:
GetWindowText = alien.user32.GetWindowTextA;
GetWindowText:types({'int', 'pointer', 'int'});
buffer = alien.buffer(128);
GetWindowText(hWnd, buffer, 128);
print(buffer);
Пытаюсь повторить и не получается. Точнее, всё отлично получается и это очень странно.
MessageBox = alien.user32.MessageBoxA;
MessageBox:types({'int', 'string', 'string', 'int'});
MessageBox(0, 'Hello', 'Hello from Lua!', 1);
и
MessageBox = alien.user32.MessageBoxA;
MessageBox:types({'int', 'string', 'string', 'int', abi = 'stdcall'});
MessageBox(0, 'Hello', 'Hello from Lua!', 1);
Оба работают.
Попробовал вызвать GetWindowTextA и SendMessageA, которые у меня всегда крашили программу, если не указать ABI, но и они работают:
GetWindowText = alien.user32.GetWindowTextA;
GetWindowText:types({'int', 'pointer', 'int'});
buffer = alien.buffer(128);
GetWindowText(hWnd, buffer, 128);
print(buffer);
Позвольте предложить альтернативное решение для Windows:
1. Создаем файл
helloworld.js
2. Компилим его:
И Запускаем helloworld.exe, при этом эффект будет ровно тот же.
Размер — 4,6 кб
1. Создаем файл
helloworld.js
import System.Windows.Forms;
MessageBox.Show("Привет Хабр!", "Заголовок окна");
2. Компилим его:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\jsc.exe helloworld.js
И Запускаем helloworld.exe, при этом эффект будет ровно тот же.
Размер — 4,6 кб
Ну это же пример был, а если у меня есть библиотека myapi.dll и в ней функция RecalculateMatrix(array), то как Вы import напишете? А то, что в .NET есть обертки для некоторых WinAPI — это ясно.
Добавить сборку в GAC?
Ну, это тоже был всего лишь пример.
Я бы хотел подчеркнуть, что через jsc у вас есть доступ ко всем библиотекам .NET Framework.
И Вы можете подключать сторонние .NET библиотеки (сборки).
Но, если Ваша RecalculateMatrix существует только в dll, написанной на языке Си и Вы не планируете ее переписывать, то через технологию P/Invoke вы можете написать для нее библиотеку-обвертку на C# и использовать технологию подключения COM/WinApi – P/Invoke. И использовать эту библиотеку, в итоге, в JavaScript.
Я бы хотел подчеркнуть, что через jsc у вас есть доступ ко всем библиотекам .NET Framework.
И Вы можете подключать сторонние .NET библиотеки (сборки).
Но, если Ваша RecalculateMatrix существует только в dll, написанной на языке Си и Вы не планируете ее переписывать, то через технологию P/Invoke вы можете написать для нее библиотеку-обвертку на C# и использовать технологию подключения COM/WinApi – P/Invoke. И использовать эту библиотеку, в итоге, в JavaScript.
Sign up to leave a comment.
Вызываем функции Windows API (и любые другие функции, написанные на языке Си) джаваскриптом из Node.js