Scripts без WSH

Russian main discussion
  • Author
  • Message
Offline
Posts: 876
Joined: Tue Jul 24, 2007 8:54 am

Post by Fr0sT »

1. Любой скрипт - это плохое решение.
Скажем так, не очень портабельное. Достаточно запрета в политике безопасности (что на самом деле очень часто встречается), чтобы сделать скрипты бесполезными. Не говоря уже про Wine. Встроенный движок скриптов решил бы проблему, но это немалый труд и практически полное переписывание всех имеющихся скриптов, + потеря многих предоставляемых WSH-ом приятностей.

Offline
Posts: 2247
Joined: Tue Aug 07, 2007 2:03 pm
Location: Vinnitsa, Ukraine

Post by FeyFre »

но это немалый труд и практически полное переписывание всех имеющихся скриптов, + потеря многих предоставляемых WSH-ом приятностей.
Не на много больший труд чем написать сам плагин. Никто же не заставляет и не рассчитывает на собственный язык, можно и нужно взять готовый. Думаю что среди таких найдется достаточно легкий, встраиваемый, фичастый и расширяемый язык. А приятности - не так уж и уникальны(я сходу уникальных не назову).

Offline
Posts: 876
Joined: Tue Jul 24, 2007 8:54 am

Post by Fr0sT »

Не на много больший труд чем написать сам плагин. Никто же не заставляет и не рассчитывает на собственный язык, можно и нужно взять готовый. Думаю что среди таких найдется достаточно легкий, встраиваемый, фичастый и расширяемый язык. А приятности - не так уж и уникальны(я сходу уникальных не назову).
Тем более что полно уже готовых реализаций (Паскаль, Луа, про другие не знаю, но точно должны быть). Но придется очень многое допиливать. Что касается фич - пожалуйста:
* Регулярки, которые никак не встроят в саму программу, что, на мой взгляд, является единственным оправданием наличия скрипта SearchReplace :)
* Весь набор функций: математика, строки, массивы (!)
* FileSystemObject

Offline
Posts: 2247
Joined: Tue Aug 07, 2007 2:03 pm
Location: Vinnitsa, Ukraine

Post by FeyFre »

Fr0sT, по сути отсутствие регулярок в большинстве претендентов и останавливает. Да, существуют различные биндинги библиотек, но от этого легче не становиться(проблема кодировок).
Математика, строки, масивы - такое в принципе есть в 99% претендентах. FSO - тоже не редкость.

Паскаль всё-таки не скриптовой, не претендент. Луа, Питон, Перл, Лиспы(я этого не говорил), Ява... но пилить есть что.(Хвала МС что для JScript нам не нужно было знать все подвохи ECMA262)

Offline
Posts: 876
Joined: Tue Jul 24, 2007 8:54 am

Post by Fr0sT »

FeyFre
Паскаль всё-таки не скриптовой, не претендент
PascalScript, DWScript... правда, эти обычно сами пишутся на Паскале, т.ч. не вариант именно по этой причине.
по сути отсутствие регулярок в большинстве претендентов и останавливает. Да, существуют различные биндинги библиотек, но от этого легче не становиться(проблема кодировок)
Думаю, стопроцентно должно быть решение. Да хотя бы тот же pcre.dll встроить. А кодировки - причем тут они? Это забота самого Акеля, чтобы текст в регулярку подался в нужной кодировке. Сама же регулярка должна кушать widechar и всё

Offline
Posts: 2247
Joined: Tue Aug 07, 2007 2:03 pm
Location: Vinnitsa, Ukraine

Post by FeyFre »

PascalScript, DWScript... правда, эти обычно сами пишутся на Паскале, т.ч. не вариант именно по этой причине.
Как язык написания плагина Паскаль подходит - AkelDll.pas лежит в исходниках лавно. Другая проблема в том, что плагин при этом развезет(я правда писал на Delphi последний раз аж в 2002 году, но с тех пор ничего не изменилось).
Сама же регулярка должна кушать widechar и всё
Всего-то нужно заставить весь мир Юникс пересесть на widechar, который у них между-прочим 4-байтный. А именно оттуда портировались на WIN32 все претенденты. Об пришитые pcre.dll я думал и даже чего-то там пробовал - пока нечем похвалится.

Offline
Posts: 876
Joined: Tue Jul 24, 2007 8:54 am

Post by Fr0sT »

Как язык написания плагина Паскаль подходит - AkelDll.pas лежит в исходниках лавно
Теоретически - да, но писать плагин кроме Инструктора некому, а он приверженец классического С :)
Другая проблема в том, что плагин при этом развезет
Широко распрострённое заблуждение. "Развезёт" точно так же, как программу на любом языке с высокоуровневым графическим фреймворком. А если юзать только WinApi, то файлы будут ничуть не больше сишных.
Всего-то нужно заставить весь мир Юникс пересесть на widechar, который у них между-прочим 4-байтный. А именно оттуда портировались на WIN32 все претенденты. Об пришитые pcre.dll я думал и даже чего-то там пробовал - пока нечем похвалится.
Хм. Хочешь сказать, что любые регулярки из Юниксов справляются только с однобайтовыми кодировками? Что-то не верится. Своими глазами видел упоминание о поддержке Юникода в них

http://www.regular-expressions.info/unicode.html

upd
In situations where performance is critical, you may want to use TPerlRegEx directly. The PCRE library is based on UTF-8 while the Delphi VCL uses UTF-16 (UnicodeString). TPerlRegEx is also based on UTF-8, giving you full control over the conversion between UTF-16 and UTF-8. You can avoid the conversions if your own code also uses UTF8String. The RegularExpressions unit uses UnicodeString just like the rest of the VCL, and handles the UTF-16 to UTF-8 conversion automatically.
По крайней мере насчет PCRE утверждение про однобайтовые частично верно (первые 127 символов). Хотя C#, Java, да тот же JS юзают widechar реализацию.

Offline
Posts: 2247
Joined: Tue Aug 07, 2007 2:03 pm
Location: Vinnitsa, Ukraine

Post by FeyFre »

Теоретически - да, но писать плагин кроме Инструктора некому, а он приверженец классического С
Если дело за "писать" то найдется кому. Дело в организации и мотивации. 90% опенсорса загнулось по причине плохой мотивации, столько же проектов просто не родилось.
Широко распрострённое заблуждение. "Развезёт" точно так же, как программу на любом языке с высокоуровневым графическим фреймворком. А если юзать только WinApi, то файлы будут ничуть не больше сишных.
Вспомните, сколько мороки нужно было пережить, что-бы написать резидента на Паскале во времена ДОС. И там "высокоуровневые" фреймворки как ни странно не использовались.
Хм. Хочешь сказать,
Хочу сказать, что заставить их работать как этого нужно WIN32 приложению тяжелее чем написать собственную реализацию. Живой пример тому - ASpell. Все выходцы из Юникс по самые я... завязаны на libc. libc в свою очередь пинают много ног, и пинок одной ногой портит отношения с другой. Чего только стоит errno. Одно слабое звено - game over. Используется много непортабельных фич. И за эти самые я... всех не поймаешь(я даже пытаться не буду, ибо если если библиотека не юзабельна без хаканья системы - ну её в баню).

Offline
Posts: 876
Joined: Tue Jul 24, 2007 8:54 am

Post by Fr0sT »

Вспомните, сколько мороки нужно было пережить, что-бы написать резидента на Паскале во времена ДОС. И там "высокоуровневые" фреймворки как ни странно не использовались.
Не доводилось, но к чему здесь этот пример, не понял.
Хочу сказать, что заставить их работать как этого нужно WIN32 приложению тяжелее чем написать собственную реализацию. Живой пример тому - ASpell. Все выходцы из Юникс по самые я... завязаны на libc. libc в свою очередь пинают много ног, и пинок одной ногой портит отношения с другой.
Возможно. Однако - факты: в Дельфи сумели встроить и zlib, и pcre - причем в виде obj, а не dll, то есть непосредственно в бинарник. И ничего, работает. А жесткая завязанность, имхо, идет от кривого кода.
Если дело за "писать" то найдется кому. Дело в организации и мотивации. 90% опенсорса загнулось по причине плохой мотивации, столько же проектов просто не родилось.
Самая весомая мотивация - это "мне позарез нужна вот эта фича, но её некому сделать, придется самому" :)

Offline
Posts: 2247
Joined: Tue Aug 07, 2007 2:03 pm
Location: Vinnitsa, Ukraine

Post by FeyFre »

Не доводилось, но к чему здесь этот пример, не понял.

Code: Select all

program pog;
uses system;
begin
end.
system вот этот гребаный юнит - паскалевский runtime ложится в каждую прогу(а сейчас и в каждый exe dll и в такое место что расчете размера резидента его вне резидентной области не вытеснишь. А сейчас он ложится в каждую DLL - каждой своя копия. И не использовать его не получается.
Возможно. Однако - факты: в Дельфи сумели встроить и zlib, и pcre - причем в виде obj, а не dll, то есть непосредственно в бинарник. И ничего, работает. А жесткая завязанность, имхо, идет от кривого кода.
И как всегда между obj и программой лежыт двойная прослойка, конвертирующая deplhi-шные типы в родные для либы.
Самая весомая мотивация - это "мне позарез нужна вот эта фича, но её некому сделать, придется самому"
Такая мотивация - это уже не вопрос развития, а вопрос выживания, о чем речь не идет.

Offline
Posts: 876
Joined: Tue Jul 24, 2007 8:54 am

Post by Fr0sT »

system вот этот гребаный юнит - паскалевский runtime ложится в каждую прогу(а сейчас и в каждый exe dll и в такое место что расчете размера резидента его вне резидентной области не вытеснишь. А сейчас он ложится в каждую DLL - каждой своя копия. И не использовать его не получается.
И что? Он сильно мешает? Добавляет огромный кусок в бинарник (на самом деле - размером всего 30 килобайт)? В сях даже на hello world нужно целых две либы подключать. Всё равно в нормальном проекте используется очень много функций из system. Но знающие толк в извращениях могут покоцать system.pas, оставив только самое-самое необходимое.
И как всегда между obj и программой лежыт двойная прослойка, конвертирующая deplhi-шные типы в родные для либы.
Где надо - возможно, и лежит. Потому что тот же char* - это убогий неудобный suxx 8-)

Offline
Posts: 767
Joined: Mon Sep 28, 2009 10:03 am
Location: Minsk, Belarus

Post by se7h »

Всяк кулик своё болото хвалит

Голосую за js, но если что, не против python'a или lua

Offline
Posts: 2247
Joined: Tue Aug 07, 2007 2:03 pm
Location: Vinnitsa, Ukraine

Post by FeyFre »

В сях даже на hello world нужно целых две либы подключать.
Аж одну:
Запускать с путями настроенными на кампилятор

Code: Select all

#if 0
#echo off
cl /O1 /Tc %~nx0 /link /nodefaultlib /entry:main kernel32.lib /release /subsystem:console
exit /b
#endif
#include <windows.h>
const char hw[] = "Hello, World";
void main(void)
{
	DWORD dw=0;
	HANDLE h = GetStdHandle(STD_OUTPUT_HANDLE);
	WriteFile(h, hw, sizeof(hw)-1, &dw, NULL);
	ExitProcess(0);
}
Покоцать System.pas просто не получится - это только брланду подсилу.

Offline
Posts: 876
Joined: Tue Jul 24, 2007 8:54 am

Post by Fr0sT »

Аж одну
Хм. Хитро придумано. Я по старинке помнил stdio/conio
Покоцать System.pas просто не получится - это только брланду подсилу.
Что ж, те, кого шибко колебут эти несчастные 30 кило, способен на всяческие извращения: для бешеной собаки 100 верст не крюк :). Другое дело - зачем? Тяжёлое наследство ДОС-а не дает покоя? Или позарез надо вместить 1000 программ на одну 5-дюймовую дискету?
Плюс, если вылезти из лабораторных хэллоу ворлдов и проверить реальную прогу с реальным функционалом, уверен, разница будет незначительна.
Говоря о JS:
https://developer.mozilla.org/en/How_to ... ipt_engine
http://code.google.com/intl/ru-RU/apis/v8/build.html
(движки от Хрома и Фаерфокса м.б. встраиваемыми - правда, неизвестно, какой при этом получается объём бинарника)

Offline
Posts: 2247
Joined: Tue Aug 07, 2007 2:03 pm
Location: Vinnitsa, Ukraine

Post by FeyFre »

Хм. Хитро придумано. Я по старинке помнил stdio/conio
Ну раз мы в винде, то зачем
(а может даже и 5-кратную: я недавно лазил по исходниках libc, когда искали проблему с NetDrive).
прослойку тянуть за собой, если можно сразу системный вызов сделать.
кого шибко колебут эти несчастные 30 кило
Ну например Инструктора (предположительно). 30 плагов по 30 кило = 900 кило. Сейчас плаги весят 1.2МБ. Не жирновато ли 75% избыточности(а по честному ещё больше)?
правда, неизвестно, какой при этом получается объём бинарник
Реализация MS 500КБ, думаю что от ХромоЛиса будет больше.
Post Reply