« Previous : 1 : ... 9 : 10 : 11 : 12 : 13 : Next »

윈도우 운영체제가 NT 초창기 시절 이래로 지금까지 사용해 오고 있는 실행 파일 포맷은 잘 알다시피 portable executable 형식입니다. 헤더도 이니셜인 PE로 시작합니다. 물론 네이티브 EXE이기 때문에 코드 부분은 기계마다 다르겠지만, 헤더 구조체라든가 리소스 같은 공통된 부분은 최대한 일치시켜서 이식성을 고려해서 설계했다는 뜻이지요.

늘 인텔 CPU에서만 돌아가는 EXE만 보다가 MIPS 같은 RISC CPU에서 돌아가는 PE 실행 파일을 헥사 에디터로 들여다보니 진짜로 기계어 코드가 한눈에 보기에도 일정 바이트 간격으로 아주 균일하게 나열돼 있더군요. 그걸 보고 놀랐던 기억이 납니다.

64비트 PE도 일부 구조체만 64비트로 확장되었을 뿐 기본적인 골격은 초창기 32비트 PE와 같습니다. 더구나 윈도우 운영체제가 인식하는 리소스(스트링 테이블, 대화상자, 메뉴 등)의 포맷은 매우 다행스럽게도 32비트 PE와 완전히 일치합니다.

EXE와 DLL은 자신만의 프로세스 공간을 만들어서 단독 실행이 가능하냐의 차이가 존재하는데, 기술적으로는 헤더의 비트 몇 군데만 다르지 똑 같은 PE 바이너리입니다. 이런 바이너리를 ‘모듈’이라고 부릅니다.

c, cpp 같은 소스 코드를 컴파일하면 기계어 코드인 obj 파일이 생깁니다. 이런 obj 파일과 lib를 링크하면 그런 모듈 파일이 결과물로 생성됩니다. lib는 또다른 obj의 묶음일 뿐 obj와 완전히 다른 파일이 아닙니다. 또한 모듈 역시 그런 obj, lib에 들어있는 코드를 PE 규격에 맞게 재배치하고 묶은 파일일 뿐이지 원시 파일과 그렇게 큰 차이가 없습니다.

윈도우 운영체제에서 개발 환경을 만든 사람들의 생각은, 링커가 특별히 할 일이 없게 하는 것이었던 것 같습니다. 물론 요즘은 전역 최적화처럼 링크 타임에도 코드를 생성하는 기술도 도입되어 사정이 그렇게 간단하지만은 않게 됐지요.

PE는 text(실행되는 기계어 코드), rdata(스트링 리터럴처럼 읽기전용 상수나 초기화 값), rsrc(윈도우 리소스 데이터), DLL 심볼 import/export 테이블, reloc(재배치 정보) 등 여러 섹션으로 나뉩니다. 특히 재배치 정보는 Win32s 시절에는 exe에도 필요했지만 지금은 dll에만 넣어 주면 됩니다.

PE의 헤더에는 자신의 기본 어드레스, 자신이 돌아가는 데 필요한 최소한의 운영체제 버전 같은 여러 정보가 들어가고 심지어 자신을 빌드한 링커의 버전을 기입하는 공간도 있습니다. 가령 비주얼 C++로 빌드하면 6.0, 7.1 (닷넷 2003), 8.0 (2005) 같은 번호를 쉽게 식별할 수 있지요.

원래 MS 자체에서 만든 프로그램 바이너리들의 링커 버전은 비주얼 C++의 버전과 거의 일치하지 않았습니다.
가령 윈도우 95는 까마득한 2.5, 그리고 98/ME는 3.1, 윈도우 2000은 5.12, 오피스 XP는 6.2였습니다. 비주얼 C++과는 별도로 자신들만 쓰는 컴파일러/링커가 있었던 것 같습니다.

하지만 이것이 언제부턴가, 한 02~03년부터 버전이 일치하기 시작했습니다. MS에서도 내부적으로 비주얼 스튜디오를 쓰기라도 했는지?
윈도우 XP는 7.0으로 당대의 최신 비주얼 C++이던 닷넷 2002와 일치합니다.
그리고 XP sp2 (sp1은 모르겠음)와 오피스 2003은 비주얼 C++ 닷넷 2003의 버전과 같은 7.1입니다.

그 후 윈도우 비스타와 오피스 2007의 모든 바이너리들은 비주얼 C++ 2005의 버전인 8.0으로 물갈이되어 있습니다. 하지만 CRT 라이브러리는 살짝 다릅니다. 오피스는 msvcr80을 쓰지만 운영체제는 자신만의 msvcrt를 고수하고 있습니다. 하지만 이제는 msvcrt에도 비주얼 C++ 2005에서 새로 추가된 strcpy_s 같은 보안 강화 함수들이 추가되어 있습니다.

msvcrt는 이제 운영체제가 혼자 마음대로 바꿔 쓰는 CRT DLL로 격리시키고 응용 프로그램들은 이제 msvcr??을 알아서 배포해서 쓰든가, 싫으면 스테틱 링크하라는 구도가 된 셈입니다.

Posted by 사무엘

2010/01/10 23:17 2010/01/10 23:17
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/31

C 런타임 라이브러리에는(이하 CRT) 단순히 내가 호출하는 printf, strcpy, malloc 같은 함수에 대한 코드만 있는 게 아니다.
사용자가 작성한 C/C++ 프로그램보다 아래 계층에서 먼저 실행되면서
사용자가 짠 main 함수를 호출해 주고, 표준 C 스펙에 정의돼 있는 각종 전역변수의 값을 설정해 주고
전역변수 C++ 오브젝트들을 미리 초기화해 주는 것도 CRT의 몫이다.

이 오버헤드가 작지는 않다.
그렇기 때문에 hello, world! 한 줄만 찍는 프로그램을 C 언어로 짜 봐도 어지간해서는 크기가 최소한 1만 바이트는 넘어서며, 특히 윈도우 프로그램의 경우 내가 전혀 호출하지 않은 GetStartupInfo, GetVersion 같은 커널 쪽 Win32 API를 호출해 있는 걸 볼 수 있다. (CRT를 스테틱 링크한 경우)

그런 함수는 당연히 CRT가 호출한 것이다.
가령 main 함수에 인자로 전달되는 명령줄 인자는 CRT가 준비해서 넘겨 준 것인데,
CRT 역시 명령줄 인자는 더 아래 계층의 GetCommandLine 같은 API 함수를 통해 얻어 온 후, 파싱해야 하기 때문이다.

이 CRT 초기화 코드를 무시하고 진짜 순수하게 내가 짠 코드만 집어넣게 하는 링크 옵션이 컴파일러에 따라서 물론 존재한다.
이렇게 하면 어셈블리 프로그래밍 하듯이 아주 작은 EXE를 만들 수 있다.
하지만 이 경우, 정상적인 C언어 사용은 포기해야 한다.

CRT 초기화 코드가 실행되지 않으면 printf, malloc 등 I/O라든가 뭔가 초기화 context가 필요한 함수들도 죄다 사용할 수 없게 되기 때문이다.
윈도우 환경의 경우 그런 것들도 Win32 API만으로 내가 직접 다시 짜야 할 것이다.
fopen은 CreateFile로,
malloc/free는 HeapCreate 등으로 힙 관리 직접 다 하고,
sprintf는 wsprintf 등으로. (그나마 윈도우는 운영체제 차원에서 % 문자를 C랑 똑같이 해석해 주는 함수가 있어서 다행이다. 운영체제 자체가 C언어로 개발됐다는 증거가 아닐까 한다)

과거 16비트 도스용 컴파일러 시절에는 이 CRT 라이브러리가
메모리 모델별로 따로 존재해야만 했다. tiny, small, medium, compact, large, huge 기억하시는가? 아주 골치아팠다.

그러다가 32비트 윈도우 환경에 와서는 메모리 모델 구분은 없어지고 CRT에 새로운 속성이 존재하게 됐다.

- 멀티스레드: 옛날에 컨텍스트를 저장하는 데 배째라 전역변수 썼던 것들을 이제 스레드 TLS로 옮겨야 한다. 대표적인 예가 strtok. 이제 비주얼 C++ 2008부터는 싱글스레드 라이브러리는 없어지고 무조건 멀티스레드만 지원한다.
- 디버그: 도스용 컴파일러 중에 디버그 용 CRT가 따로 있었던 건 별로 본 기억이 없다.
- DLL이냐 스테틱이냐: CRT를 DLL로 따로 떼어낼 수도 있게 됐다. 한 프로그램이 같은 CRT를 사용하는 수많은 DLL들을 로딩하는 경우, 그 DLL 모듈들도 CRT DLL 하나만 로딩하도록 개발하면 메모리를 많이 절약할 수 있다.

Posted by 사무엘

2010/01/10 23:01 2010/01/10 23:01
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/25

side by side assembly는 윈도우 운영체제의 구조적인 문제 중 하나였던 DLL hell 문제를 해결하기 위해 윈도우 XP에서부터 처음으로 도입한 기술입니다. (그 후 2003, 비스타 등등..)

전통적으로 Win32 EXE가 symbol import table을 통해 읽어들이도록 지정되어 로드 타임 때(런타임이 아닌) 실제로 읽어들이는 외부 dll은
해당 EXE/모듈이 있는 디렉토리, 커런트 디렉토리, 윈도우 및 윈도우 시스템 디렉토리, path 환경변수가 걸린 디렉토리 등등의 순서대로 탐색합니다. 물론 kernel32, gdi32, user32 같은 시스템 dll도 다 여기에 속하고요.

런타임이 아니라 로드(load) 타임이기 때문에
이런 dll 파일이 존재하지 않거나 한 심볼이라도 읽어들이지 못했다면
그 프로그램은 그냥 속수무책으로 전혀 실행되지 못합니다.
그런 상황에서의 처리를 프로그래머가 능동적으로 전혀 할 수 없다는 게 큰 약점입니다.

* * * * * * *

자, 이런 전통적인 로딩 방식은 잠재적인 문제를 품고 있습니다.
먼저, 한 회사에서 만들어서 여러 디렉토리에 상주하는 다수의 프로그램들이 자기네끼리 한데 공유하는 dll의 경로를 지정할 수가 없습니다. 기껏 잘 해 봐야 path 환경변수 지정이 고작인데, 이는 정량적인 방법은 아닙니다. 그 경로 지정 자체가 이미 '런타임'에만 가능한데, dll 로딩 경로는 '로드 타임'에 결정되어야만 하기 때문입니다.

이런 딜레마로 인해 조금이라도 한데 공유하는 dll은 반드시 탐색한다는 게 보장되는 윈도우 시스템 디렉토리에다 집어넣는 게 무조건 장땡이었고, 이 때문에 거기는 운영체제가 기본 제공하는 dll과, 응용 프로그램들이 집어넣은 dll로 인해 몇천 개의 수백 MB에 달하는 dll들로 난장판이 되어 버렸습니다.

둘째, dll을 식별하는 수단이 이름이 유일한지라, 이름이 같지만 다른 위치에 있거나 버전이 다른 엉뚱한 dll이 로딩되었을 때 대처할 방법이 전혀 없습니다. 이는 보안상으로도 매우 위험합니다. 이게 바로 말 그대로 DLL hell의 근본 원인입니다.

msvcrt.dll, mfc42.dll, comctl32.dll 이런 것들은 윈도우 98 이래로 이름은 같지만 그동안 버전별로 프로토콜, 인터페이스가 내부적으로 상당히 바뀐 게 많습니다. 내부적으로 문서화되지 않은 동작 방식이야 두말할 것도 없겠죠. 그런데 본이 아니게 그런 문서화되지 않은 동작 방식에 의존하던 프로그램이 다른 버전의 dll을 읽어들이면 그때부터 프로그램의 안정성은 뻑이 나기 시작한다는 것입니다.

* * * * * * *

side by side assembly 기술은 위의 두 문제를 모두 원천적으로 해결하는 과정에서 나온 해결책입니다.

첫째, 이제 MS에서는 지금까지 내놓았던 시스템 dll 이후로 제 3자 응용 프로그램의 고유 dll이 윈도우 시스템 디렉토리에다 들어가는 것을 비추(discourage) 행위로 규정했습니다.
호환성 때문에 저걸 완전 금지할 수는 없구요. <날개셋>의 경우 윈도우 IME가 반드시 시스템 디렉토리에만 있어야 하기 때문에 시스템 디렉토리를 건드립니다.

그런 특수한 경우가 아니면, 응용 프로그램이 사용하는 모든 dll은 가능하면 응용 프로그램 디렉토리에다가만 두어라! 시스템 디렉토리는 이제 운영체제만 자체적으로 쓰겠다. 이곳의 포화는 이제 그만!
메모리가 부족한 상황에서 자원을 하나라도 더 공유하려고 시스템 디렉토리를 두었지만 이제 그런 정책까지 과감히 포기한 것입니다.

이게 파격이 큰 이유는, 심지어 준시스템 dll이나 다름없는 개발툴의 런타임 dll들까지 이제 시스템 디렉토리에다 넣지 않기로 했기 때문입니다. 비주얼 C++ 기준으로 6.0이 끝입니다. 6.0으로 만든 EXE만이 mfc42.dll이나 msvcrt.dll 정도는 윈도우 98 이래로 어디에나 편재해(ubiquotous) 있다고 간주할 수 있습니다. 즉 'known dll'인 것입니다.

그 이후로, 닷넷으로 만든 EXE는 자신이 사용하는 msvcr71, msvcr80, mfc71 등등을 배포 패키지에다 자체 내장해야 합니다. 윈도우 XP, 비스타의 시스템 디렉토리에 기본으로 들어있지 않습니다. 응용 프로그램이 자기가 쓰는 런타임 dll은 무조건 복사본을 자기 디렉토리에다 심어야 합니다.

둘째. 첫째가 상당히 자비심 없는 정책이 되었는데 그럼 대책이 뭐냐 하면,
내가 정확하게 읽어들이고자 하는 DLL의 고유 식별자, CPU 아키텍쳐, 언어, 정확한 버전 번호를 exe 내부에다 리소스의 형태로 xml 문서로 명시해 놓는 것입니다. 한 컴퓨터의 디렉토리 구조와는 완전히 무관하게 말입니다. 메니페스트 xml이라고들 하죠.

그 메니페스트용으로 등록된 핵심 dll들은 윈도우 시스템 디렉토리에 있는 게 아니라 WinSxS 밑에 각 버전과 아키텍쳐별로 별개의 디렉토리에 저장됩니다.
윈도우 XP라면 gdiplus, comctl32 이런 dll이 존재할 텐데요. 이름이 같은데 윈도우 XP 원본이 갖고 있던 comctl32, SP2가 갖고 있던 comctl32 이런 버전별 '스냅샷'들이 전부 따로 저장되어 있는 걸 알 수 있습니다. 비스타에는 이보다 훨씬 더 많이 있습니다. 내가 만들어서 공유하기를 원하는 핵심 dll도 이런 식으로 등록, 배포할 수 있습니다.

* * * * * * *

윈도우 XP에서 이런 새로운 방식으로 곧바로 사용되기 시작한 대표적인 운영체제 컴포넌트가 바로 comctl32.dll 입니다. advapi, shell32 같은 거 말고 comctl32만 이런 형태가 됐습니다.
얘는 윈도우 9x 시절부터도 인터넷 익스플로러와 함께 곧잘 업데이트되었던 파일이고 특히 윈도우 9x의 안정성을 떨어뜨리는 주범이기도 했습니다.

이 파일이 특히 윈도우 XP에서는 비주얼 스타일 테마의 등장으로 인해 구조가 완전히 뒤바뀌었는데, 정작 새로운 파일은 WinSxS에 있고, system 디렉토리에 있는 파일은 버전이 여전히 5.82이고 옛날 IE 5.x 시절과 별 차이 없습니다. 한 마디로, system 디렉토리에 있는 파일은 옛날 프로그램과의 호환성을 위해 시간이 그 상태 그대로 정지해 버린 것입니다.

그 반면, 메니페스트에다가 새로운 comctl32를 사용하도록 지정을 해 놓은 exe만이 대화상자에서 윈도우 XP 이후의 비주얼 스타일 적용을 받을 수 있는 구조가 됐습니다. comctl32를 이 방법을 통해 최신 버전으로 지정하지 않으면, 옛날 프로그램에서는 알록달록한 테마만 나오지 않는 게 아니라 하이퍼링크 컨트롤 같은 XP에서 새로 추가된 컨트롤을 쓸 수도 없고, 비스타에서 그 유명한 TaskDialog 함수조차도 쓸 수 없습니다.

* * * * * * *

유행 따라서 윈도우 XP 비주얼 스타일을 쓰려고 으레 '리소스' 형태로 따로 작성해 온 메니페스트가 비주얼 스튜디오 2005에서는 개발툴 차원에서 통합적으로 지원되는 요소가 되었습니다. 2005는 이제 배포 대상 플랫폼으로서 윈도우 9x의 지원을 완전히 제껴 버리고 CRT와 MFC DLL 역시 side by side assembly 형식으로"만" 로딩하게끔 정책이 바뀌었습니다.

이게 언뜻 보기에 골때리는 이유가 뭐냐 하면, 이제 2005로 만든 exe는 msvcr80.dll이 시스템 디렉토리나 심지어 그 exe 디렉토리에 같이 있다고 하더라도 winsxs 설정이 안 되어 있으면, '응용 프로그램 구성이 잘못됐다'며 실행 안 되기 때문입니다. (msvcr80이 자체적으로 퇴짜를 때리는 듯.)
그냥 msvcr80, mfc80 같이 슬쩍 복사해 놓는 방식으로는 실행 못합니다. 이들을 winsxs 정식 등록을 해 주든가, 아니면 앗싸리 MS에서 배포하는 VS 2005 redistributable 프로그램을 같이 배포해야 합니다.

그런데 도대체가 VS 2005 redist.도 따로 있고, VS 2005 sp1 resit.도 따로 있습니다.
윈도우 비스타에 기본 내장되어 있는 msvcr80의 버전이 다르고, 오피스 2007이 사용하는 msvcr80의 버전이 다릅니다. 세부 버전 숫자가 하나라도 다르면 로딩 안 되는 게 일단 보안과 안정성 면에서는 나아진 점입니다만, 도대체 같은 기능을 하는 CRT DLL을 왜 자꾸 이렇게 바꿔 대는지, 도대체 앞으로는 또 어느 장단에 맞춰 춤을 추라는 소리인지 헷갈립니다.

MFC도 아니고 CRT가 뭐가 그렇게 자주 바뀌어야 하는지.. 그냥 아무 걱정 없이 윈도우 시스템 디렉토리의 msvcrt만 쓰던 시절이 살짝 그립기도 합니다. strcpy, malloc 이런 고전적인 함수가 도대체 뭐 변할 일이 있나요? (물론 보안 쪽으로 계속 더욱 강력해져 오긴 했죠. strtok_s, strcpy_s 이런 것도 마음에 듦.)

비주얼 스튜디오 2005로 처음으로 만들어 본 <날개셋> 4.8 64비트 바이너리들은 이런 잡음을 원천 봉쇄하기 위해, 메모리 낭비를 감수하고 일단 모든 바이너리에 CRT 라이브러리를 static 링크를 해 버렸습니다. 64비트 에디션을 앞으로 계속 이렇게 만들지는 미지수입니다.

다만, 이도 저도 못한 신세가 되어 버린 게 비주얼 스튜디오 2002/2003의 CRT DLL인 msvcr71입니다. side by side assembly 형식으로 완전히 넘어간 것도 아니면서, 운영체제의 기본 지원도 못 받아서 이 파일의 배포와 로딩은 재래식으로 응응 프로그램이 그냥 알아서 해야 합니다. 이제 VS 2005 쓰라고 64비트 지원도 중단됐고 그냥 과도기 DLL로 역사 속으로 사라지게 되었습니다.
VS 2003도 서비스 팩 1이 나온지라 버전이 살짝 다른 msvcr71.dll 두 버전이 존재하게 되었지만 겉보기 상으로 차이는 없는 듯합니다.

Posted by 사무엘

2010/01/10 22:17 2010/01/10 22:17
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/7

« Previous : 1 : ... 9 : 10 : 11 : 12 : 13 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2021/04   »
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

Site Stats

Total hits:
1578306
Today:
22
Yesterday:
390