Перед вами модная теория: «Microsoft-у конец. Как только Linux продвинется в своем набеге на десктопы, и web-приложения заменят настольные приложения (desktop application), могучая империя падет».

И хотя существует часть правды в том, что Linux представляет большую угрозу для Microsoft, предсказания о падении компании из Рэдмонда, по меньшей мере, преждевременны. У Microsoft невероятное количество денег в банке, и они до сих пор  невероятно  прибыльны. Падение будет долгим. Они могут халтурить десятилетие, прежде чем  попадут в зону относительной опасности, и кто знает… в последнюю минуту они могут реинкарнироваться в компанию по производству мороженого. Поэтому не торопитесь списывать их со счетов. В начале 90-х все  думали, что  с IBM покончено:  мейнфреймы стали историей. Тогда же Роберт Крингли предсказал, что эра мейнфреймов закончится 1 января 2000 года, когда все программы на COBOLе заклинит, а вместо исправлений  этих приложений, чьи исходники, как говорят,  давно потеряны, легче будет их переписать  на клиент-серверной платформе.

Хорошо, допустим. Мейнфреймы до сих пор с нами, ничего не произошло 1 января 2000 года, а IBM перестроилась в большую, технологически всеядную, консалтинговую  компанию, производящую даже дешовые  пластиковые телефоны.  Так что теория кончины Microsoft, выведенная из  экстраполяции по малому количеству точек,  является чрезмерной гиперболизацией.

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

А теперь, позвольте мне извиниться за насыщенность и помпезность предыдущих абзацев. Похоже я начинаю выглядеть как писатель передовиц, который продолжает и продолжает кричать о стратегическом активе Microsoft:  Windows API. Доказательство моих слов займет несколько страниц. Пожалуйста, не делайте никаких умозаключений, пока я не объясню, о чем я говорю. Это будет длинная статья. Мне понадобиться объяснить, что такое Windows API, продемонстрировать, почему это наиболее  важный стратегический актив Microsoft . Я должен объяснить, как он был потерян, какие будут  последствия. Но так как я говорю о долгосрочных тенденциях, я вынужден буду гиперболизировать и обобщать.

Разработчики, разработчики, разработчики, разработчики

Помните определение операционной системы? Это нечто, управляющее ресурсами компьютера так, что программы  могут запускаться и работать. Людям в действительности наплевать на операционную систему, им не наплевать на те приложения, которые операционная система позволяет запускать. Текстовые редакторы. Интернет-пейджеры. Электронная почта. Счета к уплате. Веб-сайты с картинками Paris Hilton. Сама по себе операционная система не так полезна. Люди покупают операционные системы  из-за полезных приложений, работающих на этой операционной системе. Следовательно, самая полезная операционная система та, на которой запускается наибольшее количество полезных приложений.

Логическое заключение состоит в том, что если вы пытаетесь продавать операционную систему, то вам необходимо сделать так, чтобы  разработчики программного обеспечения  захотели писать  программы для вашей операционной системы. Поэтому Стив Баллмер прыгал по сцене и кричал: «Разработчики, разработчики, разработчики, разработчики». Это так важно для Microsoft, что единственная причина, из-за которой средства разработки программного обеспечения не раздаются  бесплатно, заключается в том, что они не хотят случайно перерезать кислород разработчикам конкурирующих инструментов разработки (хорошо, тем, которые остались), так как разнообразие инструментов разработки, доступных для их платформы, делает ее куда более привлекательной для разработчиков. Но на самом деле они хотят раздавать. Благодаря их программе Empower ISV вы можете получить пять наборов MSDN Universal (иначе известных  как «практически все продукты Microsoft,  исключая Flight Simulator») всего за 375$. Компиляторы командной строки  для языков .NET включены с бесплатными библиотеками .NET … тоже бесплатно. Компилятор С++ теперь бесплатен. Что угодно  для поощрения разработчиков работать под .NET и ликвидации таких компаний как Borland.

Почему Apple и Sun не могут продавать компьютеры

Да, это немного глупо: конечно Apple и Sun могут продавать компьютеры, но не на двух наиболее прибыльных рынках, а именно на рынках корпоративных и домашних пользователей. Aplle до сих пор  где-то там внизу, с очень маленьким процентом рынка (Пожалуйста, поймите, что я говорю о больших числах, и следовательно, когда я говорю «никто», я на самом деле имею в виду  «меньше чем 10 000 000 людей» и так далее и так далее).

Почему? Потому что на компьютерах Apple и Sun не работают программы для Windows, или, если работают, то в режиме дорогой и не безупречной эмуляции. Помните, что люди покупают компьютеры для программ на которых они работают, а для Windows настолько больше программного обеспечения, чем для Mac, что очень трудно быть пользователем Mac. Вот почему Windows API такой ценный актив Microsoft.

(Я знаю, знаю, на этом  месте  2,3% мира –  пользователи Macintosh – разогревают свои почтовые программы, чтобы послать мне  уничтожающее письмо  о том, как они любят свои Mac’и. Еще раз: я говорю о больших цифрах и обобщаю, так что не тратьте свое время. Я знаю, как Вы любите свои Mac’и. Я знаю, что там есть все, что Вам нужно. Я люблю Вас, но Вы всего лишь 2,3% мира, и статья не про Вас).

Две силы в Microsoft

В Microsoft есть два противостоящих лагеря, я их буду называть лагерь Реймонда Чена и лагерь журнала  MSDN.

Реймонд Чен –  разработчик в команде Windows с 1992 года. Его веблог The Old New Thing набит детальными техническими историями  о порядке вещей в Windows, даже глупые вещи имеют  под собой веские основания.

Больше всего на веблоге Реймонда впечатляет история о невероятных усилиях, приложенных командой разработки Windows для поддержания обратной совместимости.

«Взгляните с  точки зрения покупателя. Вы купили программы X, Y и Z. Затем вы обновились до Windows XP. Теперь ваш компьютер внезапно зависает, и программа Z вообще не работает. Вы скажите своим друзьям: «Не обновляйтесь до Windows XP. Она внезапно зависает и не совместима с программой Z». Будете ли вы дебажить вашу систему, чтобы определить, что программа X причина зависаний, а программа Z не работает, потому что использует недокументированные сообщения Windows? Конечно нет.  Вы вернете коробку с Windows XP и получите обратно деньги. (Вы купили программы X, Y и Z несколько месяцев назад. 30-дневный срок возврата уже для них не действует. Единственное, что вы можете вернуть, это Windows XP.)»

Я впервые услышал об этом от одного из разработчиков популярной игры SimCity, который поведал мне о критической ошибке в их программе:  она использовала память сразу после ее освобождения. Главное табу, нарушение которого прощалось в DOS, но карается  в Windows, где освобожденную  память тут же стащит другое работающее приложение. Тестеры в команде разработки Windows протестировали множество популярных приложений, чтобы убедиться, что все работает без сбоев, но SymCity  зависала. Они сообщили это разработчикам Windows, которые  дизассемблировали SymCity, шаг за шагом в дебаггере найдя  ошибку, и добавили  специальный код, проверяющий наличие SymCity в памяти и  запускающий распределитель памяти в специальном режиме, в котором SymCity разрешается использовать память после ее освобождения.

И это было в порядке вещей. Команда тестировщиков Windows огромна, и она должна гарантировать – это  и является ее главной задачей и  ответственностью,  –    что каждый сможет безопасно обновить свою операционную системую. Не имеет значения, какое приложение  инсталлированно,  оно обязано работать, даже если ведет себя плохо, или использует недокументированные функции, или полагается на ошибочное поведение функции, которое было ошибочным в Windows n, но уже исправлено в Windows n+1.  На самом деле, если вы загляните в секцию AppCompatibility вашего реестра, вы увидите целый список приложений, для которых Windows эмулирует старые ошибки и необычное поведение, поэтому они могут работать.  Реймонд Чен пишет «Меня черезвычайно бесит, когда люди обвиняют Microsoft в преднамеренной невозможности запуска  приложений после обновления ОС. Если приложение не запускается под Windows 95, я воспринимаю это за персональный провал. Я  трачу много бессонных ночей, фиксируя ошибки программ сторонних производителей, чтобы они продолжали работать под Windows 95.»

Много разработчиков с этим не согласно. Если приложение ведет себя неправильно, или полагается на недокументированное поведение, то оно должно перестать работать после обновления ОС. В Apple разработчики ОС всегда придерживались этой точки зрения. Поэтому так мало старых работающих программ под Macintosh. Например, много разработчиков пытались ускорить свои приложения, копируя указатели из таблицы векторов прерываний и вызывая их непосредственно, вместо использования соответствующей функции процессора. Несмотря на то, что где-то внутри «Inside Macintosh» – официальной библии Apple по программированию на Macintosh – было техническое указание «так делать нельзя», они так делали, и это работало, и их программы работали быстрее… до выхода следующей версии ОС, после они не работали вообще. Если компания вышла из бизнеса (а большинство вышло.)…что-ж, не повезло.

Для сравнения, у меня есть программа для DOS, написанная мною в 1983 году для очень оригинального IBM PC, которая до сих пор безупречно работает благодаря лагерю Реймонда   Чена. Конечно, это заслуга не только Реймонда: это modus operandi ядра команды разработки Windows API. Реймонд очень точно отразил это на своем замечательном вебсайте  The Old New Thing.

Это первый лагерь. Другой лагерь назван мною лагерем журнала MSDN: по имени журнала для разработчиков, полного увлекательных статей обо  всех способах отстрела собственной ноги при помощи продуктов Microsoft и собственного программного обеспечения. Лагерь журнала MSDN всегда пытается убедить вас применять новые и сложные внешние технологии, такие как COM+, MSMQ, MSDE, Microsoft Office, Internet Explorer и его компоненты, MSXML, DirectX (пожалуйста, самую последнюю версию), Windows Media Player и Sharepoint... Sharepoint! У кого он есть? Пышный наряд внешних зависимостей, каждая станет причиной сильнейшей головной боли, когда вы отправите ваше приложение заплатившему вам деньги клиенту, а оно откажется работать. Техническое имя этому – ад DLL. Это работает здесь: почему оно не работает там?

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

А вот почему все вышесказанное имеет значение.

Microsoft утратила религию обратной совместимости

Лагерь журнала MSDN выиграл битву внутри Microsoft.

Первой большой победой стал Visual Basic.NET без  обратной совместимости с  VB 6.0.  Без преувеличения впервые, при покупке обновления продукта Microsoft ваши старые данные (тот же код, написанный на  VB6) не переносились беспрепятственно.  В первый раз обновление от Microsoft не проявило уважение к плодам  трудов пользователей, полученных  на предыдущих версиях продуктов.

Казалось, небеса не обрушились, не внутри Microsoft. Разработчики на VB6 и так потихоньку исчезали, поскольку большинство из них были корпоративными разработчиками и мигрировали на разработку web-приложений. Настоящий долгосрочный ущерб не был виден.

Под знаменем этой победы лагерь журнала MSDN захватил власть. Внезапно  изменение устоев стало нормой. IIS 6.0 вышел с другой потоковой моделью, из-за чего некоторые старые приложения не запускались.  Я был шокирован, узнав, что наши клиенты с Windows Server 2003 имеют проблемы с работой FogBugz. Потом .NET 1.1 не имел идеальной обратной совместимости с 1.0.  И теперь, команда разработки ОС вошла во вкус и решила вместо добавления новых функций в Windows API заменить его полностью. Нам было сказано, что вместо Win32 нужно быть готовыми к WinFX: следующему поколению Windows API. Все иначе. Основано на .NET с управляемым кодом. XAML. Avalon.  Да, значительно лучше Win32, я признаю. Но не обновление –  разрыв с прошлым.

Разработчики и так не были в большом восторге от сложности программирования под Windows, поэтому в массовом порядке покинули платформу Microsoft и занялись web разработкой. Пол Грэхэм –  создатель Yahoo! Stores  в самом начале бума доткомов – ярко подытожил: «Для начинающих компаний сейчас все больше и больше причин писать web-ориентированные приложения, потому что создание настольного программного обеспечения (desktop software) стало куда менее забавным. Если вы сегодня хотите написать настольное приложение, вы делаете это на условиях  Microsoft, вызывая их API и работая с их глючной ОС.  И если перед вами стоит задача написать что-то неординарное, то вы можете обнаружить, что просто проводите маркетинговое исследование для Microsoft.»

Microsoft выросла, обзаведясь большим количеством программистов, которые увлекшись доходами с обновлений, внезапно решили, что перепрограммировать все – не очень большой проект. Черт побери, мы может сделать это дважды! Старая Microsoft, Microsoft Рэймонда Чена, могла реализовать вещь наподобие Avalon – новую графическую систему – как серию DLL, которые запускаются на любой версии Windows, и  могут быть включены в любое приложение. Нет технических причин так не сделать. Но Microsoft нужна причина, по которой  вы купите  Longhorn, все, что они добиваются  это резкое изменение, сродни изменениям призошедших, когда Windows сменила DOS. Проблема в том, что Longhorn не является очень большим продвижением вперед над Windows XP; не настолько большим, как Windows над DOS. Наврядли это послужит  для людей достаточным основанием для покупки новых компьютеров и программ, как когда-то они сделали из-за Windows.  Хорошо, может и послужит, Microsoft это, несомненно, необходимо, но то, что я сейчас наблюдаю, не очень убедительно. Microsoft сделало много неправильных ставок. Например, WinFS, рекламируемое как средство организации  поиска путем представления файловой системы в виде реляционной базы данных, игнорирует тот факт, что настоящее средство для поиска это выполнение поиска.  Не заставляйте меня впечатывать  во все мои файлы метаданные, которые я могу искать, использую язык запросов.  Просто сделайте мне одолжение и поищите впечатанную мною строку на чертовом жестком диске, быстро, используя полнотекстовые индексы и другие технологии, наскучившие еще в 1973.

Автоматическая коробка передач одерживает победу

Поймите меня правильно… Я считаю .NET великой средой разработки, а Avalon с XAML – гигантский прогресс над старыми способами написания графических приложений для Windows. Наибольшее преимущество .NET заключается в автоматическом управлении памятью.

В начале девяностых многие из нас полагали, что главная битва произойдет между процедурным и объектно-ориентированным стилем программирования, и воспринимали объектно-ориентированное программирование как средство резкого повышения продуктивности программистов. Я тоже так думал. Некоторые до сих пор так думают. Получается, мы ошибались. Объектно-ориентированное программирование прикольная штука, но не повышает продуктивность, как это обещалось. Реальное и значительное повышение производительности мы получили от программирования на языках, автоматически управляющих памятью вместо вас. Это может быть подсчет ссылок или «сборка мусора», это может быть Java, Lisp, Visual Basic (даже 1.0), Smalltalk или любой язык написания скриптов.  Если ваш язык программирования позволяет выделять кусок памяти без раздумий о его последующем освобождении, то вы используете язык с управляемой памятью, и вы будете значительно эффективней программиста, использующего язык, где управление памятью производится в явном виде. Всякий раз, когда вы слышите чье-то хвастовство о том, насколько продуктивен их язык, вероятно, большую часть продуктивности они достигают за счет автоматического управления памятью, даже если  не признаются в этом.

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

Если вы занимались  разработкой настольных приложений в ранних версиях Windows,  то Microsoft предлагал вам два пути: написать код на С, напрямую вызывающий Windows API, и самостоятельно управлять вашей памятью, или использовать Visual Basic, который будет управлять памятью за вас. Эти две среды разработки я использую чаще  всего последние  лет три