Создание dll для Symbian OS

Дмитрий Аксёнкин, dmaxy.tagan.ru

В Symbian OS dll (загружаемые библиотеки) могут быть статическими и полиморфическими.

Статические библиотеки позволяют поместить в них один или более классов, реализующих необходимую разработчику функциональность. Важно чтобы все public функции этих классов были помечены как экспортируемые.

Полиморфические dll представляют собой реализацию класса, которые наследует интерфейс от некоторого абстрактного класса и наполняет его содержанием. В этом случае единственной функцией, которую нужно экспортировать из библиотеки, является та, которая позволит создать объект, поставляемый dll. Благодаря таблице виртуальных функций, описанных во внешнем абстрактном классе мы получим доступ ко ВСЕМ виртуальным функциям объекта.

Поскольку в Symbian OS доступ к функциям осуществляется не по их именам, а по порядковым номерам их следования в библиотеке, то необходимо этот порядок зафиксировать, чтобы при изменениях в библиотеке, не менялся порядок экспортировая функций. Достигается это путем использования .def-файла.

.def файл - текстовый файл, который перечисляет экспортируемые из dll функции.
Он используется в "нумерованной" сборке чтобы вставить порядковую информацию в таблицу экспортируемых из DLL функций.
Исключительно важно создать этот файл для DLL с полиморфическим интерфейсом;
DLL статического интерфейса используют библиотеку импорта (.Lib), и получают всю существенную информацию о экпортируемых функциях из неё.

Для статической dll в файле проекта надо указать

#if defined(WINS)
    deffile .\CreateStaticDLLWINS.def
#else if defined(ARM)
    deffile .\CreateStaticDLLARM.def
#endif
nostrictdef 

deffile переопределяет .def файл который создается для проекта по умолчанию.

Назначение порядка следования функции контролируется .def-файлов в двух случаях: Dll с полиморфическим интерфес должна экспортировать какую-то конкретную функцию как следующию под номером 1. В этом случае .def определяет эту связь, в то время как другие могут иметь произвольный порядок следования.

Вновь выпускаемая , обновленная dll, должна быть использована клиентом, постоенным со старой версией. В этом случае def файл используется чтобы гарантировать что все функции экпортируемые из dll старой версии, экпортируются в том же порядке из новой dll. (Это может оказаться важным и для статических dll)

Для большинства полиморфических dll , предоставляется специальный тип цели сборки (TARGETTYPE), который гарантирует, что под номером 1 экспортируется правильная функция. Когда предоставляется TARGETTYPE .def файл может быть опущен.

Иногда, жаргонно, .def файлы называют замораживающими, т.к. они замораживают для экспортируемых функций связь между именем и порядком следования,.

Ряд инструментов GNU и Microsoft используют различные подходы для управления именами экспортируемых функций. Это означает, что .def-файлы с одинаковыми именами должны различаться с помощью хранения их в разных директориях..

Условно,
..\bmarm\ используется для ARM .def файла,
тогда как
..\bwins\ используются для WINSCW, WINS, и WINC .def файлов.
Путь указан относительно директории, где расположен файл проекта.

По умолманию, замораживающие .def файлы берут свои базовые имена от базовых имен целей своих проектов.

Когда замораживающий .def-файл переопределяется оператором deffile , путь к файлу должен быть определен как часть имени файла.

Если путь не определен, то файл поиск файла будет осуществляться в:

директории ..\bwins\ для платформ WINSCW, WINS, WINC, CW_IDE, VC6 and VC6WINC
директории ..\barm\ для ARM платформы

Если путь задается, поместите оператор deffile внутри #ifdefined(identifier), так что один и тот же файл не будет использован во время как ARM так и не-ARM сборок. Например:

	#if defined(WINS)
	deffile-stmt
	#else if defined(ARM)
	deffile-stmt
	#endif

Заметьте что имена макросов использованы с идентификатором #ifdefined(identifier) должны быть в верхнем регистре.

На этапе разработки не требуется замораживать порядок следования поэтому добавьте в файл проекта ключевой оператор EXPORTUNFROZEN.

В случае отсутствия этой строки компилятор будет сообщать о том, что проект незаморожен. (В любом случае сборку проекта всегда надо начинать с bldmake bldfiles.)

После того как вы окончательно завешите разработку иперед поставкой dll в другой проект, закомментируйте или удалите его. Это позволит вам "заморозить" функции.

Чтобы добиться этого проект надо пересобрать. Из командной строки это делается так

>bldmake bldfiles
>abld freeze wins 
>adld build wins udeb - сборка отладочной версии под wins. 

Если не указывать платформу то будет выполняться заморозка для всех платформ сборки

Внимание! Если, в процессе разработки, вы измените функции библиотеки, так, что они не будут совпадать с их описанием в def-файле (другой набор входных параметров или иной тип возвращаемого значения), то получите ошибку линкера. Чтобы устранить её надо удалить старый .def-файл из директорию соотвествующей варианту сборки. Т.е. ..\bwins\ для платформ WINSCW, WINS, WINC, CW_IDE, VC6 and VC6WINC и ..\barm\ для ARM платформы.

Разкоментировать или вставить в файл проекта EXPORTUNFROZEN, пересобрать проект, заморозить функции, и снова пересобрать.

В большинстве случаев, функции экспортируемые из dll зависят от TARGETTYPE. Это общее правило, поскольку имена классов дескрипторов зависят от того сборка широкая или узкая (16- или 8- разрядная). Для таких DLL используются различные .def-файлы-отличающиеся по использованию суффикса -u. Хотя узкие сборки больше не поддеживаются, суффикс u- все же использется для поддежания обратной совместимости с предыдущими версиями инструментов сборки. Зависящее от суффикса поведение может быть устранено с помощью использования nostrictdef.

Заметьте также что под WINSCW/WINS, когда используется тип сборки exedll , первый экспорт, это тот, который будет вызван, когда DLL будет загружена, поэтому вы должны использовать .def только для WINSCW/WINS варианта.

Makefiles создает библиотеку импорта связанную с исполняемым файлом (когда это применимо) непосредственно из замораживающего.def-файла, т.к. только "замороженные" экспортируемые функции появятся в библиотеке импорта и только эти непосредственные функции могут быть связаны снова с другими компонентами.

Для платформы ARM , также создаются библиотеки импорта для совместимости с ABI. Например, если проект строится для ARMI тогда будут созданы библиотеки импорта для ARMI, THUMB и ARM4 и если проект строится для THUMB, тогда будет созданы библиотеки импорта для ARMI и THUMB.

Внимание! После создания dll, особенно со статическим интерфейсом, лучшее место для их размещения на устройстве - папка /system/libs/ на любом логическом томе. Именно в этих папках на каждом логическом томе система ищет dll для статического связывания, если не находит их в той же папке к которой находится модуль статически связанный с dll. В случае если система не находит dll, это может привести к зависанию модуля и его остановке системой.