И впринцыпи дело не столь в ВинСок32... а сколкьо вообще в переадресации и методов её быстрой и компактной реализации...

Fallout
xbind PROC a:DWORD,b:DWORD,c:DWORD
invoke bind,a,b,c
xbind ENDP
Однозначно нужен ret!так как ВСок АПИ уже сама стек очитстит от параметров... то нам надо будет просто возвратится в точку вызова... хм. вот.Она очистит свой кадр стека, а ret очистит стек xbind. Никаких проблем. Или делай как советует S_T_A_S_.

RobinFood
под Win2K все экспортируемые из wsock32.dll функции перенаправляются в ws2_32.dll
Верно подмечено! Кстати, некоторые старые программы, которые юзают WinSock 1.0 (wsock32.dll без ws2_32.dll) иногда глючат на XP. Подмена wsock32.dll на ws2_32.dll в импорте решает проблему. Логики в этом не вижу, но факт остаётся фактом. Баг MS?

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

xbind:
jmp bind ;; или jmp [bind]

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

call bind

?

> То бишь экспортировать адрес ... этого джампа

Совершенно верно. (хотя возможно это и вызовет трудности - я ужо подзабыл MASM)
Или можно так оформить PROC:

option prologue:none ;;  убираем стековый кадр
xbind PROC a:DWORD,b:DWORD,c:DWORD
jmp bind  ;;  здесь надо посмотреть какой
xbind ENDP
option prologue:PrologueDef

> но после него разве ничего не нужно или как?.

Код, расположенный после него выполняться не будет.
Возврат из ф-ции bind произойдет сразу в вызывающую прогу.


> почему в таком случаии нельзя было например сделать так: call bind

Это заносит в стек адрес возврата. Таким образом нарушается баланс и настоящий bind уже получит не те параметры.


Смысл здесь следующий. INVOKE заталкивает в стек параметры при вызове bind.
Но они уже и так там есть - их затолкали туда в вызывающей проге.
Поэтому можно просто передать управление при помощи jmp.
Здесь есть важный момент.
Это тип JMP - прямой т.е. jmp bind
или косвенный, т.е. jmp [bind]
Это зависит от того, как вы импортируете адруса ф-ций из реальной dll


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

Спасибо за ответ.

> почему в таком случаии нельзя было например сделать так: call bind

Это заносит в стек адрес возврата. Таким образом нарушается баланс и настоящий bind уже получит не те параметры.

но можно просто пропушить заново параметры, сделать call а потом ret xx и все будет ок. Я часто так делаю - проблем пока не вылазило. Особенно если переходники на С писать - там вообще все тривиально:

origFunc = GetProcAddress(...);
// ну там привести типы что-бы компилер не ругался...

int _stdcall XFunc( par1, par2, parN )
{
// тут что надо ДО вызова
int res = (*origFunc)( par1, par2, parN );
// тут что надо ПОСЛЕ
return res;
}

Ну иногда регистры надо сохранять в случае кривых DLLек, но такое достаточно редко бывает...

хм... вот интерестно мне стало.... нашёл время покавырятся опять.... так понял почему возникала ошибка с инвокам и почему было повисание при ДЖАМПЕ....


xbind proc
jmp [bind]
xbind endp

так вот после джампа.... знаете куда шёл возврат??? СНОВА НА ДЖАМП! причём когда был код с инвоком...

xbind proc
push bla
push blabla
call bind
рет 8
xbind endp
всё рвоно возврат шёл на начало функции то бишь на push bla .... хм... может знает как мне адрес возврата подправить ... а то что я его не нашёл.. ... странно даже...

Прям мистика какая-то..
Но если мыслить логически..

Допустим, что после джампа шёл возврат СНОВА НА ДЖАМП
Значит, что перед выполнением JMP в стеке (т.е. в [ESP]) должен нажодиться адрес этого самого JMP..
А что говорит дебаггер по этому поводу?
А то может быть просто повторно вызывается xbind
?

ЗЫ
С invoke логика точно та же.

То бишь ты имеешь ввиду что для Вызова реальной АПи используется снова моя??? хм.. странно

так до ДЖАМПА
[ЕСП] = 004C19F4 то бишь это адрес интсрукции сразу после КОЛА... всё логично и правильно так? ну вот а теперь идёт джумп... и опаньки... после джумпа адрес возврата... не меняется но после вызова "настоящей винсок" опять возврат идёт на джумп... хотя адрес ВОЗВРАТА НЕ МЕНЯЕТСЯ!!! и должен быть возврат на инструкции после КОЛА! хм... что то странное....



вот так сделано на С++ переадресация приведу на примере той же.. БИНД

Exported fn(): bind - Ord:0002h
:100010C0 55 push ebp
:100010C1 8BEC mov ebp, esp
:100010C3 51 push ecx
:100010C4 56 push esi
:100010C5 57 push edi
:100010C6 8D7C24F4 lea edi, dword ptr [esp-0C]
:100010CA 8D7508 lea esi, dword ptr [ebp+08]
:100010CD B903000000 mov ecx, 00000003
:100010D2 F3 repz
:100010D3 A5 movsd
:100010D4 83EC0C sub esp, 0000000C
:100010D7 FF1520390010 call dword ptr [10003920] // колится адрес реального ЗАГРУЖЕНОГо винсока (адрес получен через GetProcAddress)
:100010DD 8945FC mov dword ptr [ebp-04], eax
:100010E0 8B45FC mov eax, dword ptr [ebp-04]
:100010E3 5F pop edi
:100010E4 5E pop esi
:100010E5 8BE5 mov esp, ebp
:100010E7 5D pop ebp
:100010E8 C20C00 ret 000C

Fallout
Может линкер, встретив два одинаковых символа (два одинаковых имени), решил отресолвить их по адресу первого? Где-то я такой баг уже встречал...

Может .... блин придётся загружать библитеку и джампится на адреса полученые через ГетПроцесАдрес.... а так хотелось миниатюрности +)