AlexEro>> : 해커 삼촌, 당신의 말에는 논리가 없습니다. 라이브러리가 항상 자체적으로 언로드되는 경우 FreeLibrary에 대한 "내" 호출이 "많은 경우에 작동하지 않을 것"이라고 말하는 이유는 무엇입니까? deinit() 블록에서 FreeLibrary에 대한 추가 호출로 인해 어떤 피해가 발생할 수 있습니까? 아마도 FreeLibrary()에 대한 호출이 어떻게든 라이브러리 릴리스를 차단할 것이라고 생각합니다. 아니면 무엇입니까? 불일치, 멋진 해커 아저씨, 그리고 당연합니다.
이해하기 어렵지 않습니다. dll 자체가 예상대로 언로드되지 않으면 손이 비뚤어진 것이고 dll 코드에서 실수를 한 것입니다(대부분 DllMain 또는 위장된 확장에서). 이것이 유일한 이유입니다. Windows와 터미널 모두 dll에 매우 충실하기 때문에 다른 것이 없습니다. 이제 MT4 개발자가 주제넘은 관리자의 장난스러운 손에서 숨긴 FreeLibrary에 대해 알아보겠습니다. dll 코드가 정확하면 이 함수를 호출할 필요가 없으며 모든 것이 자체적으로 언로드되기 때문에 터미널 설명서에서 이해할 수 있습니다. 그러나 귀하의 경우와 같이 코드가 잘못된 경우 FreeLibrary가 교착 상태를 유발하거나 터미널을 충돌시킬 수 있습니다. FreeLibrary는 잘못된 상황의 경우 언로드를 보장하지 않습니다. 때로는 FreeLibrary가 도움이 될 수 있으며 때로는 상황을 악화시킬 수 있습니다. 이것은 복권이므로 이 경우에는 이 기능을 사용하지 않는 것이 좋습니다. 그리고 유능한 코드를 작성하는 것이 좋습니다. 물론, 이것을 할 수 없다면 dll은 거의 도움이 되지 않습니다. 하도록 하다.
사실, 이것은 이미 여기에서 여러 번 언급되었습니다. 아마도 다른 포럼의 바보인 척 하는 것을 그만두게 될 것입니다.
이해하기 어렵지 않습니다. dll 자체가 예상대로 언로드되지 않으면 손이 비뚤어진 것이고 dll 코드에서 실수를 한 것입니다(대부분 DllMain 또는 위장된 확장에서). 이것이 유일한 이유입니다. Windows와 터미널 모두 dll에 매우 충실하기 때문에 다른 것이 없습니다. 이제 MT4 개발자가 주제넘은 관리자의 장난스러운 손에서 숨긴 FreeLibrary에 대해 알아보겠습니다. dll 코드가 정확하면 이 함수를 호출할 필요가 없으며 모든 것이 자체적으로 언로드되기 때문에 터미널 설명서에서 이해할 수 있습니다. 그러나 귀하의 경우와 같이 코드가 잘못된 경우 FreeLibrary가 교착 상태를 유발하거나 터미널을 충돌시킬 수 있습니다. FreeLibrary는 잘못된 상황의 경우 언로드를 보장하지 않습니다. 때로는 FreeLibrary가 도움이 될 수 있으며 때로는 상황을 악화시킬 수 있습니다. 이것은 복권이므로 이 경우에는 이 기능을 사용하지 않는 것이 좋습니다. 그리고 유능한 코드를 작성하는 것이 좋습니다. 물론, 이것을 할 수 없다면 dll은 거의 도움이 되지 않습니다. 하도록 하다.
사실, 이것은 이미 여기에서 여러 번 언급되었습니다. 아마도 다른 포럼 바보인 척 하는 것을 그만두게 될 것입니다.
해커 아저씨, 보통 그런 순간에 (대규모 장거리 회사에서도) "거기서 뭐 담배를 피우세요?"라고 묻는 것이 관례이지만, 좀 더 정중하게 묻겠습니다.
해커 삼촌, 마크 트웨인의 "나는 어떻게 농업 신문을 편집했는지"라는 이야기를 읽었습니까? 읽었어? 그곳에서 신문 편집자는 스웨덴이 무엇인지도 모르고 나무에서 스웨덴을 따는 것에 대해 씁니다.
Dll 지옥은 오래된 잘 알려진 문제이며 사용자 수준에서 이를 해결하는 방법은 잘 알려져 있습니다.
그러나이 문제가 터미널과 어떻게 관련되는지 설명하려고합니까?
나는 당신이 이 위키를 훑어보았지만 문제의 본질을 이해하지 못했다고 의심합니다. 만일을 대비하여 다음과 같이 상기시켜 드리겠습니다. "문제의 본질은 특정 기능 을 지원하도록 설계된 DLL 버전의 충돌에 있습니다. DLL 지옥 은 숨겨진 광산처럼 날카로운 복잡성이 증가하고 시스템이 개선됩니다." (러시아 사람들이 우리 토론을 따르고 있기 때문에 러시아 위키에서 설명을 가져왔습니다.)
그렇다면 DLL 지옥은 터미널과 어떤 관련이 있습니까? 또한 regsvr32 또는 FreeLibrary가 이 문제에 대해 어떻게 도움을 줄 수 있습니까?
Dll 지옥은 오래된 잘 알려진 문제이며 사용자 수준에서 이를 해결하는 방법은 잘 알려져 있습니다.
그러나이 문제가 터미널과 어떻게 관련되는지 설명하려고합니까?
나는 당신이 이 위키를 훑어보았지만 문제의 본질을 이해하지 못했다고 의심합니다.
그렇다면 DLL 지옥은 터미널과 어떤 관련이 있습니까? 또한 regsvr32 또는 FreeLibrary가 이 문제에 대해 어떻게 도움을 줄 수 있습니까?
다시 말하지만, 일반적인 문구와 특정 사항이 없습니다. DLL 지옥은 문제와 직접적인 관련이 없으며, 당신이 DLL에 대한 모든 것을 알고 있고 거기에는 문제가 없으며 어리석지 않은 모든 사람이 DLL과 관련된 모든 문제를 피할 수 있다는 귀하의 진술만을 나타냅니다. 이 문제에 대한 나머지 질문에 인용문과 링크를 사용하여 답변했습니다. 당신과 달리.
다시 말하지만, 일반적인 문구와 특정 사항이 없습니다. DLL 지옥은 문제와 직접적인 관련이 없으며 DLL에 대한 모든 것을 알고 있고 거기에는 문제가 없으며 바보가 아닌 모든 사람이 DLL과 관련된 모든 문제를 피할 수 있다는 귀하의 진술만을 나타냅니다. 이 문제에 대한 나머지 질문에 인용문과 링크를 사용하여 답변했습니다. 당신과 달리.
화났어?! 그만, 나에게서 예를 들어, 나는 대담자를 모욕하려는 당신의 사소하고 값싼 시도에주의를 기울이지 않습니다.
그리고 dll에서는 어떤 레이크를 밟지 말아야 하는지 안다면 복잡할 것이 없습니다. 특히 메가쿼터가 제공하는 구현에서는 쉽습니다.
dll 문제를 피하는 유일한 방법은 해당 dll을 올바르게 작성하는 것임을 인정하고 싶지 않습니다. 그것은 어리석은 일입니다. 여기에 필요한 링크는 이해할 수 없습니다.
첫 번째 백필 질문 - 시스템은 dll을 언로드할 프로세스를 어떻게 압니까?
백필에 대한 두 번째 질문은 dll을 다운로드하지 않고 백필에 대한 진입점을 찾는 방법입니다.
이제 요점으로. dll은 올바른 등록을 위해 regsvr 프로세스에서 로드 및 언로드됩니다. 물론 이것은 다른 프로세스에서 언로드하는 데 영향을 미치지 않습니다.
당신보다 멍청하려고하지 마십시오. 아직 한 가지 플러스가 있지만 마나를 읽을 수 있습니다.
그것은 분명하다. dll을 언로드하는 것 외에도 표시기(전문가) 초기화 해제의 구현은 이와 직접적으로 관련된 모든 것을 포함할 수 있으며, 이는 dll의 무단 릴리스를 해킹으로 바꾸어 차례로 터미널의 올바른 작동을 보장하지 않습니다.
전체 - 당신이 낙타가 아니라는 것을 증명하기 위해 더 이상 성공하지 못할 것입니다. 행운을 빕니다.
2All: 관리자에게 전달하기 위해 머리로 생각하지 마십시오.
하지만? 뭐라고요?
이해하는 사람이 이것을 인간의 언어로 번역하십시오.
(아니요, 제가 이전에 실수를 했습니다. 전문가는 MetaQuotes와 같은 회사의 직원이 될 수 없습니다. 제 답변 중 하나가 매우 빨리 삭제되었다는 것뿐입니다.)
해커 삼촌, 당신의 말에는 논리가 없습니다. 라이브러리가 항상 자체적으로 언로드되는 경우 FreeLibrary에 대한 "내" 호출이 "많은 경우에 작동하지 않을 것"이라고 말하는 이유는 무엇입니까? deinit() 블록에서 FreeLibrary에 대한 추가 호출로 인해 어떤 피해가 발생할 수 있습니까? 아마도 FreeLibrary()에 대한 호출이 어떻게든 라이브러리 릴리스를 차단할 것이라고 생각합니다. 아니면 무엇입니까? 불일치, 멋진 해커 아저씨, 그리고 당연합니다.
이해하기 어렵지 않습니다. dll 자체가 예상대로 언로드되지 않으면 손이 비뚤어진 것이고 dll 코드에서 실수를 한 것입니다(대부분 DllMain 또는 위장된 확장에서). 이것이 유일한 이유입니다. Windows와 터미널 모두 dll에 매우 충실하기 때문에 다른 것이 없습니다. 이제 MT4 개발자가 주제넘은 관리자의 장난스러운 손에서 숨긴 FreeLibrary에 대해 알아보겠습니다. dll 코드가 정확하면 이 함수를 호출할 필요가 없으며 모든 것이 자체적으로 언로드되기 때문에 터미널 설명서에서 이해할 수 있습니다. 그러나 귀하의 경우와 같이 코드가 잘못된 경우 FreeLibrary가 교착 상태를 유발하거나 터미널을 충돌시킬 수 있습니다. FreeLibrary는 잘못된 상황의 경우 언로드를 보장하지 않습니다. 때로는 FreeLibrary가 도움이 될 수 있으며 때로는 상황을 악화시킬 수 있습니다. 이것은 복권이므로 이 경우에는 이 기능을 사용하지 않는 것이 좋습니다. 그리고 유능한 코드를 작성하는 것이 좋습니다. 물론, 이것을 할 수 없다면 dll은 거의 도움이 되지 않습니다. 하도록 하다.
사실, 이것은 이미 여기에서 여러 번 언급되었습니다. 아마도 다른 포럼의 바보인 척 하는 것을 그만두게 될 것입니다.
이해하기 어렵지 않습니다. dll 자체가 예상대로 언로드되지 않으면 손이 비뚤어진 것이고 dll 코드에서 실수를 한 것입니다(대부분 DllMain 또는 위장된 확장에서). 이것이 유일한 이유입니다. Windows와 터미널 모두 dll에 매우 충실하기 때문에 다른 것이 없습니다. 이제 MT4 개발자가 주제넘은 관리자의 장난스러운 손에서 숨긴 FreeLibrary에 대해 알아보겠습니다. dll 코드가 정확하면 이 함수를 호출할 필요가 없으며 모든 것이 자체적으로 언로드되기 때문에 터미널 설명서에서 이해할 수 있습니다. 그러나 귀하의 경우와 같이 코드가 잘못된 경우 FreeLibrary가 교착 상태를 유발하거나 터미널을 충돌시킬 수 있습니다. FreeLibrary는 잘못된 상황의 경우 언로드를 보장하지 않습니다. 때로는 FreeLibrary가 도움이 될 수 있으며 때로는 상황을 악화시킬 수 있습니다. 이것은 복권이므로 이 경우에는 이 기능을 사용하지 않는 것이 좋습니다. 그리고 유능한 코드를 작성하는 것이 좋습니다. 물론, 이것을 할 수 없다면 dll은 거의 도움이 되지 않습니다. 하도록 하다.
사실, 이것은 이미 여기에서 여러 번 언급되었습니다. 아마도 다른 포럼 바보인 척 하는 것을 그만두게 될 것입니다.
해커 아저씨, 보통 그런 순간에 (대규모 장거리 회사에서도) "거기서 뭐 담배를 피우세요?"라고 묻는 것이 관례이지만, 좀 더 정중하게 묻겠습니다.
해커 삼촌, 마크 트웨인의 "나는 어떻게 농업 신문을 편집했는지"라는 이야기를 읽었습니까? 읽었어? 그곳에서 신문 편집자는 스웨덴이 무엇인지도 모르고 나무에서 스웨덴을 따는 것에 대해 씁니다.
자, 이것은 Mark Twain과 같은 "당국"에게 "유인"하려고 시도하는 동일한 값싼 속임수입니다.
원칙적으로 dll이 무엇이며 어떻게 작동하는지 이해하지 못한다는 것을 더 잘 인정하십시오.
여기서 불분명한 것은 무엇입니까? 당신은 나쁜 관리자와 나쁜 dll 작성자입니까?
자, 이것은 Mark Twain과 같은 "당국"에게 "유인"하려고 시도하는 동일한 값싼 속임수입니다.
원칙적으로 dll이 무엇이며 어떻게 작동하는지 이해하지 못한다는 것을 더 잘 인정하십시오.
아, 어때요? 네, 하지만 해커 삼촌, 마이크로소프트 자체도 이것을 모르고/하거나 해결하는 방법을 모릅니다! 전문가들 사이에서 이것을 "DLL HELL"이라고 합니다. 못 들었어? 다음은 위키피디아의 링크입니다.
https://en.wikipedia.org/wiki/Dll_hell
Microsoft를 포함하여 끝에는 여전히 많은 링크가 있습니다.
삼촌, 저는 이 포럼에서 모든 것이 어떻게 작동하고 어떻게 정리해야 하는지 알고 있는 그런 사람을 실제로 만났다는 것을 알게 되어 기쁩니다.
Dll 지옥은 오래된 잘 알려진 문제이며 사용자 수준에서 이를 해결하는 방법은 잘 알려져 있습니다.
그러나이 문제가 터미널과 어떻게 관련되는지 설명하려고합니까?
나는 당신이 이 위키를 훑어보았지만 문제의 본질을 이해하지 못했다고 의심합니다. 만일을 대비하여 다음과 같이 상기시켜 드리겠습니다. "문제의 본질은 특정 기능 을 지원하도록 설계된 DLL 버전의 충돌에 있습니다. DLL 지옥 은 숨겨진 광산처럼 날카로운 복잡성이 증가하고 시스템이 개선됩니다." (러시아 사람들이 우리 토론을 따르고 있기 때문에 러시아 위키에서 설명을 가져왔습니다.)
그렇다면 DLL 지옥은 터미널과 어떤 관련이 있습니까? 또한 regsvr32 또는 FreeLibrary가 이 문제에 대해 어떻게 도움을 줄 수 있습니까?
Dll 지옥은 오래된 잘 알려진 문제이며 사용자 수준에서 이를 해결하는 방법은 잘 알려져 있습니다.
그러나이 문제가 터미널과 어떻게 관련되는지 설명하려고합니까?
나는 당신이 이 위키를 훑어보았지만 문제의 본질을 이해하지 못했다고 의심합니다.
그렇다면 DLL 지옥은 터미널과 어떤 관련이 있습니까? 또한 regsvr32 또는 FreeLibrary가 이 문제에 대해 어떻게 도움을 줄 수 있습니까?
다시 말하지만, 일반적인 문구와 특정 사항이 없습니다. DLL 지옥은 문제와 직접적인 관련이 없으며, 당신이 DLL에 대한 모든 것을 알고 있고 거기에는 문제가 없으며 어리석지 않은 모든 사람이 DLL과 관련된 모든 문제를 피할 수 있다는 귀하의 진술만을 나타냅니다. 이 문제에 대한 나머지 질문에 인용문과 링크를 사용하여 답변했습니다. 당신과 달리.
다시 말하지만, 일반적인 문구와 특정 사항이 없습니다. DLL 지옥은 문제와 직접적인 관련이 없으며 DLL에 대한 모든 것을 알고 있고 거기에는 문제가 없으며 바보가 아닌 모든 사람이 DLL과 관련된 모든 문제를 피할 수 있다는 귀하의 진술만을 나타냅니다. 이 문제에 대한 나머지 질문에 인용문과 링크를 사용하여 답변했습니다. 당신과 달리.
화났어?! 그만, 나에게서 예를 들어, 나는 대담자를 모욕하려는 당신의 사소하고 값싼 시도에주의를 기울이지 않습니다.
그리고 dll에서는 어떤 레이크를 밟지 말아야 하는지 안다면 복잡할 것이 없습니다. 특히 메가쿼터가 제공하는 구현에서는 쉽습니다.
dll 문제를 피하는 유일한 방법은 해당 dll을 올바르게 작성하는 것임을 인정하고 싶지 않습니다. 그것은 어리석은 일입니다. 여기에 필요한 링크는 이해할 수 없습니다.
내 개인적인 경험에 따르면 동적 라이브러리에는 문제가 없습니다(델파이 및 C++로 작성할 때). 나를 위해, 그들은 그들을 사용하는 표시기를 끈 후 즉시 풀려났습니다. 표시기의 빠른 끄기 + dll 교체는 항상 작동했습니다.
내 코드가 명시적으로 LoadLibrary를 _not_ 호출하기 때문에 FreeLibrary를 사용하지 않을 것입니다. 다른 사람의 실수를 수정하지 않을 것입니다.
논의 중인 문제가 타사 코드(windows 또는 mt)의 잘못된 작동의 결과라는 사실에 대해 큰 의구심이 듭니다.
나는 당신에게 모든 건강을 기원합니다!
이 주제에 관심이 있었고 터미널(DLLSample 프로젝트 )과 함께 제공되는 간단한 예제를 사용하여 논의 중인 주제를 확인하기로 결정했습니다.
VS 6.0에서 컴파일한 후 구운 dll은 터미널에서 성공적으로 작동하지만 자체적으로 언로드되지는 않습니다!
주요 기능은 다음과 같습니다.
이제 질문은 Windows에서 dll이 작동하는 방식을 실제로 이해하고 VS 6.0(예:)에서 프로젝트에서 올바르게 컴파일하는 방법을 알고 있는 감정가를 위한 것입니다.
주요 기능 프로토타입이 올바르게 선택되었습니까?
ATTACH/DETACH 흐름을 관리하는 방법은 무엇입니까?
그것에 대해 어디에서 읽을 수 있으며 예와 함께 바람직합니까?