EXE 만 어찌 돌리면 안되겠니? ,,, 제발

나름 개발 환경 설정에는 이제 일가견이 생겼다고 생각해도 도저히 이놈의 개발환경을 이해 하지 못하겠는게 바로 마이크로소프트의 비주얼스튜디오 2005 이상 버젼들이다.
비주얼 스튜디오 6.0 때부터 그 거지같은 매크로들을 시작해서 이건 데체 C++ 이 객체지향인건지 아니면 매크로지향인건지도 모르겠었고, 2003, 2005 나 나와서 써 봐도 이건 데체 종속성 이라는 게 마이크로소프트의 알수 없는 DLL들이 꼭 필요 해서 뭔가 Installer package 를 이용해서 설치가 가능하도록 해야 하는 제약들 때문에 정말 어떻게 써 봐도 좋아 할 수 없는 게 바로 비주얼스튜디오 라는 점이다.

비주얼스튜디오6 떄엔 MFC6 관련 DLL 들이 귀찮게 만들더니 (그렇다고 static build 하면 hello world 가 1MB 짜리가 된다,) 2005는 이제 manifest 인가 뭔가 부터 시작해서 아무리 링커를 조절해도 뭔가 결과물 EXE 가 아닌 다른 뭔가가 필요하다는 것이다.

위의 실행파일 구동에도 필요한 MSVCR80.DLL 이라는 것도 EXE explorer 나 depend searcher 등으로 보면 malloc , memset 등과 같은 기본 C library 에 필요한 심볼들이 있는 것인데 , 이건 KERNEL32.DLL 에 이미 있는게 아니냐는거다.
데체 KERNEL32.DLL 냅두고 왜 RELEASE 빌드한 저 실행 파일이 MSVCR80.DLL 을 봐야 하는지도 모르겠고 ..
또 저런 거지같은 구조를 만들어서 단일 실행파일 만으로 구동이 안되도록 한 이유는 또 뭐란 말이냐는거다.

비주얼스튜디오 에서의 개발이 디버깅이 용이하고, 특정 플러그인을 사용하면 코드 하이라이트 도 이쁘게 나오고 하는둥 개발에 편리함은 많은 편이지만, 일반적인 사용자의 입장으로 본다면 저런 실행 파일 하나 돌리려고 엄청난 덩치의 뭔가를 더 설치해야 한다는 조건이 있다면? 적어도 나라면 그런 프로그램은 쓰고 싶지 않을 것이라는 거다.

플랫폼에 이미 설치되어 있는 것들이 아닌 다른 뭔가가 추가적으로 설치 된다는 점은 물론이거니와,
어디 마이크로소트가 배포한 DLL 들이 안정적인 적이 얼마나 있었는가와,
코드 100K 짜리 돌리려고 몇메가나 되는 추가 DLL 들이 메모리에 올라가야 한다는 점들은 심플함을 추구하는 나로서는 도저히 용납이 안된다는 점이다.

차라리 minGW 로 조금 느리게 돌지도 모르지만 순수 win32 api 로만 돌도록 만들고 visual studio redistribute package 같은거 없이도 도는 (심지어 기본 시스템 DLL 외엔 load 도 안되도록) 그런 프로그램을 만들고 싶다는 점이다.

그래서 아직 typecasting 에 매우 엄격하고, c/c++ 개발자들이 어려울지도 모르는 delphi 를 아직도 쓰게 된다는 점.
별도의 DLL 을 만드는 것도 이젠 싫어서 괜시리 BCC32 로 obj 를 만들어서 delphi 에서 Link시 이를 함께 빌드하는 것이 괜히하는 것이 아니라는 점이다.

차라리 이런식으로 재배포가능한 패키지가 필요한 (사실 재배포가능 패키지를 설치해도 절대 안돈다는게 가장 정말 큰 문제라는 점 .. 데체 뭘 어찌 해야 한단 말인지) 구조 보다 ,실행파일 하나로 모든게 가능한 것이 더 우수하지 않을까 하는 게 나의 주관이다.

DLL 이 처음 나온 목적을 생각해 보자.
EXE 와 함께 static lib 으로 빌드 되지 않고 특정 함수들을 DLL 로 분리하여 , EXE 의 크기를 줄이고, 해당 함수 군의 성능이 바뀌거나 구조가 바뀔경우 EXE 는 놔 두고 DLL 만 다시 교체하여 이를 유지보수 한다는 목적은 참으로 명백하고 깔끔한 이론이었다.

리눅스에서도 so 모듈이 동일한 역활을 한다는 점을 볼때 어느 플랫폼이나 이런 구조는 유지보수에 큰 도움이 될것 같아 보인다.

하지만 결론을 보자.
윈도우 플랫폼에서 넘쳐나는 DLL 들.
이걸 어따 쓰는지도 모르겠는데 깔려 있는 것들만 봐도 몇백개의 파일은 기본이 되어 있을 것이다.
윈도우7 울티메이트 의 경우만 SYSTEM32 에 있는 DLL 들 갯수가 이미 1000 개가 넘는다. (정확히 2000개에 가깝다...)
데체 다 어디다 쓰는 것들인지 알수 없는 것들이 많이 있지만 필요하니까 존재하는 것일테니 얼마나 많은 기능들이 있는 건지 놀랍다기 보다는 그만큼 파일의 단편화부터 해당 DLL 교체등으로 인해 발생할수 있는 보안상 문제점등을 생각 해 본다면 과연 이 방법이 좋은 방향으로 가고 있는 것인가 라는 의문이 먼저 든다는 것이다.

글이 자꾸 처음 의도와는 달리 엉뚱한 방향으로 흐르긴 했지만, 결론은 이거다.
비주얼스튜디오로 뭔가 만든다는건 정말 만든것 자체만으로가 아니라 더 엄청난 것들을 항상 함께 배포해야 한다는 점이고.
이건 사용자를 위한게 아니라 그냥 개발자만 편하자고 만들어진 것이 아니냐는 것이다.
개발이 사용자를 위한게 아니라 개발자를 위한 것이라면 좀 엉뚱한 방향이 아닐까?

차라리 JAVA VM 처럼 그냥 Sun 에서 VM 다운로드 한방으로 끝난걸 쓰는게 속이 더 편하겠다는 생각이 드는 시점이다.
JAVA를 그리 좋아하는 것은 아니지만 MS 의 이런 알수없는 야롯한 정책들을 생각 해 보면 마치 그들이 만들어 놓고 인터넷을 을 온통 더럽히고 있는 OCX (ActiveX) 가 결국 MS 자체의 이런 깔끔하지 못한 정책이 투영된 것이 아닐까 라는 생각을 하게 만들게 한다.

뭘해도 MS 는 MS 일뿐.
Posted by 견족자K rageworx
  • Favicon of https://gunnih.tistory.com BlogIcon gunnih
    2009.11.30 23:40 신고

    머... exe에 static으로 link걸어서 만들면 되겠죠?? ㅋㅋ 따라서 win32 어플은 윈도7에서 돌릴려면 static으로 모두다~ 링크해서 배포해야 하는??? ㅡㅡ;;

    • Favicon of https://rageworx.pe.kr BlogIcon 견족자K rageworx
      2009.12.01 09:20 신고

      그게 안되니까 이런 글 을 쓴것이오...
      2005 부터는 static 으로 빌드 한다고 뭔가 다른걸 필요로 하지 않지 않아서 그게 문제임..

  • Favicon of https://va1kuntha.tistory.com BlogIcon deVbug
    2009.12.23 19:43 신고

    Win32API로만 작성하신 Win32 어플리케이션 프로젝트라면, 프로젝트 속성에서 side by side assembly를 disable 하는 것으로 해결할 수 있습니다.

    프로젝트 속성 -> 구성속성 -> C/C++ -> 코드 생성 -> 런타임 라이브러리 -> 다중 스레드 (디버그) 라고 되어 있는 걸로 선택해보세요.

    dll이 붙어 있는 걸로 선택해두시면 side by side assembly가 필요합니다. ;ㅁ;

    • Favicon of https://rageworx.pe.kr BlogIcon 견족자K rageworx
      2010.01.20 15:14 신고

      그 문제가 아니더군요 ^^
      VS2005 자체의 고질적인 문제로 많은 분들이 고생하는 듯 합니다.
      패키징을 안하면 구동 불가 ... OTL ....