Мы все очень ждали презентации Windows 11, но как-то нам ее подпортили. Незадолго до презентации слили рабочий билд и поэтому во время ивента ничего по-настоящему нового мы не увидели. Кроме одной вещи: Android-приложения на винде!
Вот это было действительно неожиданно. И мы даже успели немного порадоваться, но потом сразу возникли вопросы. А зачем это нужно и как это вообще будет работать?
Ведь не так давно Microsoft сильно облажались со своей Windows на архитектуре ARM, в которой очень плохо работали x86-приложения. А если у них ничего не получилось тогда, то по какой причине получится сделать фактически тоже самое сейчас, но только наоборот?
Разбираясь в этих вопросах мы буквально прозрели. И поняли, что на самом деле у Microsoft очень далеко идущие планы.
Поэтому сегодня мы узнаем как работает Rosetta от Microsoft, а заодно разберемся, чем эмулятор отличается от транслятора? Узнаем, как Windows стал на Линуксом? И поразмышляем о том, как Microsoft планируют завоевать мир?
Начнем с небольшой теоретической части. Программы общаются с процессором при помощи определенного набора инструкций. И для каждой архитектуры этот набор инструкций разный. Поэтому для того, чтобы запустить приложение, написанное под архитектуру ARM на процессоре Intel с архитектурой x86 надо как-то пояснить процессору, что от него хочет чужеродная программа.
Сделать это можно разными способами. И один из самых распространённых — эмуляция.
Например, эмуляторов Android под Windows есть огромное множество. Но в чём же тогда проблема и зачем придумывать что-то еще?
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/2c8/1a7/b12/2c81a7b122dc16263ad4b936e54f2a78.png)
Дело в том, что эмуляторы — неэффективны. По большому счету, эмулятор — это программа, которая прикидывается железом. То есть эмулятор — это софт, который пытается имитировать аппаратную часть платформы.
Программа, засунутая в эмулятор, даже «не понимает», что сейчас она находится в чужеродной среде. Она как Нео внутри «Матрицы». Вроде вокруг реальный мир, но иногда закрадываются сомнения. Потому что-то там подлагивает, подглючивает, ложки гнутся. Ну вы понимаете. А происходит это потому, что эмуляция несёт огромные накладные расходы.
Представьте, чтобы софт 100% правильно работал вам нужно эмулировать целый процессор и поэтому эмуляторы работают медленно.
И ладно, если речь идет про какую-нибудь простенькую восьмибитную консоль типа Dendy. Такие эмуляторы не смотря на тотальную неэффективность, будут работать быстро даже на смартфоне времен Windows Mobile. Но вот эмулировать какой-нибудь процессор Intel куда сложнее.
Отсюда и тормоза в Windows на ARM. Ведь Microsoft использовал именно эмулятор для запуска x86-приложений. Кстати, эмулятор назывался WOW64, но получилось совсем не WOW, как вы знаете.
Более того, до сих пор в Windows на ARM не поддерживается эмуляция 64-битных приложений, только 32-битных, то есть именно x86, а не x64, что еще сильнее усугубляет ситуацию. Но этому есть объяснение.
Эмулятор WOW64 изначально был придуман для запуска 32-битных приложений на 64-битной Windows, то есть под важную задачу Microsoft даже эмулятор новый не сделали, а скорее всего просто модифицировали старый.
Но в прошлом году Microsoft обещали, что поддержка 64-битных приложений появится, и очень скоро. И возможно она будет реализована совсем по-другому.
Как, спросите вы? Давайте для примера вспомним как это сделал Apple при переходе с процессоров Intel на свои собственные чипы на архитектуре ARM. При помощи невероятной штуки под названием Rosetta 2.
Ведь там на ARM'е каким-то чудесным образом запускаются x86-приложения практически без потери производительности.
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/2d8/533/466/2d85334661374f66ebdd10d8fd8d7fa3.jpg)
Что такое Rosetta 2? По научному, — это двоичный транслятор, то есть переводчик. Rosetta просто переводит набор инструкций одной архитектуры в другую и всё.
Но чем же это лучше эмуляции? Дело в том, что эмуляция всегда происходит в реальном времени. А Rosetta переводит приложение заранее во время его установки или при первом запуске.
Поэтому когда пользователь открывает приложения он уже работает с нативным кодом, который исполняется без каких-либо дополнительных издержек. И в итоге все работает почти также быстро, как на родном железе!
Но, естественно, всё не так радужно! Иначе никто бы не собирал разные версии приложений под разные архитектуры. У трансляторов есть серьёзные недостатки.
Во-первых, перевести весь исходный код, исполняемый для целевой архитектуры — это весьма непростая задача, а в большинстве случаев просто невозможная. Некоторые части исполняемого кода доступны лишь во время использования приложения. Поэтому такие части транслируются динамически, «прямо на лету».
И этот процесс называется Just In Time компиляцией. Или JIT-компиляцией.
Естественно, это накладный процесс, но даже его можно оптимизировать. Результирующую последовательность динамического кода можно кешировать. А к фрагментам кода можно применить агрессивную оптимизацию. Поэтому в некоторых случаях, переведенный под другую архитектуру, но при этом оптимизированный код может выполняться даже быстрее оригинального.
И этот эффект я сам постоянно наблюдаю на новых Mac. Например, неадаптированный Блендер, через Rosetta работал быстрее, чем нативно на моем MacBook Pro 16. Но и за это приходится платить. Как думаете чем? Вашим SSD-диском. Переведенный код занимает много места, а динамическое кэширование изнашивает ресурс SSD. В особенности, такой эффект наблюдается на тяжеловесных программах, которые еще не пересобрали под ARM. Поэтому, приходится выбирать либо быстрая работа, либо долгоживущий SSD.
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/09c/832/3dc/09c8323dc0b966a2ae0c0637a674e3e6.jpg)
Но почему мы так долго говорим про Apple, если мы тут Windows 11 обсуждаем?
Дело в том, что для запуска Android-приложений в новой Windows, Microsoft решили сделать, примерно тоже самое, что сделали купертиновцы.
Вместе с Intel они разработали технологию Intel Bridge, которую они сами называют пост-компилятор. Но, по сути, это такой же двоичный транслятор.
Microsoft описывает эту технологию так:
«Создается нативное прокси-приложение которое, выступает мостиком между моделью приложения Android и моделью Windows приложения».
Иными словами, как и с Rosetta. Приложение будет переведено в нативный код еще на этапе установки. А недоступные фрагменты будут транслироваться на лету.
А с учетом того, что Android-приложения в своей массе достаточно простые почти не возникает сомнений, что с переводом будет всё в порядке.
В случае Windows, трансляция кода с x86 на ARM — это не основная сложность. Ведь тут еще и несовместимость на уровне ОС.
Android и Windows — это совершенно разные системы. Android основан на модифицированном ядре Linux, а в будущем планирует перейти на чистое ядро Linux. А Windows — это просто Windows. С Linux у Windows нет ничего общего. Так каким же образом тогда будут запускаться Android-приложения?
И вот тут неожиданный момент. Оказывается, еще в 2016 году Microsoft представили подсистему Windows для Linux, Windows Subsystem for Linux или WSL - Windows subsystem for Linux.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/9c6/2ba/9b1/9c62ba9b1b06fe44494645a460527b4e.png)
Это была специальная подсистема которая позволяла запускать Linux приложения в среде Windows. Система работала хорошо, но медленно, так как она работала поверх ядра Windows NT.
Запросы системы Linux переводились в запросы, понятные ядру Windows, и только потом отправлялись дальше. Это было долго.
Но в 2019 году анонсировали вторую версию подсистемы WSL 2, в которой ядро Linux работает параллельно ядру Windows, что ускорило работу системы в двадцать раз и фактически сделало Windows наполовину Linux.
g
То есть вы правильно поняли, WSL работает и на Windows 10, просто её нужно ставить отдельно. А вот в Windows 11 подсистема Linux будут встроена из коробки.
Как понимаете, наличие полноценного рабочего ядра Linux позволило Microsoft добиться максимальной совместимости с Android-приложениями.
По описанию Microsoft Android-приложения будут вести себя также как и обычные приложения Windows и этому можно верить:
Да и вообще Android нынче уходит от классических APK и переходит на AAB, но в эту тему мы сейчас не будем углубляться.
Тем не менее, к реализации Android-приложений на Windows остаются вопросы.
Во-первых, что будет с поддержкой Google Play Сервисов? Скорее всего её не будет. Поэтому многие приложения, будут работать неполноценно, либо не будут работать вовсе.
И второй вопрос. А зачем это вообще всё надо? Ведь мобильными приложением на компе пользоваться просто не удобно.
Допустим, на MacBook я могу поставить массу приложений с iOS, но делать этого не хочется. Да на многих Windows-ноутбуках сенсорные экраны, но все равно.
Тогда зачем была проделана вся эта огромная работа по интеграции Linux в Windows, созданию транслятора Intel Bridge, доработки всей этой штуки под Android-приложения?
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/020/95a/2d7/02095a2d7a908153746f0fcafad15b62.jpg)
И тут мы готовы высказать смелое предположение. Нам кажется, что поддержка Android приложений это один из этапов полного отказа от ядра Windows NT и перехода на ядро Linux.
Да, это звучит дико. Но во-первых, не мы одни так думаем. Раньше такую же мысль высказал уважаемый человек, евангелист Open Source Эрик Реймонд.
Смотри сами как всё логично:
В мире почти все ОС основаны либо на Unix (как Mac OS) или Linux (Ubuntu, Android и прочее) и только Windows одна такая особенная сидит на своём ядре Windows NT, с которым куча проблем.
Во-первых, его нужно развивать на, что уходит много денег. А Linux-ядро бесплатное.
Во-вторых, в самом ядре куча уязвимостей, которые постоянно нужно прикрывать заплатками.
В-третьих, у Windows ничего не получилось в мобильном сегменте.
В-четвертых, Microsoft уже потратили много лет и ресурсов на создание подсистемы Linux под Windows.
Поэтому переход на ядро Linux вполне логичный шаг. Смотрите, как это может выглядеть:
Сначала мы все переходим на Windows 11 на архитектуре x86. И потихоньку привыкаем, что на Windows нормально работают Android-приложения.
Параллельно, благодаря стараниям Apple, все пилят софт под ARM архитектуру, отчего выигрывает и Microsoft. Поэтому мы потихоньку начинаем переходить на ARM Windows. На которой Android-приложения чувствует себя вообще как родные.
Постепенно Linux ядро становится основной средой, а Windows второстепенной.
А потом ядро Windows NT выпиливается, и Windows становится графической оболочкой для Linux. Ну а на ядре Windows NT остаются работать только серверы и различное оборудование, где наследие старой Windows никак не искоренить.
Это, конечно самый смелый сценарий. Тем не менее, он вполне возможен.
Но даже если этого не произойдёт. В любом случае поддержка Android-приложений — это очень интересный ход. И для Windows на ARM он точно будет полезен, вспоминая планшеты например!
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/8a0/87a/5c2/8a087a5c2aaf35597e5d94a2f16dfe2a.png)
Ну и напоследок про сам Windows 11. Мы немного поигрались с новой Windows и у нас сложилось двоякое отношение.
С одной стороны, Windows 11 — это просто «десятка» с новой графической оболочкой. И это немного разочаровывает. Ведь если откинуть ядро Linux, которое теперь будет идти из коробки. Кроме дизайна под капотом не так многое поменялось, зато с совместимостью драйверов вроде проблем нет. Более того, до старого интерфейса, по-прежнему, очень легко добраться.
Тем не менее новый интерфейс действительно симпатичный и понятный.
В нем множество крутых фич как с меню «Пуск», так и с окнами. Привыкаешь к нему буквально за 10 минут. После чего возвращаться к старому скину совершенно не хочется. Еще раз — получилось красиво и удобно! А значит переход на новую Windows пройдет безболезненно и пользователи в целом останутся довольны. А это уже победа…
А там еще можно вспомнить про новый магазин без комиссии для разработчиков с блэкджеком. Но это уже совсем другая история и другие планы Microsoft по завоеванию мира магазинов приложений и ответ лаунчерам.
Вот это было действительно неожиданно. И мы даже успели немного порадоваться, но потом сразу возникли вопросы. А зачем это нужно и как это вообще будет работать?
Ведь не так давно Microsoft сильно облажались со своей Windows на архитектуре ARM, в которой очень плохо работали x86-приложения. А если у них ничего не получилось тогда, то по какой причине получится сделать фактически тоже самое сейчас, но только наоборот?
Разбираясь в этих вопросах мы буквально прозрели. И поняли, что на самом деле у Microsoft очень далеко идущие планы.
Поэтому сегодня мы узнаем как работает Rosetta от Microsoft, а заодно разберемся, чем эмулятор отличается от транслятора? Узнаем, как Windows стал на Линуксом? И поразмышляем о том, как Microsoft планируют завоевать мир?
Эмуляторы
Начнем с небольшой теоретической части. Программы общаются с процессором при помощи определенного набора инструкций. И для каждой архитектуры этот набор инструкций разный. Поэтому для того, чтобы запустить приложение, написанное под архитектуру ARM на процессоре Intel с архитектурой x86 надо как-то пояснить процессору, что от него хочет чужеродная программа.
Сделать это можно разными способами. И один из самых распространённых — эмуляция.
Например, эмуляторов Android под Windows есть огромное множество. Но в чём же тогда проблема и зачем придумывать что-то еще?
![](https://habrastorage.org/getpro/habr/post_images/2c8/1a7/b12/2c81a7b122dc16263ad4b936e54f2a78.png)
Дело в том, что эмуляторы — неэффективны. По большому счету, эмулятор — это программа, которая прикидывается железом. То есть эмулятор — это софт, который пытается имитировать аппаратную часть платформы.
Программа, засунутая в эмулятор, даже «не понимает», что сейчас она находится в чужеродной среде. Она как Нео внутри «Матрицы». Вроде вокруг реальный мир, но иногда закрадываются сомнения. Потому что-то там подлагивает, подглючивает, ложки гнутся. Ну вы понимаете. А происходит это потому, что эмуляция несёт огромные накладные расходы.
Представьте, чтобы софт 100% правильно работал вам нужно эмулировать целый процессор и поэтому эмуляторы работают медленно.
И ладно, если речь идет про какую-нибудь простенькую восьмибитную консоль типа Dendy. Такие эмуляторы не смотря на тотальную неэффективность, будут работать быстро даже на смартфоне времен Windows Mobile. Но вот эмулировать какой-нибудь процессор Intel куда сложнее.
Отсюда и тормоза в Windows на ARM. Ведь Microsoft использовал именно эмулятор для запуска x86-приложений. Кстати, эмулятор назывался WOW64, но получилось совсем не WOW, как вы знаете.
Более того, до сих пор в Windows на ARM не поддерживается эмуляция 64-битных приложений, только 32-битных, то есть именно x86, а не x64, что еще сильнее усугубляет ситуацию. Но этому есть объяснение.
Эмулятор WOW64 изначально был придуман для запуска 32-битных приложений на 64-битной Windows, то есть под важную задачу Microsoft даже эмулятор новый не сделали, а скорее всего просто модифицировали старый.
Но в прошлом году Microsoft обещали, что поддержка 64-битных приложений появится, и очень скоро. И возможно она будет реализована совсем по-другому.
Как, спросите вы? Давайте для примера вспомним как это сделал Apple при переходе с процессоров Intel на свои собственные чипы на архитектуре ARM. При помощи невероятной штуки под названием Rosetta 2.
Ведь там на ARM'е каким-то чудесным образом запускаются x86-приложения практически без потери производительности.
Транслятор
![](https://habrastorage.org/getpro/habr/post_images/2d8/533/466/2d85334661374f66ebdd10d8fd8d7fa3.jpg)
Что такое Rosetta 2? По научному, — это двоичный транслятор, то есть переводчик. Rosetta просто переводит набор инструкций одной архитектуры в другую и всё.
Но чем же это лучше эмуляции? Дело в том, что эмуляция всегда происходит в реальном времени. А Rosetta переводит приложение заранее во время его установки или при первом запуске.
Поэтому когда пользователь открывает приложения он уже работает с нативным кодом, который исполняется без каких-либо дополнительных издержек. И в итоге все работает почти также быстро, как на родном железе!
Но, естественно, всё не так радужно! Иначе никто бы не собирал разные версии приложений под разные архитектуры. У трансляторов есть серьёзные недостатки.
Во-первых, перевести весь исходный код, исполняемый для целевой архитектуры — это весьма непростая задача, а в большинстве случаев просто невозможная. Некоторые части исполняемого кода доступны лишь во время использования приложения. Поэтому такие части транслируются динамически, «прямо на лету».
И этот процесс называется Just In Time компиляцией. Или JIT-компиляцией.
Естественно, это накладный процесс, но даже его можно оптимизировать. Результирующую последовательность динамического кода можно кешировать. А к фрагментам кода можно применить агрессивную оптимизацию. Поэтому в некоторых случаях, переведенный под другую архитектуру, но при этом оптимизированный код может выполняться даже быстрее оригинального.
И этот эффект я сам постоянно наблюдаю на новых Mac. Например, неадаптированный Блендер, через Rosetta работал быстрее, чем нативно на моем MacBook Pro 16. Но и за это приходится платить. Как думаете чем? Вашим SSD-диском. Переведенный код занимает много места, а динамическое кэширование изнашивает ресурс SSD. В особенности, такой эффект наблюдается на тяжеловесных программах, которые еще не пересобрали под ARM. Поэтому, приходится выбирать либо быстрая работа, либо долгоживущий SSD.
Intel Bridge
![](https://habrastorage.org/getpro/habr/post_images/09c/832/3dc/09c8323dc0b966a2ae0c0637a674e3e6.jpg)
Но почему мы так долго говорим про Apple, если мы тут Windows 11 обсуждаем?
Дело в том, что для запуска Android-приложений в новой Windows, Microsoft решили сделать, примерно тоже самое, что сделали купертиновцы.
Вместе с Intel они разработали технологию Intel Bridge, которую они сами называют пост-компилятор. Но, по сути, это такой же двоичный транслятор.
Microsoft описывает эту технологию так:
«Создается нативное прокси-приложение которое, выступает мостиком между моделью приложения Android и моделью Windows приложения».
Иными словами, как и с Rosetta. Приложение будет переведено в нативный код еще на этапе установки. А недоступные фрагменты будут транслироваться на лету.
А с учетом того, что Android-приложения в своей массе достаточно простые почти не возникает сомнений, что с переводом будет всё в порядке.
WSL
В случае Windows, трансляция кода с x86 на ARM — это не основная сложность. Ведь тут еще и несовместимость на уровне ОС.
Android и Windows — это совершенно разные системы. Android основан на модифицированном ядре Linux, а в будущем планирует перейти на чистое ядро Linux. А Windows — это просто Windows. С Linux у Windows нет ничего общего. Так каким же образом тогда будут запускаться Android-приложения?
И вот тут неожиданный момент. Оказывается, еще в 2016 году Microsoft представили подсистему Windows для Linux, Windows Subsystem for Linux или WSL - Windows subsystem for Linux.
![](https://habrastorage.org/getpro/habr/post_images/9c6/2ba/9b1/9c62ba9b1b06fe44494645a460527b4e.png)
Это была специальная подсистема которая позволяла запускать Linux приложения в среде Windows. Система работала хорошо, но медленно, так как она работала поверх ядра Windows NT.
Запросы системы Linux переводились в запросы, понятные ядру Windows, и только потом отправлялись дальше. Это было долго.
Но в 2019 году анонсировали вторую версию подсистемы WSL 2, в которой ядро Linux работает параллельно ядру Windows, что ускорило работу системы в двадцать раз и фактически сделало Windows наполовину Linux.
![](https://habrastorage.org/getpro/habr/post_images/347/636/ef4/347636ef407f94581cf2b2c5b7d4d9bd.png)
То есть вы правильно поняли, WSL работает и на Windows 10, просто её нужно ставить отдельно. А вот в Windows 11 подсистема Linux будут встроена из коробки.
Как понимаете, наличие полноценного рабочего ядра Linux позволило Microsoft добиться максимальной совместимости с Android-приложениями.
По описанию Microsoft Android-приложения будут вести себя также как и обычные приложения Windows и этому можно верить:
- Они будут открываться в отдельном окне
- Можно будет закрепить приложение на панели задач
- Будет полноценная поддержка: клавиатуры, мыши, тача и даже Bluetooth-наушников.
- Более того — можно будет перекидываться файлами между Windows и Android-приложениями.
- При этом уже сейчас Android поддерживает сборку универсальных APK, в которую можно запаковать бинарники как для ARM, так и для x86 архитектур? для чего нужно поставить одну галочку при сборке (разработчики исправьте меня в комментах если я не прав). Поэтому в каких-то случаях может Android-приложения даже не надо будет пропускать через транслятор Intel Bridge.
Да и вообще Android нынче уходит от классических APK и переходит на AAB, но в эту тему мы сейчас не будем углубляться.
Тем не менее, к реализации Android-приложений на Windows остаются вопросы.
Во-первых, что будет с поддержкой Google Play Сервисов? Скорее всего её не будет. Поэтому многие приложения, будут работать неполноценно, либо не будут работать вовсе.
И второй вопрос. А зачем это вообще всё надо? Ведь мобильными приложением на компе пользоваться просто не удобно.
Допустим, на MacBook я могу поставить массу приложений с iOS, но делать этого не хочется. Да на многих Windows-ноутбуках сенсорные экраны, но все равно.
Тогда зачем была проделана вся эта огромная работа по интеграции Linux в Windows, созданию транслятора Intel Bridge, доработки всей этой штуки под Android-приложения?
Будущее Windows
![](https://habrastorage.org/getpro/habr/post_images/020/95a/2d7/02095a2d7a908153746f0fcafad15b62.jpg)
И тут мы готовы высказать смелое предположение. Нам кажется, что поддержка Android приложений это один из этапов полного отказа от ядра Windows NT и перехода на ядро Linux.
Да, это звучит дико. Но во-первых, не мы одни так думаем. Раньше такую же мысль высказал уважаемый человек, евангелист Open Source Эрик Реймонд.
Смотри сами как всё логично:
В мире почти все ОС основаны либо на Unix (как Mac OS) или Linux (Ubuntu, Android и прочее) и только Windows одна такая особенная сидит на своём ядре Windows NT, с которым куча проблем.
Во-первых, его нужно развивать на, что уходит много денег. А Linux-ядро бесплатное.
Во-вторых, в самом ядре куча уязвимостей, которые постоянно нужно прикрывать заплатками.
В-третьих, у Windows ничего не получилось в мобильном сегменте.
В-четвертых, Microsoft уже потратили много лет и ресурсов на создание подсистемы Linux под Windows.
Поэтому переход на ядро Linux вполне логичный шаг. Смотрите, как это может выглядеть:
Сначала мы все переходим на Windows 11 на архитектуре x86. И потихоньку привыкаем, что на Windows нормально работают Android-приложения.
Параллельно, благодаря стараниям Apple, все пилят софт под ARM архитектуру, отчего выигрывает и Microsoft. Поэтому мы потихоньку начинаем переходить на ARM Windows. На которой Android-приложения чувствует себя вообще как родные.
Постепенно Linux ядро становится основной средой, а Windows второстепенной.
А потом ядро Windows NT выпиливается, и Windows становится графической оболочкой для Linux. Ну а на ядре Windows NT остаются работать только серверы и различное оборудование, где наследие старой Windows никак не искоренить.
Это, конечно самый смелый сценарий. Тем не менее, он вполне возможен.
Но даже если этого не произойдёт. В любом случае поддержка Android-приложений — это очень интересный ход. И для Windows на ARM он точно будет полезен, вспоминая планшеты например!
Выводы
![](https://habrastorage.org/getpro/habr/post_images/8a0/87a/5c2/8a087a5c2aaf35597e5d94a2f16dfe2a.png)
Ну и напоследок про сам Windows 11. Мы немного поигрались с новой Windows и у нас сложилось двоякое отношение.
С одной стороны, Windows 11 — это просто «десятка» с новой графической оболочкой. И это немного разочаровывает. Ведь если откинуть ядро Linux, которое теперь будет идти из коробки. Кроме дизайна под капотом не так многое поменялось, зато с совместимостью драйверов вроде проблем нет. Более того, до старого интерфейса, по-прежнему, очень легко добраться.
Тем не менее новый интерфейс действительно симпатичный и понятный.
В нем множество крутых фич как с меню «Пуск», так и с окнами. Привыкаешь к нему буквально за 10 минут. После чего возвращаться к старому скину совершенно не хочется. Еще раз — получилось красиво и удобно! А значит переход на новую Windows пройдет безболезненно и пользователи в целом останутся довольны. А это уже победа…
А там еще можно вспомнить про новый магазин без комиссии для разработчиков с блэкджеком. Но это уже совсем другая история и другие планы Microsoft по завоеванию мира магазинов приложений и ответ лаунчерам.