Windows 8 для разработчиков: возрождение мечты? (1/2)

http://arstechnica.com/microsoft/news/2011/06/windows-8-for-software-developers-the-longhorn-dream-reborn.ars/
  • Перевод
Ранее в этом месяце 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 просто, неловко сказать, одной из своих функций. Платформа быстро набирала обороты в корпоративной среде, и многие новые коммерческие проекты были основаны именно на ней.

Мечта по имени 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.

Поделиться публикацией

Комментарии 98

    +36
    Windows 8 положит всему этому конец.

    Выпилит оконные функции из WinAPI и приделает Xorg сервер
      +34
      Вы так говорите, как будто у X Window никаких проблем нет. На самом деле, там всё куда запущеннее, чем в Windows. В интернете есть несколько очень хороших статей на эту тему, особенно впечатляют несогласованные попытки расширения API разными командами.
        +14
        Я думаю, автор комментария тонко пошутил, а его заминусовали. Злые вы.
          +4
          а вы понимаете юмор
          оригинальное продолжение статьи носит такой же тонкий характер, и почему M$ ломанулось на уже исследованную нишу «пишите приложения на HTML» непонятно, ведь ждут её там только непонимание со стороны «традиционных» разработчиков и новая пачка годных мест для дыр (один WinAPI из JS чего стоит)
          +5
          хм. ну тогда wayland
          –9
          Ну почему в каждом топике про какие то новые функции Windows найдётся кто то с Xorg?
            –8
            Ну выразил несогласие, ну минуснул, но карма то тут причём?
          +31
          >> платформа .NET, которую компания продвигала на протяжении последнего десятилетия как основную для разработчиков, не будет использоваться при построении приложений для нового интерфейса Windows 8.

          это бред, нигде и никто такого не заявлял
            +5
            Как вы верно заметили в твиттере, это все спекуляции, и я это прекрасно понимаю. Тем не менее, статья является всего лишь переводом, и, как мне кажется, менять оригинальную мысль автора я не имею права.
            • НЛО прилетело и опубликовало эту надпись здесь
              +4
              Как минимум по презентации понятно что будет поддерживаться интерфейс metro-html5 и стандартный aero-win32-wpf. От стандартного они не откажутся — бизнес не поймет. Думаю в итоге будет еще один бардак в Windows.
                0
                Бизнес давно уже мигрирует в сторону веб. Монстроидальные программные комплексы сдают под натиском веб-сервисов и веб-ориентированных приложений.
                  +1
                  Ага… Монстроидальные программные комплексы сдают под натиском монстроидальных (странно… это слово проверяльщик орфографии предлагает заменить на «геморроидальных»… к чему бы это ?) веб-ориентированных приложений… ))
              +6
              отправил инвайт
                0
                Спасибо )
                0
                Надо было вторую часть статьи сначала переводить имхо. Так вот, всё это WinRT и DirectUI конечно красиво и идеалогически правильно, только имеет одну маааленькую проблемку — этого всего нет и не будет на Windows 7, Vista и XP, а XP до сих пор 60%. Значит разработчик (особенно корпоративного софта), желающий накрыть максимум целевой аудитории, будет писать на старом добром Win32 (процедурном, 25-летней давности — как сказано в статье).
                  0
                  Под Win32 естественно следует понимать и все нативные фреймворки (MFC, ATL, VCL, QT, ...) которые через него отрисовываются.
                    +2
                    Вы так говорите, как будто процедурность это плохо:)
                    На самом деле надо же с чего-то начинать. Win98 с его дос-режимом вымер достаточно быстро, хотя между ним и ХР всего 3 года разницы.
                    • НЛО прилетело и опубликовало эту надпись здесь
                      +1
                      вы откуда цифры берете? и проверяете ли их перед тем как други раздавать?
                      доля XP по версии StatCounter ~46%
                      gs.statcounter.com/#os-ww-monthly-201005-201105

                      к моменту выхода Win8, доля XP на рынке будет очень небольшой
                        +1
                        Сайт с офисным софтом под Windows:

                        1 Windows XP — 36,05%
                        2 Windows 7 — 26,20%
                        3 Другие 25,41%
                        4 Windows Vista — 5,90%
                        5 Windows 2000 — 1,65%
                        6 Windows Server 2003 — 1,28%
                        7 Linux — 1,20%
                        8 Mac OS — 0,92%
                        9 iPhone — 0,31%
                        10 Windows NT — 0,27%
                        11 Android OS — 0,26%
                        12 Windows 98 — 0,20%
                        13 BlackBerry — 0,12%
                        14 iPad — 0,08%
                        15 Windows ME — 0,05%
                        16 iPod — 0,03%
                        17 Windows CE — 0,03%
                        18 Sun OS — 0,02%
                        19 Windows 95 — 0,01%
                          +1
                          Это относительно всех систем. А вот если посмотреть на гугл аналитику (тот же период на том же сайте, но сделать выборку только по Windows):

                          1. XP — 50.34%
                          2. 7 — 40.24%
                          3. Vista — 7.25%
                          4. Server 2003 — 1.76%
                          5. 2000 — 0.31%
                          6. 98 — 0.07%
                          7. NT — 0.03%
                          8. ME — 0.01%
                          9. CE > 0.00%
                          +1
                          46 тоже много.
                          Будет небольшой, или не будет — сложно сказать наверняка.
                        –12
                        А причём тут Photoshop? Adobe же вроде на Qt перешли, разве нет?
                          0
                          Искренне радуюсь, что CSS и HTML5 стают кросплатформенным стандартом для построения интерфейсов.
                            +6
                            >> Вместо этого, разработчики должны использовать HTML5 и JavaScript.
                            Это как бы намек на открытость кода разрабатываемых приложений? И теперь все кому не лень будут копипастить чужой код и дизайн приложений

                            Да и как-то сомнительно всё с JS будет, на сколько мощный не будет процессор, всегда Microsoft придумает технологию (решение) которая будет тормозить и на нём.

                            Раньше для ОС (win 98/ win 2000/ Linux) хватало 500 мгц проца и 64/128 оперативы, а сейчас жалуются что и андроид и прочие поделки тормозят на 700 мгц мобильных процах с 256 метрами памяти. Куда только мир катится, своими красивыми обещаниями о легкости использования и разработки они прикрывают одно — желание нажиться на том, что люди будут тратить деньги на новое железо, чтобы их ОС не тормозила. В общем негодую.
                              –5
                              Ага, особенно Linux.
                                +3
                                Вы не замечаете, что ваши фразы
                                всегда Microsoft придумает технологию (решение) которая будет тормозить и на нём.

                                и
                                Раньше для ОС (win 98/ win 2000/ Linux) хватало 500 мгц проца и 64/128 оперативы, а сейчас жалуются что и андроид и прочие поделки тормозят на 700 мгц мобильных процах с 256 метрами памяти.

                                тотально противоречат друг другу?
                                  +2
                                  А вы вспомните какие были компьютеры в 1999м году, когда вышла Windows 2000. У меня Win2k в виртуалке ещё живёт, она даже там летает.
                                    +1
                                    Я говорю про нынешнюю обстановку. Хотя и в тех года было точно также. win 98 работала на 100 мгц отлично, а XP уже требовала намного большего. А после выхода SP2 XP стало еще больше требовать. Я конечно понимаю что безопасность, графика итд итп, но всё же дело в том, что сейчас пошла концепция что проще человеку купить лучшее железо, чем программисту оттачивать алгоритм программы, доводя его до совершенства и быстродействия.
                                      0
                                      По-вашему, между 98 и XP нет существенных отличий, а, следовательно, они должны жрать одинаково?
                                        +2
                                        И да, железо, зачастую, действительно стоит дешевле труда хорошего программиста.
                                          0
                                          А разве труд хорошего программиста не включает в себя оптимизацию? Чем обычный от хорошего тогда отличаться должен?
                                            +1
                                            Включает. Я про то и говорю — многим проще покупать более мощное железо, чем платить за оптимизацию.
                                          0
                                          Откройте папку с сотней файлов в win2k и win7. Сможете сказать — почему такая разница в скорости?
                                            0
                                            В win7 быстрее из-за лучшего кэша? Или тут о explorer и генерации миниатюр?
                                              +1
                                              w7 как раз медленнее. никаких миниатюр обычный список.
                                                0
                                                Вообще-то скорость открытия папки с файлами в основном зависит от файловой системы, а не ОС.
                                                  0
                                                  NTFS у меня везде. А последнее время w7 ещё и на быстром ssd — ситуацию это сильно не улучшило (с скоростью открытия папок). Ибо и так ясно — проблема где-то в другом месте.
                                                    0
                                                    отключи обновление времени доступа к файлам.
                                                    кроме того в режиме список иконки тоже подгружаются.
                                                    сделай dir из консоли — увидишь реальную скорость winapi
                                                      0
                                                      в win2k тоже подгружаются иконки-то. а время доступа по умолчанию везде выключаю.
                                          +1
                                          проще человеку купить лучшее железо, чем программисту оттачивать алгоритм программы, доводя его до совершенства и быстродействия.

                                          Это вполне разумно.
                                          И это ещё и быстрее. Современные программы достаточно быстро меняются. Каждую версию доводить до совершенства — жизни не хватит.
                                            0
                                            Современные программы достаточно быстро меняются.

                                            Всегда ли пользователю нужны эти изменения?
                                              0
                                              А что, пользователей заставляют обновляться? Можно собрать окружение и из старых версий программ. Но не стоит ожидать, что под них будут хоть какие-то обновления.
                                                0
                                                В том-то и дело, что заставляют. Бог с ними с обновлениями, но законных способов приобрести старые версии закрытого софта как правило нет. И приходится пользователям при расширении парка десктопов/серверов или мучиться с гетерогенной средой или обновлять софт и на старых машинах (а если он не заработает, то и новые машины покупать).

                                                Про внешний «прессинг»я умолчу. Достаточно внутреннего, чтобы не любить компании, заставляющие пользователей обновлять софт, да ещё небесплатно.
                                                  0
                                                  > А что, пользователей заставляют обновляться?
                                                  Да, например форматами файлов. Сколько обычно версий Photoshop и Illustrator стоит у дизайнеров, постоянно обменивающихся файлами с заказчиками?
                                          +4
                                          Ну как бы, требования пользователей и функциональность программ тоже выросла. Вот вы упомянете мобильные платформы — делов-то, сделать статичный не-скинуемый интефейс на уровне ядра, писать все аппликации на С+асм, чтоб быстрее работало, поддержку мультимедии исключить, и перезагружать два раза в день. Будет просто летать, даже на гораздо более слабых системах. Вот только продать пользователям такую «быструю» систему будет несколько проблематично…
                                            –2
                                            «Как бы» выросла? То есть на самом деле не выросла?
                                              –1
                                              «как бы» находится в начале фразы, а не перед словом «выросла»
                                            +1
                                            А как жить-то дальше? Купили одно железо и 10 лет сидим за ним, да оптимизируем программки? А деньгам откуда взяться? Если потребитель не будет покупать железо и софт — так и заглохнем. Или на подписку всех перевести? Ежемесячная плата за винду подойдёт? К тому же: 4 гигабайта RAM — 1300р., 1 терабайт HDD — 1700р., 4-ядерный процессор с частотой 3 гигагерца — 3000р. Где проблема-то?

                                            Андроид — плохой пример — опенсорс же. Там «работет — уже хорошо». Под него и девелопить — то ещё «развлечение» с таким-то эмулятором. Под iOS, например, ничего не тормозит с теми же характеристиками, хотя там тоже никто особо «оптимизацией» не занимается.
                                            0
                                            А откуда взялась информация 2й части статьи (пока еще не переведенной?)
                                            Как-то уж слишком идиалистично.
                                              0
                                              Все это лишь предположения автора статьи на основе исследований энтузиастами ранних сборок Windows 8.
                                              +11
                                              Интерфейс десктопных приложений на языке гипертекстовой разметки. Ага, и 32-ядерный процессор с 100500 GB памяти, чтоб ворд не тормозил.
                                                +1
                                                QML и XAML же не тормозят
                                                  0
                                                  У одного меня в 2010 студии «легкие» рывки? :)

                                                  А вот производительностью и удобством QML я очень доволен, однако стоит различать, что она ориентирована на мобильные платформы, и проектов типа «MS VS» на ней не будет никогда…
                                                  +3
                                                  А почему, собственно, Вы уверены, что декларативное описание интерфейса — это плохо (и очень медленно)?
                                                    +4
                                                    Эм… Файрфоксом тут многие пользуются.
                                                      +5
                                                      И памяти он много не жрет, нет. Сам рпользуюсь, знаю.
                                                        +1
                                                        А еще thunderbird, если не путаю.
                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                        +4
                                                        Очень любопытно как люди хоронят все подряд .Net, WPF, Win32… и даст нам Бог HTML 5.

                                                        Категорический не согласен с автором в его отожествленний .Net и WPF и сравнивания с WPF. .Net самобытный продукт по сложности сравним с самой Windows и к тому же способный жить и на других платформах.

                                                        Что касается HTML5 + JS, ну налепит DevDiv кривой шаблончик для VS, и на том все и закончится. Как ни как они то и решают каким образом программы будут разрабатываться.
                                                          +2
                                                          Просто раньше главным преимуществом MS была армия разработчиков, владеющих WinAPI. А потом, по мере введения новых технологий построения интерфейсов, начались расколы: MFC, STL, COM, .NET, WPF, Avalon. Разработчики видят, что нельзя доверять «новым, самым лучшим платформам MS для построения интерфейсов», потому что платформы эти живут недолго, и очень быстро сменяются новыми, ещё более «самыми лучшими». Вот и хоронят их.

                                                          А разработчики смотрят в сторону сторонних фреймворков, которые развиваются стабильно и последовательно (Qt тот же), или в сторону WinAPI, который чёрта лысого выкинут ещё 100500 лет, ибо корпораты не поймут, или — собственно — web-парадигмы разработки с HTML и JS.
                                                            +1
                                                            Мне вот стыдно, да, но я ещё пишу с использованием MFC :) Получается быстро, просто и не дорого. Все библиотеки давно в системе. Программа с фиговой тучей строк занимает 400кб. Быстро работает, быстро запускается — все довольны.
                                                              0
                                                              Так нет, пишите и дальше, если результат устраивает!

                                                              Просто в некоторых случаях, к примеру, нужна ещё и кроссплатформенность, а тут уже winapi и основанные на ней технологии не подойдут (есть, конечно, и исключения, вроде пикасы с либвайн, но это редкость, всё же).

                                                              Возникает забавный парадокс: с одной стороны, MS не должна использовать для UI технологию, доступную для других платформ, потому что а как же тогда вендор лок ин? С другой, MS должна делать так, как удобно разработчикам, чтобы они предпочитали её платформу, а разработчики хотят писать сразу для всех платформ :)
                                                                +5
                                                                Мусье знает толк в извращениях… MFC… бррр, аж передёрнуло…
                                                                  +1
                                                                  Ничего здесь стыдного нет. Стыдно не понимая указателей, доказывать, что они не нужны. А MFC — это отлично.
                                                                  +2
                                                                  Ну погодите, MFC, STL, COM, .NET, WPF — причем тут раскол? Все эти штуки делаю очень разные вещи и друг друга не сключают.
                                                                  MFC — графический фреймворк для C++
                                                                  STL — библиотека шаблонов, очень даже кроссплатформенная для того же С++
                                                                  COM — технология взаимоинтеграции приложений
                                                                  .Net — Отдельный мир (конкурирующий с JAVA)
                                                                  WPF — графический фреймворк для создания интерфейсов пользователей .Net (один из многих)

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

                                                                  Я считаю что сегодня для новых платформ разработки под PC самое главное как быстро и сильно корпоративные клиенты ее полюбят.

                                                                  QT очень прикольная вещь.
                                                                +1
                                                                Я главного не понимаю — какая разница, на чем написаны системные программы и встроенные аппликации? Какое до этого дело разработчикам сторонних приложений и пользователям? С какой радости Майкрософт будет переписывать программы, на которые потратили сотни тысяч человекочасов на новом языке, если они и так работают? Ради религиозной чистоты?
                                                                  +2
                                                                  Ради мониторов в 300dpi. Растровые интерфейсы должны по-немногу отходить в прошлое, ибо иначе чёрта лысого мы вообще увидим такие мониторы на десктопах. Очевидно, что унаследованный код будет всячески мешать этому процессу.
                                                                    0
                                                                    Во-первых проблемы переносимости майкрософтовских программ — это их проблемы, без связи растровые они или векторные.
                                                                    Во-вторых, растровые — не значит не масштабируемые. И вектор не решает всех проблем автоматом. Например, 9-и сегментные картинки, которые используются для нелепейший-растягивающихся элементов в скинах, гораздо сложнее реализовать в векторе, чем в растре. Потом, существующее железо, на порядок-другой эффективнее умеет рисовать текстурированные прямоугольники, чем растеризировать градиенты и сглаженные кривые.
                                                                      +1
                                                                      Простите, может, я соображаю плохо, но зачем в векторном интерфейсе 9-сегментные картинки?

                                                                      Насчёт железа согласен, но в десктопах gpu при обычной «офисной работе» без дела простаивают, вот пусть и растеризуют вектор :) Да и в мобильних девайсах идёт к тому же.
                                                                        +2
                                                                        s/нелепейший/нелинейно/ (спелчекер постарался)

                                                                        Простите, может, я соображаю плохо, но зачем в векторном интерфейсе 9-сегментные картинки?

                                                                        Потому как далеко не все элемента UI можно растягивать или сжимать пропорционально. Скажем у вас есть бекраунд для кнопки. Если на том-же самом DPI вам надо растянуть кнопку в 2 раза — её рамка и тень, при этом не должны стать в два раза толще. В 9-сегментных картинках, углы не растягиваются, боковые сегменты растягиваются только по одной оси, а центральный пропорционально. При этом совершенно не важно растровый он или веркторный, в векторном действительно удобнее масштабировать все на другую резолюцию, но масштабирование UI элементов это не отменяет.
                                                                        Причем если 9-сегментное масштабирование сделать легко в растре, то в векторе это нетривиальная задача. Представьте себе, что у вас границу сегментов пересекает фигура с градиентной заливкой. Как вы её нелинейно смасштабируете или разрежете на куски? Все равно, скорее всего, придется её растеризировать, а потом все делать так-же как и в растровой картинке.
                                                                  0
                                                                  Я так и не понял, это .NET Introspection (вроде того, что в GTK3, вживую видно в JS-консоли гнома3) или только JS и только для интерфейса?
                                                                    0
                                                                    Прочитал оригинал. Всё-таки до GObject Introspection (динамический биндинг к основному API из любого, в том числе и скриптового языка) не дотягивает. Всего лишь (новый) winapi↔.NET мост + JS/HTML для интерфейса.
                                                                    +2
                                                                    Windows разрабатывался в группе Windows Division (WinDiv), а .NET — в группе Developer Division (DevDiv), которая в свою очередь являлась частью группы Server and Tools business.

                                                                    … И работники Windows Division обнаружили в .NET фатальный недостаток.
                                                                      +6
                                                                      Спасибо за перевод очень интересно.

                                                                      Искренне желаю Microsoft успеха в построении новой современной красивой системы. Очень хочется чтобы программы и интерфейсы в виндовс были такими-же продвинутыми и единообразными как в Mac.
                                                                      На хабре принято ругать Microsoft. Большинство искренне желают им провала. Я этого не понимаю. Вы что мне предлагаете переходить на мак? Мак мини 30 000, мак бук про 60 000, ай мак 70 000. У меня уже есть 2 китайских десктопа и ноутбук ASUS. Я бы хотел запустить современную красивую и эффективную платформу на них.
                                                                      Неужели вы не хотите покупать компьютеры дешево? Пусть Microsoft сопутствует удача!
                                                                        –1
                                                                        > На хабре принято ругать Microsoft. Большинство искренне желают им провала. Я этого не понимаю. Вы что мне предлагаете переходить на мак?

                                                                        Политика вендор лок-ин пагубна. Основная нелюбовь к майкрософту именно из-за этой их политики и между прочим большая часть проблем в их софте — из-за неё же.
                                                                        Провал майкрософта означает активное развитие других операционных систем. В идеале хотя бы еще 2-3. Если рынок ОС будет примерно поровну поделен между хотя бы тремя игроками — будет здоровая конкуренция, что означает кроссплатформенность программ, повышение их качества и снижение цены.

                                                                          +3
                                                                          Нет это означат что на PC не будет современной системы. Можно конечно попробовать deskpoр linux, но это сильно на любителя. Я например не вижу, кто-бы сегодня смог написать свой виндовс, который могли бы использовать люди.
                                                                            –6
                                                                            Вы предвзяты.
                                                                              –2
                                                                              Во первых если под «современной системой» вы подразумеваете виндоус — то он в любом случае никуда не денется в ближайшие… много лет. Даже в случае очень серьезных проблем у майкрософта вполне очевидно, что за виндоус долгие и долгие годы будет сохраняться лидирующая позиция и он явно будет одной из этих трех-четырех ОС. Так просто выбраться из виндор лока не получится.
                                                                              Во вторых написать ОС — не такая уж невыполнимая. Основные проблемы это софт и драйвера. Софт, при наличии posix-совместимости, достаточно просто портируется. Нужно всего лишь портировать gcc и сделать пару патчей для основных тулкитов, дабы умели работать с твоей графической оболочкой.

                                                                              Намного хуже ситуация с драйверами. Фактически сейчас она не решается никак. Писать все драйвера самостоятельно слишком трудозатратно и никто не может себе этого позволить, к тому же драйвера для многих устройств отсутсвуют в открытом виде и спецификации закрыты, а производители плевать хотели на любые ОС кроме виндоус.
                                                                              Но, если позиции виндоус будут не так крепки как сейчас — почему бы и нет? У альтернативных ОС появится шанс. А у пользователей — выбор.
                                                                              А выбор — это замечательно.
                                                                                0
                                                                                > а производители плевать хотели на любые ОС кроме виндоус
                                                                                Порою даже хуже: одни плевать хотели на любые ОС, кроме 32-разрядных Windows 7, другие плевать хотели на любые ОС, кроме 64-разрядных Windows 7 (см. например страницу скачивания драйверов для Windows-версии Acer ICONA), третьи выложили в своё время драйвера для Windows XP, а для Windows 7 обновлять отказываются (см. всех производителей ноутбуков), заставляя покупать те же устройства, но в новом корпусе, только из-за наличия у новых моделей драйверов, совместимых с Windows 7.

                                                                                Тут есть желающие сказать «в Windows всё замечательно с драйверами и никогда нет никаких проблем с их работой!»?
                                                                                  +2
                                                                                  А не кажется ли вам, что словосочетание «современная система» в одном контексте с POSIX выглядит странно? Сколько лет посиксу? Мне кажется если уж писать альтернативу, то надо спроектировать современную систему, для современных задач, под современно оборудование. Тем более у нас уже есть Linux — зрелая посикс совместимая свободная ОС. Если считать посикс венцом развития для ОС, то можно более ничего не писать =)
                                                                                    +2
                                                                                    Хочу внести ясность. Я ни в коем случае не против Posix и unix в целом. Просто эта статья о том, что делает Microsoft чтобы сделать систему более продвинутой, более удобной для разработки с более богатыми API. Все это, как мне кажется, находится на более высоком уровне нежели системные вызовы и архитектурные решения POSIX. Тот-же .NET и WPF теоретически можно было запустить и на Linux.
                                                                                    То есть написание очередного юникса никак не приближает нас к созданию нового продвинутого виндовса.
                                                                                      0
                                                                                      Какое отношение имеет стандарт api для достаточно ограниченного числа системных приложений к какому то «венцу развития»? Наличие посикс-совместимости всего лишь упрощает портирование имеющегося софта. При этом у вас может быть хоть какое-нибудь сверхсовременное экзо-ядро, новаторские подходы к реализации вывода и отображения графики и что угодно еще. И при этом система вполне может не быть ни юниксом ни даже юникс-лайк. Например Haiku.
                                                                              +3
                                                                              Рискую кармой, но Денис Попов (автор BolgenOS) по сути является пророком. Он еще год назад писал о «рабочем столе на html». Вот цитата:
                                                                              «Вы говорите что HTML невозможно программировать. По-моему вы просто жутко наелись конфет…
                                                                              Этот язык заводится из простого текстового редактора и для его исполнения нужен только веб-браузер, к вашему сведению сидя на Windows я писал в блокноте копию рабочего стола...»

                                                                              По сути microsoft уже давно к этому идет. XAML на котором предлагают разрабатывать WPF приложения уже «почти html», мысль «верстать» традиционные приложения вместо того чтобы собирать их из компонент представляется мне логичной эволюцией. Подумайте сами сколько времени вы потратили бы чтобы например сделать переключалку табов с картинкой 128х128 в заголовке вместо текста? Если вы делаете web приложение то на html можно сверстать это за 30 секунд.

                                                                              По поводу отказа от .NET в пользу JavaScript сомневаюсь. Во-первых microsoft потратила очень много сил на то чтобы перевести все продукты под единую .NET платформу и интегрировать между собой (посмотрите хотябы на элегантность Power Shell и на возможность интегрировать .NET функции на c# в SQL сервер). Во вторых microsoft не является ярым сторонником открытых стандартов, а javascript таковым является, да и пальму первенства по производительности уверенно держит гугл.

                                                                              Скорее всего переход на «html и javascript» будет «переходом на XAML и WPF»
                                                                                +2
                                                                                XAML на котором предлагают разрабатывать WPF приложения уже «почти html», мысль «верстать» традиционные приложения вместо того чтобы собирать их из компонент представляется мне логичной эволюцией. Подумайте сами сколько времени вы потратили бы чтобы например сделать переключалку табов с картинкой 128х128 в заголовке вместо текста? Если вы делаете web приложение то на html можно сверстать это за 30 секунд.


                                                                                Возьмём код на WPF:

                                                                                
                                                                                        <TabControl >
                                                                                            <TabItem>
                                                                                                <TabItem.Header>
                                                                                                    <Image Source="Images\Image.png" Width="128px" Height="128px"/>
                                                                                                </TabItem.Header>
                                                                                            </TabItem>
                                                                                        </TabControl>
                                                                                


                                                                                1. В каком месте это уже «почти html»?

                                                                                2. Это «вёрстка» или «сборка из компонентов» и почему это взаимоисключающие понятия?

                                                                                3. Чем решение на HTML и, надеюсь, CSS лучше?
                                                                                  +2
                                                                                  и тут не показана главная фишка WPF — биндинги.
                                                                                    +1
                                                                                    Главная фишка WPF — это не только биндинг. Да, биндинг в WPF — это круто (это действительно круто)!

                                                                                    Но помимо биндинга и гибкости построения сложного визуального интерфейса там есть еще Маршрутизируемые события (RoutedEvents), Свойства и объекты зависимости (DependencyObject и DependencyProperty), прикрепляемые свойства (Attached Property).

                                                                                    Если копнуть глубже, то это еще использование DirectX вместо GDI/GDI+, наличие Silverlight позволяет портировать вин приложения в браузер буквально в два клика, наличие Expression Blend (Studio) позволяет именно рисовать красивые нитерфейсы, не заботясь о логике обработки.

                                                                                    Так что биндинг — это всего-лишь вершина айсберга.
                                                                                      +1
                                                                                      Это понятно. Имеется ввиду что то что приведено выше хоть и лучше HTML/CSS, но не сильно. Именно биндинги + все остальные плюшки делают WPF таким отличным фреймворком.
                                                                                –4
                                                                                Очередная смена технологии от МС?

                                                                                www.memestick.com/images/MULTIPIC/BaDumTSSS.jpg
                                                                                  +2
                                                                                  Автор статьи по видимому не совсем понимает что же собой представляет .NET.
                                                                                  .NET — это платформа которая включает очень много технологий (ADO.NET/ Windows Forms / WPF/ ASP.NET etc)
                                                                                  Необходимость создавать интерфейсы на JS/HTML (пусть даже и очень сильно преувеличенная) никоим образом не отменяет платформу. Максимум чего стоит ждать — появления новой технологии в составе .NET (например какой нибудь HyperUI.NET). Но отказываться от платформы и наработок которые уже много лет прекрасно существуют и интегрируются друг с другом никто не будет.
                                                                                  Если вспомнить историю — тот же WPF который является куда более прямым конкурентом Windows Forms не привел к отказу от последнего. Обе технологии существуют и поддерживаются по сей день.
                                                                                    +3
                                                                                    Слово Hyper тоже можно сократить:)
                                                                                    0
                                                                                    Понравилось в статье: «Visual Basic [был] королем в мире корпоративных приложений <...> И тут появилась платформа .NET и всё изменила»

                                                                                    Мне нравилось писать на Win32 API. Особенно после появления утёкших исходников и wine (вместо документации). И сейчас иногда ещё в нём копаюсь — сейчас это уже как археологический артефакт, в нём хорошо видно «культурные слои». Мне кажется, что если бы MS не стремилась всё время произвести революцию в разработке ПО, то вышло бы неплохое API.
                                                                                      0
                                                                                      Win32 API действительно ужасен, только начал с ним работать и уже жалею об этом. Усугубляет ситуацию обширный опыт в Android разработке. Может немного и не корректно сравнивать java и C, но по моему для вызов нескольких функций по 6+ аргументов ради какого нибудь элементарного действия это явно перебор, даже 15 лет назад.
                                                                                        0
                                                                                        А можете прояснить зачем вам именно напрямую нужен Win API? Мне кажется, что сейчас только очень узкий круг задач требует его непосредственного применения.
                                                                                          0
                                                                                          Ну к примеру узнать имя владельца файла. То что сейчас уже есть много библиотек которые позволяют упростить разработку не делают win32 api удобнее в использовании. Да и для небольших приложений подключать библиотеки которые значительно превышают по объему само приложение не очень хороший вариант.
                                                                                            0
                                                                                            А вы пишете на голом C++? Для небольших приложений (где скорее всего скорость некритична) намного выгоднее писать на .Net.
                                                                                              0
                                                                                              Здесь я с вами полностью согласен. Но лабы по организации ОС диктуют свои правила.

                                                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                      Самое читаемое