Dll как SDK

[npak]

Тогда пусть разработчик библиотеки напишет одну функцию инициализации как extern "C" а остальные передаст как указатели в структуре.  ИМХО, довольно гибкая схема, поддерживает расширяемость, не предъявляет больших требований к совместимости компиляторов, которыми собраны приложение и dll
опять-таки множество народу ей пользуется.

Код:

 typedef struct _ServiceProvider_01 {
    int ApiVersion;
    OpenFunction Open;
    CloseFunction Close;
    ReadFunction Read;
    WriteFunction Write;
    IoCtrlFunction IoCtrl;
} ServiceProvider;
    
extern "C" int  __cdecl  Init(int minVersion, ServiceProvider ** pp_provider);

Поле ApiVersion позволит расширять возможности приложения и библиотек и сохранять при этом обратную совместимость.  Аргумент minVersion позволит приложению указать минимальную версию API которую библиотека должна предоставить приложению.  В pp_provider библиотека передаёт указатель на массив реализованных функций.

Если приложение предоставляет функции библиотеке (Extension API), то может делать это в той же самой манере -- через структуру с номером версии и массивом функций.  Указатель на структуру передавать функции Init при загрузке DLL

[Alf]

Тогда компилятор Microsoft искажает имя С-функции. впереди ставит знак подчеркивания, а к концу добавляет суффикс, состоящий из символа @ и числа байтов, передаваемых функции в качестве параметров.

Рихтер не оговаривает, о каком именно компиляторе идет речь? И применимы ли эти данные только к C или и к C++ тоже? Например, в моем случае функция

Код:

void MDString(char *str, unsigned char *d);

в DLL превращается в

Код:

?MDString@@YAXPADPAE@Z

(компилятор VC++ из состава VS.NET 2003).

[npak]

Код:

void MDString(char *str, unsigned char *d);

в DLL превращается в

Код:

?MDString@@YAXPADPAE@Z

(компилятор VC++ из состава VS.NET 2003).

Данный пример характерен только для Си++ (name mangling)
То, о чём пишет Рихтер, справедливо только для компилятора Си (без плюсов), проверено на VC 6.0 и VC 7 (.NET 2003)

Код:

int __declspec( dllexport ) WINAPI myFunc_WINAPI(int x, int y) { return x + y; }

int __declspec( dllexport ) __cdecl myFunc_cdecl(int x, int y) { return x + y; }

Даёт _myFunc_WINAPI@8 и  myFunc_cdecl соответственно.

[Finch]

Гром, у меня такой вопрос. Когда ты пишеш драйвера, Майкрософт волнует твои проблемы, что ты хочеш намного проше. Она тебе дала DDK. Сказала, что драйвер должен иметь определенную структуру и должен почти незамедлительно отвечать на определенные запросы и все. Майкрософт не волнует, что ты будеш творить внутри драйвера, это твои проблемы. Самое главное соблюдай внешний интерфейс. Также и здесь. Сделай шаблон .h файла. Заведи туду все функции интерфейса библиотеки. Задокументируй их и все. Как разработчик библиотеки будет реализовывать внутри, тебя не должно волновать, это его проблемы. Самое главное, чтобы интерфейсные функции отрабатывались однозначно согласно документации.

[Гром]

Finch тут вот какое дело...
Я ведь не майкрософт....

[Finch]

Гром, а разве разработчиков Far или WinAMP волновало проблемы стороних разработчиков. Они сделали четкий интерфейс плугина и все. Сказали, если хотите строить свои дополнения, делайте это по таким правилам. Иначе не будет работать.
Полиморфизм интерфейса при всей его привлекательности вызовет только больше головных болей у разработчиков. Так как ловля блох, когда не известно кто глючит, не самое привлекательное занятие. И нет строго определенных правил, значит будут разночтения. Да и основной модуль будет на порядки сложнее.

[Chaa]

Если не хочется ограничивать пользователя программы в средствах, то лучше, на мой взгляд, использовать COM. Тогда библиотеки можно будет на Delphi писать, на Visual Basic, или даже на JavaScript.

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

[Hooter]

Гром, если не секрет, почему такое трепетное отношение к пользователям уже готовой программы?
Пусть пишут как хотят, а потом сделают врапперы для существующего интерфейса.

[Гром]

Ну - давайте по порядку..

Chaa  - DLL  то же можно писать на любом языке - просто не использовать заголовки от С++. СОМ для этого без надобности...

Написание плагина на С++ на порядок проще чем написание его на СОМ для ИЕ.
Попробуй на РСДН почитать статьи (единственные кстати) по написанию плагина к ксплореру - мрак.

Да и не работает ничего....



Теперь о нежном отношении

Скажу прямо. Как вы сами смотрите - много ли сайтов начинавшихся с наколенной  сборки в виде страничке на фри хостинге прорывается на уровень 1000 и более посетителей в день и живет более 2-х месяцев?

Думаю, что все вы ответите - нет очень мало.

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

Дабы было понятно, я был в свое время частным предпринимателем и примерно понимаю как происходят продажи. Примерно - это мои 2-3 года в роли менеджера продаца и хозяина в одном лице с оборотом в городе до 400000 жителей в 10 000 бакосви доходом в 1000 - 1500 в месяц. Согласитесь - результат неплохой - если учесть что начиналось все с пустого места и комнате в студ. общаге....

Вывод - я немного понимаю в системе продаж вообще и в маркетинге в частности....

Далее, я работаю в западных системах софтвеного производства уже более 7 лет. Это говорит о факте моего близкого знакомства как к раздолбайскому процессу производства, так и о знакомстве с основными правилами местных продаж софта.

Проблема звучит так.

Майкрософт - как единственный крупный производитель самой распространенной системы в мире может позволить себе не думать о конечном пользователе.
Он заботится о гигантах клиентах - таких как АОЛ Боинг, и т.п.

Винамп  - не показатель, так как он бесплатен. Его плагины никак не влияют на процесс воспроизведения музыки - есть функциональность от плагинов независящая.



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

Идея сама по себе тривиальна, но ее нет в реализации, а спрос на нее есть и не маленький.


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

[Chaa]

Лично я, как пользователь, предпочел бы, чтобы с программой поставлялись готовые исходники одной из библиотек (м.б. самой простой). Чтобы открыв ее в Visual Studio я мог посмотреть код внутри функций Open/Close/Read/Write/IoCtrl и убрав его написать свой. Или изменить существующий под свои нужды.

[Гром]

Chaa - это само собой - простейший пример в виде исходников и бинарника будет в девелопмент пакете с лицензией.

[Hooter]

Поэтому основой моих изысканий в начале пути стоит след процесс. Я разрабатываю систему, которая должна жить годы.
...
Пользователи не должны зависить от моей работоспособности и им тоже должно быть удобно.

Почему же ты тогда настаиваешь на использовании С++?
Сам ведь сказал: можно использовать любой язык для создания DLL...

[Гром]

С++ базовый язык сегодняшнего дня.
Это раз.

При работе с тестами оборудовения никто не использует другого, ибо неудобно
Это два.

Однако при желании можно создавать нужные билиотеки на любом языке
Это три

[Hooter]

Если тебе не трудно, расскажи, плз, по какому пути ты решил развивать свое приложение дальше, когда определишься. Думаю, не мне одному будет интересно.

[Гром]

По пути одной функции extern "C"

[Finch]

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

[Гром]

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

[Chaa]

Все таки к C++ намного ближе COM, чем передача через одну функцию множества указателей.
Если использовать ATL, то написание и использование COM-объектов будет достаточно простым. Практически каркас COM-объекта полностью может создаваться с помощью визардов студии.
Кстати я писал и расширения к эксплореру и плагин к интернет эксплореру. Это только сначала кажется, что там все очень сложно. Нужно просто немного привыкнуть. Основная сложность там - это неполная документация. Но здесь все в твоих руках.

[Гром]

Для того, что бы нрписать DLL достаточно легкого движения кисти...

СОМ понимают далеко не все.

Так как будет и продолжение, то СОМ рассматривается как след. этап дабы создавать сервера тестовых СОМ...

Но это потом. Сначала концепт.

[npak]

Признаться, одним из первых порывов было предложить перевести архитектуру на COM

Но потом нашёл, что у СОМ проблем будет не меньше, а может даже и больше, чем бонусов.

Во-первых, нужно прописывать компоненты в реестре, что усложняет deployment (развёртывание) плагина
Во-вторых, если DLL предоставляет только один инстанс объекта с заданным интерфейсом (Open Close Read Write IoCtrl), то объектная модель тут ни к чему

На мой взгляд -- COM несколько великоватая пушка для простой системы.