▲

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

 (warped3.substack.com)
6P by GN⁺ 18시간전 | ★ favorite | 댓글 1개
  • 현대 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가 여전히 창의적이고 실험적인 데스크톱 소프트웨어 제작을 가능하게 함

함께 보면 좋은 글 β

▲
GN⁺ 18시간전  [-]
Hacker News 의견들

  • 이상한 모양의 윈도우는 다시 돌아오지 않았으면 함
    단지 만들 수 있다고 해서 만들어야 하는 건 아님
    요즘 React, Electron, Tauri 같은 브라우저 래퍼로 만든 앱들이 전부 비슷하게 보이는 건, OS의 GUI 프레임워크를 쓰지 않기 때문임
    앱이 제각각의 비표준 위젯이나 색상, 형태를 쓰면 접근성과 사용성이 망가짐
    아이러니하게도 요즘 ‘정체성’을 강조하는 앱들은 대부분 하드웨어 제조사들이 끼워 넣은 드라이버용 제어판 같은 것들이고, 그게 가장 형편없는 블로트웨어임

    • Electron은 오히려 반대 문제를 만듦. 모든 앱이 제각각 다르게 보여서 플랫폼 가이드라인을 따르지 않음
    • 접근성은 법적 요구사항도 있는 중요한 부분임. 최신 크로스플랫폼 GUI 프레임워크들은 시각장애인을 위한 스크린리더나 HiDPI 지원을 잘 처리함
    • 그래도 나는 그런 특이한 창 형태가 멋있다고 생각함. 누군가 다시 시도한다면 환영임
    • Vista 시절 WPF와 XAML로 만든 비표준 UI들을 많이 봤는데, 창 크기 조정이나 모니터 이동 시 스케일링이 엉망이 되어 결국 불편함만 남았음
    • 내 생각은 정반대임. 예전처럼 컴퓨터를 재미있고 멋지게 만들고 싶음. 지금은 전부 서류철 같음. 인생의 재미있는 부분은 원래 선택적인 것임

  • 나는 Win32를 좋아하지만, 예전의 이상한 스킨 문화가 지금의 “브랜딩 = 정체성” 사고방식의 전조였다고 봄
    그게 결국 Electron과 반쯤 완성된 위젯 라이브러리의 난립으로 이어졌음
    Blender나 Ardour 같은 특수 앱이 아니라면, 개성 있는 GUI는 우선순위가 아님

    • Electron 앱은 전부 똑같이 생겼음. 반면 Winamp 같은 Win32 스킨은 최소한 개성이 있었음
      지금의 OS들은 개인용이 아니라 기업용임. Win3.1~XP 시절이 진짜 개인용 컴퓨팅의 시대였음
    • 일반 업무용 앱이라면 네이티브 컨트롤을 쓰는 게 맞지만, iPad나 스마트기기처럼 전체 화면을 커스텀 UI로 쓰는 경우엔 멋지고 잘 작동함

  • 요즘의 React 기반 앱들은 OS와도, 서로 간에도 일관성이 없음
    6개월마다 UI가 바뀌는데 UX는 개선되지 않음. 접근성(a11y)은 완전히 잊혀진 상태임

  • 예전엔 소프트웨어를 소수 인원이 만들고 오랫동안 안정적으로 유지했음
    지금은 빠른 반복과 대규모 팀 중심으로 바뀌었고, 플랫 디자인이 이런 환경에 맞는 결과물임
    Skeuomorphic 디자인은 자산을 계속 새로 만들어야 해서 비용이 큼
    결국 속도와 규모가 우선인 시대가 되었음. 마치 손으로 조각한 가구 대신 평면 조립 가구가 대세가 된 것처럼

    • 사실 Win32 API에서도 모든 걸 직접 구현할 필요는 없음. 기본 메시지 처리를 위임(delegate) 하면 됨
    • Skeuomorphic 디자인은 현실 모방이 과해서 시각적으로 복잡하고 지저분했음. 방향은 좋았지만 구현이 힘듦
    • 결국 비용 절감이 이유임. 더 나은 사용성을 포기하고, 자동차의 버튼을 대형 터치스크린으로 바꾼 것과 같음

  • HiDPI 시대가 되면서 예전처럼 픽셀 단위로 UI를 그리기 어려워졌음
    예전 Win95~XP 시절엔 프론트 버퍼에 직접 그려서 빠르고 메모리도 적게 썼지만, 지금은 각 창마다 백업 버퍼를 유지하느라 RAM을 더 씀

  • “The point was usually not usability. It was identity.”라는 문장을 보고 LLM이 쓴 글 같다는 생각이 들었음

    • 나도 같은 느낌을 받았음. 그래도 글쓴이가 뭔가 말하고 싶었던 건 느껴졌음
    • 모든 문장이 LLM이 생성한 것처럼 보였음

  • 예전에 Windows 앱을 개발했는데, Win32 인터페이스는 90% 정도만 제어 가능했음
    색상 테마를 바꾸려다 MessageBox를 직접 재구현해야 했던 기억이 있음

    • 예전엔 Win32 Hook으로 MessageBox를 수정할 수 있었음. HCBT_CREATEWND로 HWND를 얻어 서브클래싱하면 됨
    • 더 깊이 들어가면 User32.dll 대신 Win32U.dll을 후킹해야 하는 경우도 있음
    • 그걸 직접 다시 만드는 건 고통스러움. Qt로 하면 좀 나을까 궁금함

  • 순수 Win32 C로 만든 Notepad는 1.8MB밖에 안 쓰는데, 요즘 메모장은 50MB나 씀

    • 최소한의 “Hello World” 프로그램도 500KB는 필요함. 시스템 라이브러리들이 기본으로 메모리를 차지함
    • 최신 Windows 11 Notepad는 탭, 스타일 텍스트, AI 기능까지 포함돼서 기본 32MB를 씀
      심지어 GNU Emacs가 더 적은 메모리를 씀
      반면 텍스트 모드의 EDIT.EXE는 520KB밖에 안 써서 훨씬 효율적임

  • 예전에 Mac용 Disco라는 CD 굽기 앱이 있었는데, 디스크를 굽는 동안 창 위로 연기가 피어오르는 애니메이션이 나왔음
    Steve Jobs가 무대에서 직접 보여주며 좋아했음

  • 기사에서 데스크톱 마스코트 이야기도 나와서 반가웠음
    최근에 Godot으로 만든 데스크톱 펫 영상을 봤는데, 크로스플랫폼으로 작동함
    약간 손이 많이 가긴 하지만, Win32 수준의 복잡함은 아님. 데스크톱 펫 애호가에게는 좋은 선택임

답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.