Native DLL с помощью чистого VB6 без примочек

[Хакер]

Нет, это не проект. Скорее интересный факт.
То, что называют Native DLL, то есть DLL-библиотеку, экспортирующую произвольные функции проекта.

Можно ли сделать такую DLL на VB6 без использования дополнительных плагинов, Add-in'ов, утилит, внешних хаков, без подмены линкера, компилятора. Используя исключительно голый VB6 в своём изначальном виде (даже без сервиспаков)?

Все сказали бы «нет», но на самом деле — можно .

Собственно, я начал зарываться внутрь и изучать внутренне устройство VB ещё в 2007 году во времена работы над FNDLL. Потом во время работы над указателями на функции, созданием экземпляров классов по имени, и некоторыми другими неопубликованными кирпичами. В последнее время я плотно занялся реверс-инжинирингом засев за кирпич, который даст вам совершенно стабильную многопоточность. Причём за последние две недели я продвинулся гораздо дальше, чем за предшествующие 3 года. Прогресс идёт по экспоненте.

Итак. VBP-файл (файл проекта) по своей сути является ini-файлом. Это никакой не секрет, не тайна, а вполне себе документированный факт. Вы можете делать в нём [секции] и пары ключ=значение как в любом нормальном ini-файле. (Это настолько документировано, что Add-in'ам дали возможность вызывать методы ReadProperty/WriteProperty у класса VBProject, чтобы Add-in'ы могли хранить свои произвольные данные, привязанные к проектам.)

А теперь сюрприз: VB поддерживает секцию VBCompiler в которой может быть два ключа:

• C2Switches — который определяет дополнительные ключи вызова компилятора (c2.exe)
• LinkSwitches — который опредеяет дополнительные ключи вызова линкера (link.exe)

Ключи вызова линкера тоже не являются тайной, они все документированы, и в частности, документирован ключ /EXPORT:, который позволяет определить произвольное число экспортируемых модулем сущностей.

Так вот, если у вас в модулях есть функции Foo и Bar и вы хотите их экспортировать в своей DLL, единственное, что вам нужно сделать, это открыть vbp-файл блокнотом и добавить туда вот это:

Код: Выделить всё

[VBCompiler]
LinkSwitches=-export:Foo -export:Bar

Вуаля:


В топку всякие примочки, подменяющие link.exe или делающие подобные грязные трюки. VB изначально позволяет вам обойтись без этого. Правда и никакой «инициализации рантайма» нет, но ни одна из «грязных примочек» её и так не предлагала, только мой FNDLL имел в этом плане отличие.

Можете скачать этот проект и скомпилировать его в девственно чистом VB6 и убедиться, что экспорты создаются:

proof_project.zip

(1.07 Кб) Скачиваний: 927

P.S. Никаких других ключей, кроме этих двух (С2Switches и LinkSwitches), гарантированно не поддерживается. В смысле, поддерживаются любые ключи, но особоые значения имеют эти два. Судя по всему, я первый, кто пишет об этих фичах.

P.P.S. И конечно, использование этих двух ключей совсем не ограничивается экспортом произвольных имён.

[NashRus]

Супер!

[ger_kar]

VB изначально позволяет вам обойтись без этого. Правда и никакой «инициализации рантайма» нет

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

[Хакер]

Ну хорошо, экспорт так сделать можно, но без инициализации рантайма, какова от этого действа будет практическая польза?

Ровно такая же, как от всех утилит, которые были до FNDLL. Только их авторы мучились, что-то там перехватывали и подменяли, а мы просто добавили 2 строчки в файл проекта. В этом прелесть находки.

Ну а потом, рантайм можно попытаться инициализироваться самому-из-себя. Рантайм может быть вообще не нужно инициализировать. Пользуясь фишкой, можно прилинковать к проекту obj-шник, в котором реализована инициализация рантайма.

[ger_kar]

Ровно такая же, как от всех утилит, которые были до FNDLL

Т.е. практически нулевая, ибо у меня например получилось сделать работающую Native Dll, только при помощи FNDLL.

Рантайм может быть вообще не нужно инициализировать.

Это пока предположение, которое нужно еще проверить?

Пользуясь фишкой, можно прилинковать к проекту obj-шник, в котором реализована инициализация рантайма.

Реализацию рантайма надо будет делать сторонними средствами или же можно как то это на VB реализовать прямо в проекте?

и некоторыми другими неопубликованными кирпичами.

Интересно какими. Нет не просто интересно, а жутко интересно. Можно хоть немного пролить на это свет?
И потом FNDLL, скачать то невозможно. При попытке его скачать по указанной в этой теме ссылке мы имеем:

Not Found

The requested URL /content/fndll/1/0/install.exe was not found on this server.

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

[ger_kar]

можно прилинковать к проекту obj-шник

В принципе, по этому методу, можно и например подпрограммы на Асме прилинковать, только вот как это потом связать с основным проектом или линковщик сам по именам свяжет?

[Хакер]

Т.е. практически нулевая, ибо у меня например получилось сделать работающую Native Dll, только при помощи FNDLL.

У тебя не получилось != нулевая. Писать можно но с критически жесткими ограничениями.

Это пока предположение, которое нужно еще проверить?

Нет, можно писать код, которому не нужен рантайм. Но это очень ограниченный код.

Реализацию рантайма надо будет делать сторонними средствами или же можно как то это на VB реализовать прямо в проекте?

Можно и на VB, вызвав у самого себя DllGetClassObject. Пока объект будет жив, рантайм останется инициализированным.

И потом FNDLL, скачать то невозможно.

Логично, ибо в нём обнаружился код, основанный на неправильном предположении. Надо ждать ACM-Tools.

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

[ger_kar]

У тебя не получилось != нулевая. Писать можно но с критически жесткими ограничениями.

А я кстати и указал, что практически нулевая, что != нулевая. И про ограничения тоже читал, но как раз эти ограничения и сводят на нет практическую полезную применимость. И все ранние попытки до FNDLL, годились разве что для экспериментов не более.

[jangle]

Native DLL созданные на VB можно вызывать из других сред разработки? Например PowerBASIC

[Хакер]

Да хоть из других, хоть с помощью rundll32 — можно.
Только DLL без инициализации рантайма написанные без учёта всех ограничений скорее всего упадут.
А вот скоро я сделаю вторую версию FNDLL AMC-Tools, и уже её библиотеки можно будет использовать вообще где угодно.

К слову, то, что народ называет Native DLL, ничем не отличается от Active X DLL, за исключением того, что функции модулей экспортируются. Та же библиотека с тем же работоспособным кодом. Так что сам факт экспорта каких-то функций — мелочь. Если вам нужна библиотека на VB — без всяких FNDLL можно воспользоваться ActiveX-библиотекой. Если вас не устраивает необходимость регистрации — создавайте объект не через CoCreateInstance, а вручную вызовом DllGetClassObject.

Ну а уж для эстетов, которым нужны именно экспортируемые функции, или для тех, кому такой интерфейс взаимодействия предписан — пожалуйста, экспорт.

[jangle]

А вот скоро я сделаю вторую версию FNDLL AMC-Tools, и уже её библиотеки можно будет использовать вообще где угодно.

В таком случае, появится хоть какой-то смысл всего этого. Если будет возможность например вызывать vb native dll из c++ проектов.

[Хакер]

Такая возможность была ещё со времён FNDLL.
И ещё раз: чем не устраивает использование ActiveXDLL из C++-проектов?

[jangle]

И ещё раз: чем не устраивает использование ActiveXDLL из C++-проектов?

Человеческий фактор. Всегда проще уговорить ленивого c++ программиста вызывать твою native dll, чем activex.

[Хакер]

К Native зато нужно h-файл писать, а в ActiveX достаточно сделать #import("mylib.dll")

[jangle]

К Native зато нужно h-файл писать, а в ActiveX достаточно сделать #import("mylib.dll")

native dll более универсальные, еще есть много сред программирования, которые вообще не умеют полноценно использовать activex dll
Или же написание плагинов для различного софта, от FAR и TC до сред 3D моделирования. Там плагины тоже представляют собой native dll.

[ger_kar]

Если вас не устраивает необходимость регистрации — создавайте объект не через CoCreateInstance, а вручную вызовом DllGetClassObject.

Но с точки зрения производительности такое решение не есть гут
Да и опять же простой вызов функций из Dll наверное самый удобный метод.

[Хакер]

Но с точки зрения производительности такое решение не есть гут

Почему? Это та же работа, которую делает CoCreateInstance, только исключая поиск dll-файла в реестре. И это делается один раз, дальше объект используется сколько угодно долго.

Да и опять же простой вызов функций из Dll наверное самый удобный метод.

Почему вызов методов классов менее удобен вызова экспортируемых функций?
Ну, окей, если вызовов простых функций более удобен (кому-то), то пусть у объекта будет метод, который возвращает указатели на ключевые функции, а дальше С++-программист использует эти указатели.

[Хакер]

еще есть много сред программирования, которые вообще не умеют полноценно использовать activex dll

Но любая среда, которая может работать с обычной DLL, автоматически может работать и с ActiveX DLL, потому что последняя является всего лишь частным случаем первого.

[ger_kar]

Почему вызов методов классов удобнее вызова экспортируемых функций?

Ну вообще-то я думаю, что в определенных случаях предпочтительнее одно, а в других другое и поэтому в каждом конкретном случае лучше использовать более удобный инструмент, а у разработчика должен быть выбор. Мне кажется, что очень даже хорошо сочетается ActiveXDLL и NativeDLL в одном флаконе. Как удобно, так и юзай.

[Хакер]

Кстати, мне несколько обидно, что тему воспринимают как тему о Native DLL, хотя я сам виноват, что сделал этот момент центральным.

Но мне даже больше нравится, что с помощью ключей мы можем менять размер зарезервированной/закомиченной области стека, выставлять минимальные версии ОС/подсистемы, ставить /3GB-ключ, менять базовый адрес у EXE, менять атрибуты секций, генерировать отладочную информацию (чтобы потом во внешнем отладчике отлаживать), менять подсистему с GUI на CUI (и получать консольные приложения!) и т.п.

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

[VBTerminator]

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

Именно поэтому я перезалил это "вкусное блюдо".
И да, Хакер, вынесите это поделие в верх темы о кирпиче, чтобы народ не мучался.

И потом FNDLL, скачать то невозможно.

Логично, ибо в нём обнаружился код, основанный на неправильном предположении. Надо ждать ACM-Tools.

Что не мешает народу спокойно использовать FNDLL.

[ger_kar]

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

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

что с помощью ключей мы можем менять размер зарезервированной/закомиченной области стека, выставлять минимальные версии ОС/подсистемы, ставить /3GB-ключ, менять базовый адрес у EXE, менять атрибуты секций, генерировать отладочную информацию (чтобы потом во внешнем отладчике отлаживать), менять подсистему с GUI на CUI (и получать консольные приложения!) и т.п.

Классно, но чтобы это все делать удобно нужны еще соответствующие аддины, хотя все достаточно просто и так. Особенно радует последнее "и т.п.", что говорит о том, что приведенный список не является исчерпывающим.

Кстати, мне несколько обидно, что тему воспринимают как тему о Native DLL

Ну и название темы соответствующее, хотя все то что ты открыл, это пища не для одной темы. И каждая перечисленная возможность, включая и т.п. достойны отдельных тем, некоторые конечно можно объединить например: "менять базовый адрес у EXE, менять атрибуты секций, генерировать отладочную информацию" это одна тема, "менять подсистему с GUI на CUI (и получать консольные приложения!)" уже другая. Кстати, а что за ключ такой "3GB-ключ"?

Именно поэтому я перезалил это "вкусное блюдо".

Я именно его и скачал, за что большое спасибо.

[ger_kar]

Кстати, а почему в случае использования библиотеки как ActiveX Dll рантайм инициализируется а в случае Native Dll нет. И кто/что инициализирует рантайм при использовании библиотеки как ActiveX Dll, механизм встроенный в саму библиотеку, или же само приложение?

[jangle]

Кстати, а что за ключ такой "3GB-ключ"?

Чтобы твоя софтина могла использовать более 3 Гигов оперативки на 64-битных системах

[Хакер]

Чтобы твоя софтина могла использовать более 3 Гигов оперативки на 64-битных системах

Нет, на обычных 32-битных. Просвещайся.

И да, Хакер, вынесите это поделие в верх темы о кирпиче, чтобы народ не мучался.

Не понял, что вообще и какой кирпич в частности имеется в виду.

И кто/что инициализирует рантайм при использовании библиотеки как ActiveX Dll, механизм встроенный в саму библиотеку, или же само приложение?

Потому что инициализация потоко-специфичных данных в рантайме происходит при создании нового объекта, а деинициализация — при смерти последнего из ранее созданных. А в «Native DLL» на момент вызова функций никаких объектов из библиотеки как правило не создано, и всё рушится.

Отдельной темы заслуживают не какие-то там жалкие «Как изменить базу», а пожалуй тема «как примерно устроен рантайм и как он организовывает работу и взаимодействие нескольких одновременно использующих его проектов». О внутрирантаймовых классах:

• CThreadPool,
• CVBThreadAction,
• VBThreadObject,
• CThreadData,
• Project,
• ProjectThread,
• ProjExecContext (структура, а не класс).

Именно пребывание в созданном положении экземпляров этих классов внутри рантайма скрывается за словами «инициализации рантайма». Знаний о внутреннем устройстве msvbvm60.dll, vb6.exe и vba6.dll получено огромное количество за это время.

[ger_kar]

а пожалуй тема «как примерно устроен рантайм и как он организовывает работу и взаимодействие нескольких одновременно использующих его проектов»

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

[Debugger]

Чем дальше в лес, тем больше интересных штук находится!

[arthur2]

Офигительно! Нужно пойти переписать свой кирпич с хуком, раз всё оказалось проще. Сколько же ещё всего в нашем бейсике запрятано, что никто не знает?

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

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

[ger_kar]

К тому же, рантайм, собственно, можно и вручную поднять, если вдруг сильно нужно

Я бы еще добавил и если знаешь как это сделать Если есть желание, но нет соответствующего знания, то удачи не видать!

[Хакер]

Сколько же ещё всего в нашем бейсике запрятано, что никто не знает?

Там много интересного. Некоторые находки не столько революционны, сколько просто интересны.

Вот я всегда думал, что у проекта есть один параметр: стартовый объект. Это может быть либо Sub Main, либо какая-либо форма. Что не может быть одновременно и то, и это.

proj_prop_startup.png (2.02 Кб) Просмотров: 28596

На самом деле, это всего-лишь упрощение со стороны диалога свойств проекта. У проекта на самом деле два параметра:

• Адрес Sub Main (возможен вариант, когда Sub Main отсутствует)
• Список объектов, которые по терминологии рантайма называются Predeclared Objects. Это экземпляры классов (форм), которые должны быть автоматически порождены при старте (до вызова Sub Main!)

Так что если вам казалось, что может либо Sub Main, либо Form1, но не оба сразу — это заблуждение. Можно быть одновременно и Sub Main, и Form1.
То есть по идее вместо комбо-бокса Startup Object должно было быть два элемента в диалоге свойств проекта: элемент для выбора стартовой процедуры и список с чекбоксами для выбора predeclared-объектов.

И всё в таком духе. Теперь я знаю, где границы ответственности между VB6.EXE и VBA6.DLL. Чем отличается Lpproj от hproj. Module от hbasmod. То есть если в вот этой твоей теме мы просто хлопали глазами, то теперь я очень хорошо представляю, что это за функции, что они принимают и что возвращают. И что делают