DLL 지옥

DLL Hell

컴퓨팅에서 DLL 헬(DLL Hell)은 마이크로소프트 윈도우즈 운영 체제에서 사용되는 DLL([1]Dynamic Link Library)과 연동할 때 발생하는 합병증을 일컫는 말로, 특히 레거시 16비트 버전은 모두 단일 메모리 공간에서 실행된다.

DLL Hell은 애플리케이션이 시작되거나 제대로 작동하지 않는 여러 가지 방법으로 나타날 수 있다.

DLL Hell은 일반적인 개념 종속 지옥의 Windows 생태계에 특화된 형태다.

문제

DLL은 마이크로소프트의 공유 라이브러리 구현이다. 공유 라이브러리는 공통 코드를 래퍼, DLL에 묶어서 여러 개의 복사본을 메모리에 로드하지 않고 시스템의 응용 프로그램 소프트웨어에서 사용할 수 있도록 한다. 간단한 예로는 많은 프로그램에서 널리 사용되는 GUI 텍스트 편집기가 있을 수 있다. 이 코드를 DLL에 배치하면 시스템의 모든 애플리케이션이 메모리를 더 사용하지 않고도 사용할 수 있다. 이는 기능상 유사하지만 코드를 애플리케이션에 직접 복사하는 정적 라이브러리와 대비된다. 이 경우 모든 애플리케이션은 사용하는 모든 라이브러리의 크기에 따라 증가하며, 이는 현대 프로그램에서는 상당히 클 수 있다.

문제는 컴퓨터의 DLL 버전이 프로그램을 만들 때 사용했던 버전과 다를 때 발생한다. DLL은 역호환성을 위한 내장 메커니즘이 없으며, DLL에 대한 사소한 변경에도 내부 구조를 이전 버전과 너무 다르게 렌더링할 수 있어, 이 구조를 사용하려고 하면 일반적으로 응용 프로그램이 중단된다. 정적 라이브러리는 응용 프로그램을 빌드하는 데 사용된 버전이 그 안에 포함되어 있기 때문에, 시스템의 다른 곳에 새로운 버전이 존재하더라도, 응용 프로그램에 영향을 미치지 않기 때문에 이 문제를 회피한다.

버전이 호환되지 않는 주요 이유는 DLL 파일의 구조 때문이다. 파일에는 DLL 내에 포함된 개별 방법(절차, 루틴 등)의 디렉토리와 이들이 가져가고 반환하는 데이터 유형이 담겨 있다. DLL 코드의 사소한 변경으로도 이 디렉토리가 다시 정렬될 수 있으며, 이 경우 디렉토리의 4번째 항목으로 간주되는 특정 메서드를 호출하는 애플리케이션은 완전히 다르고 호환되지 않는 루틴을 호출하게 되어 일반적으로 응용 프로그램이 중단될 수 있다.

특히 시스템에 수많은 응용프로그램을 설치하고 제거한 후 DLL과 관련하여 공통적으로 발생하는 몇 가지 문제가 있다. DLL 버전 간 충돌, 필요한 DLL 획득의 어려움, 불필요한 DLL 복사본이 많은 것이 어려움이다.

이러한 문제에 대한 해결책은 마이크로소프트가 DLL 시스템을[citation needed] 쓰는 동안에도 알려졌다. 이것들은 이미 에 편입되었다.NET 교체, "어셈블리".

호환되지 않는 버전

라이브러리의 특정 버전은 라이브러리를 사용하는 일부 프로그램과 호환될 수 있으며 다른 프로그램과 호환되지 않을 수 있다. 윈도우는 특히 C++ 라이브러리와 OLE(Object Linking and Embedding) 객체의 동적 연결에 중점을 두었기 때문에 이에 취약했다. C++ 클래스는 많은 메서드를 내보내고, 새로운 가상 메서드와 같이 클래스에 대한 한 번의 변경으로 이전 버전에 대해 구축된 프로그램과 호환되지 않을 수 있다. 오브젝트 링크와 임베딩은 이를 방지하기 위해 매우 엄격한 규칙을 가지고 있다: 인터페이스는 안정성이 요구되며 메모리 관리자는 공유되지 않는다. 그러나, 수업의 의미론이 바뀔 수 있기 때문에 이것은 불충분하다. 한 응용 프로그램에 대한 버그 수정은 다른 응용 프로그램에서 형상을 제거할 수 있다. Windows 2000 이전에는 COM 클래스 테이블이 모든 사용자와 프로세스에서 공유되었기 때문에 Windows가 이에 취약했다. 하나의 DLL/EXE에 있는 하나의 COM 개체만 특정 글로벌 COM 클래스 ID를 시스템에 가지고 있다고 선언할 수 있다. 해당 클래스의 인스턴스를 만드는 데 필요한 프로그램이 있다면, 현재 중앙에서 등록되어 있는 구현이 무엇이든 얻을 수 있다. 결과적으로, 공통 객체의 새로운 버전을 설치한 프로그램의 설치는 이전에 설치된 다른 프로그램을 실수로 망가뜨릴 수 있다.

DLL 스텀핑

새로 설치된 프로그램이 호환성이 없는 이전 버전의 작업 시스템 DLL을 덮어쓸 때 공통적이고 골치 아픈 문제가 발생한다. 이것의 초기 예는 다음과 같다. ctl3d.dll 그리고 ctl3dv2.dll Windows 3.1용 라이브러리: 타사 게시자가 소프트웨어와 함께 배포하지만 각각 최신 버전이 아닌 함께 개발한 버전을 배포하는 Microsoft에서 만든 라이브러리.[2] 다음과 같은 이유로 DLL 스탬핑이 발생함:

  • 이전에 마이크로소프트가 공유 시스템 구성[3] 요소로 배포한 런타임 DLL(원래 C:\)Windows 및 C:\Windows\SYSTEM)은 제한된 RAM 및 디스크 공간을 가진 공유 메모리 OS에서 코드를 효율적으로 공유하기 위한 방법이다. 따라서 제3자 개발자들도 이러한 방식으로 이를 분배하였다.
  • 애플리케이션 설치자는 일반적으로 시스템 디렉터리에 DLL을 설치하고 시스템 레지스트리를 편집하여 새 DLL을 COM 개체로 등록할 수 있는 권한이 있는 보안 컨텍스트에서 실행된다. 따라서 제대로 작성되지 않았거나 잘못 구성된 설치 관리자는 Windows 파일 보호 또는 Windows 리소스 보호가 변경 사항을 롤백하지 않는 기존 버전의 Windows에서 시스템 라이브러리를 다운그레이드할 수 있다. 윈도우즈 Vista 이상에서는 "신뢰할 수 있는 설치 관리자" 계정만 핵심 운영 체제 라이브러리를 변경할 수 있다.
  • 윈도 애플리케이션은 OS 업데이트를 자체 설치 프로그램에 포함하도록 허용되었다. 즉, 많은 마이크로소프트 DLL은 재배포 가능하기 때문에 응용 프로그램이 특정 라이브러리의 서비스를 필요로 할 경우 이를 포함하게 된다.
  • Windows Installer 이전에 Windows 설치 프로그램은 역사적으로 상업적인 제품이었다; 많은 사람들이 그 과정에서 버전 관리 문제를 간과하거나 잘못 처리하면서 그들 자신의 설치 프로그램을 쓰려고 시도했다.[citation needed]
  • 일부 개발 환경은 컴파일된 라이브러리에 버전 리소스를 자동으로 추가하지 않아 많은 개발자가 이러한 측면을 간과했다. 파일 날짜 확인, 기존 파일 덮어쓰기 또는 DLL이 이미 설치된 경우 복사 작업을 건너뛰는 것만이 올바른 버전 지정 대신 사용 가능한 옵션이었다.[citation needed]
  • 때로는 OS 자체가 DLL을 제거하거나 구버전으로 대체하기도 했다. 예를 들어 Windows 2000은 컬러 프린터 다음에 흑백 프린터가 설치된 경우 컬러 인식 DLL 위에 흑백 프린터 DLL을 설치한다.[4]

잘못된 COM 등록

COM과 Windows의 다른 부분에서는 나란히 레지스트리 없는 어셈블리를 도입하기 전에 어떤 기본 DLL을 사용할지 결정하는 데 레지스트리가 사용되었다.[5] 만약 다른 버전의 모듈이 등록되었다면, 이 DLL은 예상된 DLL이 아닌 로딩될 것이다. 이 시나리오는 동일한 라이브러리의 다른 버전을 등록하는 충돌 설치로 인해 발생할 수 있으며, 이 경우 마지막 설치가 우선한다.

공유 메모리 모듈

16비트 버전의 Windows(및 Windows on Windows)는 지정된 DLL의 인스턴스 하나만 로드한다. 모든 애플리케이션은 동일한 인메모리 복사본을 참조한다. 애플리케이션이 사용하지 않고 메모리에서 언로드될 때까지. (32비트 및 64비트 버전의 Windows의 경우, 프로세스 간 공유는 다른 실행 파일이 정확히 s에서 모듈을 로드하는 경우에만 수행된다.ame 디렉토리; "메모리 매핑"이라는 프로세스를 통해 스택이 아닌 코드를 프로세스 간에 공유한다.) 따라서 원하는 DLL이 시스템 디렉토리나 애플리케이션 디렉토리와 같이 찾기를 기대할 수 있는 디렉토리에 위치하더라도, 다른 응용 프로그램이 제3의 디렉토리에서 호환되지 않는 버전으로 시작한 경우에는 이러한 인스턴스 중 어느 것도 사용되지 않는다. 이 문제는 특정 순서에 따라 응용 프로그램이 시작될 때만 발생하는 16비트 응용 프로그램 오류로 나타날 수 있다.

서비스 가능성 부족

DLL 스탬핑 문제와 직접 충돌하는 경우: DLL에 대한 업데이트가 해당 DLL을 사용하는 모든 애플리케이션에 영향을 미치지 않으면 DLL을 "서비스"하기가 훨씬 더 어려워지고, 즉 현재 버전의 DLL에 존재하는 문제를 제거하기 어렵다(보안 수정은 특히 설득력 있고 고통스러운 경우). 구현자는 DLL의 최신 버전만 수정하는 대신 이상적으로 수정하여 모든 DLL 버전에서 호환성을 테스트해야 한다.

원인들

DLL 비호환성 원인:

  • 16비트 버전의 Windows(윈도우)에서 프로세스 메모리 공간 분리의 부족과 결합된 메모리 제약 사항
  • DLL에 대한 강제 표준 버전 지정, 이름 지정 및 파일 시스템 위치 스키마 부족
  • 소프트웨어 설치 및 제거(패키지 관리)에 대한 강제 표준 방법 부재
  • DLL 응용 프로그램 이진 인터페이스 관리 및 보호에 대한 중앙 집중식 권한 지원 결여, 파일 이름과 내부 버전 번호가 동일한 호환되지 않는 DLL을 릴리스할 수 있음
  • 사용자 및 관리자가 변경하거나 문제가 있는 DLL을 식별하지 못하도록 관리 툴 과간소화
  • 공유 모듈에서 기능의 역호환성을 깨는 개발자
  • Microsoft, 운영 체제 런타임 구성 요소에 대한 Out-of-Band 업데이트 릴리스
  • 이전 버전의 Windows(윈도우)에서 동일한 라이브러리의 충돌 버전을 나란히 실행할 수 없음
  • 현재 디렉터리에 대한 의존도 또는 %PATH% 종속 DLL을 찾기 위해(명시적으로 구성된 디렉토리에서 로드하는 대신) 시간에 따라 및 시스템마다 달라지는 환경 변수
  • 클래스를 재사용하는 개발자자체적인 새로운 GUID를 생성하는 대신, 애플리케이션의 COM 인터페이스에 대한 샘플 애플리케이션의 ID.

DLL Hell은 Windows NT 이전 버전의 Microsoft 운영 체제에서 매우 일반적인 현상이었는데, 주된 원인은 16비트 운영 체제가 프로세스를 자신의 메모리 공간으로 제한하지 않았기 때문에 호환되는 공유 모듈의 자체 버전을 로드할 수 없었기 때문이다. 애플리케이션 설치자는 기존 시스템 DLL을 덮어쓰기 전에 좋은 시민이 되어 DLL 버전 정보를 확인할 수 있을 것으로 기대되었다. 애플리케이션 배포를 단순화하기 위한 표준 도구(종종 종속 운영 체제 DLL 발송을 포함)는 마이크로소프트와 다른 타사 도구 공급업체에 의해 제공되었다. 마이크로소프트는 심지어 마이크로소프트 로고를 사용하기 전에 애플리케이션 벤더들에게 표준 설치 프로그램을 사용하고 그들의 설치 프로그램이 제대로 작동하도록 인증받도록 요구하였다. 좋은 시민 설치자 접근방식은 인터넷의 인기의 상승이 부적합한 응용 프로그램을 얻을 수 있는 더 많은 기회를 제공했기 때문에 문제를 완화시키지 않았다.

멀웨어에서 사용

Windows 운영 체제에서 완전한 자격을 갖추지 못한 DLL을 로딩할 수 있는 모호성은 최근 몇 년[when?] 동안 멀웨어에 의해 악용되어, Windows 자체뿐만 아니라 많은 다른 소프트웨어 벤더의 애플리케이션에 영향을 미치는 새로운 종류의 취약성을 열어 왔다.[6]

해결 방법

다양한 형태의 DLL 지옥이 수년간 해결되거나 완화되었다.

정적 링크

응용 프로그램에서 DLL Hell에 대한 간단한 해결책은 지정된 이름의 시스템 라이브러리를 선택하는 대신 모든 라이브러리를 정적으로 연결하는 것이다. 즉, 즉 프로그램에 필요한 라이브러리 버전을 포함하는 것이다.[7] 이는 C/C++ 애플리케이션에서 흔히 볼 수 있으며, 여기서 어떤 버전의 애플리케이션에 대해 걱정할 필요가 없다. MFC42.DLL 설치되고, 응용 프로그램은 동일한 라이브러리에 대해 정적으로 연결되도록 컴파일된다. 이는 DLL을 완전히 제거하며 마이크로소프트 Foundation Class Library처럼 정적 옵션을 제공하는 라이브러리만 사용하는 독립 실행형 애플리케이션에서 가능하다. 그러나 DLL의 주요 목적인 메모리 오버헤드를 줄이기 위한 프로그램 간 런타임 라이브러리 공유는 희생된다. 여러 프로그램에서 라이브러리 코드를 복제하면 소프트웨어가 비대해지고 보안 수정 사항이나 종속 소프트웨어의 새로운 버전이 배포되는 것을 복잡하게 만든다.

Windows 파일 보호

DLL 덮어쓰기 문제(Microsoft에서는 DLL Stopping이라고 함)는 Windows 2000에서 도입된 WFP([8]Windows File Protection)로 다소 줄어들었다.[9] 이는 허가되지 않은 응용프로그램이 이를 허용하는 특정 Windows API를 사용하지 않는 한 시스템 DLL을 덮어쓰는 것을 방지한다. Microsoft의 업데이트가 기존 애플리케이션과 호환되지 않는 위험은 여전히 있을 수 있지만, 이 위험은 일반적으로 현재 버전의 Windows에서 나란히 어셈블리를 사용하여 감소한다.

타사 애플리케이션은 설치 관리자를 통해 합법적인 Windows 업데이트를 번들로 제공하거나 설치 중에 Windows 파일 보호 서비스를 사용하지 않도록 설정한 경우 이외에는 OS 파일을 스텀핑할 수 없으며, Windows Vista 이상에서는 시스템 파일의 소유권을 가져와서 스스로 액세스 권한을 부여하기도 한다. SFC 유틸리티는 언제든지 이러한 변경사항을 되돌릴 수 있다.

충돌하는 DLL을 동시에 실행

여기서의 솔루션은 디스크와 메모리에 모두 각 응용 프로그램에 대해 동일한 DLL의 서로 다른 복사본을 갖는 것으로 구성된다.

충돌에 대한 손쉬운 수동 해결책은 공통적인 시스템 전체 폴더가 아닌 다른 버전의 문제 DLL을 응용 프로그램의폴더에 배치하는 것이었다. 이는 애플리케이션이 32비트 또는 64비트이고 DLL이 공유 메모리를 사용하지 않는 한 일반적으로 작동한다. 16비트 애플리케이션의 경우, 두 애플리케이션을 16비트 플랫폼에서 동시에 실행하거나 32비트 운영 체제 하에서 동일한 16비트 가상 시스템에서 실행할 수 없다. 이전 버전의 Windows(윈도우)는 모든 응용 프로그램에 대한 단일 COM 개체 레지스트리를 가지고 있었기 때문에 OLE는 Windows 98 SE/2000 이전에 이를 방지했다.

윈도 98 SE/2000은 DLL을 필요로 하는 애플리케이션별로 DLL 사본을 별도로 로드([10]따라서 충돌하는 DLL을 필요로 하는 애플리케이션이 동시에 실행되도록 허용)하는 Side-by-by-by-by-by-assembly라는 솔루션을 도입했다. 이 접근방식은 애플리케이션이 고유의 모듈 버전을 주소 공간에 로딩할 수 있도록 하는 동시에, 메모리 매핑 기법을 사용하여 여전히 동일한 모듈을 사용하고 있는 서로 다른 프로세스 간에 공통 코드를 공유함으로써 애플리케이션 간 DLL 공유(즉, 메모리 사용량 감소)의 주요 이점을 보존함으로써 충돌을 제거한다. 그러나 여러 프로세스 간에 공유 데이터를 사용하는 DLL은 이러한 방식을 취할 수 없다.[11] 한 가지 부정적인 부작용은 자동화된 프로세스 중에 분리된 DLL 인스턴스가 업데이트되지 않을 수 있다는 것이다.

휴대용 응용 프로그램

응용 프로그램 아키텍처와 런타임 환경에 따라, 휴대용 응용 프로그램은 필요한 모든 DLL의 자체 비공개 복사본을 번들로 묶기 때문에 일부 DLL 문제를 줄이는 효과적인 방법이 될 수 있다.[9] 이 메커니즘은 종속 DLL을 로드할 때 해당 경로를 완전히 검증하지 않는 응용 프로그램과 공유 위치 이전에 실행 가능한 디렉터리를 검색하는 운영 체제에 의존한다.[12] 그러나 이 기술은 악성코드에 의해서도 이용될 수 있으며,[13] 개인 DLL이 공유되는 것과 같은 방식으로 보안 패치를 최신 상태로 유지하지 못하면 보안의 희생으로 유연성이 향상될 수도 있다.

또한 애플리케이션 가상화는 애플리케이션을 "버블"로 실행할 수 있게 해 DLL 파일을 운영 체제에 직접 설치하는 것을 피할 수 있다.

기타대책

DLL Hell을 피하기 위한 다른 대책도 있는데, 그 중 일부는 동시에 사용해야 할 수 있다. 문제를 완화하는 데 도움이 되는 몇 가지 다른 기능은 다음과 같다.

  • 이제 설치 도구는 Windows 개발을 위한 주요 환경 중 하나인 Microsoft Visual Studio에 번들로 제공된다. 이러한 도구는 DLL 설치 전에 버전 확인을 수행하며 에 미리 정의된 설치 패키지를 포함할 수 있다.MSI 설치. 이를 통해 타사 애플리케이션은 이러한 구성 요소에 대한 자체 설치 프로그램을 작성할 필요 없이 OS 구성 요소 업데이트를 통합할 수 있다.
  • 시스템 복원은 레지스트리 손상을 비롯한 잘못된 설치로부터 시스템을 복구할 수 있다. 이것이 문제를 예방하지는 않지만, 회복이 더 쉬워진다.
  • 동일한 라이브러리의 여러 버전이 공존할 수 있는 WinSxS(Windows Side-by-Side) 디렉토리.
  • 32비트 버전의 Windows(윈도우) 아래 별도의 메모리 공간에서 16비트 응용 프로그램을 실행하여 두 응용 프로그램이 동시에 충돌하는 DLL 버전을 사용할 수 있도록 하십시오.
  • Windows 파일 보호가 포함된 Windows 버전을 사용하십시오. 2000년에 출시된 Windows Me와 Windows 2000은 Windows XP와 Windows Server 2003처럼 이러한 형태의 시스템 파일 보호를 지원한다. 대체품인 윈도 리소스 보호는 윈도 비스타와 윈도 서버 2008에 도입되었으며, 시스템 파일이 변경되지 않도록 보호하는 다른 방법을 사용한다.
  • 등록 없는 COM: Windows XP는 "등록 없는 COM"이라는 새로운 COM 오브젝트 등록 모드를 도입했다. 이 기능을 통해 COM 오브젝트를 설치해야 하는 애플리케이션은 필요한 모든 COM 레지스트리 정보를 글로벌 시스템 레지스트리가 아닌 애플리케이션 자체의 디렉토리에 저장할 수 있다. 따라서, 동일한 DLL의 여러 버전을 여러 애플리케이션에 동시에 등록할 수 있는 메커니즘을 제공한다(Microsoft에서는 이것을 "Side-By-Side Assembly"[14]라고 부른다). DLL 지옥은 등록이 필요 없는 COM을 사용하면 실질적으로 피할 수 있는데, 이는 최소한 Windows XP 이상의 Windows 버전이 필요하며 EXE COM 서버나 MDAC, MSXML, DirectX 또는 Internet Explorer와 같은 시스템 전체 구성요소에 사용되어서는 안 된다는 제한 사항이다.
  • DLL 종속성을 추적할 수 있는 가능한 패키지 관리 시스템과 함께 운영 체제를 발송하여 패키지 관리자의 사용을 장려하고 DLL의 수동 설치를 금지. Windows Me, Windows 2000 및 이후 버전에 포함된 Windows Installer는 이 기능을 제공한다.
  • DLL 충돌 해결 및 소프트웨어 배포를 위한 중앙 데이터베이스 또는 권한 보유 도서관의 변경사항은 이 기관에 제출될 수 있으므로, 개발된 분기에 호환성이 유지되도록 할 수 있다. 일부 구형 소프트웨어가 현재 라이브러리와 호환되지 않는 경우 당국은 이를 위한 호환성 인터페이스를 제공하거나 이전 버전을 별개의 패키지로 번들로 제공할 수 있다.
  • 소프트웨어 개발자가 라이브러리를 커스터마이징할 필요가 있고, 메인 라이브러리 릴리즈가 필요한 변경사항을 통합하지 못할 가능성이 있는 경우, 프로그램의 전용(일반적으로 프로그램의 전용 디렉토리에 배치)을 위해 커스터마이징된 DLL을 발송하거나, 프로그램을 커스터마이징된 라이브러리와 정적으로 연계할 수 있다.
  • DLL은 애플리케이션과 시스템의 구성요소를 모듈화하는 데 가장 적합하지만, 제3자 라이브러리로서 DLL의 사용이 더 이상 메모리의 제약이 아닌 현대 시스템의 모든 경우에 반드시 필요한 것은 아니다. 예를 들어 애플리케이션이 다른 곳에서는 사용되지 않을 라이브러리를 필요로 하는 경우, 공간 위약 없이 속도 향상으로 정적으로 연결할 수 있다.
  • Windows Vista 이상에서는 특별 신뢰됨 사용운영 체제 파일을 설치하는 설치 프로그램 서비스. SYSTEM을 포함한 다른 사용자 계정은 핵심 시스템 바이너리를 덮어쓸 수 있는 액세스 권한이 없다. Windows 7(윈도우 7)은 이 기능을 레지스트리의 일부 중요한 부분으로 확장한다.
  • 웹 기반 응용프로그램은 서버에서 코드의 대부분을 실행하고 클라이언트에서 브라우저 인터페이스를 사용함으로써 많은 나란히 문제를 방지한다.

참고 항목

참조

  1. ^ "Avoiding DLL Hell: Introducing Application Metadata in the Microsoft .NET Framework". Microsoft. October 2000.
  2. ^ "A summary of CTL3D.DLL articles in Microsoft Support Knowledge Base". Microsoft.
  3. ^ Visual C++ 2005 및 Visual C++ 에서 공유 C 런타임 구성 요소의 재배포네트.
  4. ^ KB 830490: HP Color LaserJet 프린터는 Windows 2000 SP4 기반 컴퓨터에서 그레이스케일 또는 흑백으로만 인쇄하십시오.
  5. ^ Leslie Muller; Steve White (July 2005). "Registration-Free Activation of COM Components: A Walkthrough". Microsoft.
  6. ^ "Secure Loading of Libraries to Prevent DLL Preloading Attacks". Microsoft. 2011-06-11. Retrieved 2011-07-19.
  7. ^ Pfeiffer, Tim (1998-06-01). "Windows DLLs: Threat or Menace?". Dr. Dobb's Journal. Archived from the original on 2010-08-07. Retrieved 2010-07-07.
  8. ^ Windows 파일 보호 및 Windows.
  9. ^ a b Anderson, Rick (2000-01-11). "The End of DLL Hell". microsoft.com. Archived from the original on 2001-06-05. Retrieved 2010-07-07.
  10. ^ "Implementing Side-by-Side Component Sharing in Applications (Expanded)". Microsoft. Archived from the original on 10 December 2006. Retrieved 3 January 2013.
  11. ^ "How do I share data in my DLL with an application or with other DLLs?". Microsoft. Retrieved 2008-11-11.
  12. ^ Desitter, Arnaud (2007-06-15). "Using static and shared libraries across platforms; Row 9: Library Path". ArnaudRecipes. Archived from the original on 2008-06-01. Retrieved 2010-07-07.
  13. ^ "Secure loading of libraries to prevent DLL preloading attacks". Microsoft. Retrieved 16 Feb 2013.
  14. ^ 나란히 어셈블리(Windows)

외부 링크