В этом — весь UWP. Похоже, кроме как через Project Centennial, принципиально невозможно написать нормальное приложение для Магазина. Впрочем, с приложениями, которые были разработаны средствами PC, я большого опыта ещё не имел. Нельзя исключать, что и там талантливые инженеры придумали, как безнадёжно всё сломать.
В этом — весь UWP. Похоже, кроме как через Project Centennial, принципиально невозможно написать нормальное приложение для Магазина. Впрочем, с приложениями, которые были разработаны средствами PC, я большого опыта ещё не имел. Нельзя исключать, что и там талантливые инженеры придумали, как безнадёжно всё сломать.
а вы сидите дальше на своих неподдерживаемых андройдах
алсо, гугл тут показывает на своих сайтах плашку «попробуйте хроме!» с кнопками типа «да» и «нет». а кнопки «вы прикалываетесь?» нет.
Windows 10: From WinRT to Centennial with Marco Cantu; длительность 54 минуты
Ну вот, наконец, доклад по WinRT не от Microsoft, у которых, конечно, в их параллельной Вселенной всё без проблем, а как на самом деле, без мнения третьей стороны не понятно. Мне вообще наиболее интересна была бы связка Centennial+Islandwood, чтоб в вендор локе WinRT так уж сильно не увязнуть, но это с кондачка не поднять.
И да, то обновление, которое должно было быть в ноябре, не принесло поддержку Linux ARC, но поддержка Project Centennial там имеется, об этом и доклад. И это именно то, что сейчас можно скачать на шару.
Ну вот, наконец, доклад по WinRT не от Microsoft, у которых, конечно, в их параллельной Вселенной всё без проблем, а как на самом деле, без мнения третьей стороны не понятно. Мне вообще наиболее интересна была бы связка Centennial+Islandwood, чтоб в вендор локе WinRT так уж сильно не увязнуть, но это с кондачка не поднять.
И да, то обновление, которое должно было быть в ноябре, не принесло поддержку Linux ARC, но поддержка Project Centennial там имеется, об этом и доклад. И это именно то, что сейчас можно скачать на шару.
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, и получается вполне себе неплохой набор платформ.
У 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, и получается вполне себе неплохой набор платформ.
Project Centennial: Converting your Normal Windows App (Ada, Delphi, SOM) to a Metro Windows App for Distribution in the Windows Store
В Microsoft наконец зачесались, а чёй–то так мало приложений под Metro, наверное, средства разработки были трешовые, значит, надо дать возможность нормальными средствами разработки делать приложения для Metro
В Microsoft наконец зачесались, а чёй–то так мало приложений под Metro, наверное, средства разработки были трешовые, значит, надо дать возможность нормальными средствами разработки делать приложения для Metro
#2755103 ). В связи с тем, что в моём технопарке появился ещё одно устройство, на этот раз под управлением Windows 8.1, и я наконец могу пощупать это нечто, узнал поподробнее, и вынужден признать, что погорячился.
msdn.microsoft.com
msdn.microsoft.com
Таким образом, можно порадоваться, что Microsoft пытается в будущем сделать новое API, которое можно было бы применять из разных языков программирования (как, например, это позволяет BridgeSupport), и которое не было бы при этом жёстко завязано на .NET с его сборкой мусора и разной утяжеляющей белибердой. В будущем — потому что по факту полноценно писать WinRT приложения при помощи компиляторов сторонних разработчиков до сих пор невозможно. Со времён Delphi XE3 ( #2058651 ) я пока не увидел, чтобы что–то изменилось в этом направлении.
Таким образом, Windows Runtime — это продолжение COM, переизобретение BridgeSupport, но никак не SOM. WinRT и SOM, наверное, могли бы дополнять друг друга. Хочешь использовать классы как клиент — можно обращаться через Windows Runtime или COM. А хочешь отнаследовать — это только через SOM.
С появлением Windows Runtime казалось, что Microsoft таким образом переизобретает SOM ( например, в 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.
apps.microsoft.com
функционал — говно. просто проба пера — как это оно — написать приложение и затолкнуть к жерло стора.
кстати, приблуда прошла не с первого раза; самое сложное для меня было не написать функционал/код, а написать правильный privacy policy, который все никак не давал пройти проверку (((
Microsoft активировали поддержку Flash в IE10 (тот, что Metro) для W8/RTvia twitter.com
docwiki.embarcadero.com
Вот чем мне нравится само существование Embarcadero, так это тем, что они как зеркало отражают говнистость того, что делается в Microsoft'е. То, есть, если у Microsoft всё снаружи красиво, распиарено, то опыт сторонних разработчиков высвечивает всё как есть. WinRT в теории классный, но под него сейчас нельзя делать приложения сторонними компиляторами — и вот результат, для отображения Live Tiles Embarcadero делает отдельное специальное приложение–прокси, сделанное так, как требуется Microsoft, плюс теневой сервис, и через всё это становится возможной работа нормальных, написанных не на выбранных неизменно дурным вкусом Microsoft языках, приложений. Мне, конечно, хочется всё то же для Ады, но Delphi тут как первопроходец, собирает все грабли, чтоб остальным легче идти было.
Вот чем мне нравится само существование Embarcadero, так это тем, что они как зеркало отражают говнистость того, что делается в Microsoft'е. То, есть, если у Microsoft всё снаружи красиво, распиарено, то опыт сторонних разработчиков высвечивает всё как есть. WinRT в теории классный, но под него сейчас нельзя делать приложения сторонними компиляторами — и вот результат, для отображения Live Tiles Embarcadero делает отдельное специальное приложение–прокси, сделанное так, как требуется Microsoft, плюс теневой сервис, и через всё это становится возможной работа нормальных, написанных не на выбранных неизменно дурным вкусом Microsoft языках, приложений. Мне, конечно, хочется всё то же для Ады, но Delphi тут как первопроходец, собирает все грабли, чтоб остальным легче идти было.
forums.embarcadero.com
Почему нельзя делать WinRT приложения для MS app store кроме как на говноязыках:
Почему нельзя делать 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.
thomgerdes.com
Один из немногочисленных пока обзоров Windows Runtime.
Не ожидал такого дерьма от Microsoft. Это же из C++, это должно быть похоронено, алё? Один файл – один модуль, имена одинаковые. Что опять за творчество восьмидесятых?
А вот про Generics в API не знал. Здесь WinRT лучше, чем IBM SOM. Однако,
Функция эта доступна только в 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.
Один из немногочисленных пока обзоров 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.