Чтобы добавлять сообщения и комментарии, .

@OCTAGRAM:
OCTAGRAM

Что значит выпуск Юбилейного обновления Windows 10 для разработчиков

@OCTAGRAM:
OCTAGRAM

Bring your desktop app to the Universal Windows Platform
У Microsoft появилась новая платформа разработки приложений под названием Universal Windows Platform. В экспериментальном виде она была в Windows 8 под названием Metro, но скудные средства разработки и скандалы с неформальными техническими запретами третьим сторонам портировать компиляторы вменяемых языков программирования надолго отложили серьёзное применение этой платформы.
Сейчас, спустя 4 года, наконец в открытом доступе появились средства разработки, правда, чтобы они работали, требуется инсайдерская версия Windows 10, а такая сейчас может быть только у владельцев редакций Pro или Enterprise, но при некотором желании разрабатывать под UWP теперь всё же стало возможно. Остальным придётся подождать. Подождать, похоже, придётся в любом случае, ведь работать такие приложения тоже смогут только на версиях Windows 10 с необходимыми функциями.
Хоть я и был подписан на уведомления проекта Centennial, но Microsoft всё равно почему–то не сообщил, и вот я с задержкой примерно в месяц случайно узнаю о том, что бета выпущена.
Так как на приставках Xbox One могут быть запущены не только приложения, собранные левым, подходящим только для Xbox инструментарием Microsoft, но и приложения для UWP, и Microsoft настаивает именно на таком способе разработки игр, есть вероятность, что и на Xbox таким путём удастся попасть. Консольные приставки типа Xbox и PlayStation долгое время были тормозом на пути прогресса в игровой индустрии, так как выбрав из лучших побуждений язык реализации Ada, разработчик получал доступ только к Windows, Linux, Mac OS X и Android, но не к Xbox, PlayStation и iOS. Проект Centennial выбивает ножку из–под табуреточки под C++. Можно выпустить качественную игру под Windows, Linux, Mac OS X, Android, Xbox, SteamBox, и получается вполне себе неплохой набор платформ.

@OCTAGRAM:
OCTAGRAM

Project Centennial: Converting your Normal Windows App (Ada, Delphi, SOM) to a Metro Windows App for Distribution in the Windows Store
В Microsoft наконец зачесались, а чёй–то так мало приложений под Metro, наверное, средства разработки были трешовые, значит, надо дать возможность нормальными средствами разработки делать приложения для Metro

@OCTAGRAM:
OCTAGRAM

С появлением Windows Runtime казалось, что Microsoft таким образом переизобретает SOM ( например, в #2755103 ). В связи с тем, что в моём технопарке появился ещё одно устройство, на этот раз под управлением Windows 8.1, и я наконец могу пощупать это нечто, узнал поподробнее, и вынужден признать, что погорячился.

msdn.microsoft.com
A ref class that has a public constructor must be declared as sealed, to prevent further derivation.
msdn.microsoft.com
Another restriction is that any public classes or interfaces you expose can’t be generic
Polymorphism isn’t available to WinRT types, and the closest you can come is implementing WinRT interfaces; you must declare as sealed any classes that are publicly exposed by your Windows Runtime Component.

Таким образом, можно порадоваться, что Microsoft пытается в будущем сделать новое API, которое можно было бы применять из разных языков программирования (как, например, это позволяет BridgeSupport), и которое не было бы при этом жёстко завязано на .NET с его сборкой мусора и разной утяжеляющей белибердой. В будущем — потому что по факту полноценно писать WinRT приложения при помощи компиляторов сторонних разработчиков до сих пор невозможно. Со времён Delphi XE3 ( #2058651 ) я пока не увидел, чтобы что–то изменилось в этом направлении.

Таким образом, Windows Runtime — это продолжение COM, переизобретение BridgeSupport, но никак не SOM. WinRT и SOM, наверное, могли бы дополнять друг друга. Хочешь использовать классы как клиент — можно обращаться через Windows Runtime или COM. А хочешь отнаследовать — это только через SOM.

@k0st1x:
k0st1x

между тем, ms сертифицировало говноприложение, сделанное моими культями, для Windows Store
apps.microsoft.com
функционал — говно. просто проба пера — как это оно — написать приложение и затолкнуть к жерло стора.
кстати, приблуда прошла не с первого раза; самое сложное для меня было не написать функционал/код, а написать правильный privacy policy, который все никак не давал пройти проверку (((

@k0st1x:
k0st1x

Microsoft активировали поддержку Flash в IE10 (тот, что Metro) для W8/RTvia twitter.com

@OCTAGRAM:
OCTAGRAM

docwiki.embarcadero.com

Вот чем мне нравится само существование Embarcadero, так это тем, что они как зеркало отражают говнистость того, что делается в Microsoft'е. То, есть, если у Microsoft всё снаружи красиво, распиарено, то опыт сторонних разработчиков высвечивает всё как есть. WinRT в теории классный, но под него сейчас нельзя делать приложения сторонними компиляторами — и вот результат, для отображения Live Tiles Embarcadero делает отдельное специальное приложение–прокси, сделанное так, как требуется Microsoft, плюс теневой сервис, и через всё это становится возможной работа нормальных, написанных не на выбранных неизменно дурным вкусом Microsoft языках, приложений. Мне, конечно, хочется всё то же для Ады, но Delphi тут как первопроходец, собирает все грабли, чтоб остальным легче идти было.

@OCTAGRAM:
OCTAGRAM

octagram.name

В качестве летней практики накатал сравнение объектных систем (см. теги)

@OCTAGRAM:
OCTAGRAM

forums.embarcadero.com

Почему нельзя делать WinRT приложения для MS app store кроме как на говноязыках:

You know, little things like RtlUnwind for exception processing and VirtualAlloc (et. al.) for memory management... Any calls to those APIs from your application will automatically disqualify your application from being an "official" WinRT application capable of delivering through the MS app store.

Right now the VC++ RTL DLL is given special dispensation since that is the library that makes the calls to those forbidden APIs and not directly from the user's app.

@lovesan:
lovesan

А вообще — WinRT это практически тот же старый добрый(или злой, кому как) COM, подсахаренный в парочке мест, местами переименованный, а где надо — урезанный.

@lovesan:
lovesan

Блядь, ну не знаю. Это всё дело заебись выглядит под планшеты и мобильники, но блядь, под десктопы и ноуты — пиздец.

@lovesan:
lovesan

Что-то мне кажется, что с WinRT MS катит винду, и катится сам, в какую-то глубокую задницу.

@OCTAGRAM:
OCTAGRAM

thomgerdes.com

Один из немногочисленных пока обзоров Windows Runtime.

The first thing I noticed is that Windows is doing a lot to break the API down into Namespaces, and for the most part each metadata file describes one namespace. So my first reaction was to put the contents of each metadata file into one Delphi unit. This doesn't quite work though because of a few things: One metadata file may actually contain multiple namespaces, one namespace might be included in several metadata files, and there are circular dependancies between types in the various metadata files.
Не ожидал такого дерьма от Microsoft. Это же из C++, это должно быть похоронено, алё? Один файл – один модуль, имена одинаковые. Что опять за творчество восьмидесятых?

Generic Interfaces
Generics are used pretty heavily throughout WinRT. In the C++ language bindings, they end up translating down to a template class, and the pre-compiled headers actually have to parametrize every instance of a generic class. This is pretty ugly and it'd be much nicer to just declare the interface and have the compiler do the right thing. Delphi has a similar problem for similar reasons. Generic Interfaces are supported by the compiler, but the problem arises in that you cannot specify a GUID for parametrized instances of a given generic interface. So for now, I've had to create a unique interface for every parameterized interface in WinRT.

А вот про Generics в API не знал. Здесь WinRT лучше, чем IBM SOM. Однако,

But how do you go about assigning a GUID to the interfaces? The answer lies in RoGetParameterizedTypeInstanceIID.
Функция эта доступна только в Windows 8, из–за этого нельзя компилировать с других OS. Кстати, не проверял, но, может быть, было бы достаточно унаследовать GUID–интерфейс от не–GUID–ного generic interface. Ну или оставить generic interface as is, а получать его через Supported(), а GUID вычислять на целевой платформе.

Впрочем, компилятор следующей версии Delphi наверняка изменится в такую сторону, что эти workaround станут не нужны. Что нравилось в Delphi, так это сращивание с компонентными технологиями Windows до такой степени, что использовать их из Delphi удобнее, чем из C++ и C# от Microsoft. Это же и её минус как плохо переносимого ЯП. Я раньше думал, это Borland додумался TDateTime сделать из Double. Ан нет, это из COM пошло. Ну хоть проблема 2000 не грозит на время существования Солнечной Системы.

Плохо, что WinRT доступен только в Win8. Потребуется лет восемь, чтобы на нём можно было писать для массового пользователя. Лучше бы, наоборот, в 2001м году вместо .NET был бы выпущен WinRT, входил бы в обновления OS и был бы доступен везде, а .NET, наоборот, был бы доступен не ранее какой–нибудь версии Windows.