Как создать API DLL из VB , Матрица прогнулась под нами

В DLL можно использовать только модули (нет классов и форм, почему-то при их вызове прога вызвавшая функцию рушится).

Возможности:

Экспорт функций по ординалу^
Создание консольных приложений
Минимальный размер программы 5 кб
Автодобавление функций DllMain и Main (опционально)
Создание *.map файла (опционально)
Переключение языков (русский/английский)

12.08.2004
Добавилась возможность создания консольных приложений (пример есть в архиве)
автор примера Lamerroot

13.08.2004
В опциях добавилась возможность уменьшать размер любого компилируемого объекта.
Пустая экзешка теперь весит 5 кб!

18.08.2004
Приношу свои извинения. Но в последней версии Alex221(особоая благодарность за помощь) обнаружил серьезный баг не позволявший компилировать DLL-файлы.
Ссылка на скачивание обновлена.

Принимается помощь по переводам на различные языки.
Языки хранятся в виде строк с раздилителями в ресурсах файла vb_dll.dll.

Качать (Последнее обновление 2 декабря 2006г.):
(предыдущее обновление 18 Августа 2004г.):

Сообщение отредактировано: SCINER - 02.12.06, 06:46

Прикреплённый файлvb_dll.rar (27.73 Кбайт, скачиваний: 3851)

Цитата Vasya2000,7.08.04, 12:03

А теоретические основы этого феномена нельзя ли прямо щас???

Все гениальное просто:

0. перехватываем командную строку линкера
1. чуток ее изменяем
2. вызываем настоящий линкер

Интересно что на это скажут ненавистники VB.
Мы здесь на форуме доказали 3 вещи:
1. Работа с графикой не медленная (VB-BALL)
2. Можно пользоваться указателями ( Как сменить картинку на десктопе )
3. самое главное: Можно создавать полноценные DLL (не ActiveX)

Добавлено в 08.08.04, 10:48:
P.S. Даже самый дурацкий замысел можно воплотить мастерски

Добавлено в 08.08.04, 11:29:
Могу сказать больше: наши DLL лучше сишных!
Они даже работать с объектами позволяют:

Sub SetCaption(ByRef F As Form)
  F.Caption = "Hi from DLL"
  End Sub

Данную функцию можно сделать внешней и она будет корректно работать!
а декларировать ее надо так:

Private Declare Sub SetCaption Lib "DLL" (F As Form)

Сообщение отредактировано: Vasya2000 - 13.08.04, 04:06

Нечего делать пока расскажу как я до всего этого дошел:

Однажды при компиляции у меня вылетела ошибка связанная с link.exe
по опыту я знаю, что файлы типа link.exe обычно компилируют проги и все такое.
Увидев, что это досовский файл я запустил его в досе коммандой link.exe > c:\link.txt в надежде увидеть там какую нибудь инфу, а может даже ключики какие нибудь.
Он показал кучу всяких ключиков.

Цитата

Microsoft ® Incremental Linker Version 6.00.8168
Copyright © Microsoft Corp 1992-1998. All rights reserved.

usage: LINK [options] [files] [@commandfile]

options:

/ALIGN:#
/BASE:{address|@filename,key}
/COMMENT:comment
/DEBUG
/DEBUGTYPE:{CV|COFF}
/DEF:filename
/DEFAULTLIB:library
/DELAY:{NOBIND|UNLOAD}
/DELAYLOAD:dll
/DLL
/DRIVER[:{UPONLY|WDM}]
/ENTRY:symbol
/EXETYPE:DYNAMIC
/EXPORT:symbol
/FIXED[:NO]
/FORCE[:{MULTIPLE|UNRESOLVED}]
/GPSIZE:#
/HEAP:reserve[,commit]
/IMPLIB:filename
/INCLUDE:symbol
/INCREMENTAL:{YES|NO}
/LARGEADDRESSAWARE[:NO]
/LIBPATH:dir
/LINK50COMPAT
/MACHINE:{ALPHA|ARM|IX86|MIPS|MIPS16|MIPSR41XX|PPC|SH3|SH4}
/MAP[:filename]
/MAPINFO:{EXPORTS|FIXUPS|LINES}
/MERGE:from=to
/NODEFAULTLIB[:library]
/NOENTRY
/NOLOGO
/OPT:{ICF[,iterations]|NOICF|NOREF|NOWIN98|REF|WIN98}
/ORDER:@filename
/OUT:filename
/PDB:{filename|NONE}
/PDBTYPE:{CON[SOLIDATE]|SEPT[YPES]}
/PROFILE
/RELEASE
/SECTION:name,[E][R][W][S][D][K][L][P][X]
/STACK:reserve[,commit]
/STUB:filename
/SUBSYSTEM:{NATIVE|WINDOWS|CONSOLE|WINDOWSCE|POSIX}[,#[.##]]
/SWAPRUN:{CD|NET}
/VERBOSE[:LIB]
/VERSION:#[.#]
/VXD
/WARN[:warninglevel]
/WINDOWSCE:{CONVERT|EMULATION}
/WS:AGGRESSIVE

Названия некоторых(/VXD /DLL /DRIVER /DEF) ключиков меня заинтриговали. Стало понятно, что линкер способен компилировать библиотеки и драйвера.

Зашел на microsoft.com ввел link.exe в надежде хоть на что-то, по поиску набрел на ссылочку http://msdn.microsoft.com/library/default....erreference.asp.
Там были описания этих же ключей, но поконкретней, чем мне вывалил сам link.exe.
Не найдя больше ничего интересного пошел в яндекс набрал экспорт функций нашел чето-то по дельфям. Что мол для экспорта ф-ий нужен файл *.def в папке с прогой определенного содержания с именами ф-ий и т.п. Приводилось примерное его содержание.

Я недолго думая накатал такой файл с именами экспортируемых функций.
Запустил компиляцию и ... облом. Все по старому. Долго мучаясь я догадался заменить link.exe своим файлом и посмотреть какие ему шлются комманды.

Изучив пойманную комманду я понял, что в коммандной строке нет ключиков /DLL и /DEF.
Дальше я поступил так: Отловив командную строку я вставил в нее эти ключики вручную и попробовал вызвать настоящий линкер с измененной коммандной строкой. На этот раз вообще ничего не получилось...

От знакомства с PowerBasic'ом я помню, что есть такая ф-я DLLMain и она должна быть в каждой DLL.
Скопировав ее в мой компилируемый проект я опять попытался скомпилировать. Тогда я подумал, что возможно есть еще какой-то ключик. Долго мучаясь я увидел, что в коммандную строку попадает такая подстрока /ENTRY:__vbaS я недолго думая заменил ее на /ENTRY:DLLMain

Проект скомпилировался нормально.
И вдруг открывая DLL-ку с помощью Depends Viewer'a я с ужасом+криком+смехом(короче я неповерил своим глазам) но там заместо привычных глазу DllCanUnloadNow, DllGetClassObject, DllRegisterServer и DllUnregisterServer были прописаны мои функции RCP и SCINSoft.
Я тут же дрожащими пальцами создал новый проект, задекларировал свои функции, запустил прогу и тут БАБАХ, и все заработало...

В общем я до сих пор в шоке. Вот такая вот история с хорошим концом.
Я здесь описал наверно только 1/10 часть всего, что я пережил создавая данный линкер.

Я еще не написал, о том, что захотелось большего, а именно, чтобы через компилировать через IDe безгемора, ручной прописки функций. Пошарив по яндексу я был приятно удивлен, что VBIDE похож на офис, в нем можно делать такие-же макросы, ADD-In'ы и все такое. Искал пример. Нашел изучил. Написал свой. Все!

Кстати там подно еще непонятых мною ключей.
Так что впереди еще много открытий. Мы и драйвер когда нибудь на VB напишем.
А пока я лишь разобрал ключики MAP и MAPINFO, они создают карту функций и всего такого в файле Project1.map

Цитата Uhri,9.08.04, 16:22

Sciner, ты конечно молодец, я тебе даже плюсик добавляю, но тем не менее, по сравнению с длл в С++ это далеко до совершенства. Формы там ворос третий, не идут можно и Апи как говорит Вася, но вопрос самый главный, как это все отлаживать пошагово...

Цитата

Отлаживать пошагово

Поясни поконкретней

Да, довольно интересное открытие. Правда, это скорее баг компилятора, чем пробуманная реализация. Дело в том, что данный процесс нарушает некоторые аспекты компоновки, поэтому библиотека будет работать не стабильно. В общем, меня эта находка заинтересовала, так что я провел некоторое более глубокое исследования процесса компиляции. На самом деле ликер может дать больше гораздо больше возможностей, чем просто ДЛЛ. Вот, к каким результатом я пришел:
1. Приятно было узнать, что компилятор ВБ аналогичен компилятору ВЦ, причем он оба этих компилятора построены на едином стандарте и поддерживают одинаковые ключи, что несомненно является большим плюсом. Правда меня очень удивило, что наличие или отсутствие ключа /DEBUG нисколько не смущает ВБ, он всё равно добавляет в итоговый файл необходимую дебаговую информацию, а точнее ссылки на описания ошибок записанных в виртуальной машине, что только увеличивает размер файла.
2. Изучение процессы компиляции помогло разобраться в устройстве самой программы, откомпилированной в ВБ. Все надежды на то, что ВБ всё-таки делает полноценные ЕХЕ-файлы, развеялись, как дым. Как оказалось, весь бинарный код имплиментируется в некоторую оболочку из Vba6.dll. Вернее сказать, что Vbaexe6.lib вместе с основными функциями экспортирует огромное кол-во кода - какие-то классы, типы данных и т. п. Фактически в экзешник добавляется целая оболочка, которая и является цельным кодом, весь код, который пишут программисты, является почти что инструкциями интерпретатора, т.е. компилируется в бинарный код частично. Я выяснил, что все переменные хранятся не в сегменте данных, как в обычных ЕХЕ, а в специальном списке, который, видимо, создается динамически в процессе работы программы (именно этот метод позволяет ВБ создавать новые переменные в процессе работы программы при отсутствии инструкции Option Explicit). С ресурсами я не разобрался, там какая-то сложная система, но они походу тоже грузятся динамически из отдельного сегмента. Вот неполный список того, что экспортируется в ЕХЕ.

_CIcos    _adj_fptan    _adj_fdiv_m64   _adj_fprem1  
_adj_fdiv_m32   _adj_fdiv_m16i    _adj_fdivr_m16i    __vbaChkstk  
_adj_fpatan   __vbaExceptHandler    _adj_fprem    _adj_fdivr_m64    
__vbaFPException    _adj_fdiv_m32i    _adj_fdivr_m32i   _adj_fdivr_m32    
_adj_fdiv_r _CIatan   _allmul

Большинство ф-ий, такие как __adjust_fdiv, эспортируются полностью, вместе с кодом. Линкер использует ещё один объектный файл - natsupp.obj из Vbaexe6.lib. Кстати, компилятор ВБ, ну т.е. VB6.EXE, работает в режиме "автоматические заголовки компиляции", т.е. включает в obj-файл ссылки на все встречающиеся ф-ии. Но, что самое интересное, ВБ делает собственную таблицу превдонимов внутри кажного объектного файла.
К примеру, CLng на самом деле называется _CIlog, а ф-ия Int имеет вид __vbaR8IntI2.
У всех ф-ий есть характерный префикс _CI

_CIsin  _CIsqrt  _CItan  _CIexp ...

что свидетельствует о принадледности ф-ий к некоторому интерфейсу, который без сомнения тоже экстпортируется в ЕХЕ. Представьте, как это замедляет работу приложения.
3. Мне так же удалось выяснить, что именно делает возможным создание библиотек в ВБ. Это можно сказать ноухау от SCINERа. Всё дело в переопределении точки входа в ДЛЛ. Дело в том, что, как оказалось, точкой входа (т.е. ф-ей, которая вызывается при работе с ДЛЛ в памяти) ВБ назначает __vbaS, которая экспортируется из файла ИмяПроекта.OBJ. Она сначала вызывает ряд ф-ий: VB@TEXT, VB@BTXT, VB@ETXT, VB@BSS. Последняя, кстати, вероятно инициализирует классы, которые предоставляют интерфейсы позволяющие создать элементы управления. При обходе данной процедуры этого не происходит. Именно по этому попытка в полученных ДЛЛ использовать формы или другие компоненты приводят к краху виртуальной машины. Затем уже вызывается некая ф-ия _WinmainStartup, а затем - процедура Main.
У меня раньше тоже получалось экспортировать ф-ии из библиотеки с помощью def-файла, но у меня не получалось грамотно откомпилировать файл, т.к. назначение входной точкой стандартной ф-ии ВБА делало невозможным любой экспорт, т.к. вносило изменения в бинарную таблицу.
На официальном сайте майкрософт написано, что все ф-ии в ВБ не поддерживают стандарт вызова __stdcall. Однако, как оказалось, все объявленные в модуле ф-ии имеют формат __stdcall или WINAPI, т.е. потенциально могут вызываться как обычные АПИ.
Переопределение точки входа позволило обойти данный процесс и каким-то образом это позволили выполнить экспорт ф-ий, сохранив функциональность библиотеки, т.к. вызов вспомогательных ф-ий осуществляется на уровне интерпретатора.
Что касается точки входа, то всё равно, как соответствующая ф-ия будет называться. Её можно назвать просто Hello, надо только указать её имя в ключе /ENTRY, главное, чтобы она принимала 3 параметра:

Объявление в С:
BOOL __stdcall DllMain(HINSTANCE hInst, DWORD Reason, LPVOID reserved)
ВБ аналог:
Function DllMain(hInst As Long, Reason As Long, reserved As Long) As Long
где hInst - инстанция процесса, Reason - причина вызова ф-ии, reserved - зарезервированый параметр, который пока не используется.

На самом деле она совсем не бесполезна. К примеру параметр Reason может принимать следующие значения:

DLL_PROCESS_ATTACH = 1 - библиотека загружается в адресное пространство процесса
DLL_PROCESS_DETACH = 0 - библиотека выгружается из адресного пространства процесса

Ф-ия возвращает True (или 1) в случает удачного выполнения, False (или 0) - в случае ошибки, тогда библиотека загружена не будет.
Целесообразно добавить в эту ф-ию проверку параметра Reason. Если DLL_PROCESS_DETACH, тогда надо уничтожать все созданные объекты, т.к. ни один объект не будет находится в разделенном сегменте данных (ВБ этого не поддерживает), т.е. не может быть использован другим приложением.
4. Как оказалось, не смотря ни на что, ВБ позволят таким "варварским" образом компилировать ActiveX и ActiveX DLL проекты. Причем, если говорить о последнем типе, то в нём естественно можно создавать классы для множественного использования, ну и так же экспортировать ф-ии. В итоге получается интересная библиотека, ф-ии из которой можно вызывать как АПИ, а так же импортировать из неё классы через Project->Reference, как из обычной ВБ-шной ДЛЛ. Это подобно тому, как работает msvbvm60.dll - она является СОМ-обектом, однако из неё можно вызывать ф-ии типа VarPtr, как из обычной АПИ-библиотеки. Однако тут открылся небольшой минус. Как я уже сказал, ВБ создает большое количество сегментов кода и данных в исполняемом файле:

Из мапфайла:
 Start         Length     Name                   Class
 0001:00000000 0000006cH .idata$5                CODE
 0001:00000070 000004e0H .text                   CODE
 0001:00000550 00000004H .text$0                 CODE
 0001:00000560 00000030H .text$1                 CODE
 0001:00000590 00000004H .text$2                 CODE
 0001:00000594 00000014H .idata$2                CODE
 0001:000005a8 00000014H .idata$3                CODE
 0001:000005bc 0000006cH .idata$4                CODE
 0001:00000628 00000178H .idata$6                CODE
 0001:000007a0 00000044H .edata                  CODE
 0002:00000000 00000004H .data                   DATA
 0002:00000008 000002c4H .bss                    DATA тут видать компоненты хранятся
 0003:00000000 00000148H .rsrc$01                DATA
 0003:00000150 00000780H .rsrc$02                DATA

и возможно ф-ии объявленные в модуле находятся не в том сегменте, где расположены все классы. Модуль экспортирующий ф-ии является отдельным типом в ДЛЛ, но он не имеет своего CLSID, т.к. "не попадает" в нужный сегмент, таким образом стандартная ф-ия удаления зарегистрированной информации из реестра DLLUnregisterServer не сможет удалить инфорацию об этом типе из реестра, т.е. придется лазить по разделу TypeLib и удалять всё руками.
5. Лучше вообще не пользоваться в этой библиотеке такими ф-иями как New и CreateObject, т.к. создание любого объекта, размер данных которого превышает размер стека, т.е. 64 кб, приведет к краху приложения. Так же надо очень аккуратно проводить операции по копированию блоков памяти и выделению места в адресном пространстве процесса.
6. Большой плюс. Теперь в ВБ можно более ли менее работать с потоками. Из-за обхода некоторых ф-ий оболочки, библиотека стала более безопасной для многопоточных задач.
7. Так же несколько плюсов вытекает из доступных опций компиляции.
К примеру
Ещё одним интересным ключом является параметр /SUBSYSTEM:{NATIVE|WINDOWS|CONSOLE|WINDOWSCE|POSIX}[,#[.##]], он говорит виндам каким именно образом запускать исполняемый файл. Значение WINDOWS говорит линкеру, что это обычное виндовое приложение, WINDOWSCE значит, что апликуха будет работать под ЦЕ. Но большего внимания заслуживает значение CONSOLE, оно говорит, что прога должна запускаться в консоли. При запуске такого приложения, стандартный поток вывода переадресуется на консоль, т.е. GetStdHandle вернёт значение манипулятора консоли. Следовательно, на ВБ всё-таки можно делать консольные приложения.
Но эта возможность пока только исследуется.


2 SCINERL: Моё предложение - сделать аддин, который автоматически, без указания деффайла, пробегался по всем модулям и экспортирует все ф-ии, которые не private. Работать людям будет удобнее.

Сообщение отредактировано: Lamerroot - 10.08.04, 23:45

Впечетляет.
Спасибо за совет по аддину.
Конкретней отвечу позже, когда разберу все прочитанное.

Сообщение отредактировано: Vasya2000 - 11.08.04, 01:27

по теме

Как говорится - кто ищет, тот всегда найдет.
Вообще-то этот пост надо было бы запихнуть в тему: "как создать консольное приложение на ВБ", но концепция, которую я собираюсь изложить, скорее относится к этой теме.
Как я уже говорил, опции линкера ВЦ предусматривали запуск приложения разными способами. Так вот, оказалось, что линкер ВБ в этом плане полностью аналогичен линкеру ВЦ, т.е. он позволяет делать ЕХЕ с различными опциями подсистемы. Всё это делает возможным написание консольных приложений и в ВБ, причем в этих приложениях можно использовать формы и любые другие компоненты.
Я приложил к посту наглядное пособие, а то вдруг кто-то не поверит.
Как оно устроено? Просто. Проект состоит из одного единственного модуля, содержащего следующий код:

Option Explicit
 
Private Declare Function GetStdHandle Lib "kernel32" (ByVal nStdHandle As Long) As Long
Private Declare Function WriteConsole Lib "kernel32" Alias "WriteConsoleA" (ByVal hConsoleOutput As Long, _
    ByVal lpBuffer As String, ByVal nNumberOfCharsToWrite As Long, lpNumberOfCharsWritten As Long, _
    lpReserved As Any) As Long
Private Declare Function CloseHandle Lib "kernel32" (ByVal hObject As Long) As Long
 
Private Const STD_OUTPUT_HANDLE = -11&
 
Sub Main()
    Dim hConsole As Long
    Dim txt As String
    Dim num_written As Long
    'получаем манипулятор стандартного потока вывода
    hConsole = GetStdHandle(STD_OUTPUT_HANDLE)
    If hConsole = 0 Then MsgBox "Couldn't allocate STDOUT"
 
    txt = "********************************" & vbCrLf & _
          "*  Concole application on VB!  *" & vbCrLf & _
          "*     Created by Lamerroot.    *" & vbCrLf & _
          "********************************" & vbCrLf
    'работаем, как с обычной консолью, хотя можно было использовать WriteFile
    WriteConsole hConsole, txt, Len(txt), num_written, vbNullString
    'надо обязательно закрыть манипулятор при окончании работы
    CloseHandle hConsole
End Sub

Я компиляю проект, а затем линкую объектные файлы следующим образом:

LINK путь\имя_проекта.OBJ путь\имя_модуля.OBJ путь\VBAEXE6.LIB /ENTRY:__vbaS /OUT:путь\Cons.exe /BASE:0x400000
/SUBSYSTEM:CONSOLE /VERSION:1.0 /INCREMENTAL:NO /OPT:REF /MERGE:.rdata=.text /IGNORE:4078

Параметр VERSION зависит от версии среды ВБ.
Получаю указанный файл Cons.exe. Ну, вот и всё. Все файлы, откомпилированные подобным способом, будут нормально работать с консолью.

ЗЫ: Кстати, изучения опций линкования показало, что, как и в ВЦ, в исполняемый файл вместе с VBAEXE6.LIB можно включать и другие либы. К примеру, включение в ЕХЕ-файл либы ole32.lib (ставится вместе с ВЦ, папка \Lib) избавит от необходимости включать в инсталляционный пакет файл таблицы автоматизации OLE (OLE Automation) stdole2.tlb. А, скажем, изменение базового адреса входа (/BASE) способно уменьшить размер исполняемого файла.

Сообщение отредактировано: Lamerroot - 11.08.04, 19:21

Прикреплённый файлCons.exe (16 Кбайт, скачиваний: 711)

Теперь встает вопрос, как удалить ресурсы из DLL.
Они размер раздувают. А пользы 0.

Добавлено в 12.08.04, 06:17:

Цитата

надо модуль в рабочий ехе-проект вкомпиливать и проверять пошагово

Вот, что я на это могу ответить:
1. Когда ActiveX делаешь, разве не тоже самое, надо встраивать в приложение, чтобы проверить.
2. Модуль проверить легче, чем AtiveX.

Дальнейшие возражения не принимаются!

2 SCINER, Lamerrot и всем: у меня предложение, давайте напишем програмулину которая будет заменять компилятор ВБ. Т.е. при компиляции будет вызываться она и в окне установив нужные параметры линковки, тогда без напряга можно будет получать необходимый исполняемый файл или компонент.

Сообщение отредактировано: Uhri - 12.08.04, 07:56

В первом посте обновление.
В меню появилась новая строка Make console exe
Авторство сохранено за Lamerroot.

Добавлено в 12.08.04, 08:19:

Цитата Uhri @ 12.08.04, 07:55

2 SCINER, Lamerrot и всем: у меня предложение, давайте напишем програмулину которая будет заменять компилятор ВБ. Т.е. при компиляции будет вызываться она и в окне установив нужные параметры линковки, тогда без напряга можно будет получать необходимый исполняемый файл или компонент.

Дык уже все готово.
Смотри в первом посте!

Цитата

Теперь встает вопрос, как удалить ресурсы из DLL.
Они размер раздувают. А пользы 0.

Неправда, ресурсы из ДЛЛ (даже откомпилированой подобным образом) загрузить можно. Только надо пользоваться не встроенными ф-иями ВБ, а чистыми АПИ для работы с ресурсами.

Цитата

Вот, что я на это могу ответить:
1. Когда ActiveX делаешь, разве не тоже самое, надо встраивать в приложение, чтобы проверить.
2. Модуль проверить легче, чем AtiveX.

Всё правильно, Uhri загоняет. Не все же компоненты доступны в процессе создания проекта... И это нормально.

Цитата

2 SCINER, Lamerrot и всем: у меня предложение, давайте напишем програмулину которая будет заменять компилятор ВБ. Т.е. при компиляции будет вызываться она и в окне установив нужные параметры линковки, тогда без напряга можно будет получать необходимый исполняемый файл или компонент.

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

Вот ответ на твой биг-пост:

Ты написал, что данная реализация ведет себя нестабильно, т.к. нарушает некоторые аспекты компоновки. Я так понял, что ты имел в виду про обход стандартной процедуры точки входа. Если так, то да. Но. Я решил проверить стабильность. Создал DLL в VB (с функцией работающей с потоками)и начал вызывать процедуру из других языков таких как VC, Delphi, PowerBasic, ну и из самого VB конечно. При данном тестировании небыло замечено ни одного признака нестабильности. Все отработало как часы.

1. Ключ /DEBUG не не действует по той причине, что эта самая отладоная инфа уже лежит в .obj файле, созданная компилятором.

2. Ты утверждаешь, что такие функции, как __adjust_fdiv или __vbaR8IntI2 экспортируются с кодом. Плюс к тому они еще в составе какого-то интерфейса и экспортируются в EXE. Попробуй загляни в msvbvm. Все сомнения насчет этого отпадут разом! Там фугкции именно так и называются. Неможет быть такого, чтобы он таскал за собой msvbvm да еще и в себя их копировал. В этом случае экзешник был бы похож на дельфийский.

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

4. Все верно. Кстати а может по этому мап файлу может вырезать ненужные блоки. Например блок и ресурсами о версии DLL.

5. Я очень неаккуратно работал с Copymemory с блоками по 60 мег. Ничего страшного не происходило. Все стабильно. Ресурсы не глючат(тестировал на Win9X, Win2000, WinXProHome). Да и вообще действуют все те же правила, что и в простой VB-пограмме.

6. С потоками теперь можно работать не более или менее а полноценно, т.к. DLL находится не в адресном пространстве вызвавшей ее программы.

7. Мне кажется вопрос исчеран. Ты написал пример, а я добавил меню в аддине.

Предложение тоже рассмотрено и реализовано.

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

Стандартная прога теперь весит где-то 7-8 кб.

Причем данный чекбокс действует и на простые экзешки и на activex и на консольные, в общем на все.

Сорри. Минимальный размер экзешек 5120 байт!!!, т.е. 6кб!

Насчет табов заметано!

Сообщение отредактировано: SCINER - 13.08.04, 06:45

Цитата

Я решил проверить стабильность. Создал DLL в VB (с функцией работающей с потоками)и начал вызывать процедуру из других языков таких как VC, Delphi, PowerBasic, ну и из самого VB конечно. При данном тестировании не было замечено ни одного признака нестабильности. Все отработало как часы.

Я как раз сказал, что с потоками библиотека работает нормально. Ты попробуй там СОМ-объекты посоздавать побольше. Приколешься.

Цитата

1. Ключ /DEBUG не действует по той причине, что эта самая отладочная инфа уже лежит в .obj файле, созданная компилятором.

Я это и сказал.

Цитата

2. Ты утверждаешь, что такие функции, как __adjust_fdiv или __vbaR8IntI2 экспортируются с кодом. Плюс к тому они еще в составе какого-то интерфейса и экспортируются в EXE. Попробуй, загляни в msvbvm. Все сомнения насчет этого отпадут разом! Там фугкции именно так и называются. Не может быть такого, чтобы он таскал за собой msvbvm да еще и в себя их копировал. В этом случае экзешник был бы похож на дельфийский.

Ну я же не говорил, что вот прямо полностью весь код всех ф-ий в ЕХЕ переноситься. Зато вот виртуальное объявление этих ф-ий как членов класса в ЕХЕ есть точно + какие-то ф-ии точно экспортируются полностью.

Цитата

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

Ну, это совсем не мало.

Цитата

4. Все верно. Кстати, а может по этому мап файлу может вырезать ненужные блоки. Например, блок и ресурсами о версии DLL.

Не я пробовал. Они находятся в другом сегменте данных. ВБ их не видит, как членов кода, т.е. откомпилировать проект будет невозможно. Мапфайл это чисто логи линковки. Ресурсы о версии можно удалить в последствии уже из готовой ДЛЛ стандартными АПИ или прикладной прогой, а так не знаю даже.

Цитата

5. Я очень неаккуратно работал с Copymemory с блоками по 60 мег. Ничего страшного не происходило. Все стабильно. Ресурсы не глючат (тестировал на Win9X, Win2000, WinXProHome). Да и вообще действуют все те же правила, что и в простой VB-пограмме.

Причем тут CopyMemory? Я говорю про GlobalAlloc, VirtualAlloc, HeapAlloc и т.д.

Цитата

6. ... т.к. DLL находится не в адресном пространстве вызвавшей ее программы.

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