Доброго времени суток! Если в каждом процессе загружать свой экземпляр библиотеки то приложение начинает себя странно вести и в результате рушится с ошибкой Access Violation. Нашел информацию где рекомендуют для каждого процессе сделать свою копию ф-ла dll, но это как-то совсем коряво Можно ли загрузить dll в главном потоке, сохранить адреса ф-ций в глобальной переменной и вызывать их из разных потоков? Есть ли вообще решение этой проблемы? Заранее спасибо!
>'Если в каждом процессе загружать свой экземпляр библиотеки то приложение начинает себя странно вести и в результате рушится с ошибкой Access Violation.' Которое приложение? >'Нашел информацию где рекомендуют для каждого процессе сделать свою копию ф-ла dll, но это как-то совсем коряво ' Зыкий источник информации же. >'Можно ли загрузить dll в главном потоке, сохранить адреса ф-ций в глобальной переменной и вызывать их из разных потоков?' Можно >'Есть ли вообще решение этой проблемы?' А есть ли вообще проблема?
TrashGen >'Можно' Не будет ли проблемы если одновременно несколько тредов будут юзать одни и те же ф-ции dll используя ее локальные переменные? >'А есть ли вообще проблема?' Это мы сейчас и пытаемся выяснить) Как какое решение будет оптимальным?
Место под локальные переменные выделяется в стеке. Стек у каждого потока свой. Никаких проблем не вижу.
Во первых спасибо! Во вторых, только реальные кодеры кодят и портят в столь ранее время, респект! Хм, а если не локальные переменные? Или при любом раскладе такой подход есть единственно правильный?
>'Во первых спасибо!' Всегда пажалста >'Во вторых, только реальные кодеры кодят и портят в столь ранее время, респект!' Не, у меня просто кот поутру чота оббливалсо на пол довольно громко и я изволил проснуться. Глядя на кошачью бливотену, сразу вспомнил, что не плохо было бы посмотреть новые темы на форуме. Я даже не кодер. >'Хм, а если не локальные переменные?' Ну никто ж не знает что за библиотеку вы юзаете и что за функции там в ней. Бесспорно можно написать экспортируемую из длл функцию у которой будут проблемы из-за многопоточности. У системных, например, таких проблем быть не должно бы. >'Или при любом раскладе такой подход есть единственно правильный?' Ох. При каком любом раскладе и какой подход?
Код (Text): ; + ; Проецируем копию образа. ; LdrMapViewOfImage proc uses ebx Apis:PAPIS, ImageBase:PVOID, ViewBase:PPVOID Local FileU[MAX_PATH*2 + sizeof(UNICODE_STRING)]:CHAR Local ObjAttr:OBJECT_ATTRIBUTES Local File:HANDLE, Section:HANDLE Local IoStatus:IO_STATUS_BLOCK Local ViewSize:ULONG mov ecx,ImageBase lea eax,FileU mov ebx,Apis assume ebx:PAPIS .if !Ecx mov ecx,fs:[TEB.Peb] mov ecx,PEB.LoaderLock[ecx] .endif push NULL push sizeof UNICODE_STRING + 2*sizeof MAX_PATH push eax push MemoryMappedFilenameInformation push ecx push NtCurrentProcess Call [ebx].pZwQueryVirtualMemory test eax,eax mov ObjAttr.uLength,sizeof(OBJECT_ATTRIBUTES) mov ObjAttr.uAttributes,OBJ_CASE_INSENSITIVE lea ecx,FileU jnz Exit ; STATUS_INVALID_ADDRESS/STATUS_INVALID_IMAGE_NOT_MZ/STATUS_FILE_INVALID etc. mov ObjAttr.hRootDirectory,eax mov ObjAttr.pObjectName,ecx lea edx,IoStatus push FILE_NON_DIRECTORY_FILE or FILE_SYNCHRONOUS_IO_NONALERT mov ObjAttr.pSecurityDescriptor,eax lea ecx,ObjAttr push FILE_SHARE_READ or FILE_SHARE_DELETE mov ObjAttr.pSecurityQualityOfService,eax push edx lea eax,File push ecx push SYNCHRONIZE or FILE_EXECUTE or FILE_READ_ACCESS push eax Call [ebx].pZwOpenFile test eax,eax lea ecx,Section jl Exit push File push SEC_IMAGE push PAGE_EXECUTE_READ push NULL push NULL push SECTION_MAP_READ or SECTION_MAP_EXECUTE or SECTION_MAP_WRITE or SECTION_QUERY push ecx Call [ebx].pZwCreateSection test eax,eax lea ecx,ViewSize .if Zero? mov ViewSize,eax push PAGE_EXECUTE_READ push eax push ViewShare push ecx push eax push eax push eax push ViewBase push NtCurrentProcess push Section Call [ebx].pZwMapViewOfSection push eax ; STATUS_SUCCESS/STATUS_IMAGE_NOT_AT_BASE push Section Call [ebx].pZwClose pop eax .endif push eax push File Call [ebx].pZwClose pop eax Exit: ret LdrMapViewOfImage endp
