Ранее в этом месяце Microsoft несколько шокировала Windows-разработчиков: платформа .NET, которую компания продвигала на протяжении последнего десятилетия как основную для разработчиков, не будет использоваться при построении приложений для нового интерфейса Windows 8. Вместо этого, разработчики должны использовать HTML5 и JavaScript.
Многие из них, что естественно, задались вопросом, который пока не получил ответа: «Как я смогу использовать имеющийся у меня опыт для разработки новых приложений?» Microsoft же хранит молчание и не планирует сообщать ничего до конференции BUILD (бывшая PDC) в сентябре.
Но, вероятно, не все так мрачно, как многие думают. Ранние сборки Windows 8 утекли в интернет, и были приложены значительные усилия, чтобы понять, как они работают. Что ж, все выглядит так, словно разработка приложений под Windows 8 не только не ужасна, но и наконец-то сможет избавить разработчиков от многих раздражающих препятствий на их пути. Если у Microsoft получится реализовать все запланированное, следующая версия Windows станет настолько же важным релизом, насколько важным должен был стать релиз Windows Longhorn.
Чтобы понять, что к чему, следует провести некоторый исторический экскурс.
До того, как была представлена платформа .NET, Windows-приложения разрабатывались двумя способами. «Большие» приложения, такие как Office, Photoshop или Netscape Navigator, писались с использованием Win32 API и С++. Win32 API это большой набор функций, предоставляющих низкоуровневый доступ к таким вещам, как отображение графики и пользовательского интерфейса, передача данных по сети, доступ к файловой системе, а также к множеству других менее очевидных, вроде управления безопасностью.
Win32 API решал множество задач, но многие из них не самым лучшем образом, а некоторые вообще никак. Так, несмотря на наличие функций для доступа к базам данных, разрабатывать приложение, активно их использующее, было весьма неудобно. Но куда более актуальной проблемой являлось то, что Win32 API обладает лишь базовым набором инструментов для построения пользовательского интерфейса, и в нем отсутствовали какие-либо средства для контроля разметки. Каждая кнопка, каждое поле и панель инструментов должны были быть позиционированы вручную разработчиком. Если разработчик хотел, чтобы положение элементов менялось с изменением размеров окна, без проблем — он всего лишь должен был заново размещать их при каждом изменении. Конечно, со временем появилось множество библиотек, которые служили прослойкой между программистами и операционной системой, упрощая отрисовку интерфейсов (в том числе, библиотека MFC от Microsoft), но необходимость погружаться в дебри Win32, чтобы заставить все работать так, как вам нужно, не исчезла.
Другим способ разработки приложений для Windows был Visual Basic. Благодаря ему некоторые задачи решались действительно просто — в частности, доступ к БД и создание пользовательских интерфейсов — что сделало Visual Basic королем в мире корпоративных приложений, от которых требовалось ненамного больше, чем брать информацию из базы данных, показывать ее пользователю и выводить форму для внесения новых данных в БД. Со всем этим Visual Basic справлялся безупречно. Со всем остальным у него были проблемы, так как Visual Basic не мог использовать многие функции Win32. Также Visual Basic не поддерживал довольно популярную парадигму ООП.
И тут появилась платформа .NET и все изменила. .NET дала разработчикам легкость использования Visual Basic, но без его неприятных недостатков. Аналогично Visual Basic, .NET предоставляла удобные инструменты для построения пользовательских интерфейсов и взаимодействию с базами данных, то есть в высшей степени подходила для разработки корпоративных приложений. Но, в отличие от Visual Basic, .NET также сделала доступ к Win32 просто, неловко сказать, одной из своих функций. Платформа быстро набирала обороты в корпоративной среде, и многие новые коммерческие проекты были основаны именно на ней.
Windows XP, вышедший за год до появления .NET, разумеется, не использовал эту технологию. Но, на PDC в октябре 2003 Microsoft пообещала это исправить, выпустив Windows Longhorn. Эта версия Windows должна была иметь .NET FX (так .NET называли внутри компании) как часть ядра операционной системы, а .NET FX, в свою очередь, давала дорогу новой платформе WinFX — Windows Framework. Помимо прочего, WinFX включала в себя абсолютно новый способ разработки векторных масштабируемых аппаратно-ускоренных пользовательских интерфейсов, названный Avalon. Сам Windows должен был быть написан с использованием WinFX в собственных приложениях, таких как проводник, калькулятор и так далее, а .NET — стать главным средством создания приложений для Windows. Win32 был бы оставлен для обратной совместимости, но заморожен и забыт.
Longhorn должен был похоронить старые способы написания программ и начать новую эру современной разработки, не обремененной архитектурными решениями десяти-пятнадцатилетней давности.
Как мы все знаем, Longhorn так и не увидел свет. Проект вырос в нечто огромное и неуправляемое. В то же время Windows XP, на котором основывался Longhorn, начал подвергаться атакам злоумышленников, и Microsoft направила свои усилия на усиление безопасности Windows XP и Windows Server 2003, результатом которых стали Windows XP Service Pack 2 и Windows Sever 2003 Service Pack 1, а затем занялась разработкой следующей операционной системы, базирующейся на старых принципах и ныне известной как Windows Vista.
Одной из главных жертв смены курса разработки Windows стала .NET. Windows Vista, хоть и имела некоторые радикальные изменения, оставила всю концепцию WinFX за бортом. Avalon (названный Windows Presentation Framework — WPF) был включен в систему, но не являлся частью ядра. Единственным значительным носителем .NET-кода в Windows Vista и Windows 7 является Media Center (и даже он не использует WPF). Все остальное — старый добрый Win32, причем обновленный и расширенный. В него были добавлены многочисленные низкоуровневые функции, а также поддержка изменений в графической системе, вроде миниатюр запущенных приложений на панели задач или темы Aero Glass. Никакие из этих изменений с WPF нормально не работали.
Всему этому было несколько причин, например, отсутствие необходимого количества времени, чтобы переписать все, используя .NET. Но, возможно, более значимой причиной стало внутреннее деление Microsoft на группы.
Windows разрабатывался в группе Windows Division (WinDiv), а .NET — в группе Developer Division (DevDiv), которая в свою очередь являлась частью группы Server and Tools business. И хотя логично предположить, что эти две группы действовали согласованно, это было не так. Не по чьему-то злому умыслу — просто они имели разные приоритеты.
Некоторые из этих приоритетов имели определенный смысл в свое время. Так, WPF мог быть использован только .NET-программами, написанными на C# или Visual Basic.NET. Весь его API являлся недоступным для программ, написанных на C++, что являлось значительным припятствием для переноса существующих приложений на WPF. Это имело смысл в том случае, если все новые программы должны были разрабатываться, используя платформу .NET, но, когда планы изменились, и Win32 вернула себе звание главного инструмента разработки, это стало большой проблемой. Microsoft не могла использовать WPF для создания элегантных векторных масштабируемых аппаратно-ускоренных интерфейсов в своих основных приложениях.
Другие приоритеты являлись результатом банального несоответствия области деятельности WinDiv и DevDiv. Целью DevDiv было сделать .NET максимально удобной платформой для разработчиков, путем добавления новой функциональности и создания библиотек и инструментов вроде Silverlight. Для WinDiv было важно сохранить вышеупомянутую обратную совместимость, надежность, а также исправить имеющиеся технические неисправности. И то, и другое, безусловно, было важно, но DevDiv не подчинялась WinDiv и не уделила ей должного внимания. В результате WinDiv было не удобно работать с .NET, и было удобно работать без него.
Последующие обновления .NET улучшили ситуацию, но урон уже был нанесен. WinDiv, недовольная работой DevDiv, проигнорировала их работу, и Windows 7, также как и ее предшественница, использует .NET только для Media Center. Все новые API Windows 7 являются классическими Win32 API и не имеют прямого доступа для .NET-программ, а обычные Win32 приложения так и не получили замечательный фреймворк для построения пользовательских интерфейсов.
Windows 8 положит всему этому конец.
PS. Это была первая часть перевода, и опубликована по просьбе andrewpey. Спасибо Tutufa за инвайт.
Update.
Вторая часть перевода здесь
От переводчика: следует понимать, что вся вышеизложенная информация является лишь домыслами не имеющего отношения к Microsoft автора, и представлена здесь исключительно для понимания проблем, стоящих перед Windows.
Многие из них, что естественно, задались вопросом, который пока не получил ответа: «Как я смогу использовать имеющийся у меня опыт для разработки новых приложений?» Microsoft же хранит молчание и не планирует сообщать ничего до конференции BUILD (бывшая PDC) в сентябре.
Но, вероятно, не все так мрачно, как многие думают. Ранние сборки Windows 8 утекли в интернет, и были приложены значительные усилия, чтобы понять, как они работают. Что ж, все выглядит так, словно разработка приложений под Windows 8 не только не ужасна, но и наконец-то сможет избавить разработчиков от многих раздражающих препятствий на их пути. Если у Microsoft получится реализовать все запланированное, следующая версия Windows станет настолько же важным релизом, насколько важным должен был стать релиз Windows Longhorn.
Немного истории
Чтобы понять, что к чему, следует провести некоторый исторический экскурс.
До того, как была представлена платформа .NET, Windows-приложения разрабатывались двумя способами. «Большие» приложения, такие как Office, Photoshop или Netscape Navigator, писались с использованием Win32 API и С++. Win32 API это большой набор функций, предоставляющих низкоуровневый доступ к таким вещам, как отображение графики и пользовательского интерфейса, передача данных по сети, доступ к файловой системе, а также к множеству других менее очевидных, вроде управления безопасностью.
Win32 API решал множество задач, но многие из них не самым лучшем образом, а некоторые вообще никак. Так, несмотря на наличие функций для доступа к базам данных, разрабатывать приложение, активно их использующее, было весьма неудобно. Но куда более актуальной проблемой являлось то, что Win32 API обладает лишь базовым набором инструментов для построения пользовательского интерфейса, и в нем отсутствовали какие-либо средства для контроля разметки. Каждая кнопка, каждое поле и панель инструментов должны были быть позиционированы вручную разработчиком. Если разработчик хотел, чтобы положение элементов менялось с изменением размеров окна, без проблем — он всего лишь должен был заново размещать их при каждом изменении. Конечно, со временем появилось множество библиотек, которые служили прослойкой между программистами и операционной системой, упрощая отрисовку интерфейсов (в том числе, библиотека MFC от Microsoft), но необходимость погружаться в дебри Win32, чтобы заставить все работать так, как вам нужно, не исчезла.
Другим способ разработки приложений для Windows был Visual Basic. Благодаря ему некоторые задачи решались действительно просто — в частности, доступ к БД и создание пользовательских интерфейсов — что сделало Visual Basic королем в мире корпоративных приложений, от которых требовалось ненамного больше, чем брать информацию из базы данных, показывать ее пользователю и выводить форму для внесения новых данных в БД. Со всем этим Visual Basic справлялся безупречно. Со всем остальным у него были проблемы, так как Visual Basic не мог использовать многие функции Win32. Также Visual Basic не поддерживал довольно популярную парадигму ООП.
И тут появилась платформа .NET и все изменила. .NET дала разработчикам легкость использования Visual Basic, но без его неприятных недостатков. Аналогично Visual Basic, .NET предоставляла удобные инструменты для построения пользовательских интерфейсов и взаимодействию с базами данных, то есть в высшей степени подходила для разработки корпоративных приложений. Но, в отличие от Visual Basic, .NET также сделала доступ к Win32 просто, неловко сказать, одной из своих функций. Платформа быстро набирала обороты в корпоративной среде, и многие новые коммерческие проекты были основаны именно на ней.
Мечта по имени Longhorn
Windows XP, вышедший за год до появления .NET, разумеется, не использовал эту технологию. Но, на PDC в октябре 2003 Microsoft пообещала это исправить, выпустив Windows Longhorn. Эта версия Windows должна была иметь .NET FX (так .NET называли внутри компании) как часть ядра операционной системы, а .NET FX, в свою очередь, давала дорогу новой платформе WinFX — Windows Framework. Помимо прочего, WinFX включала в себя абсолютно новый способ разработки векторных масштабируемых аппаратно-ускоренных пользовательских интерфейсов, названный Avalon. Сам Windows должен был быть написан с использованием WinFX в собственных приложениях, таких как проводник, калькулятор и так далее, а .NET — стать главным средством создания приложений для Windows. Win32 был бы оставлен для обратной совместимости, но заморожен и забыт.
Longhorn должен был похоронить старые способы написания программ и начать новую эру современной разработки, не обремененной архитектурными решениями десяти-пятнадцатилетней давности.
Как мы все знаем, Longhorn так и не увидел свет. Проект вырос в нечто огромное и неуправляемое. В то же время Windows XP, на котором основывался Longhorn, начал подвергаться атакам злоумышленников, и Microsoft направила свои усилия на усиление безопасности Windows XP и Windows Server 2003, результатом которых стали Windows XP Service Pack 2 и Windows Sever 2003 Service Pack 1, а затем занялась разработкой следующей операционной системы, базирующейся на старых принципах и ныне известной как Windows Vista.
Одной из главных жертв смены курса разработки Windows стала .NET. Windows Vista, хоть и имела некоторые радикальные изменения, оставила всю концепцию WinFX за бортом. Avalon (названный Windows Presentation Framework — WPF) был включен в систему, но не являлся частью ядра. Единственным значительным носителем .NET-кода в Windows Vista и Windows 7 является Media Center (и даже он не использует WPF). Все остальное — старый добрый Win32, причем обновленный и расширенный. В него были добавлены многочисленные низкоуровневые функции, а также поддержка изменений в графической системе, вроде миниатюр запущенных приложений на панели задач или темы Aero Glass. Никакие из этих изменений с WPF нормально не работали.
Всему этому было несколько причин, например, отсутствие необходимого количества времени, чтобы переписать все, используя .NET. Но, возможно, более значимой причиной стало внутреннее деление Microsoft на группы.
Windows разрабатывался в группе Windows Division (WinDiv), а .NET — в группе Developer Division (DevDiv), которая в свою очередь являлась частью группы Server and Tools business. И хотя логично предположить, что эти две группы действовали согласованно, это было не так. Не по чьему-то злому умыслу — просто они имели разные приоритеты.
Точка напряжения
Некоторые из этих приоритетов имели определенный смысл в свое время. Так, WPF мог быть использован только .NET-программами, написанными на C# или Visual Basic.NET. Весь его API являлся недоступным для программ, написанных на C++, что являлось значительным припятствием для переноса существующих приложений на WPF. Это имело смысл в том случае, если все новые программы должны были разрабатываться, используя платформу .NET, но, когда планы изменились, и Win32 вернула себе звание главного инструмента разработки, это стало большой проблемой. Microsoft не могла использовать WPF для создания элегантных векторных масштабируемых аппаратно-ускоренных интерфейсов в своих основных приложениях.
Другие приоритеты являлись результатом банального несоответствия области деятельности WinDiv и DevDiv. Целью DevDiv было сделать .NET максимально удобной платформой для разработчиков, путем добавления новой функциональности и создания библиотек и инструментов вроде Silverlight. Для WinDiv было важно сохранить вышеупомянутую обратную совместимость, надежность, а также исправить имеющиеся технические неисправности. И то, и другое, безусловно, было важно, но DevDiv не подчинялась WinDiv и не уделила ей должного внимания. В результате WinDiv было не удобно работать с .NET, и было удобно работать без него.
Последующие обновления .NET улучшили ситуацию, но урон уже был нанесен. WinDiv, недовольная работой DevDiv, проигнорировала их работу, и Windows 7, также как и ее предшественница, использует .NET только для Media Center. Все новые API Windows 7 являются классическими Win32 API и не имеют прямого доступа для .NET-программ, а обычные Win32 приложения так и не получили замечательный фреймворк для построения пользовательских интерфейсов.
Windows 8 положит всему этому конец.
PS. Это была первая часть перевода, и опубликована по просьбе andrewpey. Спасибо Tutufa за инвайт.
Update.
Вторая часть перевода здесь
От переводчика: следует понимать, что вся вышеизложенная информация является лишь домыслами не имеющего отношения к Microsoft автора, и представлена здесь исключительно для понимания проблем, стоящих перед Windows.
