Вообще, мне «нравится», как технологию, на этот раз COM/OLE/ActiveX клеймят устаревшей, такой, сякой нехорошей, но причины оказываются не очень-то объективными, а именно:
Она появилась не вчера (и поэтому на модных курсах про неё ничего не рассказывают, и поэтому приходится довольствоваться обрывками информации, где-то услышанными)
Мы нифига её толком не знаем, поэтому наступаем на всевозможные грабли, например, неправильно инициализируем аппартамент.
CLSID_WebBrowser — это глобальный идентификатор объекта.
Это уникальный идентификатор класса, а не объекта. А уже объект это экземпляр класса. А вот глобальным идентификатором объекта мог бы стать тот самый OBJREF-моникер, приведённый к строковому предсавлению, про которой я написал выше.
Но увы, в реестре у CLSID_WebBrowser нет записи LocalServer32. Есть только запись InProcServer32, которая указывает на DLL. То есть Internet Explorer не работает как отдельный EXE‑сервер — в Microsoft не предусмотрено такого сценария.
Это не правда. В Microsoft как раз-таки предусмотрели такой сценарий.
Такой сценарий, когда COM-сервер, реализованный в виде DLL, не должен попасть в адресное пространство клиентского процесса, а должен работать в рамках отдельного процесса (как если бы COM-сервер сам был реализован в виде EXE) предусмотрен.
Техника называется COM Surrogate. Более того, Microsoft предусмотрела, что вы можете воспользоваться встроенной системной реализацией процесса-суррогата (исполняемый файл называется %windir%\System32\dllhost.exe — знакомое имя, не так ли?) либо написать свой кастомный.
Вы написали свой собственный, но назвали его Proxy, и не следовали тем правилам и соглашениям, которые установил Microsoft.
Internet Explorer работает внутри 32-битного процесса — по сути, это окно (hwnd), созданное в этом же процессе. А значит, все сообщения, связанные со взаимодействием с веб‑страницей (например, когда она в фокусе), будут приходить именно в наш прокси‑процесс. И чтобы они обрабатывались корректно, прокси обязан иметь свой собственный цикл обработки сообщений.
То есть, если бы он был не окном (hwnd), и если бы он вообще никак не связан был бы с пользовательским интерфейсом и каким бы то ни было взаимодействием с пользователем, а речь шла бы о какой-нибудь библиотеке, которая делает FFT, то цикл проачки оконных сообщений был бы не нужен?
Как бы не так: раз вы сделали CoMarshall/CoUnmarshall и создали пару proxy/stub объектов, то всё ваше межпроессное RPC как раз и работает под капотом за счёт обмена оконными сообщениями. Поэтому, в первую очередь, именно по этому вам нужен цикл обработки оконных сообщений. А не потому что IE это по сути окно.
Мне тоже нужно, но мне нужно, чтобы оно открывалось мгновенно. IDE, которая полчаса думает, меня не устраивает, я возьму старую IDE, которая молниеносно реагирует.
А ещё, то, с чем вы спорите, как вы говорите, я поправил за несколько часов до вашей предъявы мне в комментарии:
Коммент, к которому была претензия, не правился. И сделанное там громкое заявление нигде ниже уровнем не отменялось, не опровергалось. А только дополнялось новыми мыслями. Точнее там даже не одно спорное заявление, а несколько.
Я это видел. Я не проигнорировал, а с трудом удержался увидев перечисление «Trident, ActiveX, VBScript, JScript» не процитировать древний мем из аудиозаписи лекции по информатике:
В настоящее время в сети существует (живут, существуют) большое количество разнообразных злоумышленников: хакеры, крэкеры, спамы, куки, троянские кони.
Оригинал тут
Всё намешано в кучу, но особо выделяется в этом ряду «ActiveX».
Но это дополнение с непонятным перечислением разнородных терминов не опровергает и не переиначивает изначальный посыл, а точнее их было два:
Проводник является хитро запущенным IE под Windows XP.
Под Windows XP отображение содержимого папки, то есть всё, что ниже тулбара является веб-страницей.
Во-первых, мы уже выяснили, что к XP это вообще не имеет отношения.
Во-вторых, если даже взять какую-нибудь Windows 98, где был вот этот режим (как опция, а не единственный вариант существования),а а также был Active Desktop — а они устроены немного по разному — то всё равно содержимое папки не отображалось с помощью веб-страницы.
Это решение уровня:
А давайте мы в окне Проводника вместо контрола SysListView32 положим IE-фрейм, а уже внутри IE-фрейма поместим изначальный SysListView32.
В итоге ради того, чтобы пользователь мог кастомизировать внешний вид папки, сделан опциональный режим, в котором используется промежуточный контейнер (способный отображать HTML-документ ради создания того самого краевого оформления), внутри в центре которого по прежнему лежит нативный контрол.
Вся суть и соль отображения содержимого папки: файлики, папочки, значки, ярлычки, выделение файлов, табличный режим с заголовками и сортировкой при кликах по заголовкам, мелкие значки, крупные значки — всё это:
а) Нативный контрол, тот же самый ListView, какой был бы если бы ради краевого оформления режим промежуточного контейнера не привлекался
б) Не состоит из DOM-элементов и не является поддеревом DOM родительского IE-фрейма (кроме самого контрола FileList — он весь целиком представлен одним единственным DOM-узлом типа <object>).
в) Не подчиняется CSS веб-страницы, в которую он встроен. Ни с помощью CSS нельзя поменять размер или начертание шрифтов в файлов (всех или выборочно), ни с помощью JScript/VBScript из родительского страницы не получится раздвинуть два значка файлов и между ними вставить элемент <marque>, или <div>, или <table> или что угодно HTML-ное.
Отображение самого содержимого папки — не веб-страница, а нативный контрол. Но сделан режим, в котором между родительским окном и нативным контролом промежуточным контейнером выступает IE-фрейм ради возможности создать краевой оформление (то есть не только боковую левую панель, но и что-то сверху, что-то справа, что-то снизу — при желании).
--------------------
C Active Desktop и рабочим столом всё обстоит по другому: если в окне проводника нативный ListView с непрозрачным фоном лежит внутри HTML-документа, то есть один child, а другой parent, то в случае с рабочим столом ListView с прозрачным фоном лежит поверх IE-фрейма, то есть в случае иерхархии окон (тех, у которых есть HWND) они сиблинги.
------------------
Тот факт, что в окне Проводника в определённом режиме работы (то есть при определённых настройках) встроен контрол, который в первую очередь является частью приложения Internet Explorer, не делает проводник хитро запущенным Internet Explorer-ом.
Тем более оно не делает его хитро запущенным Explorer-ом под XP, где такого вообще нет. Но даже в условном Windows 98 — тоже не делает, потому что с тем же успехом автокадовский документ мог быть внедрён (слава технологии OLE, которая просто стандартизирует единый «протокол» для контролов, которые хотят быть внедряемыми, — с одной стороны, и контейнеров, которые хотят в себя что-то внедрять, — с другой) в Excel-документ, а сам Excel-документ мог быть внедрён в Word-документ.
Это же не делает Excel хитро запущенным АвтоКАДом, а Word — хитро запущенной экселькой?
У меня нет установленного АвтоКАДа, но есть установленный Компас, и я легко могу воспроизвести то, о чём говорю:
Раз
Два
Три
Четыре
Пять
Является ли то, что показано на этих 5 скриншотах доказательством того, что:
Excel это просто хитро запущенный Word
Word это всего лишь хитро запущенный Excel
Excel и Word это одно и то же
Компас-3D это всего лишь хитро запущенный Excel
Excel это всего лишь хитро запущенный Компас-3D
Компас-3D является неотъемлемой частью Excel и Word?
Во-вторых, признайте уже, что вы можете не знать всего.
Конечно, могу чего-то не знать. И в этом случае я беру инструменты, такие как тот же Spy++, отладчик, дизассемблер и иду смотреть, как оно устроено, а не перепощиваю мифы и байки.
то это играет мне на руку потому, что смысл моего комментария был в том, что идея не нова.
Какая именно идея? Идея строить UI прикладных приложений используя HTML-документ?
А вот и нет!
Ни в XP, ни в более ранних версиях ОС авторы не использовали HTML-документы и IE-frame для того, чтобы с их помощью реализовать именно интерфейс прикладных приложений.
Можете привести ещё примеры? Единственный известный мне пример использования веб-страницы в рамках других приложений: это HTMLHelp (с .chm-файлами) пришедший на смену Win95 Help (.hlp-файлы) на базе RTF-документов. Но здесь с помощью HTML отображается контент, текст с разметкой, гипертекст (то есть именно то, для чего HTML исходно задуман), а вовсе не интерфейс приложения.
Примеров, чтобы HTML использовался для отображения именно интерфейса приложения, а не контента приложения, я не могу вспомнить.
Ну а в проводнике HTML применён для кастомизации рядовым пользователем своих папок. Хочешь кастомизировать отображение своей папке — тебе не нужно быть программистом, не нужно иметь IDE, не нужно иметь компилятор, не нужно знать глубокое устройство Windows.
Для тебя, как для рядового пользователя, сделали специальный мастер:
То есть по задумке авторов это сделано для того, чтобы любая домохозяйка могла кастомизировать себе внешний вид папки. Ну, не любая, но изучившая HTML и JS. Прямо в проводник для этого встроен пунктик меню, мастер и HTML-открывается прямо в Блокноте.
Electron, хотя я про него почти ничего не знаю, создан не из таких предпосылок. Он не сделан для того, чтобы широкий круг пользователь мог кастомизировать какую-то маленькую часть внутри нативного приложений.
Он сделан таким, каким он сделан, не для того, чтобы кто-то из рядовых пользователей лез что-то модифицировать в чужом приложении, не поднимаясь до уровня разработчика по знаниям. Он таким сделан потому, что разработки деградировали до уровня домохозяек — если не по уровню знаний, то по уровню беззаботности.
Так что это не та же идея.
Я не вижу и не помню ни в XP, ни в более ранних ОС примеров именно интерфейсов на HTML+JS/VBS.
По итогу, в двух провокационных комментах выше высказывалось сразу 3 тезиса:
Прообраз Electron-а был заложен ещё во время Win9x — не правда, потому в прикладных приложениях для реализации UI никто (в Microsoft) не использовал тогда HTML+JS, а в Проводнике это было сделано для кастомизации.
Отображение папки в Windows XP — это веб-страница. Не правда, потому что в XP никаких веб-страниц не использовалось, и даже в более ранних ОС сам контент папки отображался нативным контролом ListView, а веб-страница использовалась только для создания какого-то краевого оформления вокруг этого нативного контрола.
Проводник это хитро запущенный IE. Не правда, потому что модульная архитектура приложений и наличие стандартизированного способа встраивания объектов не делает одно приложение тщательно маскирующимся другим приложением или не делает одно приложение неотъемлемой частью другого.
То, что между разными приложениями в огромной мере есть code reuse за счёт использования одних и тех же DLL, компонентов, реализации одних и тех же COM-интерфейсов — это не ставилось под сомнение. Вам об этом и написали сразу.
В Windows XP Проводник и сам рабочий стол являлись хитро запущенным Internet Explorer.То, что отображалось в самой папке ниже тулбара, к примеру, было веб-страницей.
Я написал, что ничего подобного.
На что последовало «разоблачение» меня:
Так вот, врёте и вы, только у вас не хватит сил этого признать. И вот почему:
Людям свойственно смиряться с проблемой, побухтев некоторое время. Это не значит, что проблема решена.
После прочтения захотелось глаза пойти помыть.
Цена? В личку напишу... Цену в студию!
Это что, четырехквадрантный ЛБП?
Конечно же нет. А если так, что там делает кнопка OVP? Такая же профанация, как на моём Korad KA3010.
🤦♂️
Вообще, мне «нравится», как технологию, на этот раз COM/OLE/ActiveX клеймят устаревшей, такой, сякой нехорошей, но причины оказываются не очень-то объективными, а именно:
Она появилась не вчера (и поэтому на модных курсах про неё ничего не рассказывают, и поэтому приходится довольствоваться обрывками информации, где-то услышанными)
Мы нифига её толком не знаем, поэтому наступаем на всевозможные грабли, например, неправильно инициализируем аппартамент.
Это уникальный идентификатор класса, а не объекта. А уже объект это экземпляр класса. А вот глобальным идентификатором объекта мог бы стать тот самый OBJREF-моникер, приведённый к строковому предсавлению, про которой я написал выше.
Это не правда. В Microsoft как раз-таки предусмотрели такой сценарий.
Такой сценарий, когда COM-сервер, реализованный в виде DLL, не должен попасть в адресное пространство клиентского процесса, а должен работать в рамках отдельного процесса (как если бы COM-сервер сам был реализован в виде EXE) предусмотрен.
Бымс!
Техника называется COM Surrogate. Более того, Microsoft предусмотрела, что вы можете воспользоваться встроенной системной реализацией процесса-суррогата (исполняемый файл называется %windir%\System32\dllhost.exe — знакомое имя, не так ли?) либо написать свой кастомный.
DLL Surrogates
Using system-supplied surrogate
Writing custom surrogate
Вы написали свой собственный, но назвали его Proxy, и не следовали тем правилам и соглашениям, которые установил Microsoft.
То есть, если бы он был не окном (hwnd), и если бы он вообще никак не связан был бы с пользовательским интерфейсом и каким бы то ни было взаимодействием с пользователем, а речь шла бы о какой-нибудь библиотеке, которая делает FFT, то цикл проачки оконных сообщений был бы не нужен?
Как бы не так: раз вы сделали CoMarshall/CoUnmarshall и создали пару proxy/stub объектов, то всё ваше межпроессное RPC как раз и работает под капотом за счёт обмена оконными сообщениями. Поэтому, в первую очередь, именно по этому вам нужен цикл обработки оконных сообщений. А не потому что IE это по сути окно.
И почему было не воспользоваться objref-моникерами вместо огорода с пайпами и ручным маршаллингом?
Так в чем абсурдность, про которую говорится в заголовке?
После Си-подобных языков синтаксис этого чуда оказывает на психику такое же явление, как йазыг падонкофф на учителя русского языка.
Ваши бы слова да богу в уши.
То что вы пишите про C/C++, это правда и я с эти согласен. Проблема в том, что слишком многие с этим не согласны.
Так какая связь между стилистикой интерфейса, претензиям к интерфейсу и выбором ЯП?
Что-то я непонял перескок на чёрный UI как у Блендера.
Мне тоже нужно, но мне нужно, чтобы оно открывалось мгновенно. IDE, которая полчаса думает, меня не устраивает, я возьму старую IDE, которая молниеносно реагирует.
Я про вот это:
Коммент, к которому была претензия, не правился. И сделанное там громкое заявление нигде ниже уровнем не отменялось, не опровергалось. А только дополнялось новыми мыслями. Точнее там даже не одно спорное заявление, а несколько.
Я это видел. Я не проигнорировал, а с трудом удержался увидев перечисление «Trident, ActiveX, VBScript, JScript» не процитировать древний мем из аудиозаписи лекции по информатике:
Оригинал тут
Всё намешано в кучу, но особо выделяется в этом ряду «ActiveX».
Но это дополнение с непонятным перечислением разнородных терминов не опровергает и не переиначивает изначальный посыл, а точнее их было два:
Проводник является хитро запущенным IE под Windows XP.
Под Windows XP отображение содержимого папки, то есть всё, что ниже тулбара является веб-страницей.
Во-первых, мы уже выяснили, что к XP это вообще не имеет отношения.
Во-вторых, если даже взять какую-нибудь Windows 98, где был вот этот режим (как опция, а не единственный вариант существования),а а также был Active Desktop — а они устроены немного по разному — то всё равно содержимое папки не отображалось с помощью веб-страницы.
Это решение уровня:
В итоге ради того, чтобы пользователь мог кастомизировать внешний вид папки, сделан опциональный режим, в котором используется промежуточный контейнер (способный отображать HTML-документ ради создания того самого краевого оформления), внутри в центре которого по прежнему лежит нативный контрол.
Вся суть и соль отображения содержимого папки: файлики, папочки, значки, ярлычки, выделение файлов, табличный режим с заголовками и сортировкой при кликах по заголовкам, мелкие значки, крупные значки — всё это:
а) Нативный контрол, тот же самый ListView, какой был бы если бы ради краевого оформления режим промежуточного контейнера не привлекался
б) Не состоит из DOM-элементов и не является поддеревом DOM родительского IE-фрейма (кроме самого контрола FileList — он весь целиком представлен одним единственным DOM-узлом типа <object>).
в) Не подчиняется CSS веб-страницы, в которую он встроен. Ни с помощью CSS нельзя поменять размер или начертание шрифтов в файлов (всех или выборочно), ни с помощью JScript/VBScript из родительского страницы не получится раздвинуть два значка файлов и между ними вставить элемент <marque>, или <div>, или <table> или что угодно HTML-ное.
Отображение самого содержимого папки — не веб-страница, а нативный контрол. Но сделан режим, в котором между родительским окном и нативным контролом промежуточным контейнером выступает IE-фрейм ради возможности создать краевой оформление (то есть не только боковую левую панель, но и что-то сверху, что-то справа, что-то снизу — при желании).
--------------------
C Active Desktop и рабочим столом всё обстоит по другому: если в окне проводника нативный ListView с непрозрачным фоном лежит внутри HTML-документа, то есть один child, а другой parent, то в случае с рабочим столом ListView с прозрачным фоном лежит поверх IE-фрейма, то есть в случае иерхархии окон (тех, у которых есть HWND) они сиблинги.
------------------
Тот факт, что в окне Проводника в определённом режиме работы (то есть при определённых настройках) встроен контрол, который в первую очередь является частью приложения Internet Explorer, не делает проводник хитро запущенным Internet Explorer-ом.
Тем более оно не делает его хитро запущенным Explorer-ом под XP, где такого вообще нет. Но даже в условном Windows 98 — тоже не делает, потому что с тем же успехом автокадовский документ мог быть внедрён (слава технологии OLE, которая просто стандартизирует единый «протокол» для контролов, которые хотят быть внедряемыми, — с одной стороны, и контейнеров, которые хотят в себя что-то внедрять, — с другой) в Excel-документ, а сам Excel-документ мог быть внедрён в Word-документ.
Это же не делает Excel хитро запущенным АвтоКАДом, а Word — хитро запущенной экселькой?
У меня нет установленного АвтоКАДа, но есть установленный Компас, и я легко могу воспроизвести то, о чём говорю:
Раз
Два
Три
Четыре
Пять
Является ли то, что показано на этих 5 скриншотах доказательством того, что:
Excel это просто хитро запущенный Word
Word это всего лишь хитро запущенный Excel
Excel и Word это одно и то же
Компас-3D это всего лишь хитро запущенный Excel
Excel это всего лишь хитро запущенный Компас-3D
Компас-3D является неотъемлемой частью Excel и Word?
Конечно, могу чего-то не знать. И в этом случае я беру инструменты, такие как тот же Spy++, отладчик, дизассемблер и иду смотреть, как оно устроено, а не перепощиваю мифы и байки.
Какая именно идея? Идея строить UI прикладных приложений используя HTML-документ?
А вот и нет!
Ни в XP, ни в более ранних версиях ОС авторы не использовали HTML-документы и IE-frame для того, чтобы с их помощью реализовать именно интерфейс прикладных приложений.
Можете привести ещё примеры? Единственный известный мне пример использования веб-страницы в рамках других приложений: это HTMLHelp (с .chm-файлами) пришедший на смену Win95 Help (.hlp-файлы) на базе RTF-документов. Но здесь с помощью HTML отображается контент, текст с разметкой, гипертекст (то есть именно то, для чего HTML исходно задуман), а вовсе не интерфейс приложения.
Примеров, чтобы HTML использовался для отображения именно интерфейса приложения, а не контента приложения, я не могу вспомнить.
Ну а в проводнике HTML применён для кастомизации рядовым пользователем своих папок. Хочешь кастомизировать отображение своей папке — тебе не нужно быть программистом, не нужно иметь IDE, не нужно иметь компилятор, не нужно знать глубокое устройство Windows.
Для тебя, как для рядового пользователя, сделали специальный мастер:
То есть по задумке авторов это сделано для того, чтобы любая домохозяйка могла кастомизировать себе внешний вид папки. Ну, не любая, но изучившая HTML и JS. Прямо в проводник для этого встроен пунктик меню, мастер и HTML-открывается прямо в Блокноте.
Electron, хотя я про него почти ничего не знаю, создан не из таких предпосылок. Он не сделан для того, чтобы широкий круг пользователь мог кастомизировать какую-то маленькую часть внутри нативного приложений.
Он сделан таким, каким он сделан, не для того, чтобы кто-то из рядовых пользователей лез что-то модифицировать в чужом приложении, не поднимаясь до уровня разработчика по знаниям. Он таким сделан потому, что разработки деградировали до уровня домохозяек — если не по уровню знаний, то по уровню беззаботности.
Так что это не та же идея.
Я не вижу и не помню ни в XP, ни в более ранних ОС примеров именно интерфейсов на HTML+JS/VBS.
По итогу, в двух провокационных комментах выше высказывалось сразу 3 тезиса:
Прообраз Electron-а был заложен ещё во время Win9x — не правда, потому в прикладных приложениях для реализации UI никто (в Microsoft) не использовал тогда HTML+JS, а в Проводнике это было сделано для кастомизации.
Отображение папки в Windows XP — это веб-страница. Не правда, потому что в XP никаких веб-страниц не использовалось, и даже в более ранних ОС сам контент папки отображался нативным контролом ListView, а веб-страница использовалась только для создания какого-то краевого оформления вокруг этого нативного контрола.
Проводник это хитро запущенный IE. Не правда, потому что модульная архитектура приложений и наличие стандартизированного способа встраивания объектов не делает одно приложение тщательно маскирующимся другим приложением или не делает одно приложение неотъемлемой частью другого.
То, что между разными приложениями в огромной мере есть code reuse за счёт использования одних и тех же DLL, компонентов, реализации одних и тех же COM-интерфейсов — это не ставилось под сомнение. Вам об этом и написали сразу.
Изначальное громкое утверждение:
Я написал, что ничего подобного.
На что последовало «разоблачение» меня:
Тем временем, по приведённой ссылке:
В основном в драйверах. А крайне неспреведливо называть ОС плохими словами из-за кривых драйверов.
Read-only с возможностью изменить на copy-on-write.
Вот бы на Хабре вместо бесполезного переключателя «Светлая тема»/«Тёмная тема» был переключатель «Синтаксис Intel»/«Синтаксис AT&T».
Нет, это отключаемое поведение.