__>Ну для этого LoadLibraryA есть
__>Предусмотреть все возможные проблемы заранее надо, или тогда написать чтобы не делать такое

А что — кто то уже кроме нас пробовал?

Здравствуйте, Andrew S, Вы писали:

__>>Ну для этого LoadLibraryA есть
__>>Предусмотреть все возможные проблемы заранее надо, или тогда написать чтобы не делать такое

AS>А что — кто то уже кроме нас пробовал?
Еще видимо нет, а то так бы написали =)

btw — может, лучше выкладывать новые версии отдельным архивом в файловую область? А то не всем, наверное, интересно получать довольно приличные по размеру постинги

Список изменений:

Уменьшение размера прокси в MT варианте. Теперь на VC6 размер прокси 36-44 байта для MT. Для ST размер прокси на VC6 такой же, как и раньше. В случае VC7.1 прокси оптимизируется куда качественней — процентов на 30-40 меньше, чем аналогичный на VC6.
Библиотека помещена в отдельный наймспайс — dl. Синтаксис декларации модулей и функций остался прежним.

To do

Багфиксы
Что то еще?

По поводу размеров прокси — думается, оптимизировать больше некуда, получаемый код выглядит оптимальным как в случае VC6, так и в случае VC7. Ждем новых предложений.

Исходники доступны по адресу ниже.
http://www.rsdn.ru/File/8583/delayimphlp.zip

Здравствуйте, Andrew S, Вы писали:

AS>btw — может, лучше выкладывать новые версии отдельным архивом в файловую область? А то не всем, наверное, интересно получать довольно приличные по размеру постинги

Такие люди жмут сюда

Здравствуйте, Andrew S, Вы писали:

AS>To do

AS>

AS>Что то еще?
AS>

Ну, например, вариант с GetModuleHandle вместо LoadLibrary/GetProcAddress.
Во первых работает быстрее.
Во вторых — не нужно делать FreeLibrary.
В третьих, можно вообще не синхронизировать.

Для заведомо загруженных библиотек типа NTDLL, Kernel32, USER и GDI будет лучше.

AS>

AS>            TCHAR szFunName[name_type::name_size];
AS>            name_type::MakeStr(szFunName);
AS>            FARPROC pFunction = GetProcAddress(hModule, szFunName);
AS>

Я не знаю указывали на это или нет, но GetProcAddress принимает только ASCII строку!

БП>Ну, например, вариант с GetModuleHandle вместо LoadLibrary/GetProcAddress.
БП>Во первых работает быстрее.
БП>Во вторых — не нужно делать FreeLibrary.
БП>В третьих, можно вообще не синхронизировать.

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

struct CModulePolicyLoad
{
static HMODULE Load(LPCTSTR szFileName);
static BOOL Free(HMODULE hModule);
}

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

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

A>P.S. Вызов через такую обёртку даже быстрее вызова через таблицу импорта. Вот я и думаю, а не создать ли продвинутый файл windows (как string.h -> string) в котором все функции будут раскиданы по пространствам имён? Как побочный эффект своего рода антиотладка (передаю привер шароварщикам ) Эдакая МЕГАИДЕЯ

Очень слабая защита, поскольку в первую очередь break ставится на первую инструкцию функции.
Защиту получше описал Крис Касперски:
Управление передается не на первую инструкцию импортируемой функции, а на 3-й или 4-й байт, при этом недостающие байты (обычно стандартный пролог) выполняются клиентом.

Итак, версия 1.09.

Список изменений:

Добавлены стратегии загрузки\выгрузки модулей. Соотв, добавлены 2 макроса: DL_USE_MODULE_NON_LOAD_BEGIN и DL_USE_MODULE_LOAD_POLICY_BEGIN. Первый использует GetModuleHandle для загрузки модуля, второй вызывает соотв. функции переданой ему стратегии.
Багфиксы в макросах.

To do

Багфиксы
Что то еще?

Исходники доступны по адресу ниже.
http://www.rsdn.ru/File/8583/delayimphlp.zip

P.S. Как уже писалось ранее, есть мысль выложить все это в файлы в качестве отдельной библиотеки или функционала (с соотв. маленьким описанием классов, макросов и примером использования). Если общественность в виде титулованных rsdn'енеров поддержит это (т.е. сочтет данную библиотеку как минимум полезной) — можно будет устроить и это.

Здравствуйте, Andrew S, Вы писали:

Исправление:

static typename proxy_type::fun_type &GetProxy()
    {
        static proxy_type::fun_type proxy = proxy_type::template Proxy<type>::ProxyFun;
        return proxy;
    }

Надо

typename proxy_type::fun_type proxy = proxy_type::template Proxy<type>::ProxyFun;

Почему-то это учтено выше, но в функции не учтено.

Предложение по обработке DL_MT :

В кратце : сделать и такую версию и обычную.

Сделать 2 класса CModule : CModuleMT и CModuleNoMT, CDynFunction и т.п. аналогично.

А в конце файла такое :

#ifdef _MT

// #define CModuleMT CModule
template <class Name, class LoadPolicy = CModuleLoadLibraryPolicy>
class CModule : CModuleMT<Name,LoadPolicy>
{...}

//...

#else

// #define CModuleNoMT CModule
template <class Name, class LoadPolicy = CModuleLoadLibraryPolicy>
class CModule : CModuleNoMT<Name,LoadPolicy>
{...}

//...

#endif

И не надо будет определять макрос DL_MT

P.S.
Стиль как-то не очень совпадает, пространство имен называет dl, а имена классов в другом стиле, да еще начинаются на C.

Есть предложение изменить стиль на стиль STL

Может пространство имен сменить на delayload, а то dl не очень уникально может быть.

__>

Исправление:
__>

__>static typename proxy_type::fun_type &GetProxy()
__>    {
__>        static proxy_type::fun_type proxy = proxy_type::template Proxy<type>::ProxyFun;
__>        return proxy;
__>    }
__>

__>Надо
__>

__>typename proxy_type::fun_type proxy = proxy_type::template Proxy<type>::ProxyFun;
__>

__>Почему-то это учтено выше, но в функции не учтено.

Нет, это почему то в функции не учтено, а что учтено выше — вполне очевидно. Спасибо. Fixed.

__>

Предложение по обработке DL_MT :

Мне текущий вариант нравится, он весьма лаконичен.
__>И не надо будет определять макрос DL_MT

Макрос DL_MT определяется просто для красоты — на самом деле, хватило бы и DL_NO_MT

__>P.S.
__>Стиль как-то не очень совпадает, пространство имен называет dl, а имена классов в другом стиле, да еще начинаются на C.
__>Есть предложение изменить стиль на стиль STL

Ну, у нас тоже есть некоторые свои требования на оформление кода, данный вариант является компромисным ( в данном случае я стремился к тому, чтобы типы назывались в стиле stl, а классы — в стиле MFC, что на мой взгляд более читабельно). Тем не менее внес несколько изменений, дабы было более однозначно.
__>Может пространство имен сменить на delayload, а то dl не очень уникально может быть.

Да, dl не слишком уникально (учитывая встроенный ассемблер). delayload тоже, я полагаю. Есть еще мысли по названию неймспейса?

Здравствуйте, Andrew S, Вы писали:

__>>

Предложение по обработке DL_MT :

AS>Мне текущий вариант нравится, он весьма лаконичен.
__>>И не надо будет определять макрос DL_MT

AS>Макрос DL_MT определяется просто для красоты — на самом деле, хватило бы и DL_NO_MT

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

__>>P.S.
__>>Стиль как-то не очень совпадает, пространство имен называет dl, а имена классов в другом стиле, да еще начинаются на C.
__>>Есть предложение изменить стиль на стиль STL

AS>Ну, у нас тоже есть некоторые свои требования на оформление кода, данный вариант является компромисным ( в данном случае я стремился к тому, чтобы типы назывались в стиле stl, а классы — в стиле MFC, что на мой взгляд более читабельно). Тем не менее внес несколько изменений, дабы было более однозначно.

Мне кажется что классы в стиле MFC это самое хучшее что может быть,IMHO
Зачем надо это "C" вначале, можно без него обойтись.

__>>Может пространство имен сменить на delayload, а то dl не очень уникально может быть.

AS>Да, dl не слишком уникально (учитывая встроенный ассемблер). delayload тоже, я полагаю. Есть еще мысли по названию неймспейса?

delayload довольно уникально по сравнению с dl.
Вообще надо определиться со стилем и тогда название может быть delayload, DelayLoad. delay_load.

P.S.
Стиль STL мне кажется лучше всего подходит здесь.

P.P.S.
Небольшое добавление :

struct CLWMutex
{
    void Lock()
    {
        while(::InterlockedExchange(&m_pFlag, TRUE))
            ::Sleep(1); // почему здесь не было оператора видимости ?
    }
};

__>Я имел ввиду немного другое.
__>В данной реализации невозможно использовать в проекте многопоточном немногопоточный класс и наоборот.

Отнюдь. Как раз первое — задается макросом DL_NO_MT. А второе просто не нужно — подумайте сами, зачем в немногопоточном приложении использовать явно лишний многопоточный вариант.

AS>>Ну, у нас тоже есть некоторые свои требования на оформление кода, данный вариант является компромисным ( в данном случае я стремился к тому, чтобы типы назывались в стиле stl, а классы — в стиле MFC, что на мой взгляд более читабельно). Тем не менее внес несколько изменений, дабы было более однозначно.

__>Мне кажется что классы в стиле MFC это самое хучшее что может быть,IMHO
__>Зачем надо это "C" вначале, можно без него обойтись.

Для понятности, что это класс имплементации. Класс интерфейса начинается на I. Мне наоборот нравится, хотя, может, просто привычка.

__>>>Может пространство имен сменить на delayload, а то dl не очень уникально может быть.

AS>>Да, dl не слишком уникально (учитывая встроенный ассемблер). delayload тоже, я полагаю. Есть еще мысли по названию неймспейса?

__>delayload довольно уникально по сравнению с dl.
__>Вообще надо определиться со стилем и тогда название может быть delayload, DelayLoad. delay_load.

Ок, тогда пусть будет delayload. Сейчас поправим...

__>P.P.S.
__>Небольшое добавление :
__>

__>struct CLWMutex
__>{
__>    void Lock()
__>    {
__>        while(::InterlockedExchange(&m_pFlag, TRUE))
__>            ::Sleep(1); // почему здесь не было оператора видимости ?
__>    }
__>};
__>

Ага, это тоже поправим Спасибо.

Здравствуйте, Andrew S, Вы писали:

__>>Я имел ввиду немного другое.
__>>В данной реализации невозможно использовать в проекте многопоточном немногопоточный класс и наоборот.

AS>Отнюдь. Как раз первое — задается макросом DL_NO_MT. А второе просто не нужно — подумайте сами, зачем в немногопоточном приложении использовать явно лишний многопоточный вариант.

Давайте тогда к первому :

// многопоточная программа
#define DL_NO_MT
#include <delayload.h>

А если я хочу использовать многопоточный класс тоже.
Получается что я не могу это сделать.

А было бы так:

#include <delayload.h>

// CModule - зависит от настройки
// CModuleMT - многопоточный
// CModuleNoMT - не многопоточный

//  DL_USE_MODULE_LOAD_POLICY_BEGIN
typedef delayload::CModule<NAME_ID(DL_CAT(_MODULE_, nmspace)), load_policy> module_type;

// задаем явно
// DL_USE_MODULE_NOMT_LOAD_POLICY_BEGIN
typedef delayload::CModuleNoMT<NAME_ID(DL_CAT(_MODULE_, nmspace)), load_policy> module_type;

AS>>>Ну, у нас тоже есть некоторые свои требования на оформление кода, данный вариант является компромисным ( в данном случае я стремился к тому, чтобы типы назывались в стиле stl, а классы — в стиле MFC, что на мой взгляд более читабельно). Тем не менее внес несколько изменений, дабы было более однозначно.

__>>Мне кажется что классы в стиле MFC это самое хучшее что может быть,IMHO
__>>Зачем надо это "C" вначале, можно без него обойтись.

AS>Для понятности, что это класс имплементации. Класс интерфейса начинается на I. Мне наоборот нравится, хотя, может, просто привычка.
Насчет интерфейса это согласен.
Я делаю так :
Классы которые относятся к программе делаю в стиле MFC это если программа на MFC или WTL , а классы моей библиотеки делаю не в стиле MFC, так отличить легко что куда =)

Еще опечаточка:

static void MakeReturnImpl()
        {
            TCHAR szMessage[DynFunction::name_type::length + 64];
            _stprintf(szMessage, _T("Can'n resolve procedure <%s>: %d"), DynFunction::name_type::GetStr(), GetLastError());
            throw E(szMessage);
        }

Надо can't или cannot.

P.S.
Что-то у вас нет единого стиля в коде.

return Policy::template FunctionTrait<DynFunction>::MakeReturn(); // есть template
//...
delayload::FUN_PROXY(DL_SEQ_SIZE(p))<r, DL_SEQ_ENUM(p), pl > >::GetProxy() // нет template

Может стоить добавить template где надо, хотя и без него компилируется

__>P.S.
__>Что-то у вас нет единого стиля в коде.
__>

__>return Policy::template FunctionTrait<DynFunction>::MakeReturn(); // есть template
__>//...
__>delayload::FUN_PROXY(DL_SEQ_SIZE(p))<r, DL_SEQ_ENUM(p), pl > >::GetProxy() // нет template
__>

__>Может стоить добавить template где надо, хотя и без него компилируется

Разве это относится к стилю? Если вы про спецификатор template после наймспейса — то в данном случае он не нужен. И комеау со мной тут согласен.

Здравствуйте, Andrew S, Вы писали:

__>>P.S.
__>>Что-то у вас нет единого стиля в коде.
__>>

__>>return Policy::template FunctionTrait<DynFunction>::MakeReturn(); // есть template
__>>//...
__>>delayload::FUN_PROXY(DL_SEQ_SIZE(p))<r, DL_SEQ_ENUM(p), pl > >::GetProxy() // нет template
__>>

__>>Может стоить добавить template где надо, хотя и без него компилируется

AS>Разве это относится к стилю? Если вы про спецификатор template после наймспейса — то в данном случае он не нужен. И комеау со мной тут согласен.

Ой, delayload это пространство имен
Я забыл что вы переименовали его, прощу прощения

Здравствуйте, _nn_, Вы писали:

А что насчет многопоточных и немногопоточных классов в одной программе сразу ?

__>А что насчет многопоточных и немногопоточных классов в одной программе сразу ?

Многопоточность в данном случае не сильно влияет и на размер кода, и на производительность (на размер почти не влияет, а на производительность во временнОм понятии — вообще). Макрос DL_NO_MT в свое время появился из-за того, что размер кода сильно возрос после реализации MT. Однако после выноса части прокси в отдельную функцию оказалось, что размер кода MT ~~== размеру кода ST. Так что это не принципиально. Я сначала думал сделать стратегии для поддержки многопоточности, но потом решил, что это уже слишком, да и не нужно никому.

Здравствуйте, Andrew S, Вы писали:

__>>А что насчет многопоточных и немногопоточных классов в одной программе сразу ?

AS>Многопоточность в данном случае не сильно влияет и на размер кода, и на производительность (на размер почти не влияет, а на производительность во временнОм понятии — вообще). Макрос DL_NO_MT в свое время появился из-за того, что размер кода сильно возрос после реализации MT. Однако после выноса части прокси в отдельную функцию оказалось, что размер кода MT ~~== размеру кода ST. Так что это не принципиально. Я сначала думал сделать стратегии для поддержки многопоточности, но потом решил, что это уже слишком, да и не нужно никому.

Я не про размер говорю.
Я имею ввиду что стоит сделать 2 версии классов CModule и CDynFunction.

P.S.
Поговорим насчет стиля ?