japplegame писал(а):Это один из способов найти глюк. Если сбои не исчезнут, то можно отстать от хеш-функций, раз и навсегда.
Это вообще тестовое решение, а не альтернатива текущему. Соответственно вопросы о переносимости и системных ресурсах отпадают автоматически. Хотя насчет производительности, dll не запускает ragexe в полном смысле этого слова, запускать-то запускает, но 99% времени поток находится в замороженном состоянии и ресурсов не ест, кроме пары-тройки мегабайт оперативы в худшем случае.
В конце-концов исходники либы лежат в СВН, всем особо умным предлагаю взять их в зубы и искать глюк так как им захочется.
Ндя, "всем особо умным", понимаешь, копаться в исходниках не зная что они из себя представляют, как то затруднительно.
Эппл! Я могу воспроизвести глюк, понимаешь? Я могу заставить dll выдать неправильный пакет, что я и проделал, при этом поставил бряк на вызов
dword hashData = Call16( serverMapSync, clientSync, clientAccId, type );
в Оле, данные передаваемые ей одинаковы, а вот ответ разный!!!
Значит глюк точно в ней!
Тебя уже который раз спрашиваю как с тобой связаться что бы обсудить это; а ты всместо этого обижаешься.
Да я понимаю что ты будешь запускать РО, делать что то типа SuspendThread и внедряться в него но оно надо?
Джерри сказал что я могу помочь, воспроизведя глюк, но ни он ни ты не отвечаете.
П.С.
"Это один из способов найти глюк. Если сбои не исчезнут, то можно отстать от хеш-функций, раз и навсегда."
ТОесть ты хочешь однозначно исключить ф-ю Call16 из подозрений?
Я пишу еще раз, значение возвращаемое при одних и тех же данных этой ф-ей разное в случает просто вызова энкоде и в случае вызова ее в "глючном" состоянии.
Я написал программу которая прсит лог и вызывает CreateAtk($Packet, unpack("L1", $ID3), 0x07);, и с ее помощью воспроизводится глюк!
Если просто вызвать CreateAtk, то формируется правильный пакет, но вызов ее после определнных вызовов приводит к генерации неправильного пакета!
показали, что стек при вызове 