Сообщение Re[8]: А что мешает заменить JS? от 26.03.2017 16:39
Изменено 27.03.2017 9:04 vdimas
Re[8]: А что мешает заменить JS?
Здравствуйте, alex_public, Вы писали:
V>>Перлы и прочие Питоны были в скрипте браузера IE почти сразу (ActivePerl, ActivePython).
_>Ну правильнее говорить об этом просто как о соответствующих ActiveX.
Не ведись ты на эти аббревиатуры. ))
Изначально MS решила выделить из мн-ва OLE-интерфейсов только минимально-необходимый набор для in-proc компонент. Грубо говоря, встала задача не только встраивать документы, обрабатываемые разными процессами? друг в друга, но и потребовались обычные, блин, гетерогенные (с т.з. языка) подгружаемые в процесс библиотеки.
Ну тут MS и делает ход конём, т.е. для обычных библиотек весело так использует всё ту же самую технологию OLE, за исключением всех моментов вокруг out of proc серверов. Это чтобы люди не пугались, что для обычных библиотек используются аж межпроцессное сообщение (это не так, ес-но, но всем же не объяснишь, верно?), поэтому пошёл такой мем у них — ActiveX. В графике DirectX, тут ActiveX, там прямо, здесь активно, созвучно с FX — ("крутые" музыкальные эффекты), тра-та-та, маркетинг.
Т.е., считай, что всё in-proc OLE поначалу так называлось.
Но не прижилось. В итоге название ActiveX закрепилось потом за визуальными in-proc контролами или которые имеют визуальный дизайнер. А за невизуальными закрепилось простое "COM-объект". Просто семейство интерфейсов WSH было одним из первых, вернее, родилось аккурат одновременно с рождением отдельного направления ActiveX, поэтому так и закрепилось за ними Active Scripting.
В общем, смотрю, путаница идёт до сих пор.
А в вики вообще черти что написано, сама себе в двух абзацах противоречит. ))
_>Кстати, как раз подтверждение моего тезиса о том, что как только появляется хоть какой-то путь (даже такой кривой как ActiveX)
А что там кривого-то?
Это простейшая система.
Весь исходный стандарт ActiveX — это просто IUnknown + еще IDispatch для скриптов (громко называемых "автоматизацией")
Даже на сегодня ты ничего прямее не найдёшь.
Сейчас всё работает хуже, тактов процессора жрет больше и что больше всего бесит — каждый изгаляется на свой лад.
Т.е. у каждой библиотеки свои правила управления временем жизни объектов, где мы вынуждены любоваться на плоды фантазий авторов разной испорченности. ))
COM в этом плане очень облегчал жизнь, бо не плодил зоопарк из конкурирующих систем подсчета банальных ссылок.
_>для проталкивания в браузер других языков, как этим сразу же пользуется множество людей (а сейчас они все посматривают на wasm).
Да. Альтернативные языки сдохли сугубо из-за упрямства Нетскейпа, а потом Мозиллы.
Хотя причина была на поверхности — эти ребята не осилили бы в те времена сделать универсальный скриптовый интерфейс к своему браузеру.
У них во все времена JS был прибит к браузеру гвоздями.
_>И сдохло оно вследствие судьбы ActiveX, а не из-за недостатков этих языков.
Когда сдыхали альтернативные языки, ActiveX был еще в самом разгаре, бо конкурирующих технологий, считай, не было.
Помимо Дельфей и Борланд-билдера это же была единственная живая windowsless-технология GUI.
Я в своё время поупражнялся на ATL/WTL, так потом на MFC смотреть не мог, как оно подтормаживает на каком-нить Селероне 333. ))
ActiveX-контролы просто летали.
В общем, проблема-то была не в COM-технологии, а в том, что операционки того времени были дырявые, как меха старого баяна.
Подгружаемая с сети DLL линковалась в процесс с точно такими же системными библиотеками, как и приложение-хост.
Начиная с Windows 8 бери современный "контейнер приложений" (за эти громким названием скрывается всего-навсего урезанное АПИ виндов для некоего процесса), и загружай что хошь откуда хошь )) Если у загруженного кода нет доступа к банальной GetLibrary и прочих из этой области, то такой подгруженный модуль становится беспомощным и относительно безопасным.
V>>Перлы и прочие Питоны были в скрипте браузера IE почти сразу (ActivePerl, ActivePython).
_>Ну правильнее говорить об этом просто как о соответствующих ActiveX.
Не ведись ты на эти аббревиатуры. ))
Изначально MS решила выделить из мн-ва OLE-интерфейсов только минимально-необходимый набор для in-proc компонент. Грубо говоря, встала задача не только встраивать документы, обрабатываемые разными процессами? друг в друга, но и потребовались обычные, блин, гетерогенные (с т.з. языка) подгружаемые в процесс библиотеки.
Ну тут MS и делает ход конём, т.е. для обычных библиотек весело так использует всё ту же самую технологию OLE, за исключением всех моментов вокруг out of proc серверов. Это чтобы люди не пугались, что для обычных библиотек используются аж межпроцессное сообщение (это не так, ес-но, но всем же не объяснишь, верно?), поэтому пошёл такой мем у них — ActiveX. В графике DirectX, тут ActiveX, там прямо, здесь активно, созвучно с FX — ("крутые" музыкальные эффекты), тра-та-та, маркетинг.
Т.е., считай, что всё in-proc OLE поначалу так называлось.
Но не прижилось. В итоге название ActiveX закрепилось потом за визуальными in-proc контролами или которые имеют визуальный дизайнер. А за невизуальными закрепилось простое "COM-объект". Просто семейство интерфейсов WSH было одним из первых, вернее, родилось аккурат одновременно с рождением отдельного направления ActiveX, поэтому так и закрепилось за ними Active Scripting.
В общем, смотрю, путаница идёт до сих пор.
А в вики вообще черти что написано, сама себе в двух абзацах противоречит. ))
_>Кстати, как раз подтверждение моего тезиса о том, что как только появляется хоть какой-то путь (даже такой кривой как ActiveX)
А что там кривого-то?
Это простейшая система.
Весь исходный стандарт ActiveX — это просто IUnknown + еще IDispatch для скриптов (громко называемых "автоматизацией")
Даже на сегодня ты ничего прямее не найдёшь.
Сейчас всё работает хуже, тактов процессора жрет больше и что больше всего бесит — каждый изгаляется на свой лад.
Т.е. у каждой библиотеки свои правила управления временем жизни объектов, где мы вынуждены любоваться на плоды фантазий авторов разной испорченности. ))
COM в этом плане очень облегчал жизнь, бо не плодил зоопарк из конкурирующих систем подсчета банальных ссылок.
_>для проталкивания в браузер других языков, как этим сразу же пользуется множество людей (а сейчас они все посматривают на wasm).
Да. Альтернативные языки сдохли сугубо из-за упрямства Нетскейпа, а потом Мозиллы.
Хотя причина была на поверхности — эти ребята не осилили бы в те времена сделать универсальный скриптовый интерфейс к своему браузеру.
У них во все времена JS был прибит к браузеру гвоздями.
_>И сдохло оно вследствие судьбы ActiveX, а не из-за недостатков этих языков.
Когда сдыхали альтернативные языки, ActiveX был еще в самом разгаре, бо конкурирующих технологий, считай, не было.
Помимо Дельфей и Борланд-билдера это же была единственная живая windowsless-технология GUI.
Я в своё время поупражнялся на ATL/WTL, так потом на MFC смотреть не мог, как оно подтормаживает на каком-нить Селероне 333. ))
ActiveX-контролы просто летали.
В общем, проблема-то была не в COM-технологии, а в том, что операционки того времени были дырявые, как меха старого баяна.
Подгружаемая с сети DLL линковалась в процесс с точно такими же системными библиотеками, как и приложение-хост.
Начиная с Windows 8 бери современный "контейнер приложений" (за эти громким названием скрывается всего-навсего урезанное АПИ виндов для некоего процесса), и загружай что хошь откуда хошь )) Если у загруженного кода нет доступа к банальной GetLibrary и прочих из этой области, то такой подгруженный модуль становится беспомощным и относительно безопасным.
Re[8]: А что мешает заменить JS?
Здравствуйте, alex_public, Вы писали:
V>>Перлы и прочие Питоны были в скрипте браузера IE почти сразу (ActivePerl, ActivePython).
_>Ну правильнее говорить об этом просто как о соответствующих ActiveX.
Не ведись ты на эти аббревиатуры. ))
Изначально MS решила выделить из мн-ва OLE-интерфейсов только минимально-необходимый набор для in-proc компонент. Грубо говоря, встала задача не только встраивать документы, обрабатываемые разными процессами, друг в друга, но и потребовались обычные, блин, гетерогенные (с т.з. языка) подгружаемые в процесс библиотеки.
Ну тут MS и делает ход конём, т.е. для обычных библиотек весело так использует всё ту же самую технологию OLE, за исключением всех моментов вокруг out of proc серверов. Это чтобы люди не пугались, что для обычных библиотек используются аж межпроцессное сообщение (это не так, ес-но, но всем же не объяснишь, верно?), поэтому пошёл такой мем у них — ActiveX. В графике DirectX, тут ActiveX, там прямо, здесь активно, созвучно с FX — ("крутые" музыкальные эффекты), тра-та-та, маркетинг.
Т.е., считай, что всё in-proc OLE поначалу так называлось.
Но не прижилось. В итоге название ActiveX закрепилось потом за визуальными in-proc контролами или которые имеют визуальный дизайнер. А за невизуальными закрепилось простое "COM-объект". Просто семейство интерфейсов WSH было одним из первых, вернее, родилось аккурат одновременно с рождением отдельного направления ActiveX, поэтому так и закрепилось за ними Active Scripting.
В общем, смотрю, путаница идёт до сих пор.
А в вики вообще черти что написано, сама себе в двух абзацах противоречит. ))
_>Кстати, как раз подтверждение моего тезиса о том, что как только появляется хоть какой-то путь (даже такой кривой как ActiveX)
А что там кривого-то?
Это простейшая система.
Весь исходный стандарт ActiveX — это просто IUnknown + еще IDispatch для скриптов (громко называемых "автоматизацией")
Даже на сегодня ты ничего прямее не найдёшь.
Сейчас всё работает хуже, тактов процессора жрет больше и что больше всего бесит — каждый изгаляется на свой лад.
Т.е. у каждой библиотеки свои правила управления временем жизни объектов, где мы вынуждены любоваться на плоды фантазий авторов разной испорченности. ))
COM в этом плане очень облегчал жизнь, бо не плодил зоопарк из конкурирующих систем подсчета банальных ссылок.
_>для проталкивания в браузер других языков, как этим сразу же пользуется множество людей (а сейчас они все посматривают на wasm).
Да. Альтернативные языки сдохли сугубо из-за упрямства Нетскейпа, а потом Мозиллы.
Хотя причина была на поверхности — эти ребята не осилили бы в те времена сделать универсальный скриптовый интерфейс к своему браузеру.
У них во все времена JS был прибит к браузеру гвоздями.
_>И сдохло оно вследствие судьбы ActiveX, а не из-за недостатков этих языков.
Когда сдыхали альтернативные языки, ActiveX был еще в самом разгаре, бо конкурирующих технологий, считай, не было.
Помимо Дельфей и Борланд-билдера это же была единственная живая windowsless-технология GUI.
Я в своё время поупражнялся на ATL/WTL, так потом на MFC смотреть не мог, как оно подтормаживает на каком-нить Селероне 333. ))
ActiveX-контролы просто летали.
В общем, проблема-то была не в COM-технологии, а в том, что операционки того времени были дырявые, как меха старого баяна.
Подгружаемая с сети DLL линковалась в процесс с точно такими же системными библиотеками, как и приложение-хост.
Начиная с Windows 8 бери современный "контейнер приложений" (за этим громким названием скрывается всего-навсего урезанное АПИ виндов для некоего процесса), и загружай что хошь откуда хошь )) Если у загруженного кода нет доступа к банальной GetLibrary и прочих из этой области, то такой подгруженный модуль становится беспомощным и относительно безопасным.
V>>Перлы и прочие Питоны были в скрипте браузера IE почти сразу (ActivePerl, ActivePython).
_>Ну правильнее говорить об этом просто как о соответствующих ActiveX.
Не ведись ты на эти аббревиатуры. ))
Изначально MS решила выделить из мн-ва OLE-интерфейсов только минимально-необходимый набор для in-proc компонент. Грубо говоря, встала задача не только встраивать документы, обрабатываемые разными процессами, друг в друга, но и потребовались обычные, блин, гетерогенные (с т.з. языка) подгружаемые в процесс библиотеки.
Ну тут MS и делает ход конём, т.е. для обычных библиотек весело так использует всё ту же самую технологию OLE, за исключением всех моментов вокруг out of proc серверов. Это чтобы люди не пугались, что для обычных библиотек используются аж межпроцессное сообщение (это не так, ес-но, но всем же не объяснишь, верно?), поэтому пошёл такой мем у них — ActiveX. В графике DirectX, тут ActiveX, там прямо, здесь активно, созвучно с FX — ("крутые" музыкальные эффекты), тра-та-та, маркетинг.
Т.е., считай, что всё in-proc OLE поначалу так называлось.
Но не прижилось. В итоге название ActiveX закрепилось потом за визуальными in-proc контролами или которые имеют визуальный дизайнер. А за невизуальными закрепилось простое "COM-объект". Просто семейство интерфейсов WSH было одним из первых, вернее, родилось аккурат одновременно с рождением отдельного направления ActiveX, поэтому так и закрепилось за ними Active Scripting.
В общем, смотрю, путаница идёт до сих пор.
А в вики вообще черти что написано, сама себе в двух абзацах противоречит. ))
_>Кстати, как раз подтверждение моего тезиса о том, что как только появляется хоть какой-то путь (даже такой кривой как ActiveX)
А что там кривого-то?
Это простейшая система.
Весь исходный стандарт ActiveX — это просто IUnknown + еще IDispatch для скриптов (громко называемых "автоматизацией")
Даже на сегодня ты ничего прямее не найдёшь.
Сейчас всё работает хуже, тактов процессора жрет больше и что больше всего бесит — каждый изгаляется на свой лад.
Т.е. у каждой библиотеки свои правила управления временем жизни объектов, где мы вынуждены любоваться на плоды фантазий авторов разной испорченности. ))
COM в этом плане очень облегчал жизнь, бо не плодил зоопарк из конкурирующих систем подсчета банальных ссылок.
_>для проталкивания в браузер других языков, как этим сразу же пользуется множество людей (а сейчас они все посматривают на wasm).
Да. Альтернативные языки сдохли сугубо из-за упрямства Нетскейпа, а потом Мозиллы.
Хотя причина была на поверхности — эти ребята не осилили бы в те времена сделать универсальный скриптовый интерфейс к своему браузеру.
У них во все времена JS был прибит к браузеру гвоздями.
_>И сдохло оно вследствие судьбы ActiveX, а не из-за недостатков этих языков.
Когда сдыхали альтернативные языки, ActiveX был еще в самом разгаре, бо конкурирующих технологий, считай, не было.
Помимо Дельфей и Борланд-билдера это же была единственная живая windowsless-технология GUI.
Я в своё время поупражнялся на ATL/WTL, так потом на MFC смотреть не мог, как оно подтормаживает на каком-нить Селероне 333. ))
ActiveX-контролы просто летали.
В общем, проблема-то была не в COM-технологии, а в том, что операционки того времени были дырявые, как меха старого баяна.
Подгружаемая с сети DLL линковалась в процесс с точно такими же системными библиотеками, как и приложение-хост.
Начиная с Windows 8 бери современный "контейнер приложений" (за этим громким названием скрывается всего-навсего урезанное АПИ виндов для некоего процесса), и загружай что хошь откуда хошь )) Если у загруженного кода нет доступа к банальной GetLibrary и прочих из этой области, то такой подгруженный модуль становится беспомощным и относительно безопасным.