Я предпочитаю настоящую красоту, а не виртуальную. Лучше съезжу за город, в лес или в поле, посмотрю на природу, чем буду пялиться на кучу пробелов и тире, рискуя тронуться умом
>#include <smth.h>
>#pragma comment (lib, "smth.lib"
Получается, что для работы с dll мне надо три файла: саму dll, dll_name.h и dll_name.lib?
Ну dll я к примеру пишу на PB - автоматом генерируемых lib'ов я там не нашёл, а структура их такова, что в блокноте не наваяешь - это что ещё прогу писать на VB?
Откуда ты их берёшь?
И почему в стандартном проекте с рабочими функциями, например, MessageBox и Sleep нет строки
#pragma comment (lib, "kernel32.lib"
кстати о птичках, что за слово "lib"? Оно для всех dll одно и то же или это от чего-нибудь зависит?
Про *.h спрошу потом - когда найду lib, напишу ручками *.h по подобию windows.h и у меня ничего не получиться.
А как подключать ActiveX_Dll?
>больше всего добивают эти типы : HRESULT HWND HPEN и прочая гадость
Согласен с Sharp'ом - это, как оказалось, для удобства, хотя не спорю меня поначалу тоже ломало.
Только я понял это после того как выяснил, что типы приводятся один к другому через:
HWND a; HPEN b;
a=(HWND) b;
а спустя некоторое время выяснилось, что такой код никогда не приводит ни к чему хорошему и тока потом я понял на фига нужно столько типов данных.
Так что бульдозером можно, но не нужно. 8)
>либы - те же dll, но статические.
Т.е. статические от динамических отличаются тока тем, что их (статических) код включается в экзешник, а у динамических идёт как бы ссылка?
>Lib-файл хранит "стуб" между твоей программой и DLL
т.е. получается, что lib не содержит кода, а только координаты того, что нужно выдрать из dll и воткнуть в exe?
Значит, если я создам dll на том же С++ (а он делает для неё lib, насколько я заметил), потом всё присобачу так как сказал sharp, то мне не надо будет таскать за собой библиотеку - ведь код уже в экзешнике. Но к примеру, хук на клаву должен (не я придумал - где-то слышал) находится в адресном пространстве, общем для всех приложений. Т.е. я так понимаю, что если ActiveXDLL это класс и экземпляр этого класса создаётся отдельно для каждого приложения (точнее оно само создаёт эту копию, делая Set A=new ActiveXDLL.ClassName), то простая dll это тот же модуль в проекте VB только для всей винды - и значит все переменные являются общими для всех приложений. Но как же тогда хук выйдет, если dll попросту не будет на том компе, где я запущу ту прогу, в которую (якобы) будут через lib вшиты функции dll?
Где-то тут хрень какая-то...
А если lib не выдирает код, тогда на фиг вообще нужен - ведь подключается же библиотека динамически, значит и без либов тоже должна.
Ни фига не врубаюсь. 8(
>Нет, он как раз таки копирует, только делает это не компилятор, а препроцессор.
Спасибо, что утвердил меня в моём мнении. 8)
А что такое препроцессор - это типа то, что из исходных файлов собирает что-то типа асмовского исходника и передаёт его компилятору?
Нет, он как раз таки копирует, только делает это не компилятор, а препроцессор.
Что копирует? файл? Куда?
Делаем так:
include <wininet.h>
размер wininet.h - 128 кБ. Если что-то куда-то копируется, то либо текст исходника, либо сам ехе вырастут на 128 кБ.
Но этого не происходит. Потому что ничего никуда не копируется. Это только указание, где искать значения констант, прототипы функций и т.д.
>Не запутывай себя! Купи себе книгу Рихтера "Windows для профессионалов" чтобы не угадывать и не тыкать. Книга хорошая, даже очень.
Я не могу читать книги подобного характера. Электронные - ещё куда ни шло, а бумажные - нет. В них нет поиска (кстати, крутейший баг) и поэтому, чтобы из них что-то извлечь надо прочитать кучу неинтересной (а значит и незапоминающейся) информации. А электронки читаешь по ходу надобности: не понял, нашёл, прочитал, понял. Потом, когда время есть, прочитаешь то, что находится между тем, что ты искал - глядь, а ты уже всю книгу прочёл.
Да и купить проблема.
>А хук на клаву в АктивиксДЛЛ не может быть (глобальный). Только в stdcall библиотеках.
как же не может, когда он делается. Ведь несмотря на отдельные классы, которые у всех разные, модули и формы, включённые в проект библии являются общими. Ну может фенька и не в этом, но факт то, что клавовый и мышовый хук на VB возможен при том, что stdcall библии он делать не может. И я честно говоря не знаю почему его не может быть, ведь SetWindowsHookEx может вызываться хоть из экзешника.
Или я не так понимаю слово "глобальный"...
>>Нет, он как раз таки копирует, только делает это не компилятор, а препроцессор.
>Что копирует? файл? Куда?
Ну если текст инклуда такой:
-------------------
// белиберда 1
// белиберда 2
-------------------
а текст cpp такой:
-------------------
#include <inlude.h>
// белиберда 3
// белиберда 4
-------------------
то этот самый препроцессор, наверное, создаёт tmp.cpp следующего содержания:
-------------------
// белиберда 1
// белиберда 2
// белиберда 3
// белиберда 4
-------------------
а потом компилятор его компилирует.
>размер wininet.h - 128 кБ. Если что-то куда-то копируется, то либо текст исходника, либо сам ехе вырастут на 128 кБ.
насколько я знаю, С++ отбрасывает неиспользуемые имена констант и прочий мусор. Т.е. даже если ты без инклуда напишешь
#define kkk 99
а потом нигде эту kkk не используешь, то в экзешник она не попадёт (как и вышеописанные комментарии). И с инклудами то же самое - он берёт оттуда тока нужное. А может даже копирует вслепую, а потом уже отсеивает и твои константы и те, которые в инклуде.
>Это только указание, где искать значения констант, прототипы функций и т.д.
Если это только указание, то как быть с этим кодом:
#include <myclass.cpp>
myclass_exmlpr A;
ведь объявления методов класса ссылаются на функции, находящиеся в этом же файле, а не где-нибудь в библии.
>блин...ну чем дальше в лес - тем больше дров!
Да я просто пытаюсь разобраться в этом, чтобы один раз понять, а потом уже не вспоминать. Гораздо проще обзавестись некоторыми понятиями (можно даже не совсем верными, но главное, чтобы их неверное пнимание не мешало кодить) и потом отталкиваться от них, чем от пустоты. Если чувствуешь, что что-то ты не так понял, то возвращешся назад и тебе уже есть из чего строить новую теорию - из того, что точно знаешь, из того что предполагаешь и с учётом того, что (как ты точно знаешь, исходя из опыта ошибки, вернувшей тебя назад) является неверным.
А чем больше мнений ты узнаешь о проблеме, тем больше шансов, что твоя теория окажется близкой к истине.
Проще конечно прочесть в книге того, кто это придумал, но:
1. Проблема найти книгу.
2. Проблема найти нужное место.
3. Проблема понять то, что написано, т.к. ты и тот, кто писал обладаете различным багажом знаний и если ему удобно всё представлять в нулях и единицах, то мне может быть в яблоках и грушах. Я вообще считаю, что если я из будущего буду объяснять себе же из настоящего или прошлого, то я (тот, кому объясняю) скорее пойму, чем когда мне эту же хрень объясняет левый чел (типа препода). У меня часто бывало, что всю пару препод по высшмату вдалбливал мне одно и то же, а под её (пары) конец, он находил те слова (буквально два-три слова), которые сдвигали меня с мёртвой точки и я вдруг всё понимал. Такими скачками я понял производные (саму суть), такими же интегралы (проще, т.к. препод уже знал меня год) и так же не понял изображения (препод сменился). А в книге-то переспросить не у кого. Написано предложение о том, что ты не понимаешь и три страницы того, что тебе и без того ясно как день.
4. Вообще поиск в книге менее развивает, чем рассуждения. Следовательно, если по какому-то вопросу ты книгу не нашёл, а пять предыдущих нашёл в литературе, то самому догадаться до шестого тебе будет сложнее, чем если ты и все пять предыдущих раскусил без бумажного друга.
Ок Neco, не буду с тобой спорить об инклюдах. Пусть по твоему. Но смотри, не вздумай где-нибудь указать windows.h, а то из него ссылается на всё подряд, того и гляди, вся папка include размером больше 21 Мб скопируется к тебе
Хм, а как делается ActiveX dll с разделяемыми секциями?????. Обычную dll и ту нужно делать, специально оговаривая некоторые ключи для линковщика, чтобы получить разделяемые секции. А ActiveX dll - насколько я понимаю, вообще не dll, com-подобная субстанция....
Если не оговаривать разделяемые секции, то в чужое пространство её не втолкаешь, соответственно и хука никакого не будет.
я думаю, что это не глобальный хук, а какой-то другой способ
перехвата... Почему? Потому, что попросту НЕВОЗМОЖНО загрузить
АктивиксДЛЛ созданную в ВБ в адресное пространство всех процессов, не подгружая VB
runtime, а это за тебя никто не сделает...
И после таких слов это Я ВАС запутываю??? 8)))))
Было бы проще, если б я понимал, что такое "разделяемые секции" - в двух словах, если не трудно. Я писал библию для хука на клаву на трёх языках (VB,VC++,PB - не без помощи форумлян, конечно), но нигде не использовал переменную razdelyaemye_sexcii - я имею ввиду, что я ничего не обговаривал или же делал это не понимая, что делаю. Хотя в PB вроде всё понятно было или он сам за меня всё обговорил?
В чём проблема создания хука на клаву в VB я не понимаю? Вам что функция SetWindowsHookEx говорит "бамс! Это АктивИкс библиотека - здесь нельзя меня использовать"? У меня (как у нормального ламака) была проблема тока оформить это всё в виде событий, а вся остальная хрень вытекает из обычного сабклассинга. Вот даже в экзешнике код:
' в форме:
Option Explicit
Private Sub Form_Load()
hAppHook = SetWindowsHookEx(WH_GETMESSAGE, AddressOf AppHookProc, App.hInstance, App.ThreadID)
End Sub
Private Sub Form_Unload(Cancel As Integer)
UnhookWindowsHookEx hAppHook
End Sub
' в модуле
Option Explicit
Public Declare Function SetWindowsHookEx Lib "user32" Alias "SetWindowsHookExA" (ByVal idHook As Long, ByVal lpfn As Long, ByVal hmod As Long, ByVal dwThreadId As Long) As Long
Public Declare Function UnhookWindowsHookEx Lib "user32" (ByVal hHook As Long) As Long
Public Declare Function CallNextHookEx Lib "user32" (ByVal hHook As Long, ByVal nCode As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
Public Const WH_GETMESSAGE = 3
Public hAppHook As Long
Public Function AppHookProc(ByVal nCode As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
 ebug.Print Time$, "!!!"
Call CallNextHookEx(hAppHook, nCode, wParam, ByVal lParam)
End Function
или это не хук? 8)
По крайней мере когда крысой двигаешь, количество debug.print'ов резко возрастает - значит хук работает не только в библиях.
>Потому, что попросту НЕВОЗМОЖНО загрузить АктивиксДЛЛ созданную в ВБ в адресное пространство всех процессов
ты имеешь в виду то, что работающая активдлл у каждого приложения своя? И не может быть общей? Иначе я просто не понимаю что значит "общее адресное пространство".
Моё понятие: "общее адресное пространство" - это пространство в котором все переменные будут ссылаться на одно и то же место в памяти. Т.е. была у тебя переменная public f as long и ты сделал в первой проге f=10 а потом в другой f=5, то если в первой прочесть debug.print f, то там уже будет 5, а не заданные 10.
Ну тогда у активдлл есть такое пространство - это все модули и формы, которые ты туда подключаешь, а индивидуально копируются тока классы. Я на это нарвался, когда делал библию для общения по сети - не вышло, т.к. проще оказалось замутить сабклассинг микрофона в экзешнике, чем отлаживать одну библиотеку (на одном компе), которую использует два экзешника, т.к. сабклассинг устанавливается в модуле, а он общий для всех экземпляров класса, использующих эту длл.
Я просто сравниваю хук в обычной библии (которую я на PB и VC++ делал) и "этот-псевдо-хук" в экзешнике или в активдлл и не нахожу различий. Ни там ни там я не делал ничего, чтобы специально что-то загрузить в общее адресное пространство. Я просто даю указание винде при получении кода клавиши от клавиатуры вызвать не ту функцию, что стоит у неё первой в очереди, а мою (и указываю адрес моей функции), а адрес старой функции она возвращает мне, чтобы я самостоятельно передал параметры следующей (этой старой) функции через CallNextHook, что я и делаю. Где тут общее пространство - не понимаю...
Кароче, блин!
Началось с С++, а закончилось старым добрым васяткой. 8))))
Завязываю спорить... сам ни хрена не знаю, а других типа учу...
Для лобального хука последний параметр должен быть 0.
Когда ты делаешь stdcall ДЛЛ на С++, например, и ставишь глобальный хук, система сразу грузит ДЛЛ в адресное пространство всех процессов. АктивиксДЛЛ она не загрузит.
Столько ошибок в одном топике я никогда раньше не видел. Будем лечить
Получается, что для работы с dll мне надо три файла: саму dll, dll_name.h и dll_name.lib?
Да.
Ну dll я к примеру пишу на PB - автоматом генерируемых lib'ов я там не нашёл
Для этого используется специальная программа, в masm32 она, вроде, есть.
И почему в стандартном проекте с рабочими функциями, например, MessageBox и Sleep нет строки
#pragma comment (lib, "kernel32.lib"
Они обычно включаются в настройках проекта (каждый раз включать там нестандартные libы геморрно и я пишу их в коде), по крайней мере в VS 2003
А как подключать ActiveX_Dll?
Надо ботать COM, там несколько по другому, либо через MFC.
т.е. получается, что lib не содержит кода, а только координаты того, что нужно выдрать из dll и воткнуть в exe?
lib полезного кода не содержит, она содержит координаты вызываемых функций в DLL, которые не включаются в ехешник, а подгружаются Виндой при исполнении ехешника в его адресное пространство.
Значит, если я создам dll на том же С++ (а он делает для неё lib, насколько я заметил), потом всё присобачу так как сказал sharp, то мне не надо будет таскать за собой библиотеку - ведь код уже в экзешнике.
Обязательно надо.
А если lib не выдирает код, тогда на фиг вообще нужен - ведь подключается же библиотека динамически, значит и без либов тоже должна.
Это вопрос, скорее, философский.
А что такое препроцессор - это типа то, что из исходных файлов собирает что-то типа асмовского исходника и передаёт его компилятору?
Нет, он из сишного кода с директивами препроцессора, которые начинаются с # делает сишный код без них.
Купи себе книгу Рихтера "Windows для профессионалов" чтобы не угадывать и не тыкать.
Или скачай.
А хук на клаву в АктивиксДЛЛ не может быть (глобальный). Только в stdcall библиотеках.
Не могу быть уверен, но Винда использует адрес процедуры хука, поэтому должно быть пофигу, какой способ используется для доступа к процедурам: COM или таблица экспорта. Но рекомендовать их использовать я бы не стал
Что копирует? файл? Куда?
В исходник.
Делаем так:
include <wininet.h>
размер wininet.h - 128 кБ. Если что-то куда-то копируется, то либо текст исходника, либо сам ехе вырастут на 128 кБ.
Бред. Инклюды для библиотечных функций преимущественно содержат прототипы функций, которые компилятор используется только для проверки правильности вызова, дефайны (например с константами или типами данных), которые подставляются в код программы, либо объявления структур, которые вставляются в файл. Зато вот если бы ты поместил в h нормальные функции, то сразу бы увидел увеличение размера ехешника. И вообще, .h от .cpp отличаются только расширением, и дефайны и объявления структур и прототипы можно поместить и в .cpp.
Ну может фенька и не в этом, но факт то, что клавовый и мышовый хук на VB возможен при том, что stdcall библии он делать не может.
Без использования DLL, созданной в другом средстве программирования я видел только журнальные хуки.
Т.е. даже если ты без инклуда напишешь
#define kkk 99
а потом нигде эту kkk не используешь, то в экзешник она не попадёт (как и вышеописанные комментарии).
#define - это директива препроцессора, попасть в ехешник она по определению не может, если у тебя где-то есть kkk, то он будет просто заменен на 99 и скомпилируется то, что получится.
Такими скачками я понял производные (саму суть), такими же интегралы (проще, т.к. препод уже знал меня год) и так же не понял изображения (препод сменился).
Может, отображения, а не изображения?
А в книге-то переспросить не у кого. Написано предложение о том, что ты не понимаешь и три страницы того, что тебе и без того ясно как день
Радует, что у меня с моим IQ таких проблем не возникает :P
НЕВОЗМОЖНО загрузить
АктивиксДЛЛ созданную в ВБ в адресное пространство всех процессов, не подгружая VB
runtime, а это за тебя никто не сделает...
Зачем ActiveX нужен VBшный рантайм????? Это же обычный COM DLL с некоторыми особенностями.