Здравствуйте, Serginio1, Вы писали:

V>>Потому что ты вовсе не UWP имеешь ввиду во всей этой беседе, а банальный нейтивный WinRT.
V>>И мне уже порядком надоело продираться сквозь чащу твоей неточности и поверхностности, положа руку на.

S> Я говорил прежде всего о Xaml. То есть декларативном описании интерфейса.
S>А его используют WPF, UWP

Режет глаз такая безграмотность...
Я могу под UWP использовать WPF.


S>И главное можно разделить работу верстальщика и программиста.

Такие тулзы есть под большинство популярных GUI-библиотек.


S>В свое время на Xamarin можно было писать только код. Затем появился XAML. С XAML удобнее.

Если там нет компиляции шаблона в код, то тоже на помойку, ес-но.
Если есть, то респект.
Сможешь собрать простейший проект, залезть в него через dotPeek и посмотреть — что там реально происходит? Выполняется ли код построения сцены или интерпретируется XAML/BAML?


S>UWP не поддерживает Windows 8.1 и Windows Phone 8.1
S>Что такое Universal Windows Platform
S>

S>UWP стала результатом эволюции более ранних технологий. Так, с выходом Windows 8 была внедрена новая архитектурная платформа для приложений — Windows Runtime (WinRT), которая позволяла запускать приложения в так называемом режиме Modern (Metro) на десктопах, планшетах. Затем с выходом Windows 8.1 и Windows Phone 8.1 эта технология получила развитие — появились "универсальные приложения", которые можно было запускать сразу Windows 8.1 и WP8.1. И в июле 2015 года официально вышла новая ОС Windows 10. Она использует платформу UWP, которая представляет собой развитие Windows Runtime.

Это маркетинг. ))


S>Так, что посмотри наконец на себя. Оцени свои высказываия. У тебя много знаний, но они либо устаревшие, либо поверхностные.

Либо у меня перед глазами нейтивное SDK Windows 10 и там сплошное WinRT. ))


S>

S>Теперь сделаем простейшее приложение. Визуально приложение UWP представлено через страницы — отдельные объекты Page. По умолчанию в проекте есть только одна страница — MainPage. Код этой страницы и определяет то, что мы увидим на экране при запуске приложения. И теперь немного изменим ее.
S>Итак, откроем файл MainPage.xaml:

Вот, для хомячков. А на деле ты можешь разработать WinRT приложение вообще без страниц или на основе DirectX или даже OpenGL (тоже поддерживается в AppStore-приложухах).

====================
Кароч, попробую распутать это нагромождение легенд, слухов и мифов.

Параллельно с чтением можно открыть у себя папку:
C:\Program Files (x86)\Windows Kits\10\Include
И выбрать одно из SDK для Windows 10.
Если там в include содержатся только CRT-заголовки, то скачай себе Windows 10 SDK (выбрать галочку — устанавливать только само SDK).

А потом рядом открыть папку:
C:\Program Files (x86)\Windows Kits\8.1\Include

Натравить какой-нить инструмент сравнения папок и поржать.
Например, поржать с того, что всё WindowsRT-like API для 10-ки лежит в подпапке winrt, ес-но, как и в SDK от Windows 8.1.

=================
Итак, вернёмся в прошлое.
С каждой версией Windows добавлялось какое-нить новое АПИ, которых не было в предыдущих версиях.
Например, я писал нейтивную приложуху для WindowsXP, отрисовывал контролы с текущей темой, ОК.
Но мне надо было, чтобы прложуха работала так же и под Windows 2000.
Мои действия?
Я в рантайм определял версию Windows и, если она была WindowsXP или выше, загружал библиотеку отрисовки тем Windows XP, если ниже, то рисовал через стандартную прорисовку контролов из либы User32.

Позже, под Windows Vista, Windows 7, Windows 10 djn ctqxfc — это всё так же прекрасно работает, т.е. прекрасно работает еще та приложуха, которая обыгрывает ситуацию с Windows XP или ВЫШЕ, динамически подгружает библиотеку прорисовки и рисует согласно текущей темы.

Теперь рассмотрим приложения AppStore. Что это за приложения такие? — это приложения, для которых исходный Win32 API был урезан до подмножества только "безопасных" ф-ий. Ну и плюс к этому новое развитое АПИ WinRT.

Так вот, проблема в том, что ф-ия АПИ LoadLibrary недоступна в урезанном АПИ ОС для приложух из магазина. А значит, я не смогу загрузить динамически какую-нить DLL в зависимости от версии ОС, на которой исполняется моё приложение. Более того, теперь от версий Windows отказались, считай, есть только версия обновления, а номер 10 теперь навечно. ))

Но рано или поздно некие АПИ будут добавляться, верно?
Или в неких устройствах, наоборот, может присутствовать урезанная версия АПИ, верно?

Итого, требуется некая функциональность динамического определения наличия некоего АПИ и пользования этим АПИ.
Так вот, в 10-ку в АПИ WinRT добавили эту функциональность, см. файл winrt\windows.foundation.metadata.idl, в нем интерфейс IApiInformationStatics.

Разумеется, такую функциональность добавили сугубо в виде WinRT-АПИ, ы-ы-ы:

interface IApiInformationStatics : IInspectable
{
    HRESULT IsTypePresent([in] HSTRING typeName, [out] [retval] boolean* value);

   [overload("IsMethodPresent")] 
   HRESULT IsMethodPresent([in] HSTRING typeName, [in] HSTRING methodName, [out] [retval] boolean* value);
...

Вот прямо тут можно запрашивать наличие неких интерфейсов и наличие в них методов/св-в.

Такой подход они назвали "универсальным", отсюда новый маркетинговый мем UWP, опять и снова ы-ы-ы.

И да, ввиду того, что Windows 10 совместима сверху вниз, то приложения WinRT 8.0 и приложения WinRT 8.1 будут прекрасно работать в "обычной" WinRT 10.0. Точно так же, как под Windows 7 прекрасно работали приложения, писанные под Windows XP. Например, в Windows 10 обновились коды енумов ActivationKind, но имеющиеся ранее для Windows 8.1 так же прекрасно работают, ес-но.

Далее.
Почему я настаиваю на упоминании WPF vs WinRT вместо WPF vs UWP?
Да потому что я запросто могу создать UWP-приложение на основе WPF.
Это вносит путаницу.
Но у нас в обсуждении подразумевалась та разница, КАК именно реализован движок GUI — практически полностью в дотнете (WPF) или в виде тонкой обертки над нейтивным WinRT API, верно?

=============
Весьма надеюсь, что я достаточно разъяснил суть моих поправок...