Почему Windows 10 становится лучшей платформой для разработчиков

Ещё не так давно Windows была обречена. Разработчики покупали оборудование Apple, и каждый доклад на технических конференциях освещался сотнями светящихся логотипов Apple. В этом нет ничего удивительного: под капотом macOS является производной от BSD-Unix, что позволяло разработчикам быстро устанавливать на своих ноутбуках те же наборы инструментов, что и на их серверах или в облаке. В случае отсутствия нужных приложений, разработчики могли установить виртуальную машину Parallels Desktop и запускать нужные приложения для Windows, как если бы они были частью рабочего стола macOS.

Разработчики – первопроходцы. Куда бы они ни пошли, все в конечном итоге последуют за ними. Пришло время для Windows измениться, предоставив среду, ориентированную на разработчиков, без изменения способа использования ПК всеми остальными. Это было сложной задачей для Microsoft, но компания прошла долгий путь к ее решению. Теперь разработчики снова покупают ПК, и эти светящиеся яблоки больше не доминируют в конференц-залах.

Смена Windows, оборудования и программного обеспечения

Как это произошло и, что более важно, как это произошло так быстро? Частично эта история связана с переходом Microsoft на аппаратное обеспечение при пониманием того, что сочетание аппаратного и программного обеспечения Apple было большой причиной ее успеха. Это привело к появлению линейки устройств Surface с высококачественным дисплеем формата 4:3, а также с удобными для разработчиков высококачественными устройствами Surface Book и Surface Laptop, которые поставляются с мощными процессорами и видеокартами, большим объемом памяти, а так же с отзывчивой клавиатурой.

Поскольку разработчики подолгу сидят за экранами, создание правильного оборудования было первым шагом на этом пути. Теперь Windows должна была стать лидером среди операционных систем, привлекательных для разработчиков. Так переход от Windows 8 с сенсорным управлением к гибридной среде Windows 10 стал большим стимулом для перемен. Новая операционная система сохранила функции мультитача и планшета Windows 8, но объединила их со знакомым меню и окнами Windows 7.

Хотя оборудование Surface помогло вернуть разработчиков, модель Windows 10 «Windows как услуга» с двумя выпусками в год позволила Microsoft быстрее реагировать на запросы разработчиков, чем в более ранних версиях Windows. В то же время компания начала отделять SDK и инструменты разработчиков от монолита Windows, заменяя редкие обновления более последовательным циклом выпуска и более быстрым исправлением ошибок.

Терминал – дорога к разработчикам

По большей части это связано с тем, что Microsoft давно описывает как «движение туда, где находятся разработчики». Это означало переосмысление кода, который старше Windows, рефакторинг того, как компания делает документацию, и выход за рамки традиционных ограничений и соперничества, которые ограничивали Windows одним способом работы.

Одним из ключевых достижений является разработка нового терминала – Windows Terminal. Заменив старый cmd.exe, новый терминал использует современный подход к командной строке, используя уроки, извлеченные из Linux и кроссплатформенных приложений терминалов. Windows Terminal можно установить и из магазина Microsoft Store и из репозитория GitHub. Последние сборки поддерживают многопанельные представления в окне, полноцветную поддержку, а также поддержку окон с несколькими вкладками, поэтому вы можете работать с несколькими терминалами одновременно.

Новый терминал от Microsoft упрощает разработчикам работу в Windows или, например, с удаленными серверами при использовании недавно добавленной в Windows встроенной поддержки SSH для безопасных подключений (одна из первых функций Windows, которая зависит от проекта с открытым исходным кодом). Поскольку Windows Terminal поддерживает 24-битный цвет и стандартные соединения ANSI, вы можете перейти из знакомой командной строки Windows прямо к удаленной системе Linux без изменения контекста и с полной поддержкой всех функций терминала Linux.

Linux в Windows

Одновременно с запуском терминала с открытым исходным кодом Microsoft представила вторую итерацию своей подсистемы Windows для Linux (WSL 2). Первоначальный WSL 1 был разработан для обеспечения эмулируемой среды Linux с использованием набора инструментов для преобразования системных вызовов Linux в вызовы Windows, что позволяло запускать код в Windows. Идея заключалась в том, чтобы ключевые элементы цепочки инструментов Linux могли работать в Windows, что в свою очередь предоставит разработчикам возможность работать со знакомыми инструментами и тестовым кодом, не покидая своего ПК.

WSL оказался очень популярным инструментом среди разработчиков, тем более Apple поменяла способ поддержки UNIX в macOS.Сосредоточившись на облачных моделях разработки, таких как контейнеры, Microsoft превратила Windows в портал для разработчиков.

Во втором выпуске WSL использовался другой подход, основанный на низкоуровневом гипервизоре Microsoft Krypton. Являясь частью семейства Hyper-V, Krypton тесно связан с ядром Windows, что позволяет лучше распределять ресурсы между хостом и виртуализированной ОС. Krypton также используется для обеспечения безопасности на основе виртуализации в Windows 10, запускает изолированную тестовую среду Windows Sandbox и режим Application Guard в браузере Microsoft Edge.

С WSL 2 компания Microsoft теперь поставляет собственное ядро Linux и упрощает поддержку контейнеров Linux в Windows. Реализация Docker для Windows теперь основана на WSL 2, что упрощает создание и тестирование контейнеров Linux в Windows перед их развертыванием в Kubernetes в облаке. С контейнером, работающим в Windows, вы можете использовать режим удаленного редактирования Visual Studio Code для работы с кодом внутри контейнера, что дает вам бесшовную среду разработки с редактором и отладчиком внутри контейнера и графическим интерфейсом пользователя, работающим внутри Windows.

Комбинация популярного редактора и конвергентной кроссплатформенной среды разработки оказалась именно тем, чего не хватало в Windows для разработчиков. Вдохновленные линейкой устройств Surface, поставщики оборудования, такие как Dell, Lenovo и Razer, начали поставлять ориентированные на разработчиков ноутбуки, которые дополнили изменения в Windows и предоставили как индивидуальным, так и корпоративным разработчикам доступ к выбору оборудования.

Воспользуйтесь скриптом для установки инструментов с помощью Winget

Остальные изменения менее очевидны. Microsoft работает над улучшением установки приложений и инструментов с намерением предоставить скрипты для установки всего набора инструментов. Вы, конечно, можете использовать сторонний установщик, например, Chocolatey, но Microsoft экспериментирует с двумя собственными подобными инструментами.

Первый инструмент – интеграция командной строки Windows с магазином Microsoft Store. Просто введите «python», и Windows предложит установить популярный язык программирования из Microsoft Store. Добиться подобного удалось благодаря сотрудничеству между проектом Python с открытым исходным кодом и разработчиками командой командной строки Windows и магазином Microsoft Store.

Компания Microsoft сейчас разрабатывает инструмент установки, управляемый из командной строки. Winget работает с размещенным на GitHub репозиторием манифестов пакетов, которые ссылаются на загружаемые установщики. Манифест содержит подробную информацию о приложении с управлением версиями и поддержкой различных установщиков, которые поддерживают разные архитектуры процессоров.

Добавление удобных для разработчиков настроек и функций в Windows

Другие удобные для разработчиков функции появляются в надстройках, таких как набор утилит Microsoft PowerToys. С помощью PowerToys вы можете настроить опцию Fancy Zones для управления макетами экрана, добавить поддержку предварительного просмотра изображений SVG в проводнике, изменить размер изображений и настроить средство запуска приложений на основе поиска. Power Toys – это проект с открытым исходным кодом, в который регулярно добавляются новые функции – одна из последних – это список комбинаций клавиш Windows, который идеально подходит для разработчиков.

Обеспечение хорошего взаимодействия с разработчиками не является задачей какой-либо одной группы в Microsoft или в Windows. Это требует согласования множества различных движущихся частей, поэтому наблюдение за работой Microsoft по охвату этого и других аспектов взаимодействия с разработчиками Windows и разработчиками инструментов является важным событием. Поскольку собственные инструменты разработчиков Windows претерпевают серьезные изменения, следующие несколько месяцев должны стать очень интересными для разработчиков, как тех, кто использует Windows, так и тех, кто создает для Windows.

Начало разработки для Windows

Создавайте возможности с доступом для пользователей на любом устройстве.

Разработка для конкретных устройств

Компьютеры с Windows

Создавайте классические приложения, предназначенные для компьютеров под управлением Windows, с помощью различных платформ, включая универсальную платформу Windows (UWP), .NET и Windows API (Win32).

Windows 10 IoT

Используйте Интернет вещей для реализации широких возможностей приложений.

Смешанная реальность

Привлекайте пользователей с помощью Microsoft HoloLens и иммерсивных гарнитур.

Разрабатывайте игры и приложения UWP для многомиллионной аудитории игроков Xbox One по всему миру.

Surface Hub

Создавайте решения для Microsoft Surface Hub, с помощью которых множество пользователей смогут легко работать вместе.

Изучите разные типы приложений

Интернет

Создавайте прогрессивные веб-приложения, расширения для браузера Microsoft Edge, современные веб-приложения на основе ASP.NET и др.

Enterprise

Перенесите свои классические и веб-приложения в Windows 10 и воспользуйтесь функциями безопасности и развертывания корпоративного уровня.

Создавайте игры для Xbox One, компьютеров и других платформ и их многомиллионной аудитории игроков.

Платформы и технологии

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

Занимаетесь разработкой для более ранних версий Windows?

Ознакомьтесь с нашим архивом документов для Windows 8.x, Windows 7, Windows Phone и других предыдущих версий Windows.

Как создается Windows

Written on 07 Января 2009 . Posted in Windows

Первая версия — Windows NT 3.1, вышла через 5 лет, в 1993 году. На этот момент в команде было уже 250 разработчиков.

Windows сегодня

• 1 миллиард пользователей
• 140 миллионов строк кода (включая тестовый код и инструментарий)
  Код Windows очень разный. Какие-то части написаны 20 лет назад, какие-то появились только в текущей версии. Например, код Web Services on Devices (WSD) в Windows Vista существует в своей первой версии, код GDI находится на завершающей стадии своего развития и почти не изменяется, код DirectX уже хорошо разработан, но активно изменяется и в настоящее время.
• 8000 разработчиков
• 36 языков локализации
• 20 лет разработки

Разработка Windows

20-30 лет назад использовалась только одна методология программирования «Водопад». Она представляет собой последовательность:

Спецификации → Дизайн → Реализация → Тестирование → Поставка.

Но такая методология работает только для небольших проектов. Для такого продукта, как Windows сегодня, нужны другие методологии:

• Product Cycle Model
• Team Software Process
• «Экстремальное программирование»

У всех этих методологий есть и преимущества и недостатки. В зависимости от размера команды и этапа развития компонента разные группы разработчиков Windows применяют разные методологии разработки.
Для Windows, как продукта в целом, используется Product Cycle Model:

• Периоды по 3-4 месяца
• Внутри периода — «водопад»

Самая главная проблема в разработке продукта такого масштаба состоит в том, что разработка требует времени. На начальном этапе решаются те проблемы, которые существуют в текущем времени и существующими средствами. Но единственная вещь, которая постоянна, это то, что все изменится. За годы разработки:

• Требования изменятся
• Возможности изменятся
• График работ изменится
• Проект изменится
• Пользователи изменятся

Несмотря на то, что разные команды ведут разработку по-разному, существуют «универсальные» правила:

• Выпуск промежуточных версий (milestones, beta, CTP) для широких масс тестеров
• Выпуск внутренних сборок с короткими циклами (1 сутки)
• Простота и надежность дизайна
• Личные и командные вычитывания кода
• Unit-тесты
• Верификационные тесты (Build Verification Tests)
• Любая промежуточная сборка должна быть качественной (то, что написано, должно работать)

От себя отмечу, что за месяц работы с Windows 7 build 6801 в качестве основной ОС на домашнем компьютере, у меня сформировалось положительное впечатление об этой сборки.

Весь процесс разработки Windows построен вокруг ежедневной сборки:

• Это пульс продукта
• Разработка никогда не прекращается
• Ежедневное автоматическое тестирование
• Интеграция на ранней стадии
• Ответственность разработчиков
• Очевидное состояние продукта

Когда-то раньше была только одна ветка исходного кода, и все разработчики вносили изменения прямо в неё. Сейчас команда разработчиков настолько большая, что это не работает. Поддерживается множество веток, среди которых есть основная — WinMain. У каждой лаборатории есть своя локальная ветка разработки, в которую интегрируются изменения. Проверенные изменения со временем интегрируются в WinMain.

Ежедневный цикл разработки:

• 15:00 — Допущенные к интеграции изменения в систему контроля исходного кода
• Сборка 6 версий (Free/Checked — x86, x64, IA64)
• 18:00 — Новые версии доступны для тестирования
• Новая версия устанавливается на несколько тысяч рабочих станций и серверов для тестирования
• Автоматизированный стресс-тест
• 05:00 — Протоколы тестов анализируются, сбои диагностируются
• 09:00 — Сводные отчеты автоматически рассылаются командам
• 09:30 — Сводное совещание руководителей команд для определения целей

Все участники проекта, включая самых высокопоставленных руководителей, используют промежуточные версии на своих рабочих (а обычно и домашних) компьютерах.

На чем пишется Windows?

• C, C++, C#, Ассемблер (x86, x64, IA64)
  Ассемблеры применяются в довольно ограниченном объеме в тех ситуациях, когда без этого не обойтись
• Visual Studio, Source Insight, build, nmake
• Source Depot — система контроля исходных текстов
• WinDbg, KD, NTSD — отладчики

Многие внутренние инструменты, такие как build, можно скачать с microsoft.com/whdc/devtools.

Изменения ядра Windows 7

Ядро Windows 7 претерпело следующие изменения:

• Рефакторинг
  Почему в Windows нельзя удалить графическую подсистему?
  Ответ на этот вопрос с технической точки зрения состоит в том, что графическая подсистема в Windows не самостоятельна, это часть подсистемы Win32.
  В Windows 7 произошел рефакторинг многих низкоуровневых компонентов для того, чтобы разбить зависимости. Пользователям это не будет заметно, появятся только новые Dll, например kernel32.dll разделилась на kernel32.dll и kernelbase.dll.
  Это разбиение дало возможность выделить минимальное ядро, называемое MinWin (20 мегабайт на диске).
• Поддержка EFI для x86 и x64 (как в Vista SP1)
  Многие производители пытаются избавиться от BIOS в пользу EFI.
• Загрузка с VHD (виртуальный жесткий диск)
• Параллельная инициализация устройств и старт сервисов
  При загрузке Windows довольно длительное время занимает построение дерева устройств. PNP-менеджер должен опрашивать драйверы шин (PCI, USB, FireWire и др.) на предмет того, какие устройства на них есть. И большую часть времени процессор ждет, пока устройства ответят (или нет). Ведь для того, чтобы определить устройства на шине нужно их опросить. Если они есть, то они ответят, а если нет, то приходится ждать, и процессор простаивает. Параллельное выполнение этих задач сокращает время загрузки.
• Удаление Dispatcher lock из планировщика и PFN lock из менеджера памяти
  Последние несколько лет тактовые частоты процессоров не растут, и развитие идет в сторону увеличения кол-ва параллельно выполняющихся инструкций как на уровне одного ядра, так и на уровне системы (multicore). В связи с этим, была проведена большая работа по улучшению масштабирования.
  Два самых «горячих» лока, которые были в ядре, это Dispatcher lock и PFN lock были удалены.
  Dispatcher lock использовался планировщиком при изменении состояния потоков. Этот лок был удален, и состояние потока «ожидание» разделилось на несколько:
  • Ожидание: В процессе
  • Ожидание: Завершено
  • Ожидание: Отменено

  PFN lock использовался при изменении атрибутов физических страниц памяти. В мультипроцессорной системе каждый процессор запрашивал доступ к этому локу, что вело к большим затратам времени.

• Поддержка 256 логических процессоров
  Раньше в Windows в качестве affinity mask использовалось машинное слово. Это было сделано из-за того, что так было легко находить свободные процессоры — каждый бит представляет собой процессор. Соответственно, в 32-битной системе поддерживалось 32 логических процессора, а в 64-битной — 64.
  В Windows 7 в результате перехода на сегментную модель affinity mask стала возможна поддержка 256 логических процессоров. Процессоры стали группироваться в группы/сегменты. В каждой группе могут находиться до 64-х процессоров. В результате получается обратная совместимость, старые программы «видят» только процессоры в одной группе, а новые программы, использующие новые интерфейсы, работают со всеми процессорами в системе.
• Улучшенное энергосбережение: отключение процессорных сокетовСегодня стоит серьезная проблема энергосбережения не только перед владельцами ноутбуков, но и владельцами датацентров. В США 2% электроэнергии потребляются компьютерными датацентрами. Многие из них выключают часть своих серверов на время низкой активности пользователей (выходные дни).
  Было выяснено, что гораздо выгоднее отключать весь процессорный сокет, чем по одному ядру на нескольких, т.к. в этом случае можно отключить и всю инфраструктуру поддержки сокета (контроллер памяти).

Сопровождение Windows, обновления

Раньше обновления зачастую были кумулятивными(накапливаемыми). Это означало, что если ошибочный код содержался в раннем обновлении компонента, то и поздние версии будут содержать этот код. Но не всем пользователям нужны все обновления, у них разная конфигурация.

Теперь после выпуска (RTM) в Windows существует 2 версии исходного кода:

• RTM GDR (General Distribution Release)
  Включает те немногие изменения, которые предназначены для всех. В основном исправления безопасности.
• RTM LDR (Limited Distribution Release)
  Во время установки обновления клиент Windows Update выбирает нужную ему ветку и устанавливает код из нее.

Создание обновления безопасности

Работа по созданию обновления безопасности начинается с обнаружения уязвимости. Есть масса разных способов обнаружения — внутренние команды безопасности, партнеры безопасности, разработчики. Когда уязвимость обнаружена, начинается 2 параллельных процесса:

• Разработка исправления для всех платформ
• Поиск «вариантов»
  Масштабный поиск похожих вариантов уязвимостей на всех платформах. Поиск не идентичного кода, а похожего.

После разработки исправления, начинаются проверки его кода. Когда они завершатся, исправление интегрируется в сборку, и сборка отправляется на тестирование:

• Ручное и автоматическое тестирование компонент
• Автоматическое тестирование искажений форматов файлов, сетевых компонент и т.п. (больше миллиона вариантов)
• Тестирование системы в целом, включая тестирование обратной совместимости

Только исправления, удовлетворяющие всем критериям качества, допускаются к выпуску на Windows Update и Download Center.