Re-Coder

2017년 7월 18일 화요일

Windows가 느려졌다?

최첨단의 기술을 필요로하는 게임을 하는 것도 아니다.

하던 업무의 목표가 상향되면서, 더 복잡하고 다양한 기능을 가진 S/W로 업그레이드 한 것도 아니다.

늘상 하던 일을 했고, 내가 원하는 목표치는 항상 같은 수준이었다.

그래서 매일 같은 프로그램을 사용하고, 매일 같은 작업을 반복하고 있다.

그런데, 왜 내 컴퓨터는 점점 느려지는 걸까?

대단한 통찰력의 컬럼을 쓰려는 게 아니다.

그동안 겪었던 몇가지 궁금증, 발견한 몇가지 사실, 그리고 밝히고 싶은 몇가지가 있어서이다.

궁금증에 대한 한가지 설명(?)

- 매일 같은 브라우저를 열어서 같은 사이트를 돌아다니는데, 어느날 부터인가 부쩍 느려지고 버벅대는 컴퓨터. 대체 무엇때문일까?

:
(1) 나도 모르게 브라우저는 조금씩 조금씩 업데이트를 하면서 버그도 고치고, 새로운 사양의 기술도 추가해 나간다. 그러면서 조금씩 무거워지고 느려진다.
(2) 새로운 사양의 기술은 조만간에 여러 웹사이트에서도 적용된다. 아니 대부분의 웹사이트는 새로운 기술이 아니더라도, 자체의 룩앤필(Look & Feel)을 바꾸기도 하고, 내용을 바꾸면서 웹사이트 자체가 무거워지기도 한다.(사실 이게 대부분...)
(3) 흔하게 듣는 해결법에 해당하는 것으로, 인터넷 페이지의 방문 기록, 임시 파일, 캐쉬 파일 등등이 너무 많아져서 저장 매체의 처리가 느려지기 때문에 발생하는 문제도 있다. 이 경우에는 브라우저의 설정 등에서 쓸모없는 파일들을 지워주면 된다.

발견한 몇가지 원인들

- 구글 크롬 브라우저의 백그라운드 프로세스 문제
: 구글의 설정에서 선택할 수 있다.
브라우저를 종료했음에도 불구하고 컴퓨터가 느리다면 한번쯤 확인해 봄직하다.
크롬 브라우저가 워낙에 자주 업데이트되다 보니 어렵지 않게 부딪히는 문제인데, 백그라운드 상태에서 업데이트를 하느라 CPU와 Network, Disk를 상당 부분 점유하곤 하는데, 처음에는 이유를 몰라서 당황하다가 이유를 알고나서 괘씸해서 설정을 바꾸어 버리게 된다.

- LoL의 백그라운드 업데이트 문제.
: League of Legend도 크롬과 마찬가지인데, LoL의 경우에는 이를 사용자의 마음대로 바꿀 설정이 없다는 것. 보통은 게임을 다 마치고 난 뒤에 컴퓨터가 현저하게 느려지곤 하는데, LoL의 업데이트는 용량이 매우 크고 CPU를 많이 사용하는 듯이 보여서 체감상의 성능 저하가 크게 느껴진다.

밝히고 싶은 몇가지

- 특정 svchost.exe가 CPU를 독점하는 문제 (wuaueng.dll의 문제)
- nossvc.exe

2017년 1월 25일 수요일

키보드 후킹

MS-Windows 환경에서 키보드를 후킹하는 방법에 대한 프로그래밍 예 입니다.

http://www.codeguru.com/cpp/w-p/system/keyboard/article.php/c5699/Hooking-the-Keyboard.htm

반(反) 역공학 방지 기법?

Reverse Engineering Protection Technique = 역공학 방지 기법
Anti Reverse Engineering Technique = 반 역공학 기법

이 정도로 해석하고 이해하면 좋을 듯 한데,

Anti Reverse Engineering Protection Technique은 대체 뭐라고 해석하고 이해해야 하는 걸까?

반 역공학 방지 기법?

그렇다면 역공학 방지 기법을 무력화시키는 기법이라는 뜻인걸까?

그렇다면 다음 구문은...

Anti Reverse Engineering Protection Technique To Use Before Releasing Software
(원문에서 사용한 대문자를 그대로 사용한 것임)

'소프트웨어를 출시하기 전에 적용해야 하는 반 역공학 방지 기법'???

통상적인 소프트웨어라면, 역공학 기법에 의해 위변조 되어 악용되거나 핵심적인 기법이 노출되는 것을 방지할 필요성이 있을 수 있지만, 반 역공학 방지 기법이 필요한 소프트웨어란 대체 무엇일까?

암튼, 해당 사이트의 URL은 다음과 같다.
https://www.apriorit.com/dev-blog/367-anti-reverse-engineering-protection-techniques-to-use-before-releasing-software

================================================================
※ 오랫만에 위 링크를 다시 방문해 보니 페이지의 타이틀이 바뀌었다.
Anti Debugging Protection Techniques With Examples.
'나처럼 이상하게 생각하는 사람이 많아서 정정했나 보군'이라고 잠시 생각했지만, 가만히 보니 이것도 별반 다를 것 없는 이상한 문장.
정확한 내용은 본문을 읽어 봐야 알듯. 그런데 아직도 안 읽어봤으면서 대체 언제 읽어 볼건데?

※ 이런 건 어떨까? 참고할 만한 링크 추가.
https://www.codeproject.com/Articles/30815/An-Anti-Reverse-Engineering-Guide
An Anti Reverse Engineering Guide
================================================================

2016년 3월 30일 수요일

파이썬의 라이브러리 NumPy + SciPy _____ 8

dynload_win.c

pathname이라는 변수 대신에 pathbuf를 쓰는게 맞다고 생각해서 위 처럼 소스를 수정했다.

그리고 다시 빌드하고, 다시 실행해 본 결과,

역시나 같은 결과.

그것도 아니면 대체 뭐가 문제란 말인가?

dynload_win.c

의심이 가는 변수들의 값을 모두 확인하고자, 에러 메시지의 내용을 원하는 변수 값으로 출력하도록 수정했다.

그리고 다시 빌드하고 실행해 본 결과,

위의 함수가 호출될 때, 로드하라고 지정한 라이브러리는 _ufuncs
여기에 경로가 모두 포함된 pathname과 pthbuf는 결과적으로 _ufuncs.pyd를 똑같이 지정하고 있었다.

하지만 내가 알아낸 바에 의하면 _ufuncs.pyd라는 파일 자체를 로드하지 못한 것이 아니라, _ufuncs.pyd에서 필요로 하는 또 다른 DLL인 libifcoremd.dll을 찾지 못했기 때문에 발생한 것이었다.

그리고, 내 짐작엔 소스에서 로드하려고 LoadLibraryEx를 호출하는 이 부분이 바로 libifcoremd.dll를 대상으로 삼고 있을거라 생각했던 것이다.

하지만 그게 아니었다.

어쩌면 당연한거였는지도 모르겠다.

너무나 1차원적으로, 단순하게 생각했던 것이다.

저 메시지로 짐작하건데, _ufuncs.pyd도 라이브러리 이므로 LoadLibraryEx() 함수를 이용해 로딩하는 게 맞지만, OS의 입장에서 본다면, _ufuncs.pyd에서 또 다른 라이브러리의 함수를 사용할 수도 있는 것이고 그렇다면 그에 해당하는 DLL도 또한 로드해야만 제대로 된 작동을 할 수 있을 것이다.

그것이 libifcoremd.dll 이었던 것이다.

그렇다면 libifcoremd.dll은 어디에 명시되어 있을까?
아마도 _ufuncs.pyd에 명시되어 있을 것이다. 그래서 Ollydbg에서 해당 DLL을 찾을 수 없다고 메시지를 보여 줬던 것이리라.

그러면 통상의 DLL 탐색 순서에 따라 libifcoremd.dll을 탐색하고 찾아서 자동으로 로드해 주었으면 좋으련만, 윈도우즈에서는 그렇게까지 하지 않는 모양이다.

~~어쩌면 _ufuncs.pyd에는 libifcoremd.dll이 명시되어 있지 않을 수도 있고, 단지 libifcoremd.dll에 포함된 함수(프로시져)의 이름만을 명시하고 있을지도 모른다.~~

그렇다면 OS는 해당 함수를 가지고 있는 DLL이 무엇인지를 모두 뒤져봐야 할 것이고, 이건 너무나도 비효율적일테니, 특별히 자신이 가지 함수 이름을 미리 등록해 놓은 DLL에 대해서만 이런 서비스를 제공해 주는 것일지도 모른다.

~~(마침 _ufuncs.pyd에서 libifcoremd라는 문자열이 있는지 검색해 보았지만 찾지 못하고 있다. 오히려 Ollydbg가 메시지를 보여준게 신기할 따름.)~~

그렇다면 애초에 인텔의 이 라이브러리들을 아무 곳이나 PATH가 지정된 곳에 복사해 넣어서는 안되고, regsvr32라는 프로그램을 이용해서 등록해 주는 절차가 필요한 것이 아니었을까?

그렇다면 전에 받아 두었던 인텔의 배포용 라이브러리를 설치하는 것이 가장 좋은 해결책이 될지도 모르겠다.

그래서 당장 실행.

Intel C++ Redistributables for IA32

Intel Fortran Redistributables for IA32

설치 후에 추가된 PATH. 저기에 DLL들이 위치하고 있다.

설치 후에 다시 실행

그러나 이 모든 것을 다시 설치하고도 문제는 여전.
내가 빌드한 파이썬의 바이너리와 DLL을 모두 지우고, 원래 배포버전으로 돌려놓고 시험해도 마찬가지였다.

그럼 정말 이것도 문제가 아니었단 말인가?

틀림없이 libifcoremd.dll이 설치된 것을 확인했는데도?

그래서 다시 Ollydbg에서 _ufuncs.pyd를 불러 보았다.

헉...이번엔 메시지가 달랐다.

이번엔 libifcoremd.dll이 아니라, libmmd.dll이 문제였고, 그것도 해당 DLL 없다는 것이 아니라 특정 함수의 진입점이 없다는 것.

진전은 있지만 굉장히 불길한 예감.

============================================================================
애초에 이문제는 파이썬의 문제가 아니었다.

생각해 보면 NumPy나 SciPy의 문제도 아니었다.

NumPy나 SciPy를 MS-Windows용으로 빌드를 하는 과정에 어떤 툴을 이용했느냐에 따라 필요로하는 라이브러리나 DLL이 달라질 수 있기 때문이다.

친절한 크리스토프 골케씨가 NumPy와 SciPy를 빌드해서 배포해 주셨지만, 거기에 필요한 Intel의 라이브러리에 대한 충고는 깜빡했다고 밖에 볼 수 없다.
=============================================================================

마지막으로 OllyDbg에서 보여준 메시지에 따라 libmmd.dll을 확인해 보았다.

인텔의 배포 라이브러리 중 C++용과 Fortran용 양쪽 모두에 있는 라이브러리이며, 양쪽 라이브러리 모두 libm_sse2_exp2라는 함수의 이름은 존재하고 있었다.

문제는 정말 함수의 이름만 존재하고 진입점이 없다면....이번엔 인텔의 문제?

2016년 3월 29일 화요일

파이썬의 라이브러리 NumPy + SciPy _____ 7

빌드된 python.

배포되는 Python 실행. 빌드버전과 CRC로 보이는 숫자가 있고 다음에 빌드 시각 2015년 12월 5일 20시 32분.

새로 빌드된 Python 실행. 버전 대신 default, 빌드 시각은 2016년 3월 28일 23시 18분.

Python 소스의 트리 구조

Python의 트리 구조

파이썬 소스의 폴더는 바이너리 배포 버전의 폴더와 약간은 다른데, 여기에서 고민이 생긴다.
완벽한 파이썬의 실행 환경이 갖추어져 있지 않으므로 바로 여기에서 디버깅을 하기엔 제약이 따른다는 것이다.

그러면 어떻게 디버깅을 해야 하는가?

1) 빌드된 디버그 버전의 바이너리를 원래의 환경에 복사해 넣고 디버깅을 한다?
소스와 바이너리의 위치가 다를 경우엔 어떻게 해야 하지?
gdb라면 간단하게 소스 위치만 지정하면 될텐데, Visual Studio의 IDE 환경에서도 이게 가능할까?

2) 소스 디렉토리에 필요한 나머지 파일들을 복사해 놓고 디버깅?
파이썬이 비록 인스톨러로 설치가 되긴 하지만, PATH에 경로를 지정하는 것 외에는 별다른 작업이 필요하지 않은 것 같던데? 아닌가?
그리고 Windows/system32 폴더에 python27.dll이 복사되어 있는 것도 보았다.

먼저 2번의 방법을 좀 더 생각해 보다가, 이런 의문이 떠 올랐다.
- 맨 처음의 NumPy와 SciPy를 설치할 때도 특별히 파이썬의 위치를 지정하지 않았지만 알아서 설치가 되었다. 이건 어떻게 가능했을까? (PATH를 보고? 설치 프로그램인 pip의 위치를 기준으로?)
: 이걸 새로 빌드된 환경에서 시험해 보려고 했는데, 아무리 찾아봐도 pip가 보이질 않는다.
그냥 복사를 해서라도 해 볼까 하다가 걍 포기.

- 파이썬 인터프리터에서 import를 하면 해당 라이브러리를 잘 찾아낸다. 어떻게 가능한걸까?
: 구글에서 "python import dir order"로 검색을 하자 파이썬의 문서에서 "module-search-path" 부분을 찾아서 보여준다.
https://docs.python.org/2/tutorial/modules.html#the-module-search-path

위 링크에서 언급하는 sys.path를 직접 확인해 보았다.

Python의 sys.path

새로 빌드된 Python의 sys.path

환경변수인 PATH에 지정된 경로와는 상관없이, 현재 실행된 위치를 기반으로 내부의 탐색 경로가 바뀌는 것을 알 수 있다.

다시 위의 디버깅에서 1번의 방법에 대해 알아보니, 빌드시에 생성된 pdb에 소스의 위치 정보가 있으므로 바이너와 소스의 위치가 달라도 소스 레벨의 디버깅이 가능하다고 한다......정말일까?

그래서 빌드된 exe, dll, pdb 파일들을 모두 원래의 파이썬이 설치되어 있던 폴더에 복사했다. (원래의 exe와 dll은 다른 폴더에 피신 시켜 둠.)

새로 빌드한 파일들을 파이썬 설치 폴더에 복사

그런데.... 안된다.
Visual Studio에서 읽어 들여 보았으나, 디스어셈블 코드만 보여 줄 뿐, 소스를 찾지 못한다.
심지어 소스 폴더를 지정하는 옵션도 없다.

그래서....Visual Studio에서 프로젝트의 속성을 수정했다.

Python 프로젝트의 속성에서 Debugging의 Command 항목 수정

저기에 직접 디버깅할 실행 파일 이름을 지정해주면 된다.

Debugging 위의 General에서 Output Dir을 바꿔주는 것도 방법이긴 한데, 수정 - 빌드 - 디버깅 작업이 그리 많지 않을거라 생각하기에 최소한만 건드리는 방법을 택한 것이다.

그리고 Visual Studio에서 Start Debugging(F5)을 하면 다음과 같이 나온다.
여기에서 sys.path로 작업중인 디렉토리를 확인할 수 있다.

Start Debugging후에 sys.path로 작업중인 위치 확인.

그리고 그토록 알고자 했던 그 문제점이 재현되는지 확인하기 위해 "from scipy import special, optimize"를 입력하자...

기존의 문제점이 재현되는지 확인....어?

출력되는 메시지가 다르다. 에러는 에러인데....뭔가 이상하다.

아까 디버그와 릴리즈 버전의 바이너리를 모두 복사해 놓은 상태이기에, Visual Studio를 거치지 않고 바로 실행해서 다시 확인해 보았다.

먼저 디버그 버전의 경우..

디버그 버전

역시나 맨 처음과는 다른, Visual Studio를 거쳤을 때와 같은 에러 메시지.

그럼 릴리즈 버전의 경우는...

릴리즈 버전

애초에 보았던 것과 동일한 에러 메시지.

이런 x같은 경우를 보았나.

디버그 버전과 릴리즈 버전의 동작이 서로 다르단 말인가? 왓더뻐~어~억 쒜트 쒜~에~트

메시지를 차근 차근 확인해 본 결과, 릴리즈 버전은 numpy를 먼저 다 import하고 난 후에 scipy의 special을 import하는 중에 에러가 발생했고, 디버그 버전은 numpy를 import하는 과정에서부터 에러가 발생한 것으로 보인다.

침착하고.....

이 문제점이 내가 빌드하는 과정에서 발생한 것인지, 파이썬 자체의 소스 혹은 빌드 구성에 문제가 있는 것인지 알려면 빌드 로그를 모두 꼼꼼하게 확인해 보아야 한다.

그리고 애초에 문제가 되었던 부분에 대한 확인은, 당장은 릴리즈 버전으로 밖에 할 수 없는 상황이고, 이것도 메시지 출력을 이용하거나, 의심되는 부분을 바로 수정해서 확인해 보는 방법 뿐인 듯 하다.

단, 하나의 문제점 때문에 너무나 많은 과정을 거치고 있고, 자꾸 곁가지를 치면서 목표의식마저 흐릿해져 가고 있는 듯 하다.

디버그 버전과 릴리즈 버전의 문제를 확인하기 앞서서, 본래의 문제점을 먼저 해결하길 나 자신에게 바래 본다.

2016년 3월 28일 월요일

파이썬의 라이브러리 NumPy + SciPy _____ 6

==========================================================
이 포스팅은 쓸모 없어진 포스팅입니다.
(NumPy + SciPy ____ 4 ~ NumPy + SciPy ____ 8)
해당 문제점은 Scipy 패키지를 빌드했던 툴(아마도 MS Visual Studio 201x)이 Windows XP를 지원하지 않아서 발생한 것으로 추측하고 있습니다.
이후의 포스팅에서 이 시행착오를 정리할 계획입니다. (아마도 NumPy + SciPy ____ 9)
==========================================================

앞선 포스팅에서 언급한 방법 중, 첫번째인 파이썬 직접 빌드 시도.

파이썬의 창시자가 구글에서 일하고 있으며, 구글의 지원아래 업무시간의 일정 부분을 파이썬 개발에 할애하고 있다고.....누군가한테 들은 적이 있었다.

각설하고...파이썬 소스를 보면서 잠깐 보았던 빌드에 관한 문서를 보고, 빌드 해보고, 실패하고, 인터넷 검색하고, 다시 좌절하고, 귀찮아지고...아마 며칠간은 귀차니즘에 손도 안댔던 거 같다.

그래도 이제 고지가 코 앞이라...는 희망으로 다시 힘을 내 보자.

시작하기 전에 필요한 것들 미리 정리해 보았다.
===========================================

1) 파이썬 소스 : 나는 파이썬 2.7.11을 받아서 빌드하기로 했음. 파이썬 3.x는 Windows Vista 이상에서만 빌드되고 실행되니 이 점은 주의 할 것.

2) 컴파일러 : MS Visual Studio 2008 이상. Express Edition도 된다고 함.

3) SVN client : svn.exe 이름으로 실행되는 command line 버전으로 어디서나 호출 되도록 PATH에 경로 지정 필요.
나는 Tortoise SVN을 사용했는데, 아래 링크된 정성태님의 글에도 나와 있지만 설치시에 반드시 command line client tool을 설치하도록 변경 해 주어야 한다.
그리고 Tortoise SVN은 1.7.15가 Windows XP에 설치되는 마지막 버전이다.(1.9.x & 1.8.x는 설치 안되는 거 확인했음.)

TortoiseSVN 1.9.3

TortoiseSVN 1.9.3 설치 안 됨.ㅠㅠ

TortoiseSVN 1.7.15는 설치 됨. command line client tools는 기본적으로 선택되지 않음.

command line client tools를 설치하도록 바꿈.

Explorere와 연동되는 툴이라서 어지간한 프로그램들을 종료해야 설치 됨.

그러고도 시스템 재시작 필요.

4) Perl interpreter : perl.exe 이름으로 실행되는 command line 버전으로 PATH 경로 지정 필요. 가급적 최신 버전으로 할 것. Strawberry Perl 5.12.2를 이용했으나 에러 발생.

빌드 중 에러 발생. 대놓고 Active Perl 쓰라고 함.

다시 정정. 아마도 Pre-Build event에 뭔가 잘못이 있는 듯 함.
ActivePerl 5.22.1을 설치했으나 다음과 같이 에러 발생.

ActivePerl 설치 후에 build -r로 rebuild한 결과. 마찬가지 에러 발생.

그러나 메시지를 보면, 에러 없이 ssl 라이브러리가 완성되었다.
단지 메시지의 문제였을 뿐?

5) NASM (v2.10 이상) : nasm.exe 이름으로 실행되는 command line 버전으로 PATH 경로 지정 필요.

시작하기 전에 읽어보면 도움이 될 것 들.
=====================================

1) 직접 파이썬을 빌드해 본 경험자의 정리 된 자료
정성태님의 Python 소스 코드를 Visual C++로 빌드하는 방법 (단, 이건 Python 3.x를 64 bit로 빌드하는 경우)
저 버전의 파이썬은 조금 예전 버전 경우라 그런지 참 이상한 문제들로 문제를 겪고 있는 부분들이 보인다. 이 버전에서 같은 문제가 발생하지 않을 수 있으니 반드시 증상을 확인한 후에 참조할 것.

2) 파이선 소스에 포함 된 readme.txt 첫번째 : Python-2.7.11/PCBuild/readme.txt

3) 파이선 소스에 포함 된 readme.txt 두번째 : Python-2.7.11/PC/VS9.0/readme.txt

미리 알아두면 좋은 것들.
=======================

1) 파이썬은 시간을 거치면서 많은 기능의 확장이 있었고, 이들 기능 중 일부는 이미 독립적인 라이센스를 가진 소스들을 이용하고 있다. 이런 소스들이 파이썬을 빌드하는데 필요하긴 하지만, 무작정 파이썬 소스에 묶어버리기엔 많은 문제점들이 존재한다. (카피라이트, 라이센스, 버전 관리 등)
따라서 이들 써드 파티의 소스는 별도로 가져와서 빌드를 해야 한다.

2) 위에서 읽어보라고 한 문서를 보면 알겠지만, 문서가 알아보기 쉽거나 간결하지 못하다. 중언 부언에, 내가 원하는 경우를 딱 꼬집어 찾기도 어렵고, 끝까지 읽어 보고 필요한지 아닌지 직접 판단해야 한다.

3) 예전에는 지원했지만, 이제는 지원을 하지 않는다고 없애지 않고 남겨진 폴더들이 있다.
VC6 (Visaul C++ 6.0), VS7.1 (Visual Studio 2003), VS8.0 (Visual Studio 2005)는 더 이상 지원하지 않는다고 하니 쓸데없는 희망을 가지지 말자.

시작
====
명령 프롬프트에서 PC/VS9.0으로 이동해서 build -e를 실행.

이 과정을 통해서 써드파티의 소스를 다운로드 받고 각각을 빌드한다.

문서에서는 pcbuild.sln을 열어서 빌드를 하라고 되어 있지만, 문서를 조금 더 읽어보면 그럴 수 없는 이유들이 나온다.

즉, 초기에 써드파티 소스를 가져오는 과정과 특별히 먼저 빌드되어야 하는 하위 프로젝트들이 존재하기 때문이다.
(하위 프로젝트들 가운데 좀 까다로운 부분이 Open SSL이고, 또 Tcl/Tk 그리고 이를 이용하는 tkinter 부분이라고 되어 있다. 특히 Tcl/Tk 부분은 pcbuild.sln으로는 빌드나 클린이 안되니 반드시 build.bat를 한번은 거쳐야 한다고 한다.)

아마도 처음에 이 부분들이 빌드가 되고 나면, 나머지 파이썬 자체의 소스를 변경하고 빌드하는 과정은 Visual Studio 내에서 가능하리라 생각한다.

build -e, 먼저 받은 소스가 있는 경우에는 skip하고 빌드.

25개 프로젝트 성공, 실패 없음, skip 1개?

이제 각 폴더에 남겨진 BuildLog.htm을 확인해 보고 문제가 없는지 확인해봐야 함.

그리고 Skip된 프로젝트가 무엇인지도...

2016년 3월 21일 월요일

파이썬의 라이브러리 NumPy + SciPy _____ 5

==========================================================
이 포스팅은 쓸모 없어진 포스팅입니다.
(NumPy + SciPy ____ 4 ~ NumPy + SciPy ____ 8)
해당 문제점은 Scipy 패키지를 빌드했던 툴(아마도 MS Visual Studio 201x)이 Windows XP를 지원하지 않아서 발생한 것으로 추측하고 있습니다.
이후의 포스팅에서 이 시행착오를 정리할 계획입니다. (아마도 NumPy + SciPy ____ 9)
==========================================================

정말 정말 궁금했습니다.
왜 나만 안된다고 혼자서 이리도 고생을 하는건지....
정말 미치도록 알고 싶었습니다.

그래서 결국....파이썬의 소스를 보기로 했습니다.

마이크로 소프트가 언급한 DLL의 탐색 경로에 들어가 있음에도 자꾸 DLL을 찾지 못한다고 나오는게 너무 답답해서 누가 잘못하고 있는건지 알아봐야겠습니다.

이젠 귀찮아서 사진도 어지간하면 안올릴 생각이다.

다운로드 받은 소스는 2.7.11
https://www.python.org/downloads/release/python-2711/

소스 분석엔 소스인사이트가 최고.

핵심만 빠르게 찾아가기 위해서 메시지를 바로 찾아 보는게 장땡.

"DLL load failed"라는 문자열로 검색한 결과

dynload_os2.c
dynload_win.c

위의 두개 파일만 검색 된다...그나마 다행.
이름을 보니 볼 거 없이 dynload_win.c가 내가 찾는 파일임이 확실하다.

dynload_win.c

DLL load failed는 저기 보이는 소스에서 조금 더 내려가면 나온다.

저기서 봐야 할 것은 GetFullPathName()과 LoadLibraryEx().

먼저 해당 함수에 대한 MSDN의 설명을 참조.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa364963(v=vs.85).aspx

GetFullPathName()

첫번째 두번째 인자가 입력이고 세번째 네번째가 출력.

그러니까 pathname을 넣고 pathbuf를 받아온 것이다.

그러면 다음엔 pathname이 아닌 pathbuf를 사용해야 할텐데, 다음의 LoadLibraryEx()에서는 pathname을 사용하고 있다.???

LoadLibraryEx()에 대한 설명도 찾아 보자.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx

LoadLibraryEx()

이 함수는 좀 복잡한데 마지막 인자인 dwFlags에 따라서 DLL 탐색의 순서나 방법이 달라진다고 한다.

LoadLibraryEx()의 dwFlags 설명 중.

이 플래그에 대한 설명도 참 복잡한데, LOAD_WITH_ALTERED_SEARCH_PATH를 사용할 때에는 반드시 파일을 절대 경로로 적어야 한다는 것.

그리고 탐색방법은 아래에 설명....한다고 되어 있는데, 설명이 없다.휴....

다른 페이지에서 설명을 찾았는데,

https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

Dynamic-Link Library Search Order이라는 페이지이고,

여기에서

Alternate Search Order for Desktop Applications

이라는 항목을 찾아보면 설명이 나와 있다.

하지만 해당 항목을 읽어보면 알겠지만 통상적으로 탐색을하는 디렉토리의 순서가 다를 뿐 크게 문제가 되지는 않아보인다.

그렇다면 문제가 될 것으로 예상되는 건, 앞서 LoadLibraryEx()에서 LOAD_WITH_ALTERED_SEARCH_PATH 플래그 사용시 반드시 절대경로를 사용해야 한다는 문구였다. 절대 경로가 아닐 경우에는 결과가 어찌될지 모른다는게 설명...

과연 파이썬 소스에 결정적인 문제가 있어서 이것이 원인이었는지를 확인하려면,

1. 직접 파이썬을 빌드하고 해당 부분을 적절하게 수정한 뒤 문제가 해결되는지 확인한다.

2. 파이썬 3.x의 경우에는 이 부분이 같은지 다른지 확인하고, 또 문제가 발생하는지 여부를 확인해 본다.

2-1. 파이썬 3.x도 소스가 같고 문제도 동일하게 발생한다면 위의 1번 방법으로 확인해야 한다.

2-2. 파이썬 3.x도 소스가 같은데 문제가 발생하지 않는다면, 문제의 원인은 다른 곳에 있다는 의미이다. 골치 아픈 케이스.

2-3. 파이썬 3.x는 소스가 다르고 문제가 발생하지 않는다면 3.x의 소스를 최대한 활용해서 무엇이 문제였는지 최대한 유추해 볼 수 있다. 하지만 결국엔 1번의 과정을 밟아야 한다.

2-4. 파이썬 3.x는 소스가 다른데 문제가 동일하게 발생한다면 완전히 별개의 문제로서 따로 따로 소스를 분석해야 하지만, 파이썬 소스의 문제가 아니라 내가 사용하는 환경의 문제일 가능성이 높아진다.

3. 최소한의 비용으로 최대한의 결과를 얻기위해 리버싱으로 살짝만 확인해본다.(?)

이상의 계획을 가지고 생각해보니, 먼저 2번의 과정을 거치는게 빠르겠다 싶었다.

그래서 파이썬 3.x의 소스를 받아서 확인해 본 결과....소스가 달랐다.

아예 LoadLibraryEx()를 부르는 함수에 들어오기 전에 먼저 처리를 한게 아닐까 싶게...그래서 소스만으로 비교를 하기엔 무리가 있어서 직접 실행해 보기로 했다.

그.런.데......파이썬 3.x는 Windows Vista이상에서만 돌아간단다.....설치도 안된다...ㅠ.ㅠ

결국 2번의 방법은 몽땅 수포로 돌아가고....

1번의 정공법이냐, 3번의 편법이냐....만 남은 상황이다.