'하위호환성'에 해당되는 글 2건

  1. 2007.10.04 .NET으로 포팅된 Quake2 소스.. (10)
  2. 2007.05.06 Window Vista에서 레거시 프로그램 적응시키기.. (2)
무척 오래된 내용인데, 블로그에 백업 차원에서.. 음, 이런 글을 스프링노트(위키)에 올려둬야 하는건가?

퀘이크 2는 소스코드가 공개된 Id Software의 유명한 FPS 게임이다.. 소스코드가 공개된 덕에 여러가지 실험(?)에 자주 사용되곤 하는데, 자바 그래픽 엔진을 테스트 하기 위해 사용되기도 하고, Visual C++ .NET의 기능 홍보(?)에 사용되기도 한다.. 이 샘플소스코드는 Microsoft MVP로 활동하던 시절, MSDN 세미나에서 사용했던 샘플이기도 한데, 2004년도에 VS 2003에 포함된 VC++을 홍보하기 위해 많이 사용되었던 샘플이기도 하다.. VC++을 가지고 아주 흥미로운 시도를 한 좋은 샘플이다..
(현재는 그 다음 버젼인 퀘이크3까지 소스코드가 공개되어 있다..)
.NET으로 포팅된 Quake 2 살펴보기
이 샘플이 흥미로운 이유는 공개된 퀘이크2 소스 (C 코드로 되어있다)를 수정하지 않고 .NET 환경에서 바로 사용할 수 있으며, 여기에 몇가지 기능을 더 추가하여 새로 추가되는 기능은 .NET 코드로 작성을 해, 두 코드가 잘 섞여 돌아가는 모습을 보여줬기 때문이다.. 유명한 게임에 내가 원하는 기능을 추가하는 흥미로운 방법으로 보여줘서 샘플로서 효과가 아주 크다고 할 수 있다..

원 게임에는 없는 기능인 레이더 기능(위에 소개된 URL들 중에서 코드프로젝트 사이트에 가보면 화면 캡쳐 이미지가 있다..)이 추가되어 있는데, 이 기능이 .NET 코드로 작성된 코드다.. 즉, C 언어로 작성된 원 게임소스는 컴파일러 및 개발툴에 의해 자동으로 .NET 어셈블리로 빌드되어 추가된 기능과 함께 .NET 환경에서 실행이 되는 것이다..

간단한 빌드 설정만 바꾸면 쉽게 .NET 어셈블리로 빌드가 되는 놀라운(?) VC++의 기능이라 할 수 있겠다.. 예전에 작성된 많은 C 코드들을 쉽게 재활용할 수 있는 기회가 열리기 때문이다.. 하지만, C++ 코드들은 이렇게 되지 못하는 경우가 많아 반쪽짜리 기능 이기도 하다.. .NET을 고려하는 C/C++ 개발자들 중에는 C++ 개발자들이 더 많고, 그들이 C 코드와 C++ 코드 중 어떤 것을 더 많이 가지고 있을지는 뻔하기 때문이다..

이러다 보니 .NET 환경에서의 VC++은 정말 무슨 존재인가 하는 생각이 들기도 한다.. 허브셔터나 스탠리 리프먼 등 많은 C++의 대가들이 대거 Microsoft에 입사하여 C++을 .NET 환경에서 사용하기 편리하게 만드는 작업에 몰두하고 있다.. 이들이 블로그에 올리는 내용이나, 활동하는 뉴스그룹, 메일링 리스트에 관련 내용들이 자주 언급되며 비중도 많이 차지하고 있다.. 하지만, [C++/CLI] Mixed-Type 사용시의 메모리 해제 문제와 같은 글들을 읽어보며 드는 생각은 뭐하러 이렇게 복잡하게 만들어야 하는가 하는 생각 뿐이다..

.NET 환경에서 VC++은 찬밥이 아닌 이유..
  1. Native 코드를 작성할 수 있는 유일한 개발도구이다.. VB .NET 너무 많이 바뀌었다.. C#, 새로운 언어이니 .NET 전용이다..
  2. COM 프로그램을 쉽게 개발할 수 있도록 되었다
  3. 표준 C++ 지원 및 이제는 STL도 지원한다..
  4. 웹서비스 개발에도 최적의 성능을 제공해준다..
  5. Native 코드와 .NET 코드를 섞을 수도 있다..
위와 같은 이유들을 만들어(?) 내긴 하지만, 사실 1번과 5번 이외에는 차라리 C++을 쓰고 말지 하는 생각이 든다.. 굳이 .NET 어셈블리로 만들어 얻는 이득이 없기 때문이다..

이야기가 상당히 다른 방향으로 흘러갔는데, 아무튼 C 코드는 VC++ .NET 덕분에 .NET 환경에서 거의 소스코드의 수정없이 100% 사용이 가능하다는 것을 잘 보여주는 샘플이다..
Posted by 미친병아리
새로운 OS가 나오게 되면 가장 관심을 가지는 것은 과연 내가 만든 프로그램이 새 OS에서 정상적으로 동작할 것인가 하는 점이다.. 윈95가 등장할때 그랬으며, 윈98, 윈ME, 윈2000, 윈XP 등등.. 이번 윈도우 비스타도 예외는 아니었지만, 그러면서도 안심이 되는 부분은 MS가 새 OS를 내 놓을때 가장 신경을 많이 쓰는 부분이 다름아닌 하위호환성 보장이라는 것.. 새 OS들이 나올때마다 걱정은 했지만, 별 일 없이 넘어갈 수 있었던 것이 바로 이 부분 때문이었으며, 이번에도 큰 어려움 없을 것이라는 안일한 자세.. 사실 윈3.1에서 윈95로 넘어갈때 말고는 큰 일이 없었던것이 사실이다.. (Microsoft가 그렇게 중요시 하는 하위호환성에 대해 자세히 느껴보고 싶으면 조엘 온 소프트웨어를 읽어보시길..)

하지만, 윈도우 비스타는 달랐다.. 많이 달랐다.. 윈XP에서 잘 돌아가는 프로그램을 윈도우 비스타에서 돌아가게 만드는데 무려 2달 정도가 걸렸다.. 물론, 다른 일들이 많아 팀원 전체가 붙어 대응을 하지 못해 오래 걸리긴 했지만, 애초에 예상했던 것 보다는 훨씬 오래걸린 대응 준비기간이었다..

우리 프로그램의 문제점
- ActiveX 컨트롤
- 레지스트리
- 파일저장
- 프로세스 생성
- 윈도우 메시지 전달
ActiveX 컨트롤은 사실 아무런 문제없이 윈도우 비스타로 옮길 수 있다.. 윈도우 비스타라고 해서 ActiveX 컨트롤이 없으질게 아니고 (Silverlight도 윈도우 환경에서는 ActiveX로 구현되며, 플래쉬, 애크로뱃리더도 ActiveX로 구현되어 있기 때문에 대체기술이 나오기 전에는 없어질 리가 없기 때문에.. 대체기술은 웹표준이 그래픽과 멀티미디어쪽으로 확정되기 전에는 오랜기간 없을 것으로 보인다..) 기본적으로 우리 프로그램도 아무런 문제가 없었지만, 레지스트리와 파일억세스를 하는 부분이 많았다..

레지스트리 접근은 HKEY_CURRENT_USER 하위는 읽고 쓸 수 있기 때문에 위치만 옮기면 아무런 문제가 되지 않는다.. 물론, 현실에서는 이 위치를 공유하는 프로그램들이 많을 수 있고, 어떤 프로그램에서는 위치를 변경하는게 만만한 작업이 아닐 수 있기 때문에 현실은 그리 녹녹치 않을 수도 있다.. 가장 좋은 방법은 레지스트리 사용은 아예 하지 않도록 수정하는 방법이 정답이다.. 하지만, 우리 프로그램은 새 버젼이 개발중이었으므로 최소한의 노력을 들이기로 했다..

파일저장 부분도 사실 큰 어려운 부분은 아니지만, 레지스트리의 경우와 비슷하다.. 권한이 없는 폴더에는 접근하지 않도록 수정해줘야 한다.. 특히, 권한을 가진 프로그램이 만들어둔 파일을 다른 프로세스에서 접근해야 하는 경우 문제가 생길 수 있다.. 가장 문제가 되는 것이 ActiveX 컨트롤이 접근해야 하는 경우인데, 이 경우는 ActiveX 컨트롤이 해당 파일에 접근할 수 있는 방법이 없으므로 권한이 낮은 프로세스에서도 접근 가능한 위치로 옮겨야 한다..

프로세스 생성은 비교적 간단하다.. ShellExecute에 추가된 파라미터를 넣어 높은 권한으로 실행시킬 수 있는 방법이 있기 때문이다.. 하지만, 원래 권한이 낮은 곳에서 (다른 프로세스나 ActiveX 컨트롤이) 높은권한의 프로세스를 실행시키는 일이라 권한상승 경고창이 뜬다..

윈도우즈 메시지 전달은 사실 별로 신경을 쓰지 못했던 부분인데, 낮은 프로세스에서 높은 프로세스로 메시지를 보내는 것은 사정없이 무시된다.. 특히, ActiveX 컨트롤이 실행파일을 실행시킨 후에 메시지를 통해 데이터를 전달하는 구조의 경우 문제가 된다..

하지만, 위의 문제들을 해결하기 위해 그동안 여러가지 검토를 하고 테스트 코드를 짜며 든 생각은 과연 무엇이 더 좋아졌는가 이다.. 좋아진 부분이 딱 하나 있기는 하다.. 권한이 상승된 프로세스가 허락없이 실행될때 경고창이 뜬다는 것이다.. 이점은 나 몰래 어떤 프로그램을 실행시키기가 더 어려워 졌다는 점에서 보안이 강화되었다고 할 수 있는데, 이외의 것들은 소위 하위호환성 때문에 조금만 코드를 고치면 XP에서 동작했던 것 처럼 동작하도록 수정할 수 있다.. 어찌 보면 내가 예상한대로였는데, 작년말쯤 팀원들과 이야기 하던 내용이 기억난다.. "그렇다면 좋아질게 하나도 없는데, 그렇게 고칠거면 뭐하러 고치나?"

열심히 함 고쳐보라는건가? 뭐하러 이런 소모적인 해야 수정을 하는지 모르겠다.. 되먹지 않은 악성 프로그램을 배포하는 사람들이 코드 좀 수정해서 비스타에서도 동작하도록 만들게 하기 위해, 전 세계 수많은 프로그래머들이 비스타에서 돌아가는 프로그램을 위해 코드를 수정하게 만들어야 했는가? 하위호환성 때문에 피해가는 방법이 다 존재한다면, XP에서 문제없이 돌아가는 프로그램은 비스타에서도 그냥 돌아가도록 하는게 더 좋았을 것이다.. 그렇다 하더라도 권한상승창 때문에 원래의 목적은 달성할 수 있었을 것이다.. 참, 아쉬운 부분이다..

권한 상승창이 뜨는 부분은 비스타 사용자들로부터 많은 이야기가 나올 것인데, 윈도우 비스타에서 깔끔하게 돌아가는 프로그램을 만들기 위해서 (권한상승 허가하는 창이 뜨지 않고 동작하도록)는 앞으로는 개발초기 설계시부터 잘 고려를 해야하겠다..


Posted by 미친병아리