Як порівняно час виконання програми Windows 8 (програми WinRT / Windows Store / універсальний додаток Windows 10) із Silverlight та WPF? [зачинено]


353

Я намагаюся обернутися новою програмою Windows 8 Runtime, яка використовується для створення програм у стилі метро . Я знаю, що ви можете використовувати його з XAML, і він заснований на .NET, тому C # і VB.NET можна використовувати для написання програм, але тоді, здається, це має щось спільне з HTML, CSS, DOM та JavaScript.

Чи може хтось пояснити, що це в декількох абзацах, з точки зору, який програміст .NET UI може зрозуміти? (Я пропускаю щось «ключове», яке необхідно, щоб зрозуміти це.)


Всі ми знаємо, що WPF, Silverlight , Windows Forms тощо будуть продовжувати працювати в Windows 8 (і Windows 10) принаймні на системах Intel, тому, будь ласка, не кажіть мені, що ...


22
Він не ґрунтується на .NET, а лише піддається впливу (трохи схожий на COM interop, але набагато більш безпроблемний ... наприклад, ніяких збірок interop).
Павло Мінаєв

Ви запитуєте про WinRT як платформу (ABI, об'єктну модель тощо) - в такому випадку є більш сенсом порівняти її з COM або .NET - або про бібліотеки стандартного класу WinRT, у тому числі для UI?
Павло Мінаєв

1
Зауважте, що слід розрізняти базову технологію, об'єктну модель тощо - подібну, наприклад, COM - та конкретні бібліотеки, реалізовані за цією технологією. Навіть у випадку останньої, не всі стандартні бібліотеки - це бібліотеки інтерфейсу користувача - якщо ви подивитесь у Object Browser в VS, ви зможете побачити широту функцій, які Windows.*охоплюють простори імен. Термінологія поки що дещо заплутана, оскільки WinRT посилається як на технологію, так і на весь набір стандартних бібліотек. Я не думаю, що існує якась стисла мітка лише для бібліотек інтерфейсу користувача ( Windows.UI.*).
Павло Мінаєв

@TrueWill: Більше сенсу вивчити всіх трьох, щоб ваші знання були більш чіткими, і ви зможете вирішити, яке рішення найкраще підходить для даної проблеми. Не просто вивчіть одну з трьох.
Кріс Чарабарук

2
@TrueWill: Silverlight не матиме жодних - або майбутніх релізів: zdnet.com/blog/microsoft/microsoft-releases-silverlight-5 / ...
Sabunçu

Відповіді:


479

На найнижчому рівні WinRT - це об'єктна модель, визначена на рівні ABI. Він використовує COM в якості основи (тому кожен об’єкт WinRT реалізує IUnknownта робить перерахунок) і будує звідти. Це додає досить багато нових понять порівняно зі старими COM, більшість з яких надходить безпосередньо з .NET - наприклад, об’єктна модель WinRT має делегатів, а події виконуються у стилі .NET (з делегатами та додавання / видалення підписника методів, по одному на подію), а не старої моделі COM джерел подій та раковин. Серед інших помітних речей, WinRT також має параметризовані ("загальні") інтерфейси.

Ще одна велика зміна полягає в тому, що всі компоненти WinRT мають для них метадані, як і .NET збірки. У COM у вас щось на зразок було з typelibs, але не кожен компонент COM мав їх. Для WinRT метадані містяться у файлах .winmd - загляньте всередину "C: \ Program Files (x86) \ Windows Kits \ 8.0 \ Windows Metadata \" у Preview Developer Preview. Якщо ти замислишся, то побачиш, що це насправді збірки CLI без коду, просто таблиці метаданих. Ви можете відкрити їх за допомогою ILDASM. Зауважте, це не означає, що самим WinRT управляється - він просто повторно використовує формат файлу.

Тоді існує ряд бібліотек, реалізованих з точки зору цієї об'єктної моделі - що визначає інтерфейси та класи WinRT. Знову подивіться згадану вище папку "Метадані Windows", щоб побачити, що там є; або просто запустіть браузер об’єктів у VS та виберіть "Windows 8.0" у селекторі фреймворків, щоб побачити, що охоплюється. Там багато, і це не стосується лише інтерфейсу користувача - ви також отримуєте простори імен, наприклад Windows.Data.Json, або Windows.Graphics.Printing, або Windows.Networking.Sockets.

Потім ви отримуєте кілька бібліотек, які спеціально мають справу з інтерфейсом користувача - переважно це будуть різні простори імен під Windows.UIабо Windows.UI.Xaml. Багато з них дуже схожі на простори імен WPF / Silverlight - наприклад Windows.UI.Xaml.Controls, тісно співпадають System.Windows.Controls; ditto for Windows.UI.Xaml.Documentsetc.

Тепер .NET має можливість безпосередньо посилатися на компоненти WinRT так, ніби вони були .NET збірками. Це працює інакше, ніж COM Interop - вам не потрібні проміжні артефакти, такі як збірки interop, ви просто /r.winmd файл, і всі типи та їх члени в його метаданих стають вам видимими, ніби вони об’єктами .NET. Зауважте, що самі бібліотеки WinRT є повністю рідними (і тому рідні програми C ++, які використовують WinRT, взагалі не потребують CLR) - магія розкривати всі ті речі, як керовані, всередині самого CLR, і досить низький рівень. Якщо ви ildasm .NET програма, яка посилається на .winmd, ви побачите, що це насправді схоже на зовнішню посилання на збірку - немає хитрості хитрощів, таких як вбудовування типу.

Це теж не тупе відображення - CLR намагається адаптувати типи WinRT до їх еквівалентів, де це можливо. Так наприклад GUIDs, дата і ідентифікатори URI стають System.Guid, System.DateTimeі System.Uri, відповідно; Інтерфейси колекції WinRT, такі як IIterable<T>і IVector<T>стати IEnumerable<T>та IList<T>; і так далі. Це іде обома способами - якщо у вас є .NET-об’єкт, який реалізує IEnumerable<T>, і передати його назад WinRT, він побачить це як IIterable<T>.

Зрештою, це означає, що ваші додатки .NET Metro отримують доступ до підмножини існуючих стандартних бібліотек .NET, а також до (рідних) бібліотек WinRT, деякі з яких - особливо Windows.UI- дуже схожі на Silverlight, що відповідає API. У вас все ще є XAML для визначення вашого інтерфейсу, і ви все ще маєте справу з тими ж основними поняттями, що і в Silverlight - прив'язки даних, ресурсів, стилів, шаблонів тощо. У багатьох випадках можливо перенести додаток Silverlight просто за usingдопомогою нових просторів імен, і налаштувати декілька місць у коді, де налаштовано API.

Сам WinRT не має нічого спільного з HTML та CSS, і він має відношення до JavaScript лише в тому сенсі, що він також там відкритий, як і для .NET. Вам не потрібно мати справу з HTML / CSS / JS, коли ви використовуєте бібліотеки інтерфейсу WinRT UI у вашому додатку .NET Metro (ну, мабуть, якщо ви дійсно хочете, ви можете розмістити WebViewконтроль ...). Усі ваші навички .NET і Silverlight залишаються дуже актуальними в цій моделі програмування.


А як щодо сумісності WPF-WinRT? Чи будуть подібні невідповідності WPF-Silverlight?
День

5
@Den WPF не є хорошою базовою точкою порівняння тут - API набагато, набагато ближче до Silverlight. Якщо ви дивитесь на це таким чином, між ними є невідповідність, але масштаб ближче до робочого столу проти WP7 Silverlight, а не Silverlight проти WPF.
Павло Мінаєв

11
Чудова відповідь. Чи має доступ WinRT до ядра NT безпосередньо (коли йому потрібна підтримка ОС) чи він проходить через Win32?
Тиморес


66

З основного коментаря Build :

Основний стек

Вони надають загальні API як для програм HTML / CSS / JavaScript, так і для програм C # / XAML. C # і XAML будуть використовуватися, але це не буде точно WPF або Silverlight.


8
Це дещо більше, оскільки нова XAML-річ доступна як для C #, так і для (рідного) C ++. Це ні WPF, ні Silverlight, але дуже близький до останнього - як це було показано в основній записці, ви часто можете піти, просто замінивши купу вставки та інші подібні банальні рефактори в існуючому коді Silverlight. Основні ідеї WPF / Silverlight - декларативна розмітка, ресурси, стилі, шаблони, прив'язка даних тощо - є всіма. Більшість елементів контролю також є.
Павло Мінаєв

2
Там є краща графіка, яку я бачив сьогодні вранці, але я просто не можу її знову знайти. EDIT: Знайдено, завдяки іншій відповіді на це питання. dougseven.files.wordpress.com/2011/09/win8-new-platform.png
Chris Charabaruk

1
Де WPF поміщається на слайді?
папараццо

1
Він згрупований разом із .NET / Silverlight в нижньому правому куті.
BoltClock

1
Ця картина є абсолютно неправильною, що стосується існуючих творів. Ви можете майже виправити це, замінивши "Сервіси ядра Windows" на "Win32 kernel32.dll" та "Win32" на "Win32 user32.dll + gdi32.dll" ... але IE та .NET / Silverlight слід шарувати в основному зверху користувача user32.dll + gdi32.dll, а також C / C ++ / Java / Delphi / і т.д. також сягають до kernel32.dll. Важливо те, що user32.dll і gdi32.dll НЕ лежать в основі WinRT, і що додатки Windows Store не можуть досягти минулого WinRT прямо на всю потужність kernel32.dll.
Бен Войгт

37

Ключова ідея полягає в тому, що зараз є дві доріжки розвитку - Desktop та Metro.

  • На робочому столі живуть старі програми.
  • Новий клас додатків, програми Metro, можна будувати різними способами, в тому числі за допомогою VB.NET, C # або C ++. Ці три мовні параметри можуть використовувати XAML для побудови інтерфейсу. Альтернативою є використання JavaScript / HTML5 / CSS для розробки як інтерфейсу, так і коду програми.

Деякі важливі моменти:

  • Windows 8 відчуває себе схожим на розширену ОС мобільного телефону.
  • У Metro немає перекриваються вікон верхнього рівня, так само як їх немає на мобільному телефоні. Якщо ви хочете застосувати стиль MDI, вам потрібно залишитися на робочому столі.
  • Додатки в стилі метро автоматично призупиняються, коли їх не видно. Це було зроблено для продовження терміну служби акумулятора. Це означає, що для багатьох існуючих додатків для настільних ПК, які виконують обробку фону, навіть якщо користувач не взаємодіє з ними, не буде сенсу переноситися в Metro.
  • Версія ARM Windows 8 не підтримує настільні програми. Отже, якщо ви хочете написати додаток, і ви хочете, щоб він працював у будь-якій версії Windows, тоді це повинен бути додаток Metro.

2
У метро немає перекриття вікон верхнього рівня . Є ще Popup( msdn.microsoft.com/en-us/library/windows/apps/… ), тому, якщо хочете, ви можете приготувати щось подібне до MDI. Очевидно, не рекомендується зловживати ним, оскільки ви ризикуєте покінчити з інтерфейсом, не сприйнятим дотиком.
Павло Мінаєв

@Pavel - це цікаво - чи це означає, що ви можете мати кілька вікон верхнього рівня, які працюють поруч, але не перетинаються? напр., кахельна плитка ... спільний використання половини екрана, наприклад? Додаток WPF, над яким я зараз працюю, потребує такого функціоналу.
dodgy_coder

3
Кожна програма Metro має лише одне вікно верхнього рівня. У вас можуть бути два програми Metro, які працюють поруч, але це те, що вирішує користувач - додатки не можуть примусити себе в цій конфігурації. Крім того, навіть якщо у вас є два програми, які працюють поруч, вони не можуть спілкуватися для координації (за винятком явних жестів користувачів, таких як "Поділитися").
Павло Мінаєв

1
З іншого боку, ви, звичайно, можете розділити власне єдине вікно верхнього рівня на стільки областей, скільки вам потрібно, і надати рухомий роздільник, щоб змінити їх розмір - який, з точки зору користувача, виглядатиме як два кахельні вікна верхнього рівня . Хоча вони все ще відображатимуться як єдине, що відбувається в програмі переключення програм (але тоді ви, мабуть, цього хочете?).
Павло Мінаєв

3
За словами Мартіна Ловелла, для цього немає жодного навмисного механізму, і деякі, які могли б бути використані для цього, навмисно обмежені. Наприклад, іменованих труб немає, наприклад, файлів із картографічною пам'яттю. Є розетки (включаючи серверні розетки), але під час підключення до них localhostможна підключитися лише до тієї самої програми. Ви можете використовувати звичайні файли в одній із спільно використовуваних "відомих папок" (Документи, Зображення тощо), але це досить груба хакерська робота, яка потребує опитування та є видимою для користувача.
Павло Мінаєв

24

Існує модифікована версія архітектури, яка точно допоможе вам зрозуміти, де саме лежать речі. Один з ніндзя Telerik поспілкувався з командою CLR та змінив зображення:

Платформа та інструменти Windows 8 (включаючи CLR)

Тут ви можете побачити, де стоїть CLR. Тепер .NET Framework має два профілі

1- .NET Metro profile (CLR, який займається програмою Metro)

2- .NET клієнтський профіль (час виконання CLR для додатків C # і VB.NET)

Я сподіваюся, що це дає вам чіткішу картину. Прочитайте повну статтю в «Погана картина» - це тисяча довгих дискусій. .


17

Багато деталей від Microsoft тут .

Виконання програми Windows піддається впливу метаданих API (файли .winmd). Це той самий формат, який використовує рамка .NET (Ecma-335). Бінарний контракт, що лежить в основі, полегшує вам доступ до API API виконання Windows безпосередньо на розробленій вами мові розробки. Форму та структуру API Windows Runtime можна зрозуміти як статичними мовами, такими як C #, так і динамічними мовами, такими як JavaScript. IntelliSense доступний у JavaScript, C #, Visual Basic та C ++.

Коротше кажучи, Windows Runtime - це новий набір бібліотек, що розкривають функціональність Windows і доступні для JavaScript / C # / VB / C ++. Кожна мова була зрозуміла і змогла викликати їх безпосередньо, а не потрібно проходити через якийсь громозахисний шар.

Silverlight та WPF - це аромати XAML, які працюють на CLR. Серед інших функціональних можливостей Windows Runtime відкриває версію XAML, дуже схожу на Silverlight, але робить це по-рідному, а не через CLR. Доступ до нього можна отримати з CLR, але також і з C ++.


2
Можливо, присутній "громоподібний шар" - наприклад, CLR фактично використовує RCW - але зараз це детальна інформація про реалізацію. З точки зору розробника, ви безпосередньо посилаєтеся на WinRT .winmd файли та працюєте безпосередньо з типами всередині.
Павло Мінаєв

3
У той час як товстуючий шар використовує RCW, RCW для часу роботи Windows є легшими, ніж старі RCW з P / Invoke.
ReinstateMonica Ларрі Остерман
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.