[MSDN] End of DLL War!

앞서 본 DLL 이야기 처럼 DLL은 많은 장점을 가지고 있으나 관리하기 쉽지 않다는 문제가 있다.

사람들이 흔히 만드는 DLL의 오류나 에러는 3가지 타입으로 분류된다고 하는데,

Type 1은 사용자나 일부 잘못된 프로그램이 OS가 사용하는 핵심 DLL의 버전을 지 맘대로 바꿔버릴는 경우를 말하는데 최신 버전의 DLL이 구버전으로 바뀌어 버림으로써 오는 문제다.

이 Type 1 DLL 에러는 과거 Windows 98 시절에는 셀수없이 많았다고 한다. 하지만 지금은 그 자취를 거의 감추었다는데 그 이유는 차차 알아보자.

Type 2는 Side-Effect 라 불리는 오류인데 이것은 DLL이 업데이트 되면서 (최신 버전으로 바뀌면서) 사용자가 의도와는 다르게 변경된 DLL의 함수들이 예상치 못한 작동을 하는 것이라는데 이것은 뭐 DLL을 만든사람의 실수가 아닌가 싶다만... 구버전의 DLL로 잘 작동하던 프로그램은 반드시 새 버전의 DLL과 잘 작동해야 하지만 100% 그렇지는 않다는게 문제란다.

Type 3는 가장 드물지만 DLL 자체에 버그가 있는 경우다. 물론 이건 아주아주 드물기는 해도 발생할 수 있음을 명심해야 한다. 베타 버젼을 즐겨 사용하는 사람이라면 더더욱 그렇겠지...

이런 3가지 타입의 DLL 오류의 제거를 위해서 Windows 2000에서 아주 기발하고 유용한 방법이 제시되는데 그것이 바로 WFP (Windows File Protection) 이라는 것이다.

우선 이것을 이해하기 위해서는 System DLL과 Private DLL을 알아야 한다. 하나의 컴퓨터에는 무수히 많은 DLL이 존재하는데 이것들은 딱 크게 나눠서 두가지의 DLL로 분류가 된다.

System DLL은 Windows/System32 폴더안에 주로 존재하는 '핵심적인' DLL들이다. 즉, OS가 빈번히 사용하며 여러가지의 프로그램에 대해서 많이 사용하는 DLL을 말한다.

고로 이런 System DLL들은 '잘못' 건드리게 되면 윈도우 전체가 멈춰버리거나 죽음의 '퍼런 화면'을 경험하게 될것이다.

그래서 Windows 2000부터는 이런 System DLL들은 사용자가 변경을 하려해도 DLL에 내장되어 있는 Key를 체크하여 잘못된 변경을 하더라도 윈도우가 알아서 재복사를 해버린다.

즉, Service Pack 과 같은 '시스템이 제공하는 업데이트'가 아니고서는 이 System DLL들을 변경 할수 없다. 고로 사용자의 실수로 인한 시스템 전체의 오류는 완전히 차단하는 것이다.

두번째로 Private DLL이다. 이 Private DLL은 다른말로 하면 Side-by-side DLL이다. 흐흐흐... 나는 이 말을 듣는 순간, Side-by-side Assembly가 빠악! 하고 머리에 떠올랐는데 과연 다른 사람도 그럴까? :)

이 Private DLL은 어떻게 보면 DLL의 기본 원리중에 최대 장점이었던 '통일성'을 완전히 역행하는 반역자이지만 '독립성'을 확보하게 해주는, 즉 소소한 프로그램을 많이 사용하는 나같은 프로그래머에게는 꼬옥 필요한 것이다.

원래 DLL은 통일된 하나의 DLL을 사용함으로써 모든 프로그램이 공유하는 DLL 하나를 관리함으로써 유지 보수 및 관리를 쉽게 한다는 장점이 디스크나 메모리 공간 절약보다 더 크다고 말했다.

하지만 Visual Studio를 써본 사람은 알겠지만 Visual Studio는 하나의 프로젝트를 컴파일 할때 .NET Framework가 제공하는 Assembly 들 (일종의 DLL)을 사용하는데 이놈들의 버전이 컴퓨터마다 달라서 기껏 만들어논 프로그램이 다른 컴에서 돌리면 실행조차 되지 않는 이상한 경험을 해보았을 것이다.

이때는 물론 다른 컴퓨터에 Visual Studio를 설치하거나 .NET Framework를 설치해서 업데이트 하면 되겠지만 만약 그런게 없는 컴퓨터라면 어쩔건가?

바로 이런 점이 '통일성'이 가지는 문제점이다. 다른 환경을 가지는 다른 컴퓨터에 대한 '이식성'이 떨어지는데 이걸 해결하기 위한 것이 'Static한 링크' 즉, 통일성과 반대되는 의미로 '유동성 혹은 프로그램의 독립성'이다.

이 Private DLL은 내가 실행하고자 하는 .exe파일과 같은 폴더에 존재하며 .exe 파일에 필요한 DLL 파일을 말한다. 이것은 당연히 System DLL이 아니기 때문에 사용자가 원하는, 필요로 하는 특정한 버전의 DLL을 .exe 파일과 함께 놔두면 되는 것이다.

내가 참고한 MSDN의 문서에서는 Private DLL을 사용한다는 것을 OS인 윈도우에게 알려주기 위해서는 .exe가 있는 폴더에 (Private DLL에 있는 폴더) 간단하게 실행하고자 하는 실행 파일과 같은 이름 + .local 파일을 만들어주면 된다고 되어 있는데 아직까지 이 룰이 적용되는지는 잘 모르겠다.

내가 알기로는 .exe 파일은 기본적으로 현재 실행 파일이 있는 폴더에 필요로 하는 DLL이 있는지 먼저 검색하는 것으로 알고 있다. 물론 테스트 해본적은 없다... -_-

이 Private DLL을 .exe 파일과 함께 두면 .exe 파일은 실행시 Private DLL을 읽게되고 프로그램 제작자는 이 프로그램이 잘 작동하는 Private DLL을 .exe 파일과 같이 제공하면 그만인 것이다. 이렇게 함으로써 '통일성'은 잃게 되지만 Private DLL을 사용하는 .exe 프로그램은 대신에 System DLL에 영향을 전혀 받지 않는 '독립성'을 가지게 된다.

자, 이 두가지의 DLL 분류와 WFP를 이용하면 위에서 나열한 거의 모든 Type 에러를 해결할 수 있다.

System DLL은 윈도우가 자동으로 관리함으로써 사용자의 미숙으로 인한 잘못을 예방하고, Private DLL을 이용함으로써 환경이 다른 컴퓨터로 이식성 및 독립성을 증가 시켰다.

이 문서에서는 DLL Universal Problem Solver라는 프로그램(DUPS: 둡스!?)을 이용해서 네트워크 상에 있는 모든 연결된 컴퓨터에 대해 DLL 버전을 체크하고 문제가 있는지 검사하는 프로그램에 대해 간단히 설명하고 있는데 사실 나에게는 아직 필요가 없는 듯해서 한번 읽고 넘어 갔지만, 게임방 사장님들에게는 필요한 유틸리티가 아닌가 싶다...

워낙 우리나라 게이머들께서 겜방 PC로 이것 저것 많이 테스트 하시니...  ^^