윈도우 11에서 사라진작업표시줄 데스크밴드,WinUI·WPF로 되살려봤습니다

이호원 · airtaxi

Windows를 좋아해서 C#과 .NET을 시작했고,
지금은 WinUI·Uno Platform으로 Windows 앱을 만듭니다.

지금, 제 작업표시줄입니다

전부 실제로 돌아가는 .NET 앱입니다. 오늘은 이걸 만드는 법을 이야기합니다.

오늘 나오는 네 프로젝트, 전부 직접 만들었습니다

이 밖에도 AT-Installer · DeskBorder · LidGuard 등 오픈소스 Windows 앱을 15개 넘게 만들어 공개했습니다.

github.com/airtaxi

오늘 이야기

데스크밴드: 작업표시줄에 살던 도구들

• IDeskBand COM 확장 — 작업표시줄 안에 서드파티 UI를 넣는 공식 통로탐색기가 내 DLL을 로드해서 작업표시줄 안에 그려줬습니다
• 미디어 컨트롤 · 주소창 · 시스템 모니터 · 퀵런처가 여기 살았습니다

작업표시줄 전면 재작성, 그리고 사망선고

• Deskband API 제거 — 공식 대체재 없음도구 모음 메뉴 자체가 사라졌습니다
• Windows 10까지의 서드파티 작업표시줄 도구, 전부 전멸

어느 날 GitHub에서 본 것

• zadjii/Deskband11 — Windows 11 작업표시줄에 미디어 컨트롤을 얹은 해커톤 프로젝트
• 데스크밴드 API 없이, 작업표시줄 안에 UI가 실제로 떠 있었습니다

"작업표시줄 위에 투명한 창을 얹으면 되잖아?"

핵심 트릭: 전부 평범한 Win32였습니다

그대로 쓰기엔 아까웠습니다

• 스스로 밝힌 "해커톤급 코드" — 현재 Windows 11 빌드에선 위치·크기가 어긋남
• 시작 버튼 중앙 정렬도, 위젯 버튼도 고려되지 않음
• 한 앱에 박제된 구조 — 다른 앱에서 재사용 불가

팝업 창을 자식 창으로 — 창 수술

// 1. 창 스타일 교체: 최상위 팝업 → 자식 창
var style = GetWindowLongPtr(hwnd, GWL_STYLE);
style &= ~(WS_POPUP | WS_CAPTION | WS_THICKFRAME);
style |= WS_CHILD;
SetWindowLongPtr(hwnd, GWL_STYLE, style);

// 2. 작업표시줄의 자식으로 입양
SetParent(hwnd, taskbarHwnd);  // Shell_TrayWnd

// 3. 빈 공간에 배치하고 클리핑
SetWindowPos(hwnd, x, y, width, height, ...);
SetWindowRgn(hwnd, CreateRectRgn(0, 0, width, height), true);

그런데, 버튼 폭을 알 수 없습니다

해법: UI Automation으로 직접 잰다

정렬은 레지스트리가 알려줍니다

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced

TaskbarAl = 0   → 왼쪽 정렬
TaskbarAl = 1   → 중앙 정렬 (기본값)

// 값이 없다면? 시작 버튼의 X 좌표로 추론

정렬에 따라 빈 공간이 생기는 위치가 완전히 달라집니다 — 원본이 놓친 부분이었죠.

빈 공간 고르기 — Placement

시작 버튼·앱 버튼·위젯 버튼·알림 영역과는 절대 겹치지 않습니다

측정이 UI를 막지 않게

• 스캔이 실패하면? 이전 측정값 유지 — 위젯은 아무 일 없이 계속 동작UIA는 "최선 노력" 프로브 — 실패가 기능 정지로 이어지지 않는 설계

목표: 설치 한 줄, 코드 세 줄

$ dotnet add package Deskband11Lib.WinUI

var window = new MainWindow();
var host = new TaskbarContentHost(window, rootElement,
new TaskbarContentHostOptions
{
    PreferredWidth  = 360,
    PreferredHeight = 48
});

await host.AttachWhenLayoutReadyAsync();
window.Activate();

Core 하나, Facade 여럿

Facade가 얇을수록 새 프레임워크 지원이 쉬워집니다 — 엔진은 단 하나

Explorer는 언젠가 재시작됩니다

host.TaskbarWindowRecreated += async (_, _) =>
{
    await RecreateMainWindowAsync();  // 창을 새로 만들어 다시 Attach
};

보조 모니터가 분리됐다 재연결되어도 자동으로 원래 작업표시줄로 복귀합니다

여러 앱이 같은 자리를 원한다면?

• 중앙 서버도 IPC 채널도 없음 — 죽은 프로세스는 IsWindow 검사로 자동 퇴출

Fixed-then-Stretch 배분

• ManualSlotPriority가 낮을수록 앞자리 — 기본값 65535는 "도착 순서대로"

마지막 500ms의 디테일

작업표시줄의 일부처럼 보이려면, 움직임도 OS처럼 자연스러워야 합니다

P/Invoke를 손으로 쓰지 않습니다

SetParent
SetWindowPos
FindWindowEx
GetWindowLongPtrW
SetWindowRgn

PInvoke.SetParent(childHwnd, taskbarHwnd);
// 시그니처·마샬링·SafeHandle까지
// Microsoft.Windows.CsWin32가 전부 생성

• Win32 메타데이터에서 정확한 시그니처를 생성 — 손 P/Invoke의 마샬링 실수 원천 차단
• 생성된 코드는 분석 가능한 정적 코드 — NativeAOT·트리밍과 궁합이 좋습니다

UI Automation도 소스 생성 COM으로

[GeneratedComInterface]
[Guid("30cbe57d-d9d0-452a-ab13-7ac5ac4825ee")]
internal partial interface IUIAutomation
{
    IUIAutomationElement GetRootElement();
    IUIAutomationElement ElementFromHandle(nint hwnd);
    // COM vtable 호출 코드를 컴파일 타임에 생성
}

런타임에 코드를 만들어내는 고전 COM 마샬러는 AOT의 적 — 소스 생성이 답이었습니다

결과: NativeAOT로 컴파일되는 위젯

⚡ 즉시 시작

JIT 없이 네이티브 바이너리 — 부팅 직후 뜨는 위젯에 딱 맞는 특성

🪶 가벼운 상주

항상 떠 있는 앱이니 메모리 발자국이 곧 매너입니다

📦 IsAotCompatible

라이브러리 전체가 AOT 분석 경고 0 — 소비 앱이 안심하고 PublishAot

BarPlay — 검증용으로 만든 미디어 위젯

• SMTC 연동 — Spotify · 브라우저 · YouTube, 시스템 미디어면 전부
• 위젯 클릭 → 플라이아웃으로 탐색 슬라이더 · 설정까지
• NativeAOT + Microsoft Store 출시 — "라이브러리가 진짜 쓸만한가?"의 답

기존 앱에도 며칠 만에 붙습니다

두 앱 모두 통합 코드는 옵션 몇 개 + AttachWhenLayoutReadyAsync 한 줄이 전부였습니다.

데모의 신이 노하시면 준비된 영상으로 대체합니다 :)

솔직한 한계, 그리고 교훈

• 여긴 문서화되지 않은 영역입니다 — Windows 업데이트가 언제든 깨뜨릴 수 있습니다공식 API가 사라진 자리를 채우는 일엔 그만한 대가가 따릅니다
• 그래서 감시와 복구를 처음부터 설계에 내장했습니다폴링 감시 · TaskbarWindowRecreated · 모니터 재연결 자동 복귀 — "깨질 수 있음"을 전제한 설계
• UIA 기반 측정은 내부 구현 변화에 비교적 유연합니다AutomationId는 접근성 계약 — 픽셀 좌표 하드코딩보다 오래 살아남습니다

감사합니다 — 질문 받겠습니다. 이호원 · airtaxi