Как Windows 8 Runtime (WinRT / приложения Магазина Windows / универсальное приложение Windows 10) сравнивается с Silverlight и WPF? [закрыто]

Я пытаюсь получить мою голову вокруг новой ОС Windows 8 Время воспроизведения , который используется для создания Metro - приложений в стиле. Я знаю, что вы можете использовать его с XAML, и он основан на .NET, так что C # и VB.NET можно использовать для написания приложений, но тогда, похоже, это как-то связано с HTML, CSS, DOM и JavaScript.

Может ли кто-нибудь объяснить, что это такое, в нескольких абзацах, в терминах, понятных программисту .NET UI? (Я упускаю что-то «ключевое», что необходимо, чтобы понять это.)

Мы все знаем, что WPF, Silverlight , Windows Forms и т. Д. Будут работать под Windows 8 (и Windows 10) хотя бы на системах Intel, поэтому, пожалуйста, не говорите мне об этом ...

На самом низком уровне 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 \» в Developer Preview. Если вы поэкспериментируете, то увидите, что это на самом деле сборки CLI без кода, а только таблицы метаданных. Вы можете открыть их с ILDASM, на самом деле. Обратите внимание, это не означает, что WinRT управляется сам - он просто повторно использует формат файла.

Затем существует ряд библиотек, реализованных в рамках этой объектной модели - определение интерфейсов и классов WinRT. Снова, посмотрите на папку Windows Metadata, упомянутую выше, чтобы увидеть, что там; или просто запустите Object Browser в 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; То же самое Windows.UI.Xaml.Documentsи т. д.

Теперь .NET имеет возможность напрямую ссылаться на компоненты WinRT, как если бы они были сборками .NET. Это работает иначе, чем COM Interop - вам не нужны какие-либо промежуточные артефакты, такие как сборки взаимодействия, вы просто /rфайл .winmd, и все типы и их члены в его метаданных становятся видимыми вам, как если бы они были объектами .NET. Обратите внимание, что библиотеки WinRT сами по себе являются полностью нативными (и поэтому нативным программам на C ++, использующим WinRT, вообще не требуется CLR) - магия для раскрытия всего, что управляется, находится внутри самой CLR и является довольно низким уровнем. Если вы ildasm .NET-программы, которая ссылается на .winmd, вы увидите, что на самом деле она выглядит как внешняя ссылка на сборку - здесь нет хитрости в ручном обмане, таком как встраивание типов.

Это также не тупое отображение - CLR пытается адаптировать типы WinRT к их эквивалентам, где это возможно. Так, например, GUID, даты и 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 остаются очень важными в этой модели программирования.

Из основного лота Build :

Они предоставляют общие API для приложений HTML / CSS / JavaScript и приложений C # / XAML. Будут использоваться C # и XAML, но это не будет точно WPF или Silverlight.

Ключевая идея заключается в том, что сейчас есть два пути разработки - Desktop и Metro.

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

Некоторые важные моменты:

• Windows 8 выглядит как расширенная ОС для мобильных телефонов.
• В Metro нет перекрывающихся окон верхнего уровня, как и на мобильном телефоне. Если вы хотите приложение в стиле MDI, вам нужно оставаться на рабочем столе.
• Приложения в стиле Metro автоматически приостанавливаются, когда их не видно. Это было сделано для продления срока службы батареи. Это означает, что для многих существующих настольных приложений, которые выполняют фоновую обработку, даже если пользователь не взаимодействует с ними, перенос в Metro невозможен.
• ARM-версия Windows 8 не будет поддерживать настольные приложения. Так что, если вы хотите написать приложение и хотите, чтобы оно работало на любой версии Windows, тогда это должно быть приложение Metro.

Есть модифицированная версия архитектуры, которая, несомненно, поможет вам понять, где именно находятся вещи. Один из ниндзя Telerik поболтал с командой CLR и изменил картинку:

Здесь вы можете увидеть, где стоит CLR. .NET Framework теперь имеет два профиля

1- .NET Metro профиль (CLR, который имеет дело с приложением Metro)

2- Профиль клиента .NET (среда выполнения CLR для приложений на C # и VB.NET)

Я надеюсь, что это дает вам более четкую картину. Прочитайте статью полностью в Плохая картина стоит тысячи долгих обсуждений. ,

Много подробностей от Microsoft здесь .

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

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

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