Direct Win32 API, 이상한 모양의 윈도우, 그리고 그것들이 대부분 사라진 이유

2 days ago 3
  • 현대 Windows 앱은 웹 기반 프레임워크 의존으로 인해 느리고 무거워졌으며, 과거 Win32 시절의 운영체제 수준 제어권이 사라짐
  • Win32 API는 메시지 루프와 HRGN 객체를 통해 창의 형태를 자유롭게 정의할 수 있었고, 비표준 창 디자인이 흔했음
  • 비트맵과 레이어드 윈도우 기술을 이용하면 투명도와 애니메이션을 가진 자유로운 형태의 창을 구현할 수 있었음
  • 그러나 커스텀 창은 기본 기능을 모두 수동 구현해야 하는 복잡성과 사용자들의 단순성 선호 변화로 인해 점차 사라짐
  • 그럼에도 Win32는 여전히 창 제어와 실험의 자유를 제공하며, 창의적 데스크톱 소프트웨어 제작 가능성을 유지함

현대 Windows 앱의 단조로움과 Win32의 잃어버린 자유

  • 최근 Windows 데스크톱 앱은 대부분 React, Electron, Tauri 같은 브라우저 래퍼 위에서 동작하며, 느리고 메모리를 과도하게 사용하는 복잡한 웹 기반 구조로 변함
    • 단순한 메모장조차 50MB의 메모리를 차지하지만, 순수 Win32 C로 작성된 동일 기능 앱은 1.8MB에 불과함
    • 최신 하드웨어에서도 Windows 11 부팅 시 메모리 사용률이 77%에 달함
  • 과거 Win32 API로 직접 프로그래밍하던 시절에는 운영체제 수준의 완전한 제어권을 가질 수 있었음
    • 당시에는 사각형 창에 갇히지 않고, 비표준 형태의 창을 자유롭게 만들 수 있었음
    • Windows XP 시대에는 Windows Media Player를 비롯해 다양한 앱이 독특한 외형을 가졌음

과거의 ‘이상한 모양’ 윈도우들

  • 한때 Windows 앱은 정체성과 개성을 표현하기 위해 다양한 형태로 제작되었음
    • 미디어 플레이어는 하드웨어처럼 보였고, 데스크톱 마스코트가 화면을 돌아다녔으며, 유틸리티 패널은 계기판, 장난감, 외계 콘솔처럼 디자인됨
    • 창의 형태는 사각형일 필요가 없었고, UI의 목적은 사용성보다 개성에 가까웠음
  • 오늘날 이런 형태가 사라진 이유는 프로그래머가 더 이상 창 자체를 제어하지 않기 때문
    • 대부분의 현대 UI 프레임워크는 운영체제를 감추고, 개발자는 제한된 사각형 영역 안에서만 작업함

Win32 메시지 기반 구조와 창 제어

  • Win32 프로그래밍의 핵심은 이벤트 메시지 루프에 있음
    • GetMessage, TranslateMessage, DispatchMessage로 구성된 루프가 모든 동작의 기반
    • “WM_CREATE”, “WM_PAINT”, “WM_SIZE”, “WM_DESTROY” 등 메시지를 처리하며 창의 동작을 정의함
  • HRGN(Region Object) 을 사용하면 창의 모양을 자유롭게 변경 가능
    • SetWindowRgn으로 창에 영역을 지정하면, 그 영역만 실제 창으로 인식됨
    • 예시 코드에서는 CreateEllipticRgn으로 타원형 창을 만들고, 제목 표시줄이 없는 상태에서 직접 드래그 기능을 구현
    • “WM_LBUTTONDOWN” 시 “WM_NCLBUTTONDOWN”을 “HTCAPTION”으로 보내 창 이동을 흉내냄
  • 이처럼 모양을 만드는 것은 쉽지만, 기본 프레임이 제공하던 기능을 직접 구현해야 하는 점이 핵심 과제임

비트맵 기반 창과 레이어드 윈도우

  • “drivenbyimage/main.c” 예제는 비트맵 데이터로 창의 형태를 정의
    • “shape.bmp”를 로드해 투명색(마젠타) 을 제외한 픽셀을 창 영역으로 설정
    • 비트맵은 동시에 화면에 그려질 이미지이자 창의 실제 형태로 작동
    • 과거 스킨형 앱들이 이런 방식으로 강아지, 우주선, 라디오, 캐릭터 얼굴 등 다양한 형태를 구현함
  • 하지만 비트맵 기반 영역은 경계가 단단하고 반투명 표현이 불가능
    • 부드러운 가장자리나 애니메이션을 위해서는 레이어드 윈도우(WS_EX_LAYERED) 가 필요함
  • “Animated/” 예제에서는 투명 알파 채널을 가진 32비트 이미지를 UpdateLayeredWindow로 업로드
    • GDI+ 로 메모리 비트맵에 스프라이트 시트를 그려 프레임을 전환하고, 이를 데스크톱에 표시
    • 창의 형태가 고정된 것이 아니라, 현재 픽셀 상태 자체가 창의 모양이 됨
    • 이 방식은 부드러운 투명도, 프레임별 형태 변화, 자연스러운 애니메이션을 지원

커스텀 창의 어려움과 문화적 변화

  • Win32 API로 커스텀 창을 만들면 모든 세부 동작을 직접 처리해야 함
    • 드래그, 리사이즈, 닫기, 키보드 입력, DPI 대응 등 기본 창이 자동으로 처리하던 기능을 수동 구현해야 함
    • 프로토타입은 쉽지만, 완성도 높은 제품으로 다듬는 데는 큰 비용과 노력이 필요함
  • 사용자들은 이런 시각적 실험보다 안정성과 단순함을 선호하게 되었음
    • 비표준 창은 종종 광고 프로그램, 툴바, 불필요한 유틸리티와 연관되어 부정적 인식이 생김
    • 결과적으로 “이상한 모양의 창”은 진지한 소프트웨어보다는 장난스러운 요소로 여겨지게 됨

Win32의 여전한 가능성과 의미

  • 그럼에도 Win32는 여전히 직접 제어와 실험의 자유를 제공함
    • 메시지, 핸들, 그리기 API만으로도 운영체제 수준의 창 제어가 가능
    • 대부분의 경우 사각형 창이 합리적이지만, 그 형태가 선택일 뿐 강제는 아님을 상기시킴
  • 예제 코드는 GitHub 저장소 WierdApps에 공개되어 있음
    • 타원형 창, 비트맵 기반 창, 애니메이션 마스코트 등 세 가지 샘플 포함
    • Win32가 여전히 창의적이고 실험적인 데스크톱 소프트웨어 제작을 가능하게 함
Read Entire Article