MSDN에서 인용한 "당신은 우리의 이상한 사람입니다"입니다. "시스템이 DLL_PROCESS_ATTACH 이외의 값으로 DllMain 함수를 호출하면 반환 값이 무시됩니다."
저것들. Dll-in을 언로드할 때 시스템은 당신이 그곳에서 프로그래머로서 자신을 어떻게 생각하는지 전혀 신경 쓰지 않습니다.
철자가 맞고 틀릴 수 없습니다. 당신이 거기에 없으면 그냥 나옵니다. 혹시 가능하다면.
나는 특히 재능이 있는 사람들을 위해 다시 한 번 반복합니다. dll이 오류 없이 작성되면 모든 것이 예상대로 작동해야 합니다. 후기 바인딩에 의해 로드된 라이브러리를 언로드하기 위한 특별한 메커니즘은 없습니다. 이것은 분명하다?! MQL4는 Load\FreeLibrary를 통한 명시적 Dll 로드/언로드와 관련된 서비스를 제공하지 않습니다. 마찬가지로 Terminate에 대한 액세스 권한이 없습니다.
나는 당신이 본질적으로 무언가를 썼다는 것을 알지 못합니다. 프로젝트에서 동적 연결을 제거하십시오.
런타임 패키지에 대한 종속성, 관련 Dll과의 작업을 신중하게 구성합니다.
물론 거기에서 사용되며 OleInitialize와 같은 단일 호출이 발생할 수 있는 COM 하위 시스템과 함께 작동할 수 있습니다.
수십 시스템 Dll-in. 이러한 모든 종속성이 한 번에 로드되기 때문에 ... 모든 것이 시작부터 쉽습니다.
그러나 초기화 해제를 사용하면 - 예를 들어 Dll과 메타 트레이더가 동일한 시스템 라이브러리를 후크하는 경우 -
문제가 있을 수 있습니다 - OS의 깊이에 무엇이 있는지 아는 사람.
리히터를 읽고 적극 권장합니다. dll 작업에는 마법이 없으며 프로세스의 현재 주소 공간에 더 이상 필요하지 않은 라이브러리는 항상 언로드됩니다. 이 필요성은 카운터에 의해 결정됩니다. MQL 프로그램이 언로드될 때까지 카운터가 0으로 재설정되지 않으면 어딘가에서 오류가 발생했음을 의미하고 그 부분에서 심각한 오류가 발생했음을 의미합니다.
나는 dll을 프로세스의 주소 공간에 매핑하는 메커니즘을 캐싱 메커니즘이라고 부르지 않을 것이다. 이것은 완전히 독립적인 프로세스입니다.
당신은 좀 이상합니다. Windows \ system32 디렉토리에는 dllcache 디렉토리도 있고, 세상의 모든 시스템 관리자는 regsvr32를 사용하여 모든 dll을 강제로 언로드하고 여기 사람들에게 우화를 말하고 있습니다. 누구를 의지하고 있습니까? 여기에 같은 새끼들이 모여 있지 않습니다.
WinAPI에는 UnloadLibrary() 함수가 없고 FreeLibrary()가 있습니다.
네가 옳아 :-). 어떤 이유로 MSDN이 로드되지 않았습니다 :-).
.
OS는 로드 카운터 값이 0일 때만 dll을 언로드합니다.
이 경우 dll을 로드하는 유일한 응용 프로그램은 메타 트레이더입니다.
이 경우 dll을 로드하는 유일한 응용 프로그램은 메타 트레이더입니다.
#import를 통해 외부 라이브러리를 사용합니다.
idnikator를 언로드하면 터미널에 여전히 dll이 있습니다. 제거하는 방법?
오류 없이 dll을 작성하십시오. 일반적으로 dll은 예상치 못한 상황이 없는 경우 자체적으로 언로드됩니다.
"해커" 방식을 제외하고는 이것이 가능한 유일한 방법입니다.
오류 없이 dll을 작성하십시오. 일반적으로 dll은 예상치 못한 상황이 없는 경우 자체적으로 언로드됩니다.
글쎄, 자기야.
나는 새로운 DLL을 가지고 있었고 당신이 틀렸다는 것을 진지하게 증명하기로 결정했습니다 :-).
스크립트를 종료한 후와 표시기를 종료한 후
(창을 닫거나 표시기를 제거하여) DLL이 언로드됩니다...
그리고 "문맹 퇴치"에 관해서는 ... 저 DllMain은 항상 어리석게도 TRUE를 반환합니다.
하지만 약 1년 전쯤에 DLL을 교체하기 위해 메타트레이더를 종료해야 했던 걸로 기억합니다.
OS=WinXP SP3, MT=225
얘들아, 너 좀 이상해. 언로드되지 않는 문제가 있었고 몇 번만 있었고 항상 코드의 오류와 연결되었습니다. 이것이 첫 번째입니다. 두번째. 이 암시적 로드/언로드 메커니즘은 Dll 작업을 단순화하기 위해 Microsoft에서 특별히 고안한 것임을 상기시켜 드립니다.
이러한 이상한 문제는 어디서 발생합니까? 이해하기를 거부합니다.
예, 그리고 이것은 개인적으로 DllMain을 직접 사용하지 않습니다.
얘들아, 너 좀 이상해. 언로드되지 않는 문제가 있었고 몇 번만 있었고 항상 코드의 오류와 연결되었습니다.
이러한 이상한 문제는 어디서 발생합니까? 이해하기를 거부합니다.
예, 그리고 이것은 개인적으로 DllMain을 직접 사용하지 않습니다.
MSDN에서 인용한 "당신은 우리의 이상한 사람입니다"입니다.
"시스템이 DLL_PROCESS_ATTACH 이외의 값으로 DllMain 함수를 호출하면 반환 값이 무시됩니다."
저것들. Dll-in을 언로드할 때 시스템은 당신이 그곳에서 프로그래머로서 자신을 어떻게 생각하는지 전혀 신경 쓰지 않습니다.
철자가 맞고 틀릴 수 없습니다. 당신이 거기에 없으면 그냥 나옵니다. 혹시 가능하다면.
.
하지만 자신을 프로라고 생각하기 때문에 농담 대신 초보자에게 조언할 수 있습니다.
나는 당신이 본질적으로 무언가를 썼다는 것을 알지 못합니다. 프로젝트에서 동적 연결을 제거하십시오.
런타임 패키지에 대한 종속성, 관련 Dll과의 작업을 신중하게 구성합니다.
물론 거기에서 사용되며 OleInitialize와 같은 단일 호출이 발생할 수 있는 COM 하위 시스템과 함께 작업할 수 있습니다.
수십 시스템 Dll-in. 이러한 모든 종속성이 한 번에 로드되기 때문에 ... 모든 것이 시작부터 쉽습니다.
그러나 초기화 해제를 사용하면 - 예를 들어 Dll과 메타 트레이더가 동일한 시스템 라이브러리를 후크하는 경우 -
문제가 있을 수 있습니다 - OS의 깊이에 무엇이 있는지 아는 사람.
.
따라서 사실 우리는 모든 Dll 기능을 연결하는 API 사용자로서 일반적으로 .h / .lib를 통해 라이브러리를 로드하고 있습니다.
대부분의 경우 애플리케이션 초기화 시 발생하므로 *아무것도* 할 수 없습니다.
또는 모든 라이브러리를 직접 로드하고 모든 기능을 손으로 동적으로 연결합니다.
그러나 순수 수학 또는 일부 API 함수에서는 모든 것이 정상이어야 합니다.
Windows는 모든 DLL을 캐시합니다. 많이 캐시되었습니다.
위와 관련하여 현실에 매우 가깝습니다. 저것들. Dll-ina가 종속성을 연결하는 경우 -
그러면 운영 체제는 이 DLL을 로드한 응용 프로그램을 언로드하지 않고는 더 이상 이를 언로드할 수 없습니다.
MSDN에서 인용한 "당신은 우리의 이상한 사람입니다"입니다.
"시스템이 DLL_PROCESS_ATTACH 이외의 값으로 DllMain 함수를 호출하면 반환 값이 무시됩니다."
저것들. Dll-in을 언로드할 때 시스템은 당신이 그곳에서 프로그래머로서 자신을 어떻게 생각하는지 전혀 신경 쓰지 않습니다.
철자가 맞고 틀릴 수 없습니다. 당신이 거기에 없으면 그냥 나옵니다. 혹시 가능하다면.
나는 특히 재능이 있는 사람들을 위해 다시 한 번 반복합니다. dll이 오류 없이 작성되면 모든 것이 예상대로 작동해야 합니다. 후기 바인딩에 의해 로드된 라이브러리를 언로드하기 위한 특별한 메커니즘은 없습니다. 이것은 분명하다?! MQL4는 Load\FreeLibrary를 통한 명시적 Dll 로드/언로드와 관련된 서비스를 제공하지 않습니다. 마찬가지로 Terminate에 대한 액세스 권한이 없습니다.
하지만 자신을 프로라고 생각하기 때문에 농담 대신 초보자에게 조언할 수 있습니다.
나는 당신이 본질적으로 무언가를 썼다는 것을 알지 못합니다. 프로젝트에서 동적 연결을 제거하십시오.
런타임 패키지에 대한 종속성, 관련 Dll과의 작업을 신중하게 구성합니다.
물론 거기에서 사용되며 OleInitialize와 같은 단일 호출이 발생할 수 있는 COM 하위 시스템과 함께 작동할 수 있습니다.
수십 시스템 Dll-in. 이러한 모든 종속성이 한 번에 로드되기 때문에 ... 모든 것이 시작부터 쉽습니다.
그러나 초기화 해제를 사용하면 - 예를 들어 Dll과 메타 트레이더가 동일한 시스템 라이브러리를 후크하는 경우 -
문제가 있을 수 있습니다 - OS의 깊이에 무엇이 있는지 아는 사람.
리히터를 읽고 적극 권장합니다. dll 작업에는 마법이 없으며 프로세스의 현재 주소 공간에 더 이상 필요하지 않은 라이브러리는 항상 언로드됩니다. 이 필요성은 카운터에 의해 결정됩니다. MQL 프로그램이 언로드될 때까지 카운터가 0으로 재설정되지 않으면 어딘가에서 오류가 발생했음을 의미하고 그 부분에서 심각한 오류가 발생했음을 의미합니다.
따라서 사실 우리는 모든 Dll 기능을 연결하는 API 사용자로서 일반적으로 .h / .lib를 통해 라이브러리를 로드하고 있습니다.
대부분의 경우 애플리케이션 초기화 시 발생하므로 *아무것도* 할 수 없습니다.
또는 모든 라이브러리를 직접 로드하고 모든 기능을 손으로 동적으로 연결합니다.
그러나 순수 수학 또는 일부 API 함수에서는 모든 것이 정상이어야 합니다.
위와 관련하여 현실에 매우 가깝습니다. 저것들. Dll-ina가 종속성에 집착하는 경우 -
그러면 운영 체제는 이 DLL을 로드한 응용 프로그램을 언로드하지 않고는 더 이상 이를 언로드할 수 없습니다.
MT4 개발자는 사용자에게 Load\FreeLibrary 메커니즘을 제공하지 않음으로써 아주 좋은 일을 했습니다. 매우 정확합니다. 그것은 모두 프로그래밍 거래자의 문화 수준에 관한 것입니다.
마지막으로 Microsoft 자체의 권장 사항을 읽으십시오. 흑백으로 표시되어 복잡한 dll 종속성을 자체적으로 만들 수 있지만이 모든 것에는 한계가 있습니다.
Windows는 모든 DLL을 캐시합니다. 많이 캐시되었습니다.
나는 dll을 프로세스의 주소 공간에 매핑하는 메커니즘을 캐싱 메커니즘이라고 부르지 않을 것이다. 이것은 완전히 독립적인 프로세스입니다.
나는 dll을 프로세스의 주소 공간에 매핑하는 메커니즘을 캐싱 메커니즘이라고 부르지 않을 것이다. 이것은 완전히 독립적인 프로세스입니다.
당신은 좀 이상합니다. Windows \ system32 디렉토리에는 dllcache 디렉토리도 있고, 세상의 모든 시스템 관리자는 regsvr32를 사용하여 모든 dll을 강제로 언로드하고 여기 사람들에게 우화를 말하고 있습니다. 누구를 의지하고 있습니까? 여기에 같은 새끼들이 모여 있지 않습니다.