이 장부터 2부이며 다루는 주제와 프로젝트 형태가 달라진다. 1부에서는 C# 문법 학습을 위해 칙칙하고 썰렁한 콘솔에서 예제를 만들었는데 이제부터 화려한 멀티 태스킹과 잘 어울리는 그래픽 환경에서 실습을 진행한다. 윈도우용 응용 프로그램을 작성하는 방법은 여러 가지가 있다.
Win32 API를 직접 사용할 수도 있고 객체지향적인 MFC 라이브러를 쓸 수도 있다. 비주얼 베이직이나 델파이도 개발 속도가 빨라 많이 활용된다. 닷넷에서는 윈폼(WinForm) 라이브러리를 사용한다. WPF나 UWP 같은 모바일까지 지원하는 더 최신의 방법도 있지만 윈도우폰의 실패로 인해 아직 일반화되지는 않았다.
현재 시점에서 윈폼은 좀 구식이지만 여전히 현역이다. C#과 방대한 BCL 라이브러리, 생산성 높은 비주얼 스튜디오가 결합된 효율적인 개발 방법이다. 완전히 새로 만들었지만 하부는 Win32이며 구조를 거의 그대로 차용한다. 몇 가지 예를 들어 보자.
l 메시지 구동 방식으로 동작한다. 메시지의 종류나 발생 시점, 인수 등이 유사해 Win32의 메시지 구동 시스템을 이해하고 있다면 따로 공부하지 않아도 될 정도다. 다만 닷넷은 델리게이트로 메시지 핸들러를 만든다는 정도만 다르다.
l 윈폼의 컨트롤은 대부분 Win32의 것을 그대로 물려 받아 모양, 스타일, 동작이 거의 유사하다. 새로 추가되었거나 약간 변형된 예도 있지만 단순한 확장일 뿐이다.
l 함수도 거의 비슷해 인수, 플래그 등을 그대로 쓴다. 다만 오버로딩을 적극 활용하여 함수의 이름이 조금씩 다르고 클래스의 멤버로 소속된다는 형식적인 차이만 있다.
윈폼은 추상화를 거의 하지 않아 Win32 API를 객체지향적으로 래핑한 정도에 불과하다. 완전히 새로운 구조를 만드는 것보다 검증된 API를 활용하는 것이 쉽고 기존 개발자의 경험을 재사용할 수 있기 때문이다.
윈도우와의 관계가 너무 긴밀해 과연 플랫폼 독립성을 달성할 수 있을지 의구심이 들 정도다. 이론적으로는 어디로나 이식 가능하지만 타 플랫폼에 윈도우를 통째로 올려 놓고 그 위에서 닷넷 런타임을 돌리는 식이라 성능을 담보하기는 어렵다.
윈폼은 Win32보다 10년 정도 더 최신이다. GDI+를 적극 활용하고 객체지향적이며 컨트롤의 혁신도 많다. 그러나 라이브러리 수준에서 운영체제를 능가하는 것은 어려워 Win32보다 열등한 점도 있다.
l 그리기 모드가 없어 XOR모드로 그릴 수 없다.
l 공통 대화상자를 사용자 정의할 수 없다.
l 클립보드 뷰어 체인을 만들 수 없다.
l 캐럿 관리 기능을 제공하지 않는다.
대체할 방법을 찾을 수 있지만 번거롭다. 닷넷의 주 지향점은 웹이어서 GUI 응용 프로그램 지원이 완벽하지 않다. Win32를 그대로 계승하다보니 API나 MFC에 익숙한 개발자에게 윈폼은 거저 먹기나 다름없다. 반대로 생각해 보면 기존 개발 경험이 전무한 사람은 Win32를 배우는 만큼의 시간과 노력이 필요함을 의미한다.
이 책은 Win32를 모른다고 가정하되 다 설명하자면 지면을 감당할 수 없어 요약적으로 정리한다. 국내에서 출판된 한 API 서적은 무려 2000페이지가 넘는다. 기초가 없다면 그래픽 개발 툴로 준비 운동을 좀 하고 오는 것이 좋다. 델파이 경험이 있으면 좀 쉬운데 델파이 창시자가 C#을 만들었기 때문이다. 이래 저래 기초가 없으면 힘든 건 어느 분야나 마찬가지이다.