Здравствуйте,
есть ряд DLL(ActiveX) написанных на VB которые поставляют данные.
Для отображения данных начал писать XUL-интерфейс.
Напрямую из javascript вызвать объекты этих DLL нельзя.
Как я понимаю, можно создать XPCOM на С++ и из него
работать с вышеуказанными DLL.
Есть ли более простой способ?
Может есть сервисы позволяющие это сделать(создавать объекты из DLL)?
Нашел уже не поддерживаемый плагин, но стоит ли с ним связываться.
В перспективе хочу переписать эти DLL на C++ в виде XPCOM и перенести на Linux.
Но сейчас бы начать с XUL-интерфейса.

YuryL пишет

Есть ли более простой способ?

Нет. FF понятия не имеет ни про какой ActiveX, т.к. ActiveX - это специфика Microsoft. Поэтому - да, только XPCOM-компонент на C++. Теоретически еще можно делать вызовы через js-ctypes, но, по моему скромному, это совсем не более простой способ (и работать в сишном стиле через ctypes-прослойку с ActiveX я не пожелаю и врагу).

Большое спасибо,
пытаюсь создать тестовый компонент.
Много чего перечитал. Статьи по теме 2008, 2004,
а то и 2001 годов. Скачал Visual C++ 2010 express.
XULRUNNER-7.0-SDK. Пока ничего не получется.
Будет ли работать данная SDK с этим компилятором.
Возможно ли где найти работающий пример для
этого SDK? Погряз в информации....

YuryL
Вот здесь смотрели?

https://developer.mozilla.org/en/Gecko_FAQ#Are_Gecko's_APIs_based_on_ActiveX.3F_COM.3F_JavaBeans.3F

Спасибо, это тоже смотрел.
Думаю мне надо вначале определиться с компилятором.
Известно ли каким компилятором скомпилирован SDK 7.0?
Я думаю мне лучше установить такой же.
Visual C++ 2010 express - просто монстр. И .Net мне не нужен.
Хотя от него, наверное, не избавиться.

YuryL пишет

Хотя от него, наверное, не избавиться.

У VS2010 - без разницы, express, или не express - весь интерфейс сделан на WPF. А это самый что ни на есть .Net.
Я бинарники для расширения компилирую с помощью VS2010 prof. edition - всё собирается нормально. Насколько я помню, на MDC где-то были мануалы по компиляции с помощью mingw - поищите, может, получится.

пытался откомпилировать различные найденные мной в инете примеры, но так и не получилось.
Работал с VS2010 prof., xulrunner-sdk 7.0
Намерен еще попробовать с xulrunner-sdk 1.9.2 т.к. есть примеры с этой СДК.
Но этот СДК наверняка построен другой версией VS C++
Опять, видимо, не получится.

YuryL пишет

Но этот СДК наверняка построен другой версией VS C++

Версия сишных рантаймов здесь дело пятое. У этого СДК особенность в другом: то, что вы соберете в связке с ним, не будет работать на FF4.0 и выше. Потому что неприятная особенность XPCOM-компонентов после выхода 4-й версии заключается в следующем:

Traditionally, Mozilla has maintained a set of XPCOM interfaces and functions with the @status FROZEN marking. Using these interfaces, and using dynamic calls to QueryInterface, it has been possible to write binary XPCOM components which were compatible with multiple versions of Firefox. Beginning with Mozilla 2 (Firefox 4), this will no longer be supported: all @status markings have been removed,

and extensions that use binary components will need to recompile for each major version they wish to support

.

FF4.0 - это xulrunner 2.0, в более поздних версиях номер версии xulrunner соответствует версии FF (https://developer.mozilla.org/en/Gecko_SDK#Downloading)

YuryL пишет

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

а можно ссылку на эти примеры?

а можно ссылку на эти примеры?

взял пример по вашей ссылке, он для версии  Gecko 1.8.

#include "nsIGenericFactory.h"

уже не содержится в xulrunner-sdk 7.0 . Я нашел в инете на что его заменить.
После замены все равно выскочили ошибки компиляции.

пробовал также пример из https://developer.mozilla.org/en/Modularization_Techniques
компиляция не прошла, "внутренняя ошибка компиляции"...

остальные примеры что я нашел также содержат

#include "nsIGenericFactory.h"

Компилятор VS 2010 c++ для меня новый, последний раз писал на С лет 5 назад(VS C++ 6.0).
Может что не так сделал. Хотя старался действовать по инструкции.

Сейчас буду пробовать на работе VS установить.
Спасибо за участие.

YuryL пишет

пробовал также пример из https://developer.mozilla.org/en/Modularization_Techniques

Ну там как бы и написано, что содержимое могло сильно устареть, т.к. последний раз изменялось в 2004-м году :)
Я вечером из того, что имеется, попробую сделать тестовый helloworld. Как сделаю - дам ссылку на исходники.

Как обещал ранее, вот проект тестового XPCOM-компонента, и расширения к нему: http://xp-dev.com/svn/xpcom-test/trunk/
XPCOM-компонент в примере очень простой: принимает на вход стринг, возвращает его же, присоединив в конец строчку ": boo".

Сначала - настройка среды. На компьютере, помимо MS Visual Studio, должен быть Win32 platform SDK, C/C++ runtime libraries, и, разумеется, xulrunner SDK.
Структура папок проекта такова:

project-struct.png

(я переименовал папку с xullrunner SDK в gecko-sdk - так предлагалось сделать в каком-то примере, который я нашел в инете - с тех пор так и осталось).
В свойствах проекта необходимо указать следующее:

  • Configuration properties > C/C++ > General > Additional include directories: ..\gecko-sdk\include;%(AdditionalIncludeDirectories)
  • Configuration properties > C/C++ > Language > Treat Wchar_t as built-in type: No (/Zc:wchar_t-)
  • Configuration properties > C/C++ > Preprocessor > Preprocessor definitions: WIN32;_WINDOWS;_USRDLL;XP_WIN;XP_WIN32;MOZ_NO_MOZALLOC;%(PreprocessorDefinitions)
  • Configuration properties > Linker > General > Additional Library directories: ..\gecko-sdk\lib;%(AdditionalLibraryDirectories)
  • Configuration properties > Linker > Input > Additional dependencies: nspr4.lib;xpcom.lib;xpcomglue_s_nomozalloc.lib;

(всё это уже задано в файле проекта по ссылке выше).

Далее. Отправная точка - idl-файл. Это описатель интерфейса на диалекте IDL - XPIDL. По нему с помощью xpidl.exe генерируем интерфейсный файл .xpt (библиотека типа; содержит только информацию о контракте компонента), и интерфейсный хидер. Вот пример bat-файла, который выполняет оба эти действия сразу:

..\gecko-sdk\bin\xpidl.exe -m header -I..\gecko-sdk\idl %1
..\gecko-sdk\bin\xpidl.exe -m typelib -I..\gecko-sdk\idl %1

Все следующие шаги делались по образу и подобию того примера, о котором я упоминал выше.
После того, как нужные файлы были сгенерены, делаем хидер для реализации класса c объявлением в нем CID'a и contract id компонента. Далее пишем реализацию модульной части для nsIClassInfo. В последнюю очередь приступаем к написанию реализации класса.
В тестовом проекте:

  • nsIXPCOMTest.idl - описание интерфейса
  • nsIXPCOMTest.h - интерфейсный хидер
  • nsXPCOMTest.h - хидер для реализации класса
  • nsXPCOMTestModule.cpp - реализация модульной части для nsIClassInfo
  • nsXPCOMTest.cpp - реализация класса.

После этого можно компилировать. Если скомпилировалось успешно - делаем расширение для класса. Расширение тоже очень простое, но ввиду наличия компонента имеет некоторые нюансы:

1) в chrome.manifest нужны такие объявления:

interfaces components/nsIXPCOMTest.xpt

- объявляем интерфейсный файл

binary-component platform/WINNT_x86-msvc/xpcom-test.dll ABI=WINNT_x86-msvc

- объявляем бинарник с компонентом. В принципе, положить его можно куда угодно, но путь, приведенный выше (с указанием ABI в пути) - де-факто стандарт.

2) Обязательно в install.rdf надо указать

<em:unpack>true</em:unpack>

- бинарный компонент должен быть распакован при инсталляции расширения, иначе Firefox его не увидит.

3) Ввиду пункта 2, надо будет запаковать содержимое папки chrome в jar, и в chrome.manifest соответствующим образом указать пути к частям расширения внутри этой папки.

Практически это всё. Инстанциирование и вызов методов компонента стандартный:

Выделить код

Код:

var xtest=Components.classes["@mozilla.org/xpcomtest;1"].createInstance();
    var answer=xtest.sayTest(.....

Расширение с компонентом, скомпилированным под xulrunner 8.0 (еще раз напоминаю - с другими версиями скомпилированный компонент работать не будет) лежит здесь: http://xp-dev.com/svn/xpcom-test/trunk/xpcom-test.xpi.
Если нужно будет обеспечить совместимость расширения с несколькими версиями FF, то можно сделать так: в папку platform\[ABI_name] поместить несколько бинарников, скомпилированных под разные версии xulrunner, и с именами вида [library_name].x.dll, где х - номер версии xulrunner, под которую делалась компиляция. Выбор того или иного бинарника указывать с помощью versioning flags в chrome.manifest.

спасибо большое, hydrolizer!!!
dll построилась без ошибок.
Я использовал xulrunner-sdk 7.01.
Расширение не устанавливается, либо
устанавливается, но не работает.
Пытаюсь разобраться...

Ура!! заработало!!
видимо не правильно я установщик делаю.
В профиле появляется файл ***.jason
В данный момент не это главное.
Подправил руками в профиле и заработало.
спасибо, hydrolizer! очень помог!

нашел еще, видимо, актуальные примеры в исходниках Firefox.
Не пробовал с ними работать. Теперь, наверное, не понадобятся.

>>писал ночью, почему-то не отправилось(не отправил)<<

а насколько быстро меняются эти данные?
или там по запросу из дополнения?

система запланирована как "глобальная"))
данные меняются в он-лайне несколькими пользователями.
Работа будет не из дополнения, а из xulrunner-приложения.
VB-библиотеки планирую переписать на C++ на основе
xulrunner как фрэймворка и перенести все на Linux.
Так что мне в любом случае надо было разобраться с XPCOM.
Спасибо, еще раз!

Сегодня при попытке собрать проект под 17-ю версию xulrunner посыпались многочисленные ошибки. В ходе разбирательств было выяснено, что причина ошибок - в интерфейсном хидере, который был ранее сгенерирован с помощью xpidl.exe; также было выяснено, что в 17-й версии SDK нет этого xpidl.exe - начиная с 9-й версии для генерации хидера и библиотеки типа нужно использовать питоновские скрипты. Располагаются эти скрипты в папке sdk\bin самого SDK. Пример использования:

..\xulrunner-sdk\sdk\bin\header.py -I..\xulrunner-sdk\idl\ -o nsIXPCOMTest.h nsIXPCOMTest.idl
..\xulrunner-sdk\sdk\bin\typelib.py -I..\xulrunner-sdk\idl\ -o nsIXPCOMTest.xpt nsIXPCOMTest.idl

Подробнее см. здесь.
После перегенерации всё собралось нормально - т.е. в общем случае для каждого релиза xulrunner нужно делать перегенерацию этих файлов.

И еще новости об изменениях в процессе сборки. Для сборки с xulrunner sdk версии 19.0 в настройке проекта Configuration properties > C/C++ > General > Additional include directories помимо папки xulrunner-sdk\include нужно дополнительно указать папку xulrunner-sdk\include\nspr - без этого компиляция рванет.