WinRT הוא COM — IInspectable, .winmd, language projections, ולמה WinUI עדיין יושב על חוזה בינארי

רוצים להוסיף יכולת Windows חדשה לאפליקציית WPF או WinForms. אבל קריאה ל-WinRT picker זורקת exception. אחר כך קוראים על WinUI, ונראה כאילו צריך לבנות מחדש את ה-UI. הבלבול הזה מתבהר ברגע ש-מפרידים איך WinRT עובד מבחירת UI framework.

נקודת ההתחלה של המאמר הזה היא ש-גם WinRT יושב על החוזה הבינארי של COM. Microsoft עצמה קובעת במפורש ש-“The Windows Runtime is based on COM”.¹ טבלת Excel שמוטמעת ב-Word שראינו ב-מאמר הקודם על OLE objects, ו-WinRT ו-WinUI של היום, יש להם אותו IUnknown בשורש.

כאן קודם נועצים את שלושת האלמנטים שמרכיבים את WinRT, אחר כך מסתכלים על מה לשים לב כשמשתמשים בו מאפליקציית desktop, ולבסוף שוקלים איך לטפל בנכסים קיימים. קהל היעד הוא מפתחים עם ניסיון ב-COM או בפיתוח desktop ל-Windows, סביבת הבסיס היא Windows 10/11 ו-.NET 6 ואילך (C#) או C++17 (C++/WinRT), ו-רמת הקושי היא בינונית.

1. קודם המסקנות

יש שלוש מסקנות להחזיק.

• WinRT אינו managed runtime; זה ABI (חוזה בינארי) שנבנה על COM. לחוזה הזה נוספו .winmd, שנושא מידע טיפוסים, ו-language projections, שמאפשרים לכל שפה לקרוא לו באופן טבעי.¹²³⁴
• רוב WinRT APIs ניתנים לשימוש מאפליקציות WPF, WinForms ו-Win32 קיימות. אבל שלושה תנאים מוקדמים צריך לבדוק: העברת HWND, package identity, ואתחול thread.⁵⁶⁷⁸
• מעבר UI מלא ל-WinUI ושימוש בררני ב-WinRT APIs הם החלטות נפרדות. גם WinUI יושב על ה-ABI של WinRT, ונכסי COM/ActiveX קיימים ו-WinRT יכולים להתקיים יחד על אותו יסוד.⁹²¹

מכאן ואילך, קריאה בסדר הבא מקלה ביותר לעקוב אחרי הקשרים.

מפת הידע למטה היא לסקירת איך האלמנטים קשורים. אם מעדיפים לקרוא את ההסבר קודם, ממשיכים מפרק 2 בסדר.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 20, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. גם ל-OLE וגם ל-WinRT יש אותו חוזה בינארי בשורש

בבלוג הזה עד כה עקבנו אחרי עולם ה-COM הקלאסי: פילוסופיית התכנון של COM, מודל ה-threading של STA/MTA, טיפול ב-ActiveX/OCX, ו-OLE compound documents. כל אלה הן טכנולוגיות משנות ה-90.

WinRT, לעומת זאת, הוא יסוד ה-API שהוצג עם Windows 8 (2012). היום הוא מספק toast notifications, Share, Bluetooth, OCR ועוד כ-APIs במרחבי השמות Windows.*, והוא גם מה ש-WinUI ו-Windows App SDK עומדים עליו.¹⁰ ישן וחדש נראים כמו עולמות נפרדים לגמרי, אבל במהות הם רציפים.

מה שהם חולקים הוא ההבטחה לקרוא דרך ממשקים

רכיבי COM ומחלקות WinRT שניהם חושפים את הפונקציונליות שלהם דרך ממשקים. בהשוואת ממשסי הבסיס, הקשר נראה כך.¹

כלומר, WinRT לא החליף את COM במנגנון לא קשור; זו שכבה נוספת שמונחת מעל IUnknown. Reference counting, QueryInterface ו-HRESULT כולם ממשיכים לחיות כמו שהיו.

התיעוד של C++/WinRT גם קורא ל-WinRT APIs “evolution of COM” ומסביר שהם מתוכננים לצריכה דרך language projections כ-APIs מבוססי COM.²¹¹

flowchart TB
    accTitle: ייחוס COM הקלאסי ו-WinRT
    accDescr: על היסוד המשותף של החוזה הבינארי של COM העשוי מ-IUnknown ומ-vtables עומדים, זה לצד זה, עולם ה-COM הקלאסי של OLE ו-ActiveX משנות ה-90 ועולם WinRT מ-2012 ואילך עם WinUI ו-Windows App SDK מעליו; השניים אינם הדדיים-בלעדיים אלא רציפים
    base["חוזה בינארי של COM (IUnknown, vtable)"]
    base --> classic["COM קלאסי (OLE, ActiveX, COM מותאם)"]
    base --> winrt["WinRT (IInspectable, .winmd)"]
    winrt --> winui["WinUI / Windows App SDK"]
    classic -.-> coexist["יכולים להתקיים יחד על אותו יסוד"]
    winrt -.-> coexist

איור 1: COM קלאסי ו-WinRT אינם עולמות נפרדים אלא שני דורות, ישן וחדש, על אותו חוזה בינארי.

לכן המאמר הזה אינו רק “מבוא ל-API חדש”. זה מאמר שמאשר איפה ידע ה-COM שכבר יש לכם חל בפיתוח Windows ב-2026.

3. IInspectable מעל IUnknown

היסוד שלא השתנה ושלוש השיטות שנוספו

המפרט הרשמי של מערכת הטיפוסים של WinRT קובע ש-כל ממשק WinRT דורש במרומז IInspectable, ו-IInspectable דורש IUnknown. מה ש-IUnknown מגדיר הוא, כמו תמיד, שלוש השיטות QueryInterface, AddRef ו-Release.¹²

מעל זה, IInspectable מוסיף את שלוש השיטות הבאות.¹³

flowchart TB
    accTitle: IInspectable שיושב על IUnknown
    accDescr: כל ממשק WinRT דורש IInspectable, ו-IInspectable דורש IUnknown. IUnknown מספק QueryInterface, AddRef ו-Release; IInspectable מספק GetIids, GetRuntimeClassName ו-GetTrustLevel; ושיטות כל ממשק WinRT יושבות מעליהן
    unk["IUnknown (QI, AddRef, Release)"]
    insp["IInspectable (GetIids, שם טיפוס, trust level)"]
    api["שיטות כל ממשק WinRT"]
    unk --> insp
    insp --> api

איור 2: אובייקט WinRT עורם את שלוש השיטות של IInspectable על שלוש השיטות של IUnknown, וה-APIs הבודדים יושבים מעל זה.

משם טיפוס אפשר לחפש את ההגדרות של שיטות, מאפיינים ואירועים

מה שחשוב אינו מספר השיטות שנוספו אלא היכולת לחבר שם טיפוס ל-metadata.

ב-COM קלאסי, הדרך הסטנדרטית ללמוד את זהות האובייקט בזמן ריצה הייתה “לדעת את ה-IID ולשאול דרך QueryInterface”. לשפות סקריפט היה נתיב נפרד, IDispatch.

ב-WinRT, שם הטיפוס שמתקבל מ-GetRuntimeClassName ניתן לפתרון מול metadata של .winmd שמכוסה בפרק הבא. משם מקבלים את ההגדרה המלאה של השיטות, המאפיינים והאירועים שלו. המפרט עצמו אומר שהיכולת לקבל שם טיפוס WinRT שניתן לפתרון דרך metadata “מאפשרת language projection”.¹²

flowchart TB
    accTitle: מ-GetRuntimeClassName עד language projection
    accDescr: כשהקורא קורא ל-GetRuntimeClassName על אובייקט, שם טיפוס WinRT המלא חוזר; פתרון שם הטיפוס הזה מול Windows Metadata נותן את ההגדרה המלאה של הטיפוס, וזה מה שמאפשר projection לכל שפה
    obj["אובייקט WinRT"] --> name["שם טיפוס (GetRuntimeClassName)"]
    name --> md["פותרים את הגדרת הטיפוס ב-.winmd"]
    md --> proj["language projection הופך לאפשרי"]

איור 3: “שם הטיפוס זמין בזמן ריצה, ושם הטיפוס מוביל ל-metadata” הוא לב המנגנון של WinRT.

מפרידים “ירושה” מ”דורש” לממשקים מוגדרים-משתמש

יש גם הבדל שמי שמורגל ב-COM צריך לשים לב אליו. למערכת הטיפוסים של WinRT אין ירושה בין ממשקים מוגדרים-משתמש. גזירה כמו IFileSystemBindData2 : IFileSystemBindData של COM קלאסי נעדרת במכוון; במקום זאת זה מבוטא בהצהרה “ממשק A דורש ממשק B”.¹²¹

זה עניין נפרד משרשרת ה-ABI הבסיסית IUnknown → IInspectable שראינו עד כאן. הבסיס הזה נשאר כיסוד של כל ממשק WinRT.

חוזים מוגדרים-משתמש הוזזו לכיוון צורה רופפת יותר שאינה תלויה בפריסת ירושת vtable. באותו זמן, הקריאות עצמן עדיין עוברות דרך ה-vtable. חשוב לא לבלבל בין הדרך שבה כותבים חוזים לבין מנגנון הקריאה.

4. מה .winmd פתר — גיהינום ה-binding של מידע טיפוסים

הקושי של COM קלאסי היה ב”איך מפיצים מידע טיפוסים”

בפרקטיקה של COM קלאסי, יותר מאמץ הלך ל-איך להפיץ מידע טיפוסים מאשר למימוש הממשקים עצמם.

ל-TLB יש מגבלות טיפוס מכוונות אוטומציה: חלק מהמידע שאפשר לכתוב ב-IDL לא נכנס ל-TLB. וכי לכל שפה יש נתיב משלה, כשאחד מהם מתיישן מגיעים לאי-התאמות טיפוס. כיסינו את הצרות האלה ב-מאמר על type libraries ו-dscom וב-מאמר על תאימות לאחור של ממשקי DLL ו-COM.

.winmd הוא החוזה המשותף שכל שפה קוראת

התשובה של WinRT היא Windows Metadata (.winmd). ה-APIs מתוארים כ-metadata קריא למכונה, וכלים ו-language projections קוראים אותו כדי לייצר projection לכל שפה.³

Windows משווק את ה-metadata לכל WinRT API שמסופק על ידי המערכת וגם מספק APIs שפותרים namespaces וטיפוסים בזמן ריצה. Windows SDK מכיל עותק לזמן קומפילציה. גם צדדים שלישיים יכולים לקחת חלק ב-language projection דרך אותו מנגנון כמו APIs המערכת על ידי צירוף .winmd לרכיב WinRT שלהם.³

מה שהשתנה כאן הוא הצורה שבה מידע טיפוסים מופץ. במקום TLBs, headers ו-interop assemblies שמפוזרים לפי שפה, .winmd אחד נקרא כעת על ידי ה-projections של כל שפה.

עם זאת, IDL לא הפך למיותר. כשכותבים רכיב WinRT, עדיין מתארים את החוזה ב-IDL (MIDL 3.0, שעודכן ל-WinRT), ומהדר MIDL מייצר את ה-.winmd.¹⁴

flowchart TB
    accTitle: צינור הייצור של רכיב WinRT
    accDescr: החוזה של רכיב WinRT עדיין נכתב ב-IDL, כלומר MIDL 3.0, ומהדר MIDL מקמפל אותו ל-.winmd. מה שמופץ הוא ה-.winmd הזה, וכלי ה-projection של כל שפה, כמו cppwinrt.exe או cswinrt.exe, קורא אותו כדי לייצר את ה-projection. מה שהוחלף אינו IDL אלא הצורה שבה מידע טיפוסים מופץ
    idl2["כותבים את החוזה (IDL, MIDL 3.0)"]
    midl2["מהדר MIDL"]
    winmd4[".winmd (מידע טיפוסים מופץ)"]
    proj3["מייצרים את ה-projection של כל שפה"]
    idl2 --> midl2
    midl2 --> winmd4
    winmd4 --> proj3

איור 4: נקודת הכניסה של החוזה (IDL) נשארת בשירות; נקודת היציאה, מידע הטיפוסים המופץ, אוחדה ל-.winmd.

אותו פורמט קובץ כמו .NET, אבל לא managed runtime

הפורמט הפיזי של .winmd משתמש ב-מפרט ECMA-335, אותו מפרט כמו CLR assembly. הכללים לאילו שילובי נתונים תקפים שונים מאלה של CLR assemblies, עם זאת. לשאול את הפורמט ולהזדקק ל-CLR כדי לרוץ הם שני דברים שונים.³

כאן צריך לקרוא APIs של המערכת ורכיבי צד שלישי בנפרד.

כי .winmd נראה כמו .NET assembly כשפותחים אותו בכלי, קל ליפול לתפיסה השגויה “WinRT = managed”. אבל התוכן של .winmd שמסופק על ידי המערכת הוא חוזה לממשקי COM.³

flowchart TB
    accTitle: הפרדת .winmd מהמימוש
    accDescr: .winmd הוא metadata ששואל את הפורמט הפיזי של ECMA-335; אלה שמסופקים על ידי המערכת הם חוזים בלי קוד להרצה, והמימוש של WinRT APIs שמסופקים על ידי המערכת חי ב-DLLs native של מערכת ההפעלה. בגלל ההפרדה הזו, גם אם .winmd נראה כמו .NET assembly, ה-CLR אינו נחוץ כדי להריץ את WinRT APIs של המערכת (ה-.winmd של רכיב מנוהל של צד שלישי מכיל MSIL ודורש את .NET runtime)
    winmd3[".winmd (חוזה, פורמט ECMA-335)"]
    impl["DLL native של מערכת ההפעלה (מימוש)"]
    winmd3 -.->|"מסופק על ידי המערכת: אין קוד"| note3["APIs של המערכת לא צריכים CLR"]
    impl --> note3
    winmd3 ---|"הגדרות טיפוס ממופות למימוש"| impl

איור 5: ל-WinRT APIs שמסופקים על ידי המערכת ה-.winmd הוא החוזה והמימוש הוא DLL native של מערכת ההפעלה. הפורמט נראה כמו .NET, אבל ההרצה היא COM native.

flowchart TB
    accTitle: מידע טיפוסים של COM קלאסי מול .winmd
    accDescr: ב-COM קלאסי נתיב מידע הטיפוסים פוצל לפי שפה, מ-IDL ל-headers של C++, מ-type libraries ל-VB6 ולסקריפטים, מ-interop assemblies ל-.NET, מה שגרם לאי-עקביות, ואילו ב-WinRT .winmd אחד נקרא במשותף על ידי ה-projections של כל שפה
    subgraph old["COM קלאסי: נתיב אחד לכל שפה"]
    idl["IDL ל-headers של C++"]
    tlb["TLB ל-VB6 ולסקריפטים"]
    ia["Interop assembly ל-.NET"]
    end
    winmd[".winmd (metadata יחיד)"]
    winmd --> all["נקרא במשותף על ידי ה-projection של כל שפה"]

איור 6: .winmd קיפל את הפיזור לפי שפה של מידע טיפוסים ל”קובץ metadata אחד שכולם קוראים”.

המגבלות לא נעלמו; הן עברו לציר של projectability

למי שמכיר COM קלאסי, במשפט: .winmd הוא “ה-type library, שנעשה מחדש”. חושבים עליו כתפקיד ש-TLB ניסה למלא, שתוכנן מחדש מההתחלה כמקור אמת יחיד שמשותף לכל השפות, מעל פורמט ECMA-335 המוכח, ומקומו מתבהר.

המגבלות לא נעלמו, עם זאת. מגבלות ה-TLB המכוונות אוטומציה הוחלפו במגבלות של מערכת הטיפוסים של WinRT עצמה, שהציר שלהן הוא “אפשר להקרין בבטחה לכל שפה”. היעדר ירושה בין ממשקים מוגדרים-משתמש, שנראה בפרק 3, הוא דוגמה אחת.¹²

כתוצאה, חוזה COM/IDL קיים לא בהכרח ניתן לשאת ל-WinRT כמו שהוא. ייתכן שצריך לתכנן מחדש את ה-API.

flowchart TB
    accTitle: החלפת מגבלות type library במגבלות מערכת הטיפוסים של WinRT
    accDescr: מגבלות הביטוי המכוונות אוטומציה של ה-TLB (type library) לא הוסרו על ידי .winmd אלא הוחלפו במגבלות של מערכת הטיפוסים של WinRT עצמה, שהציר שלהן הוא projection בטוח לכל שפה. דוגמה אחת היא היעדר ירושת ממשק מוגדר-משתמש; חוזה COM/IDL קיים לא בהכרח ניתן לשאת כמו שהוא, ויתכן שצריך לתכנן מחדש את ה-API
    tlb["מגבלות TLB (מכוונות אוטומציה)"] -->|"הוחלפו ב"| wrt["מגבלות מערכת הטיפוסים של WinRT (ציר projectability)"]
    wrt -.-> ex["דוגמה: אין ירושה מוגדרת-משתמש"]
    wrt -.-> re["חוזי COM קיימים עשויים להזדקק לתכנון מחדש"]

איור 7: מגבלות ה-TLB לא “נעלמו”; הן הוחלפו במגבלות שונות שהציר שלהן הוא projectability לכל שפה.

5. C++/WinRT ו-C#/WinRT הם projections, לא “wrappers”

מראים את החוזה המשותף לכל שפה בצורה הטבעית שלה

ברגע שיש חוזה משותף בצורה של .winmd, אפשר לייצר את התצוגה לכל שפה אוטומטית בכלים. זה language projection. הוא חושף WinRT APIs בניב של כל שפה ומסתיר את פרטי COM, ומספק חוויית תכנות שמרגישה טבעית לשפה הזו.⁴¹¹

ה-projections ש-Microsoft תומכת בהם כעת הם השניים הבאים.⁴

ההיסטוריה בצד C# קצת מבלבלת, אז נפרק אותה. עד .NET Core 3.x, ל-.NET runtime הייתה תמיכה מובנית בצריכת WinRT/winmd. ב-.NET 5 התמיכה המובנית הזו הוסרה, והתפקיד עבר ל-C#/WinRT.¹⁶ WinRT APIs לא הפכו לבלתי שמישים; איפה מטפלים ב-projection השתנה.

היום, כשמציינים TFM כמו net8.0-windows10.0.19041.0 ב-C#, assemblies ה-projection של Windows SDK מקושרים אוטומטית.¹⁰

flowchart TB
    accTitle: ייצור projections לכל שפה מ-.winmd
    accDescr: כש-cppwinrt.exe קורא את ה-.winmd היחיד, הוא מייצר headers של projection ב-C++17; כש-cswinrt.exe קורא אותו, הוא מייצר interop assembly ב-C#; ו-WinRT APIs חשופים בצורה שעוקבת אחרי הניב של כל שפה
    winmd2[".winmd (חוזה ה-API)"]
    winmd2 --> cpp["cppwinrt.exe ל-headers של C++17"]
    winmd2 --> cs["cswinrt.exe ל-interop assembly ב-C#"]
    cpp --> cppcode["קריא בניב C++"]
    cs --> cscode["קריא בניב C#"]

איור 8: projection אינו wrapper שנכתב ביד; כלים מייצרים אותו מכנית מהחוזה (.winmd).

גם אם הוא מיוצר, הקריאה עצמה היא עדיין COM

המאמר הזה אומר “projection” ולא “wrapper” כדי להדגיש שזה מנגנון שנגזר מכנית מ-metadata, לא שכבת תרגום שאנשים מתחזקים API-API. כל API שקיים ב-.winmd יכול להיות שמיש בכל שפה נתמכת מההתחלה.

ומאיזו שפה שקוראים, מה שקורה מתחת ל-projection הוא אותה קריאת COM. למשל, כשכותבים await picker.PickSingleFolderAsync() ב-C#, ה-projection מגשר את IAsyncOperation של WinRT לעולם ה-Task של .NET. גם אז, בצד ה-ABI, קריאות שיטות vtable ו-HRESULT הם מה שבשימוש. לכן שגיאות מופיעות בצורה של COM exceptions (HRESULT כמו 0x80070005).

flowchart TB
    accTitle: השכבות מקוד C# עד WinRT API של מערכת ההפעלה
    accDescr: קוד C# או C++ של האפליקציה מומר דרך language projection לקריאות ABI של WinRT, כלומר קריאות vtable על IInspectable, ומגיע ל-WinRT API שמממשת מערכת ההפעלה. ה-projection רק מסתיר את פרטי COM; הקריאה עצמה היא COM
    code["קוד האפליקציה (C#, C++)"]
    proj2["language projection"]
    abi["ABI של WinRT (vtable של IInspectable)"]
    os["מימוש מערכת ההפעלה של WinRT API"]
    code --> proj2
    proj2 --> abi
    abi --> os

איור 9: מה שה-projection מסתיר הוא ה”פרטים” של COM, לא COM עצמו.

ידיעת המבנה הזה מאפשרת לפצל תקלות לשתי שכבות. אי-התאמת גרסה בקוד שנוצר או הגדרת TFM חסרה היא שכבת ה-projection; HRESULTs, apartments ו-reference counting הם שכבת ה-ABI. באחרונה, ניסיון פיתוח COM משרת אתכם ישירות.

6. איפה אפליקציות desktop נתקעות — HWND, identity, apartments

קודם מפרידים “יכולת להפנות ל-API” מ”התנאים שהוא יעבוד”

רוב WinRT APIs ניתנים לקריאה מ-WPF, WinForms ואפליקציות desktop של Win32.⁵ נקודת הכניסה לקריאה אליהם נבדלת בין C# ל-C++ כך.¹⁰

יכולת להפנות ל-APIs, עם זאת, אינה אומרת שכל API עובד כמו שהוא. בודקים את שלוש הנקודות הבאות. תנאי הרישום ל-toast notifications מכוסים בנפרד בפרק 9.

נקודת תקיעה 1: מעבירים HWND ל-UI כמו pickers

חלק מה-pickers, דיאלוגים ו-Share UI מצפים ל-CoreWindow של UWP כמשטח להציג עליו. לאפליקציית desktop אין CoreWindow, כך ש-HWND של חלון הבעלים חייב להיות מועבר במפורש לפני שמראים את האובייקט.⁶

נקודת הכניסה שמשמשת ל-pickers ודומים היא ממשק COM שנקרא IInitializeWithWindow. הוא יורש מ-IUnknown ומספק חלון בעלים לאובייקטי WinRT שמשמשים באפליקציות desktop.¹⁷

ב-C#, קודם מקבלים את ה-HWND לפי ה-UI framework שבשימוש.¹⁸⁶

אחר כך, מוסרים אותו ל-picker עם WinRT.Interop.InitializeWithWindow.Initialize(picker, hwnd), ורק אז מראים אותו. ב-C++/WinRT, מקבלים את האובייקט כ-as<IInitializeWithWindow>() ואז קוראים ל-Initialize(hwnd). אם מדלגים על האתחול, זה זורק או נכשל בשקט.¹⁸¹⁹

אתחול אובייקט WinRT מודרני ב-QueryInterface לממשק COM קלאסי: העובדה שהגשר הזה הוא הפרקטיקה הרשמית היא מקום נוסף שבו WinRT מראה שהוא COM.

ה-Share UI משתמש בממשק אחר. ל-DataTransferManager לא משתמשים ב-IInitializeWithWindow. משתמשים ב-IDataTransferManagerInterop הייעודי ומעבירים את ה-HWND ל-ShowShareUIForWindow.⁶

ה-pickers החדשים יותר של Windows App SDK הם נתיב נפרד נוסף. Microsoft.Windows.Storage.Pickers מקבל WindowId ב-constructor, כך שדפוס InitializeWithWindow מיותר. הם אינם APIs שאפשר להשתמש בהם עם הגדרת TFM לבדה, עם זאת. בנוסף להוספת Windows App SDK, אפליקציה unpackaged צריכה שה-runtime ייפרס ויאותחל במכונות היעד.¹⁹

sequenceDiagram
    accTitle: צעדים להצגת picker מאפליקציית desktop
    accDescr: אחרי שאפליקציית desktop יוצרת picker, קריאה ל-PickSingleFolderAsync כמו שהיא מסתיימת ב-exception או בכישלון שקט, כך שצריך קודם לקבל את HWND של חלון הבעלים ולהעביר אותו דרך Initialize של IInitializeWithWindow לפני שמראים את ה-picker
    participant A as אפליקציית desktop
    participant P as Picker (WinRT)
    A->>P: יוצרים
    alt מציגים בלי להעביר HWND
        A->>P: PickSingleFolderAsync
        P-->>A: exception או כישלון שקט
    else מעבירים את ה-HWND קודם
        A->>P: מגדירים את ה-HWND דרך IInitializeWithWindow
        A->>P: PickSingleFolderAsync
        P-->>A: ה-picker מוצג
    end

איור 10: מילוי הפער של “אין CoreWindow ב-desktop” בהעברת HWND במפורש הוא הפרקטיקה הרשמית.

נקודת תקיעה 2: חלק מה-APIs דורשים package identity

חלק מ-WinRT APIs, כמו היסטוריית toast notification (ToastNotificationHistory), jump lists ו-share targets, עובדים רק באפליקציות שיש להן package identity (אפליקציות packaged). קריאה אליהם מאפליקציה unpackaged שמופצת עם installer מסורתי נכשלת.⁷

יש שני תיקונים. לארוז את האפליקציה ב-MSIX, או להשתמש ב-“package with external location” (מה שנקרא sparse package), שנותן identity תוך שמירה על ה-installer הקיים.²⁰ אילו APIs דורשים identity אפשר לבדוק ברשימה הרשמית.⁷

flowchart TB
    accTitle: שני נתיבים ל-APIs שדורשים package identity
    accDescr: קריאה ל-WinRT API שדורש package identity מאפליקציה unpackaged נכשלת, לכן נותנים לאפליקציה package identity או באריזה ב-MSIX או ב-package שמצביע למיקום חיצוני, שנותן רק את המזהה תוך שמירה על ה-installer הקיים
    need["רוצים להשתמש ב-API שדורש identity"]
    need --> m1["אורזים ב-MSIX"]
    need --> m2["package שמצביע למיקום חיצוני"]
    m1 --> id2["מקבלים package identity"]
    m2 --> id2
    id2 -.-> okid["היסטוריית התראות וכו' עובדים"]

איור 11: התיקון ל-APIs שדורשים identity הוא בחירה משתיים: “MSIX” או “installer קיים + מתן מזהה”.

נקודת תקיעה 3: בודקים אתחול thread ו-STA/MTA

thread שמטפל באובייקטי WinRT חייב להיות מאותחל ל-WinRT מראש. בקוד native, משתמשים ב-RoInitialize או ב-winrt::init_apartment ו-מציינים את מודל ה-concurrency, STA או MTA. באפליקציות C# WPF/WinForms, ה-runtime בדרך כלל מטפל באתחול.⁸

RoInitialize הוא נקודת הכניסה של דור WinRT בתוך אותו framework כמו CoInitializeEx של COM. התיעוד של CoInitialize עצמו מפנה לקרוא ל-RoInitialize או ל-Windows::Foundation::Initialize במקום כשמשתמשים ב-Windows Runtime.²¹

ה-UI thread של WPF/WinForms הוא STA; אובייקטי UI חייבים להיגע ב-UI thread; המתנות חוסמות על STA מזמינות deadlocks. החשיבה שכוסתה ב-מאמר STA/MTA עוברת ללא שינוי ל-WinRT APIs.

חלק מה-APIs אינם ניתנים לשימוש גם עם HWND ו-identity במקום

התיקונים עד כאן נוגעים ל-APIs שיש להם נקודת כניסה לשימוש desktop. APIs שתלויים ב-CoreWindow או ב-ApplicationView עצמם אינם ניתנים לשימוש מאפליקציות desktop. במקרה כזה, במקום להוסיף אתחול, מחפשים API חלופי.⁵⁷

flowchart TB
    accTitle: פיצול נקודות התקיעה כשקוראים ל-WinRT APIs מה-desktop
    accDescr: קודם מאשרים שה-thread מאותחל ל-WinRT (בקוד native מציינים STA/MTA במפורש עם RoInitialize או דומה; ב-C# ה-runtime בדרך כלל מטפל). אחר כך, אם ה-WinRT API שרוצים לקרוא הוא UI שמניח CoreWindow, מעבירים HWND דרך IInitializeWithWindow או משתמשים ב-pickers החדשים; אם הוא דורש package identity, נותנים מזהה עם MSIX או package שמצביע למיקום חיצוני; APIs שתלויים ב-CoreWindow או ApplicationView עצמם אינם ניתנים לשימוש ב-desktop, לכן מחפשים API חלופי; ורוב ה-APIs הגדול שנשאר ניתן לקריאה כמו שהוא רק עם הגדרת TFM או C++/WinRT
    pre["אתחול thread"] --> q{"איזה סוג API זה?"}
    pre -.-> auto["native: מפורש; C#: בדרך כלל אוטומטי"]
    q -->|"UI"| h["HWND או ה-pickers החדשים"]
    q -->|"דורש identity"| p2["MSIX או מתן מזהה"]
    q -->|"תלוי ב-CoreWindow עצמו"| x["מחפשים API חלופי"]
    q -->|"כל השאר"| ok3["קריא כמו שהוא"]

איור 12: עם אתחול thread כהנחה (מפורש בקוד native, בדרך כלל מושאר ל-runtime ב-C#), נקודות התקיעה נופלות לשלוש משפחות, לכל אחת תיקון סטנדרטי.

flowchart TB
    accTitle: התאמת אתחול thread בין COM ל-WinRT
    accDescr: ב-COM קלאסי thread מאותחל עם CoInitializeEx תוך ציון STA או MTA, ואילו ב-WinRT הוא מאותחל עם RoInitialize תוך ציון אותו מודל concurrency של STA או MTA. גם התיעוד של CoInitialize מפנה לקרוא ל-RoInitialize כשמשתמשים ב-WinRT, ומושג ה-apartment משותף
    com3["COM קלאסי: CoInitializeEx"] --> apt["Apartment (STA / MTA)"]
    wrt["WinRT: RoInitialize"] --> apt
    apt -.-> rule["UI thread הוא STA; זהירות מהמתנות"]

איור 13: שם ה-API של האתחול השתנה, אבל אותו מושג apartment ממשיך להיות בשימוש.

7. מה יושב מתחת ל-WinUI — פיתוח בגלוי לא משנה את החוזה

מעבר לפיתוח בגלוי אינו שינוי לחוזה הבינארי

בקיץ 2025, Microsoft הכריזה רשמית, כ-גישה מדורגת, על מדיניותה להעביר את פיתוח ה-mainline של WinUI לגלוי ב-GitHub. יש ארבעה שלבים: להגביר את תדירות העדכון של ה-mirror, לאפשר builds מקומיים, לקבל תרומות קהילה ברגע שיש בדיקות, ולבסוף להפוך את GitHub לבית הראשי של הפיתוח.²²

נכון לפרסום המאמר הזה (סוף אוגוסט 2026), גם התיעוד הרשמי קובע במפורש ש-WinUI הוא “built in the open”. אפשר כעת לעקוב אחרי התקדמות ההנדסה היומיומית במאגר הציבורי.⁹

מפתחים שעקבו אחרי מעברי הדור מ-WinForms ל-WPF ל-UWP ל-WinUI מרגישים באופן טבעי “ה-framework משתנה שוב?”. אבל ה-UI frameworks שהמשיכו להשתנות והיסוד מתחתיהם צריכים להיראות בנפרד. Win32 ו-COM, ומ-2012 ה-ABI של WinRT, נשארו באותו מקום.

גם חלונות WinUI מגובים ב-HWND

WinUI הוא קבוצת WinRT APIs שמסופקת כחלק מ-Windows App SDK.⁹²³ ה-Microsoft.UI.Xaml.Window שלו הוא חלון שמגובה ב-HWND, שמחליף את מודל החלון מבוסס CoreWindow של דור UWP. גם ה-walkthrough הרשמי של interop מתחיל בקבלת window handle.²⁴

כלומר, אפליקציית WinUI היא אפליקציית Win32 שבה עץ אובייקטים שעוקב אחרי חוזה IInspectable רץ מעל חלון HWND. הידע של QueryInterface, reference counting ו-apartments שנרכש דרך COM, והידע של HWNDs ולולאות הודעות שנרכש דרך Win32, שניהם חלים ישירות על troubleshooting של WinUI.

flowchart TB
    accTitle: מעברי דור של UI frameworks והיסוד שלא השתנה
    accDescr: ה-UI frameworks WinForms, WPF, UWP XAML ו-WinUI עברו דור אחרי דור, אבל WinForms ו-WPF יושבים ישירות על יסוד Win32 ו-COM, בעוד UWP XAML ו-WinUI יושבים על אותו יסוד Win32 ו-COM דרך ה-ABI של WinRT. מה שהחליף דורות הוא השכבה העליונה; החוזה מתחת לא השתנה
    gen["מעברי דור של UI frameworks"]
    gen --> f1["WinForms, WPF"]
    gen --> f2["UWP XAML"]
    gen --> f3["WinUI (נוכחי)"]
    f2 --> abi3["ABI של WinRT (מ-2012)"]
    f3 --> abi3
    f1 --> stable["יסוד שלא השתנה (Win32 + COM)"]
    abi3 --> stable

איור 14: מה שעלה ונפל היה שכבת ה-framework. WinForms ו-WPF יושבים ישירות על Win32 + COM; UWP ו-WinUI יושבים על אותו יסוד דרך ה-ABI של WinRT.

flowchart TB
    accTitle: השכבות שתומכות באפליקציית WinUI
    accDescr: ה-XAML והפקדים של WinUI מסופקים כחלק מ-Windows App SDK, רצים על ה-ABI של WinRT, כלומר חוזה IInspectable, ומתחת לזה יושב היסוד של COM ו-HWND של Win32. תחת מעברי הדור של UI frameworks, החוזה הבסיסי הזה לא השתנה
    ui["WinUI (XAML, פקדים)"]
    sdk["Windows App SDK"]
    abi2["ABI של WinRT (IInspectable)"]
    base2["COM + Win32 (HWND)"]
    ui --> sdk
    sdk --> abi2
    abi2 --> base2

איור 15: מתחת ל-WinUI יושב ה-ABI של WinRT, ומתחת לזה COM קלאסי ו-Win32. רק הערימה השתנתה; היסוד זהה.

ערבוב עם XAML Islands: בודקים את המגבלות של כל דור

האסטרטגיה של “לערבב רק פקדי WinUI במסכי WPF/WinForms קיימים” צריכה להיות מוערכת בנפרד לכל דור של XAML Islands.

אם מתכננים ערבוב הדרגתי, בטוח יותר לא להניח ערבוב ברמת פקד לבדו. ארגון התוכנית סביב שימוש ברמת תכונה ב-WinRT APIs (פרק 6) או הפרדה ברמת מסך או process הוא הגישה הבריאה יותר נכון ל-2026.

8. השלכות לאפליקציות עסקיות — מעבר מלא ושימוש בררני הם בעיות נפרדות

“WinRT הוא עולם חדש ונפרד, כך שהשימוש בו פירושו לזרוק נכסים קיימים ולבנות מחדש.” התפיסה השגויה הזו, שפוגשים בפרויקטי Custom Software Development, מתמוססת ברגע שמפצלים אותה לשתיים.

נכסי COM קיימים ו-WinRT יכולים להתקיים יחד

אפליקציית WPF שמשתמשת באוטומציית COM של Excel, מארחת פקדי ActiveX, וקוראת לרכיבי COM פנימיים יכולה לקבל WinRT APIs שנוספים אליה. זה לא אקרובטיקה מיוחדת, כי משלבים תכונות על אותו יסוד COM.

ל-toast notifications, למשל, מגדירים את ה-TFM כדי להפנות ל-API ומספקים את תנאי הרישום להצגת התראות. כדי שהאחרון לא יישכח, פרק 9 מניח אותו נתיב-נתיב. ב-C++/WinRT, גם ממשקי WinRT וגם ממשקי COM קלאסיים ניתנים לטיפול באותם מנגנונים, winrt::com_ptr ו-winrt::implements.²¹

מעריכים חידוש UI והוספת תכונה בנפרד

“להעביר את ה-UI במלואו ל-WinUI?” ו”להשתמש ב-WinRT APIs רק איפה שצריך?” הם החלטות שנבדלות בקנה מידה, במשך ובסיכון.

מעבר UI מלא הוא בעיית בחירת framework שתלויה בנכסי מסכים, פקדי צד שלישי וארגון הפיתוח. כיסינו את ההחלטה הזו ב-בחירה בין WinForms, WPF ו-WinUI. שימוש בררני ב-WinRT APIs, לעומת זאת, הוא שיפור קטן שאפשר להתחיל באפליקציה קיימת היום.

לפרויקט שרק רוצה toast notifications, אין צורך להעריך מעבר UI מלא. ולהפך, אין צורך לעכב שימוש ב-WinRT APIs “כי לא עוברים ל-WinUI”.

flowchart TB
    accTitle: מעבר מלא ושימוש בררני הם החלטות נפרדות
    accDescr: מעבר UI מלא ל-WinUI הוא החלטת בחירת framework גדולה שתלויה בנכסי מסכים ובארגון, ואילו שימוש בררני ב-WinRT APIs הוא החלטה קטנה שאפשר להוסיף לאפליקציית WPF או WinForms קיימת היום עם הגדרת TFM או דומה; שוקלים את השתיים בנפרד בלי לבלבל אותן
    goal["רוצים להשתמש בתכונות Windows חדשות"]
    goal --> big["מעבר UI מלא (החלטה גדולה)"]
    goal --> small["שימוש בררני ב-WinRT API (החלטה קטנה)"]
    big -.-> dep["תלוי בנכסי מסכים ובארגון"]
    small -.-> today["אפשר להוסיף לאפליקציה הקיימת היום"]

איור 16: יש שני כבישים ל”תכונות חדשות”, ובלבול ביניהם מעיף גם את ההערכה וגם את ההחלטה.

9. טבלת החלטה — גרסת WinRT של להשאיר, לעטוף, להחליף

בוחרים רק את השינויים שכל מצב צריך

כהרחבה של טבלת ההחלטה של ActiveX, הנה מדריך החלטה לפי מצב בצד WinRT.

Toast notifications לא מופיעות עם הגדרת TFM לבדה

ההגדרה שהופכת את ה-API לקריא והרישום שהופך התראה למופיעה הם שני דברים שונים. כש”ה-build מצליח אבל אין התראה”, בודקים לא רק את קוד הקריאה אלא את הנתיב שבשימוש, את צורת האריזה, ואם ה-process elevated.

כשמשתמשים ב-ToastNotificationManager הקלאסי

לאפליקציה unpackaged בלי package identity, התנאי המוקדם הוא רישום shortcut בתפריט Start עם AppUserModelID (AUMID) מוקצה. בלעדיו, אי אפשר להציג toasts.²⁷

אפליקציה שמאורזת ב-MSIX או דומה לא צריכה את הרישום הידני הזה, כי package identity מספק את ה-AUMID.

כשמשתמשים ב-AppNotificationManager של Windows App SDK

בנתיב המומלץ כעת הזה, הוספת Windows App SDK וקריאה ל-Register() בהפעלה נדרשות. מעבר לזה, התנאים מתפצלים לפי צורת אריזה.²⁸

יתר על כן, בנתיב Windows App SDK, התראות מתהליך שהועלה ל-administrator אינן נתמכות. Show נכשל בשקט בלי לזרוק. באפליקציה שצריכה elevation, שוקלים להפריד התראות ל-process לא-elevated.²⁸

פרטי המימוש סביב הרישום מכוסים ב-מדריך המימוש של system tray והתראות.

flowchart TB
    accTitle: שני הנתיבים ל-toast notifications והרישום שכל אחד צריך
    accDescr: כדי להציג toast notification מאפליקציית desktop, נתיב ToastNotificationManager הקלאסי מתפצל לפי אם האפליקציה packaged: אפליקציה unpackaged חייבת לעבור ברישום shortcut בתפריט Start עם AppUserModelID מוקצה, בעוד לאפליקציה packaged ה-package identity מספק את ה-AppUserModelID. בנתיב AppNotificationManager של Windows App SDK, בנוסף להוספת ה-SDK ולקריאה ל-Register בהפעלה, אפליקציה unpackaged חייבת לפרוס את ה-runtime בכל מחשב יעד ואפליקציה שמאורזת ב-MSIX חייבת להצהיר על COM activator במניפסט לפני שהיא יכולה להמשיך. נתיב Windows App SDK מתפצל עוד לפי אם ה-process elevated: התראות מתהליך שהועלה ל-administrator אינן נתמכות ו-Show נכשל בשקט בלי לזרוק, כך שבנתיב הזה התראה מוצגת רק ל-process לא-elevated, ואפליקציה שצריכה elevation מפרידה התראות ל-process לא-elevated
    want["רוצים להציג toast"]
    want --> c1["קלאסי: ToastNotificationManager"]
    want --> c2["WASDK: AppNotificationManager"]
    c1 --> q1{"Packaged?"}
    q1 -->|"לא"| s1["רושמים shortcut עם AUMID"]
    q1 -->|"כן"| s2["Identity מספק את ה-AUMID"]
    c2 --> r2["מוסיפים את ה-SDK + Register()"]
    r2 --> q2{"Packaged?"}
    q2 -->|"לא"| s3["פורסים את ה-runtime"]
    q2 -->|"כן"| s4["מצהירים COM במניפסט"]
    s1 --> shown["ההתראה מוצגת"]
    s2 --> shown
    s3 --> elev{"process מוגבה?"}
    s4 --> elev
    elev -->|"לא"| shown
    elev -->|"כן"| fail["לא נתמך: Show נכשל בשקט"]
    fail -.-> comp["מפרידים התראות ל-process לא-elevated"]

איור 17: בכל נתיב, ההתראה מופיעה רק אחרי שתנאי המוקדם של צורת האריזה מסופקים. בנתיב Windows App SDK, גם עם כל תנאי המוקדם במקום, שום דבר לא מוצג מ-process elevated.

לבסוף, בחזרה להשאיר, לעטוף, להחליף

האם צריך תכונה חדשה, או רוצים לחדש את ה-UI עצמו? חזרה לשאלה הזו מאפשרת להחליט על שימוש ב-WinRT ועל החלפת נכסים קיימים בנפרד.

flowchart TB
    accTitle: זרימת החלטה לאיך נכסים קיימים ו-WinRT מתאימים יחד
    accDescr: החל מאפליקציית desktop קיימת, זרימת החלטה מדורגת: אם אין צורך בתכונת Windows חדשה, משאירים; אם צריך תכונה, עוטפים בשימוש בררני ב-WinRT APIs (עם תשומת לב לנקודות התקיעה של פרק 6 של HWND, package identity ואתחול thread); ורק כשה-UI עצמו צריך חידוש, שוקלים להחליף ב-WinUI
    start["אפליקציית desktop קיימת"] --> q2{"מה נחוץ?"}
    q2 -->|"המצב הנוכחי מספיק"| keep2["להשאיר (לתחזק כמו שהוא)"]
    q2 -->|"תכונה חדשה"| wrap2["לעטוף (שימוש בררני ב-WinRT API)"]
    q2 -->|"חידוש UI"| rep["להחליף (להעריך WinUI)"]
    wrap2 -.-> note2["שים לב ל-HWND, identity, אתחול (פרק 6)"]

איור 18: אותו מבנה “להשאיר, לעטוף, להחליף” כמו טבלת ההחלטה של ActiveX חל ישירות בצד WinRT.

10. סיכום

WinRT אינו סביבת הרצה חדשה שמנותקת מ-COM. זה יסוד API שמשלב את החוזה הבינארי של COM עם metadata ו-projections לכל שפה.

גם כשהמשטח הוא API טבעי ב-C# או ב-C++, מתחתיו קריאות COM דרך vtables ו-HRESULTs. לכן הבנת העברת HWND ב-desktop, package identity, ו-STA/MTA עם אתחול thread מקלה לבודד תקלות WinRT.

המאמץ להעביר את פיתוח ה-mainline של WinUI לגלוי הוכרז בקיץ 2025 כגישה מדורגת. נכון לפרסום המאמר הזה התיעוד הרשמי גם אומר “built in the open”, אבל החוזה מתחתיו, IUnknown → IInspectable, לא השתנה.²²⁹

המסקנה לאפליקציות עסקיות זהה. נכסי COM/ActiveX קיימים ו-WinRT יכולים להתקיים יחד. לא לבלבל מעבר UI מלא עם שימוש בררני ב-WinRT APIs הוא מה שמגן על דיוק ההערכות וההחלטות.

ה-compound documents של שנות ה-90 שנראו במאמר OLE ו-WinUI של היום עומדים על אותו IUnknown. לדעת COM אינו רק “להיות בקיא ב-legacy”. זה להיות מסוגל לקרוא את היסוד של Windows של היום.

מאמרים קשורים

• מה זה COM — למה התכנון של Windows COM עדיין מחזיק
• COM, ActiveX ו-OCX — ההבדלים והקשר ביניהם
• STA ו-MTA ב-COM — threading model, ואיך נמנעים מ-hang
• ActiveX / OCX: להשאיר, לעטוף או להחליף
• WinForms, WPF או WinUI — טבלת החלטה מעשית
• מה זה OLE object? — איך embedding ו-linking עובדים, והמלכודות במסמכים עסקיים
• איך קוראים ל-DLL של .NET 8 מ-VBA עם טיפוסים: COM host ו-dscom

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בפיתוח רכיבי COM ובתחזוקה, שינוי והחלפה של אפליקציות עסקיות ל-Windows שכוללות נכסי COM. אפשר להתייעץ מהשלב שבו תוכן המאמר הזה הוא בדיוק הבעיה שעל הפרק: “רוצים toast notifications ו-pickers תוך הישארות על WPF”, “קריאה ל-WinRT API נעצרה ב-exception”, “רוצים להחליט אם לעבור ל-WinUI או להפיק את המרב מנכסים קיימים”.

• Windows Custom Software Development
• פיתוח רכיבי COM
• ייעוץ טכני וסקירת תכנון
• יצירת קשר

קישורים

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

האם WinRT הוא managed runtime כמו .NET?

לא. WinRT (Windows Runtime) אינו סביבת הרצה עם מכונה וירטואלית או garbage collector; זה ABI (חוזה בינארי) שנבנה על COM. התיעוד של Microsoft עצמה קובע במפורש ש-"The Windows Runtime is based on COM", וכל ממשק WinRT דורש IInspectable, שיורש מ-IUnknown. כל קריאה היא עדיין קריאת COM דרך vtable, שנשענת על reference counting (AddRef/Release) ועל QueryInterface. השם ".winmd" וההתאמה הקרובה ל-.NET מקלים לטעות ולחשוב ש-WinRT הוא סביבה מנוהלת, אבל .winmd הוא קובץ metadata ששואל את אותו פורמט פיזי כמו ECMA-335, וקבצי ה-.winmd שמסופקים על ידי המערכת לא מכילים קוד להרצה. הסיבה ש-C# יכול לקרוא לו כל כך טבעית היא ש-language projection מייצר תצוגת C# מה-metadata הזה.

שמעתי ש-UWP כבר לא מיינסטרים. יש עדיין טעם ללמוד WinRT?

כן. UWP, מודל האפליקציה, ו-WinRT, יסוד ה-API, הם שני דברים שונים. גם אחרי ש-UWP צומצם, רוב WinRT APIs ממשיכים להיות מסופקים בצורה שאפליקציות desktop של WPF, WinForms ו-Win32 יכולות לקרוא, והרבה מיכולות Windows של היום, כמו toast notifications, Share, Bluetooth ו-OCR, חשופות כ-WinRT APIs. מעל זה, WinUI (Windows App SDK), ה-UI framework ה-native ש-Microsoft ממליצה עליו כעת, בנוי על ה-ABI של WinRT. כלומר, המכונה של WinRT (IInspectable, .winmd, language projections) אינה שריד של UWP; היא היסוד עצמו של פיתוח אפליקציות Windows הנוכחי.

האם אפליקציית WPF או WinForms יכולה לקרוא ל-WinRT APIs?

כן. ב-.NET 6 ואילך, כל מה שצריך הוא להגדיר את TargetFramework של הפרויקט ל-TFM עם גרסת Windows, כמו net8.0-windows10.0.19041.0; אז assemblies ה-projection של Windows SDK מקושרים ואפשר לקרוא ל-WinRT APIs במרחבי השמות Windows.* ישירות מ-C#. ב-C++, מוסיפים את חבילת NuGet Microsoft.Windows.CppWinRT ומשתמשים ב-C++/WinRT עם C++17 ואילך. יש עם זאת שלוש נקודות תקיעה. ראשית, מחלקות UI שמניחות CoreWindow, כמו pickers ודיאלוגים, צריכות את HWND של חלון הבעלים שיועבר דרך IInitializeWithWindow לפני שהן מוצגות (ה-Share UI של DataTransferManager הוא החריג: במקום IInitializeWithWindow הוא משתמש ב-IDataTransferManagerInterop הייעודי, נתיב נפרד שמעביר את ה-HWND ל-ShowShareUIForWindow). שנית, חלק מה-APIs, כמו היסטוריית ההתראות ו-jump lists, דורשים package identity (אריזת MSIX או package עם מיקום חיצוני). שלישית, thread שמטפל באובייקטי WinRT חייב להיות מאותחל קודם. בקוד native, מציינים את מודל ה-concurrency של STA/MTA עם winrt::init_apartment או RoInitialize (באפליקציות C# WPF/WinForms ה-runtime בדרך כלל מטפל בזה). שימו לב ש-APIs שתלויים ב-CoreWindow או ב-ApplicationView עצמם אינם ניתנים לשימוש מאפליקציות desktop בכלל.

קריאה ל-picker כמו FolderPicker מאפליקציית desktop זורקת exception. למה?

כי חלק ממחלקות picker ודיאלוג של WinRT תוכננו להציג על UWP CoreWindow. לאפליקציית desktop אין CoreWindow, כך שצריך לומר במפורש את חלון הבעלים לפני שמראים את האובייקט. בפועל, קודם מקבלים את HWND של חלון הבעלים (WinRT.Interop.WindowNative.GetWindowHandle ל-WinUI Window, WindowInteropHelper ל-WPF, מאפיין Handle של הטופס ל-WinForms), ואז ב-C# מוסרים אותו ל-picker עם WinRT.Interop.InitializeWithWindow.Initialize. ב-C++/WinRT, עושים QueryInterface לאובייקט ל-IInitializeWithWindow (as<IInitializeWithWindow>()) וקוראים ל-Initialize(hwnd). בלי האתחול הזה, הקריאה זורקת או נכשלת בשקט. שימו לב שה-pickers החדשים יותר של Windows App SDK (Microsoft.Windows.Storage.Pickers) תוכננו מחדש לקבל WindowId ב-constructor, מה שהופך את דפוס האתחול הזה למיותר (אבל כי הם Windows App SDK APIs, הגדרת TFM לבדה אינה מספיקה: צריך להוסיף את ה-SDK, ולאפליקציה unpackaged צריך לפרוס ולאתחל את ה-runtime במכונות היעד).

שמעתי שפיתוח WinUI נפתח ב-GitHub. האם לזרוק אפליקציות WPF/WinForms קיימות?

אין צורך למהר. פתיחת פיתוח ה-mainline של WinUI היא הצהרת כיוון, ש-Microsoft משקיעה ברצינות ב-framework ה-native שלה, לא הודעת סיום ל-frameworks הקיימים. WPF ו-WinForms עדיין נתמכים כחלק מ-.NET היום. מפצלים את ההחלטה לשתיים. אחת היא אם להעביר את ה-UI framework, החלטה גדולה שתלויה בגודל נכסי המסכים, פקדי צד שלישי וארגון הפיתוח. השנייה היא אם להשתמש ב-WinRT APIs באופן בררני מהאפליקציה הקיימת, מה שאפשר להתחיל היום עם הגדרת TFM. שימו לב שה-TFM רק הופך את ה-APIs לקריאים; toast notifications, למשל, דורשים רישום בנוסף לקריאה (בנתיב הקלאסי, אפליקציה unpackaged חייבת לרשום shortcut עם AppUserModelID — אפליקציה packaged לא, כי package identity מספק את ה-AppUserModelID; בנתיב Windows App SDK, צריך להוסיף את ה-SDK — ולאפליקציה unpackaged גם להתקין את Windows App SDK runtime בכל מחשב יעד — ולקרוא ל-Register() של AppNotificationManager, בעוד לאפליקציה שמאורזת ב-MSIX הרישום האוטומטי של Register() לא עובד וצריך בנוסף להצהיר על COM activator ב-Package.appxmanifest). גם, בנתיב Windows App SDK התראות מתהליך שהועלה ל-administrator אינן נתמכות, ו-Show נכשל בשקט בלי לזרוק — אפליקציה שצריכה elevation צריכה לשקול להפריד התראות ל-process לא-elevated. גם אז, אם כל מה שרוצים הוא toast notifications, מעבר ל-WinUI מיותר. שימו לב שערבוב פקדי WinUI במסכי WPF/WinForms קיימים (XAML Islands) דורש הבחנה בין דורות. ה-Islands של דור UWP נעצרו ב-.NET Core 3.x ל-WPF/WinForms, ולדור WinUI 3 ה-XAML hosting API של Windows App SDK (DesktopWindowXamlSource) שמיש מ-WPF/WinForms, אבל אין פקדי wrapper נוחים ועומס המימוש כבד, כך שהערכה זהירה היא המסלול הבטוח כעת.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.