Довольно очевидно, что Windows используется большим количеством людей, и что всем им система нужна для выполнения различных задач: от создания корпоративного сервера и установки на POS-терминалы до использования её на домашнем компьютере, и не только для этого. Многие понимают, что когда Microsoft обновляет Windows, ей приходится принимать множество компромиссных решений для обеспечения корректной работы своей операционной системы. Существует, однако, ещё один тип компромиссов, о существовании которого многие люди, пусть даже они и называют себя продвинутыми пользователями или администраторами, даже не догадываются. Это конфликт между разработчиками/программистами и самой Microsoft.
Разработчиками обычно называют людей, пишущих приложения для пользователей, а Microsoft разрабатывает операционную систему, на которой впоследствии эти приложения будут работать. Точкой их соприкосновения является желание обеспечить стабильную работу приложений, написанных ранее, на новой ОС. Пользователи используют Windows не ради самой Windows, а ради существующих для неё необходимых им приложений. Разработчики же зачастую ограничены в количестве рабочего времени и ресурсов, и необходимость постоянно что-то изменять в своей программе из-за постоянно изменяющегося API/ABI будет вызывать у них лишь раздражение. Хуже того, если какие-либо API будут исключены из ОС полностью, разработчик будет вынужден практически полностью переписать своё приложение. Однако стоит сказать, что в мире Windows такие вещи происходят куда реже, чем в мире open source, но и даже там это крайне редкое событие, поскольку в этом случае существует риск того, что развивающие эту платформу люди могут просто-напросто отвернуться от неё. Кроме того, разработчики хотят, чтобы используемая ими программная платформа постоянно обновлялась, в неё добавлялись новые возможности и удалялись ошибки, что, несомненно, направлено на упрощение как работы с ней, так и программирования для неё. Вопреки тому, что многие пользователи могли подумать, разработчики программных платформ хотят продолжать поддерживать своих клиентов и пользователей и хотят добавлять новые возможности при сохранении работоспособности уже существующих. Это довольно сложная задача, однако как только фреймворк или платформа устаревает, без проведения её обновления пользоваться ей может быть довольно сложно, поскольку она просто уже не сможет выполнять некоторые новые задачи.
Однако порой наступает необходимость вносить в платформу коренные изменения, поскольку в ней накапливается настолько большое число «костылей» и архитектурных проблем, что её поддержка и улучшение будет даваться её разработчикам непомерно высокой ценой. Разработчики для Windows знают это очень хорошо, поскольку win32 API было создано много лет назад. Изначально win32 API было 16-битным, и уже позже было расширено для поддержки 64-битных платформ. Во многих местах оно довольно громоздко и неэффективно, и зачастую просто крайне, крайне избыточно, а с повышением акцента на использование C++ для разработки, C-ориентированное win32 API с каждым годом всё больше и больше показывает своё устаревание. Библиотека Microsoft Foundation Classes стала попыткой Microsoft предоставить API для C++ для низлежащей платформы win32, однако и она стала жертвой проблемы избыточности и получила дурную славу из-за недостаточной гибкости в тех случаях, когда кто-либо пытался сделать что-либо из того, что явно ей не поддерживается. Среди разработчиков Windows было немало людей, недовольных текущим положением дел и говоривших о необходимости выхода из сложившейся ситуации, сколь болезненно бы это не было. Microsoft для этого решила воспользоваться средой .NET и обновила платформу WinForms, чтобы облегчить работу разработчикам. Однако платформа .NET является средой выполнения, и хотя она и получила широкую популярность, всё же она не подходит для использования разработчиками, пишущими нативные приложения для Windows. Какое-то время спустя Microsoft выпускает библиотеку под названием Windows Template Library, предназначенную для абстрагирования от некоторых из наиболее раздражающих аспектов API Win32, при этом куда более легковесную и гибкую, чем MFC. Многие полюбили WTL и им стало ясно, что именно такой подход к программированию и должен применяться в Windows в качестве стандарта де-факто, однако появилась ещё одна перспектива, которая в итоге убила эту возможность.
Проблема, с которой столкнулась Microsoft, связана не только с громоздкостью и неуклюжестью win32 API. Низкоуровневые системы также были спроектированы уже очень-очень давно и практически не отвечают современным требованиям. Графический движок Windows был написан ещё в те времена, когда основным средством рендеринга графики был центральный процессор. Однако графические процессоры за прошедшие годы стали куда мощнее и взаимодействовать с ними стало куда удобнее, но графический движок Windows просто не умел с ними работать. Выбор был очевиден, но не столь прост, как это кажется на первый взгляд. Microsoft может разработать абсолютно новый графический движок и создать новый API поверх него, что, несомненно, позволит сделать программирование и использование системы более удобным. В то же время им обязательно необходимо сохранить совместимость с существующими фреймворками и приложениями, в противном случае пользователи просто не будут видеть смысл в покупке новой версии Windows. Первым шагом в этом направлении стала Windows Vista, которую справедливо или несправедливо многие помнят как яростного пожирателя ресурсов, да ещё и страдающего от несовместимости со многими приложениями. Изменения эти, однако, были необходимы, поскольку Microsoft была нужна какая-нибудь основа, которая позволила бы дать разработчикам легкий доступ к постоянно растущей мощи графических процессоров. Заставлять разработчиков писать приложения с применением Direct3D было бы излишним, в особенности это касается попыток использовать Direct3D для написания 2D приложений, поскольку это приведёт к необходимости написания ими большого количества избыточного кода.
Microsoft пока ещё не готова создать новый API, и вместо этого она свалила на разработчиков Windows Presentation Foundation, Silverlight, и XNA. Пользователи .NET Framework пришли в восторг, поскольку все эти три инструмента были довольно неплохими. Хотя WPF и страдал от некоторых серьезных проблем с производительностью из-за архитектурных недостатков дизайна, но Microsoft постепенно улучшила низлежащую систему. Silverlight набрал довольно большую популярность в среде корпоративных интранет-приложений, создав тем самым в мире IT целую мини-отрасль. Всё это вкупе, вероятно, помогло увеличить привлекательность серверов на основе Windows, а это именно то, чего всегда так хотела добиться Microsoft в своих попытках потеснить Linux в серверных средах. Ранее многие компании использовали сервера на основе Windows в первую очередь для Active Directory, в настоящее же время у них стало больше причин относиться к веб-хостингу под управлением Windows Server более серьезно. С другой стороны XNA предлагает очень хороший уровень абстракции от довольно сложного и избыточного Direct3D API, тем самым позволяя разработчикам создаваемого приложения задействовать большую мощность графических процессоров без излишних затруднений. Microsoft также предлагает некоторые уступки, нацеленные на привлечение независимых разработчиков игр на сервис Xbox Live Arcade, однако для того, чтобы выставить игру на Marketplace, разработчику всё же необходим привилегированный аккаунт. Всё это делалось для создания сообщества XNA-разработчиков, которые могли бы впоследствии наполнить созданный и контролируемый Microsoft магазин приложений. Похоже, что это стало самой крупной ошибкой, когда-либо сделанной Microsoft, однако об этом мы поговорим чуть позже.
И вновь все эти улучшения были предназначены для разработчиков приложений .NET, порождая недовольство и разочарование разработчиков нативных приложений. Они тоже хотели иметь возможность без лишних усилий использовать все преимущества более мощного оборудования, и это касается не только использования графического процессора, но и работы с увеличившимся количеством ядер процессора, однако ни один из существующих вариантов не предоставлял такой простоты и дружественности к разработчику, как инструменты разработчиков .NET. Стоит сказать, однако, что вместе с выпуском Windows 7, Microsoft выпустила Direct2D, представляющее собой новое системное API, которое добавило в ОС новые функции по отрисовке 2D-графики, полностью выполняемые средствами графического процессора, но при этом не требующие непосредственного взаимодействия с самим GPU; кроме того, Microsoft предложила разработчикам средства, призванные облегчить работу с многопоточными приложениями. Потенциал Direct2D был очевиден многим, в том числе и разработчикам игр, особенно с учётом того, что в будущем его функции будут только улучшаться. Впервые после всех тех разочарований, которые пришлось испытать сторонним разработчикам за время, прошедшее с момента выхода Windows XP до выхода Vista, а затем и от самой Vista, будущее стало выглядеть многообещающим. А затем дела приняли довольно странный оборот.
Многие помнят, что это произошло в тот момент времени, когда Apple с их комбинацией iPad/iPhone и AppStore получила огромную популярность. Руководители Microsoft, вероятно, заметили эту популярность, а также связанные с ней доходы Apple, и захотели повторить этот успех. В процессе подготовки к завоеванию рынка они, однако, приняли несколько довольно странных решений. Прежде всего, всегда нужно иметь ввиду, что успех AppStore или любого другого магазина приложений зависит в первую очередь от числа разработчиков, создающих для него приложения. И Google, и Microsoft это прекрасно понимали, и обе эти компании пытались заманить разработчиков, предлагая им простые в использовании, но мощные и гибкие API и хорошую поддержку программного инструментария. Microsoft, как впрочем и всегда, сильна в поддержке инструментов разработки, это подтвердит любой, кому приходилось пользоваться Visual Studio. Microsoft даже сделала некоторые подвижки с целью сделать платформу XNA пригодной для разработки приложений для своих телефонов. А затем, представив публике Metro/Modern API, Microsoft фактически показала средний палец большей части своего сообщества разработчиков.
Самыми крупными потерями стали платформы Silverlight и XNA, которыми Microsoft фактически пожертвовала для того, чтобы разработчики использовали «Modern» API для Windows 8. Проблема здесь, однако, в том, что область применения Silverlight не соответствует области применения Modern. Silverlight по существу является плагином для браузера, предназначенным для работы веб-приложений, в то время, как Modern предназначен для приложений ОС. Кроме того, у них не соответствуют и сценарии развёртывания. Silverlight в основном располагается на вебсервере, а приложения Modern доступны для скачивания лишь из собственного цифрового магазина Microsoft. Корпоративные клиенты, как и разработчики их приложений, разумеется не пришли от этого решения в восторг. Одним лишь ударом Microsoft удалось не только уменьшить ценность серверов на основе Windows в качестве веб-узлов, но и практически полностью отбить желание перейти на Windows 8 у своих корпоративных пользователей. Самым странным в этом является то, что разработчики Silverlight это явно не те люди, которые могут просто так взять и начать писать приложения для цифрового магазина. Их использование Silverlight просто не укладывается в рамки разработки приложений для Modern. Позиция Microsoft по этому поводу (кроме, разумеется, простого игнорирования жалоб) состояла в том, чтобы просто-напросто предложить этим людям использовать HTML5. И опять же это отнюдь не самый умный ответ, поскольку разработчики Silverlight не создают вебсайты в общепринятом смысле этого слова, а чаще всего создают набор бизнес-приложений, которые, так уж случилось, разворачиваются на вебсервере. Нередко эти бизнес-приложения являются довольно сложными, и их разработчики выбрали Silverlight именно из-за того, что он предлагает множество инструментов для упрощения работы разработчика. Несмотря на продвижение HTML5 в различными сферы деятельности, HTML5 и AJAX всё не так подходят для этих целей, как Silverlight, и их использование неизбежно приведёт к увеличению сроков разработки и снижению производительности труда разработчика. Зачем всё это понадобилось Microsoft до сих пор не ясно. Возможно за этим стояло решение унифицировать разработку при помощи введения единого API, однако парадигма «всё в одном» никогда не работала при разработке программного обеспечения раньше, да и не похоже, что она заработает в ближайшем будущем.
Участники сообщества XNA — это именно те люди, которые легко могли бы перейти на использование магазина приложений, однако Microsoft нанесла им ещё больший урон. Их обращение с разработчиками независимых игр на XBLA было поистине нечеловеческим, например те люди, которые управляют Xbox Live, казалось, делают всё возможное, чтобы максимально увеличить доходы Microsoft даже в ущерб отношениям с сообществом разработчиков. В принципе это может иметь смысл, поскольку развлекательное подразделение Microsoft несло потери в течение многих лет, однако в долгосрочной перспективе они серьезно подорвали ранний энтузиазм людей по поводу XNA и всей экосистемы Microsoft в целом. А затем Microsoft отказывается от XNA, опять же в пользу Modern, и вновь не предоставляет никаких процедур по миграции/переходу на него. И такая свистопляска происходит на многих уровнях, например разработчики приложений .NET внезапно потеряли прямой доступ к работе с графическим процессором. Это создает противоположную в сравнении с предыдущими итерациями ситуацию, когда разработчики .NET первыми получали много блестящих новых игрушек, в то время, как нативные разработчики вынуждены были довольствоваться поломанным старьём. Однако, в точности также, как разработчики нативных приложений зачастую не могли или не желали перейти на разработку программ для .NET, разработчики .NET не могли или не желали перейти на разработку нативных приложений. Эта новая асимметрия, возможно, угрожает Microsoft ещё сильнее, поскольку сторонние разработчики смогли реализовать свою собственный вариант среды .NET от Microsoft и назвали его Mono. Также, независимыми разработчиками был анонсирован проект по созданию фреймворка, полностью совместимого на уровне API с XNA, что позволяет участникам сообщества XNA просто-напросто совсем отказаться от использования экосистемы Microsoft. Кроме того, Sony выпустила свой собственный SDK, предназначенный для написания приложений на C#. Одним ударом Microsoft фактически убила значительную часть своего сообщества разработчиков, и это была именно та часть, которая, скорее всего, была способна и готова заниматься разработкой для их цифрового магазина приложений.
А что же нативные разработчики? В итоге они конечно получили новенький API, относительно современный и довольно мощный, особенно если сравнивать его с win32. И всё же многие из нас до сих пор чешут голову. Многие из нас были разработчиками приложений для компьютеров, при этом мы просто наслаждались гибкостью операционной системы. И вот вдруг Microsoft вводит ограничения для программ, написанных на новом API, и становится совершенно очевидно, что они разработали эту новую API совсем не для настольных приложений, а для планшетов и телефонов. И мы просто взяли и послали их ко всем чертям.
Microsoft поставила перед собой стратегическую цель: перейти на экосистему телефонов и планшетов. Они ясно поняли, что для того, чтобы достигнуть этой цели, им нужны приложения, а также разработчики, которые будут их писать. В результате на создание инструментария для сторонних разработчиков были потрачены огромные усилия. Правда в это время они потеряли значительную часть этих самых разработчиков, которые или были не удовлетворены их решением об отказе от дальнейшей поддержки используемой ими платформы и фактически выказанным им неуважением, или же были недовольны тем, что их вынуждают писать приложения для телефонов и планшетов путём выставления искусственных ограничений. Microsoft, похоже, сделала ставку на то, что их экосистема привлечёт достаточно новых разработчиков, и они вполне могут не замечать неизбежного недовольства «стариков». Многое ли они при этом теряют? Возможно нет… С другой стороны, потеря целых сообществ разработчиков, например то, что они сделали с XNA, скорее всего будет иметь долгосрочные стратегические последствия. Это были те люди, которые могли, возможно, привести магазин приложений Microsoft к огромному успеху, поскольку они могли создавать качественные приложения и игры. Они надолго запомнят то, как Microsoft с ними обошлась, и уж конечно шепнут об этом другим независимым разработчикам, которые так нужны Microsoft. Будут ли акционеры Microsoft достаточно мудры, чтобы понять последствия всего этого, уже совершенно другой вопрос.
В итоге всё сводится к тому, что Microsoft фактически переработала всю систему полностью, чего так хотели многие разработчики. Но только вот то, как они это сделали, больше похоже на попытку вообще отказаться от настольной операционной системы, вместо того, чтобы дать разработчикам новые и более совершенные инструменты, чтобы те и дальше могли продолжать разрабатывать приложения для настольных компьютеров. Это было совсем не то, чего так просили разработчики, и вот теперь Microsoft пытается исправить ситуацию. Вопрос здесь лишь в том, будет ли Microsoft готова зайти достаточно далеко и снабдить разработчиков приложений необходимым им инструментарием, или же они настолько решительно настроены на развитие своего магазина, что легко готовы отказаться от всех несогласных размещать свои приложения в их магазине разработчиков, а может быть их магазин получит огромный успех в деле продажи «классических» приложений для компьютера… Но в Microsoft похоже не очень понимают, что помомо игр, существует не так уж и много программ, которые простые пользователи используют в своей повседневной работе, что означает, что количество приложений, которое необходимо для достижения точки насыщения их магазина, не так уж и велико. Куда гораздо больше приложений являются узконаправленными или специализированными для какой-либо задачи, требования которых или не совместимы с ограничениями Modern API, или же совсем не вписываются в модель магазина приложений. Исходя из этого можно сделать вывод, что Microsoft в первую очередь интересуют игры, однако она уже испортила отношения с сообществом независимых разработчиков игр, что, как я уже говорил, может иметь для Microsoft серьезные последствия в долгосрочной перспективе, а магазин наполнять в любом случае нужно. Они также не очень хорошо обошлись с разработчиками обычных приложений, а это как раз те люди, благодаря которым Windows получила широкое распространение в качестве платформы для рабочих станций, разработки и творчества. Безусловно будет интересно посмотреть, смогут ли руководители Microsoft проявить достаточную гибкость и осознать это, или же они всё же абсолютно уверены, что смогут построить успешную в долгосрочной перспективе платформу, поломав всё, что только возможно и сконцентрировавшись на краткосрочном росте доходов, который так заманчиво предлагает модель собственного цифрового магазина.
Перевод: © evilslon
Автор: Jeditobe
