Comments 98
Windows 8 положит всему этому конец.
Выпилит оконные функции из WinAPI и приделает Xorg сервер
Вы так говорите, как будто у X Window никаких проблем нет. На самом деле, там всё куда запущеннее, чем в Windows. В интернете есть несколько очень хороших статей на эту тему, особенно впечатляют несогласованные попытки расширения API разными командами.
Я думаю, автор комментария тонко пошутил, а его заминусовали. Злые вы.
а вы понимаете юмор
оригинальное продолжение статьи носит такой же тонкий характер, и почему M$ ломанулось на уже исследованную нишу «пишите приложения на HTML» непонятно, ведь ждут её там только непонимание со стороны «традиционных» разработчиков и новая пачка годных мест для дыр (один WinAPI из JS чего стоит)
оригинальное продолжение статьи носит такой же тонкий характер, и почему M$ ломанулось на уже исследованную нишу «пишите приложения на HTML» непонятно, ведь ждут её там только непонимание со стороны «традиционных» разработчиков и новая пачка годных мест для дыр (один WinAPI из JS чего стоит)
UFO just landed and posted this here
Ну почему в каждом топике про какие то новые функции Windows найдётся кто то с Xorg?
>> платформа .NET, которую компания продвигала на протяжении последнего десятилетия как основную для разработчиков, не будет использоваться при построении приложений для нового интерфейса Windows 8.
это бред, нигде и никто такого не заявлял
это бред, нигде и никто такого не заявлял
Как вы верно заметили в твиттере, это все спекуляции, и я это прекрасно понимаю. Тем не менее, статья является всего лишь переводом, и, как мне кажется, менять оригинальную мысль автора я не имею права.
Как минимум по презентации понятно что будет поддерживаться интерфейс metro-html5 и стандартный aero-win32-wpf. От стандартного они не откажутся — бизнес не поймет. Думаю в итоге будет еще один бардак в Windows.
отправил инвайт
Надо было вторую часть статьи сначала переводить имхо. Так вот, всё это WinRT и DirectUI конечно красиво и идеалогически правильно, только имеет одну маааленькую проблемку — этого всего нет и не будет на Windows 7, Vista и XP, а XP до сих пор 60%. Значит разработчик (особенно корпоративного софта), желающий накрыть максимум целевой аудитории, будет писать на старом добром Win32 (процедурном, 25-летней давности — как сказано в статье).
Под Win32 естественно следует понимать и все нативные фреймворки (MFC, ATL, VCL, QT, ...) которые через него отрисовываются.
Вы так говорите, как будто процедурность это плохо:)
На самом деле надо же с чего-то начинать. Win98 с его дос-режимом вымер достаточно быстро, хотя между ним и ХР всего 3 года разницы.
На самом деле надо же с чего-то начинать. Win98 с его дос-режимом вымер достаточно быстро, хотя между ним и ХР всего 3 года разницы.
вы откуда цифры берете? и проверяете ли их перед тем как други раздавать?
доля XP по версии StatCounter ~46%
gs.statcounter.com/#os-ww-monthly-201005-201105
к моменту выхода Win8, доля XP на рынке будет очень небольшой
доля XP по версии StatCounter ~46%
gs.statcounter.com/#os-ww-monthly-201005-201105
к моменту выхода Win8, доля XP на рынке будет очень небольшой
Сайт с офисным софтом под 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 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%
46 тоже много.
Будет небольшой, или не будет — сложно сказать наверняка.
Будет небольшой, или не будет — сложно сказать наверняка.
А причём тут Photoshop? Adobe же вроде на Qt перешли, разве нет?
Искренне радуюсь, что CSS и HTML5 стают кросплатформенным стандартом для построения интерфейсов.
>> Вместо этого, разработчики должны использовать HTML5 и JavaScript.
Это как бы намек на открытость кода разрабатываемых приложений? И теперь все кому не лень будут копипастить чужой код и дизайн приложений
Да и как-то сомнительно всё с JS будет, на сколько мощный не будет процессор, всегда Microsoft придумает технологию (решение) которая будет тормозить и на нём.
Раньше для ОС (win 98/ win 2000/ Linux) хватало 500 мгц проца и 64/128 оперативы, а сейчас жалуются что и андроид и прочие поделки тормозят на 700 мгц мобильных процах с 256 метрами памяти. Куда только мир катится, своими красивыми обещаниями о легкости использования и разработки они прикрывают одно — желание нажиться на том, что люди будут тратить деньги на новое железо, чтобы их ОС не тормозила. В общем негодую.
Это как бы намек на открытость кода разрабатываемых приложений? И теперь все кому не лень будут копипастить чужой код и дизайн приложений
Да и как-то сомнительно всё с JS будет, на сколько мощный не будет процессор, всегда Microsoft придумает технологию (решение) которая будет тормозить и на нём.
Раньше для ОС (win 98/ win 2000/ Linux) хватало 500 мгц проца и 64/128 оперативы, а сейчас жалуются что и андроид и прочие поделки тормозят на 700 мгц мобильных процах с 256 метрами памяти. Куда только мир катится, своими красивыми обещаниями о легкости использования и разработки они прикрывают одно — желание нажиться на том, что люди будут тратить деньги на новое железо, чтобы их ОС не тормозила. В общем негодую.
Ага, особенно Linux.
Вы не замечаете, что ваши фразы
и
тотально противоречат друг другу?
всегда Microsoft придумает технологию (решение) которая будет тормозить и на нём.
и
Раньше для ОС (win 98/ win 2000/ Linux) хватало 500 мгц проца и 64/128 оперативы, а сейчас жалуются что и андроид и прочие поделки тормозят на 700 мгц мобильных процах с 256 метрами памяти.
тотально противоречат друг другу?
А вы вспомните какие были компьютеры в 1999м году, когда вышла Windows 2000. У меня Win2k в виртуалке ещё живёт, она даже там летает.
Я говорю про нынешнюю обстановку. Хотя и в тех года было точно также. win 98 работала на 100 мгц отлично, а XP уже требовала намного большего. А после выхода SP2 XP стало еще больше требовать. Я конечно понимаю что безопасность, графика итд итп, но всё же дело в том, что сейчас пошла концепция что проще человеку купить лучшее железо, чем программисту оттачивать алгоритм программы, доводя его до совершенства и быстродействия.
По-вашему, между 98 и XP нет существенных отличий, а, следовательно, они должны жрать одинаково?
И да, железо, зачастую, действительно стоит дешевле труда хорошего программиста.
Откройте папку с сотней файлов в win2k и win7. Сможете сказать — почему такая разница в скорости?
В win7 быстрее из-за лучшего кэша? Или тут о explorer и генерации миниатюр?
w7 как раз медленнее. никаких миниатюр обычный список.
проще человеку купить лучшее железо, чем программисту оттачивать алгоритм программы, доводя его до совершенства и быстродействия.
Это вполне разумно.
И это ещё и быстрее. Современные программы достаточно быстро меняются. Каждую версию доводить до совершенства — жизни не хватит.
Современные программы достаточно быстро меняются.
Всегда ли пользователю нужны эти изменения?
А что, пользователей заставляют обновляться? Можно собрать окружение и из старых версий программ. Но не стоит ожидать, что под них будут хоть какие-то обновления.
В том-то и дело, что заставляют. Бог с ними с обновлениями, но законных способов приобрести старые версии закрытого софта как правило нет. И приходится пользователям при расширении парка десктопов/серверов или мучиться с гетерогенной средой или обновлять софт и на старых машинах (а если он не заработает, то и новые машины покупать).
Про внешний «прессинг»я умолчу. Достаточно внутреннего, чтобы не любить компании, заставляющие пользователей обновлять софт, да ещё небесплатно.
Про внешний «прессинг»я умолчу. Достаточно внутреннего, чтобы не любить компании, заставляющие пользователей обновлять софт, да ещё небесплатно.
> А что, пользователей заставляют обновляться?
Да, например форматами файлов. Сколько обычно версий Photoshop и Illustrator стоит у дизайнеров, постоянно обменивающихся файлами с заказчиками?
Да, например форматами файлов. Сколько обычно версий Photoshop и Illustrator стоит у дизайнеров, постоянно обменивающихся файлами с заказчиками?
Ну как бы, требования пользователей и функциональность программ тоже выросла. Вот вы упомянете мобильные платформы — делов-то, сделать статичный не-скинуемый интефейс на уровне ядра, писать все аппликации на С+асм, чтоб быстрее работало, поддержку мультимедии исключить, и перезагружать два раза в день. Будет просто летать, даже на гораздо более слабых системах. Вот только продать пользователям такую «быструю» систему будет несколько проблематично…
А как жить-то дальше? Купили одно железо и 10 лет сидим за ним, да оптимизируем программки? А деньгам откуда взяться? Если потребитель не будет покупать железо и софт — так и заглохнем. Или на подписку всех перевести? Ежемесячная плата за винду подойдёт? К тому же: 4 гигабайта RAM — 1300р., 1 терабайт HDD — 1700р., 4-ядерный процессор с частотой 3 гигагерца — 3000р. Где проблема-то?
Андроид — плохой пример — опенсорс же. Там «работет — уже хорошо». Под него и девелопить — то ещё «развлечение» с таким-то эмулятором. Под iOS, например, ничего не тормозит с теми же характеристиками, хотя там тоже никто особо «оптимизацией» не занимается.
Андроид — плохой пример — опенсорс же. Там «работет — уже хорошо». Под него и девелопить — то ещё «развлечение» с таким-то эмулятором. Под iOS, например, ничего не тормозит с теми же характеристиками, хотя там тоже никто особо «оптимизацией» не занимается.
А откуда взялась информация 2й части статьи (пока еще не переведенной?)
Как-то уж слишком идиалистично.
Как-то уж слишком идиалистично.
UFO just landed and posted this here
Очень любопытно как люди хоронят все подряд .Net, WPF, Win32… и даст нам Бог HTML 5.
Категорический не согласен с автором в его отожествленний .Net и WPF и сравнивания с WPF. .Net самобытный продукт по сложности сравним с самой Windows и к тому же способный жить и на других платформах.
Что касается HTML5 + JS, ну налепит DevDiv кривой шаблончик для VS, и на том все и закончится. Как ни как они то и решают каким образом программы будут разрабатываться.
Категорический не согласен с автором в его отожествленний .Net и WPF и сравнивания с WPF. .Net самобытный продукт по сложности сравним с самой Windows и к тому же способный жить и на других платформах.
Что касается HTML5 + JS, ну налепит DevDiv кривой шаблончик для VS, и на том все и закончится. Как ни как они то и решают каким образом программы будут разрабатываться.
Просто раньше главным преимуществом MS была армия разработчиков, владеющих WinAPI. А потом, по мере введения новых технологий построения интерфейсов, начались расколы: MFC, STL, COM, .NET, WPF, Avalon. Разработчики видят, что нельзя доверять «новым, самым лучшим платформам MS для построения интерфейсов», потому что платформы эти живут недолго, и очень быстро сменяются новыми, ещё более «самыми лучшими». Вот и хоронят их.
А разработчики смотрят в сторону сторонних фреймворков, которые развиваются стабильно и последовательно (Qt тот же), или в сторону WinAPI, который чёрта лысого выкинут ещё 100500 лет, ибо корпораты не поймут, или — собственно — web-парадигмы разработки с HTML и JS.
А разработчики смотрят в сторону сторонних фреймворков, которые развиваются стабильно и последовательно (Qt тот же), или в сторону WinAPI, который чёрта лысого выкинут ещё 100500 лет, ибо корпораты не поймут, или — собственно — web-парадигмы разработки с HTML и JS.
Мне вот стыдно, да, но я ещё пишу с использованием MFC :) Получается быстро, просто и не дорого. Все библиотеки давно в системе. Программа с фиговой тучей строк занимает 400кб. Быстро работает, быстро запускается — все довольны.
Так нет, пишите и дальше, если результат устраивает!
Просто в некоторых случаях, к примеру, нужна ещё и кроссплатформенность, а тут уже winapi и основанные на ней технологии не подойдут (есть, конечно, и исключения, вроде пикасы с либвайн, но это редкость, всё же).
Возникает забавный парадокс: с одной стороны, MS не должна использовать для UI технологию, доступную для других платформ, потому что а как же тогда вендор лок ин? С другой, MS должна делать так, как удобно разработчикам, чтобы они предпочитали её платформу, а разработчики хотят писать сразу для всех платформ :)
Просто в некоторых случаях, к примеру, нужна ещё и кроссплатформенность, а тут уже winapi и основанные на ней технологии не подойдут (есть, конечно, и исключения, вроде пикасы с либвайн, но это редкость, всё же).
Возникает забавный парадокс: с одной стороны, MS не должна использовать для UI технологию, доступную для других платформ, потому что а как же тогда вендор лок ин? С другой, MS должна делать так, как удобно разработчикам, чтобы они предпочитали её платформу, а разработчики хотят писать сразу для всех платформ :)
Мусье знает толк в извращениях… MFC… бррр, аж передёрнуло…
Ничего здесь стыдного нет. Стыдно не понимая указателей, доказывать, что они не нужны. А MFC — это отлично.
Ну погодите, MFC, STL, COM, .NET, WPF — причем тут раскол? Все эти штуки делаю очень разные вещи и друг друга не сключают.
MFC — графический фреймворк для C++
STL — библиотека шаблонов, очень даже кроссплатформенная для того же С++
COM — технология взаимоинтеграции приложений
.Net — Отдельный мир (конкурирующий с JAVA)
WPF — графический фреймворк для создания интерфейсов пользователей .Net (один из многих)
Что касается професиональных разработчиков, то они смотрят туда куда деньги платят, а на сегодняшний день самая большая доля приходится на корпоративные приложения, что в большинстве случаев означает Java или .Net
Я считаю что сегодня для новых платформ разработки под PC самое главное как быстро и сильно корпоративные клиенты ее полюбят.
QT очень прикольная вещь.
MFC — графический фреймворк для C++
STL — библиотека шаблонов, очень даже кроссплатформенная для того же С++
COM — технология взаимоинтеграции приложений
.Net — Отдельный мир (конкурирующий с JAVA)
WPF — графический фреймворк для создания интерфейсов пользователей .Net (один из многих)
Что касается професиональных разработчиков, то они смотрят туда куда деньги платят, а на сегодняшний день самая большая доля приходится на корпоративные приложения, что в большинстве случаев означает Java или .Net
Я считаю что сегодня для новых платформ разработки под PC самое главное как быстро и сильно корпоративные клиенты ее полюбят.
QT очень прикольная вещь.
Я главного не понимаю — какая разница, на чем написаны системные программы и встроенные аппликации? Какое до этого дело разработчикам сторонних приложений и пользователям? С какой радости Майкрософт будет переписывать программы, на которые потратили сотни тысяч человекочасов на новом языке, если они и так работают? Ради религиозной чистоты?
Ради мониторов в 300dpi. Растровые интерфейсы должны по-немногу отходить в прошлое, ибо иначе чёрта лысого мы вообще увидим такие мониторы на десктопах. Очевидно, что унаследованный код будет всячески мешать этому процессу.
Во-первых проблемы переносимости майкрософтовских программ — это их проблемы, без связи растровые они или векторные.
Во-вторых, растровые — не значит не масштабируемые. И вектор не решает всех проблем автоматом. Например, 9-и сегментные картинки, которые используются для нелепейший-растягивающихся элементов в скинах, гораздо сложнее реализовать в векторе, чем в растре. Потом, существующее железо, на порядок-другой эффективнее умеет рисовать текстурированные прямоугольники, чем растеризировать градиенты и сглаженные кривые.
Во-вторых, растровые — не значит не масштабируемые. И вектор не решает всех проблем автоматом. Например, 9-и сегментные картинки, которые используются для нелепейший-растягивающихся элементов в скинах, гораздо сложнее реализовать в векторе, чем в растре. Потом, существующее железо, на порядок-другой эффективнее умеет рисовать текстурированные прямоугольники, чем растеризировать градиенты и сглаженные кривые.
Простите, может, я соображаю плохо, но зачем в векторном интерфейсе 9-сегментные картинки?
Насчёт железа согласен, но в десктопах gpu при обычной «офисной работе» без дела простаивают, вот пусть и растеризуют вектор :) Да и в мобильних девайсах идёт к тому же.
Насчёт железа согласен, но в десктопах gpu при обычной «офисной работе» без дела простаивают, вот пусть и растеризуют вектор :) Да и в мобильних девайсах идёт к тому же.
s/нелепейший/нелинейно/ (спелчекер постарался)
Потому как далеко не все элемента UI можно растягивать или сжимать пропорционально. Скажем у вас есть бекраунд для кнопки. Если на том-же самом DPI вам надо растянуть кнопку в 2 раза — её рамка и тень, при этом не должны стать в два раза толще. В 9-сегментных картинках, углы не растягиваются, боковые сегменты растягиваются только по одной оси, а центральный пропорционально. При этом совершенно не важно растровый он или веркторный, в векторном действительно удобнее масштабировать все на другую резолюцию, но масштабирование UI элементов это не отменяет.
Причем если 9-сегментное масштабирование сделать легко в растре, то в векторе это нетривиальная задача. Представьте себе, что у вас границу сегментов пересекает фигура с градиентной заливкой. Как вы её нелинейно смасштабируете или разрежете на куски? Все равно, скорее всего, придется её растеризировать, а потом все делать так-же как и в растровой картинке.
Простите, может, я соображаю плохо, но зачем в векторном интерфейсе 9-сегментные картинки?
Потому как далеко не все элемента UI можно растягивать или сжимать пропорционально. Скажем у вас есть бекраунд для кнопки. Если на том-же самом DPI вам надо растянуть кнопку в 2 раза — её рамка и тень, при этом не должны стать в два раза толще. В 9-сегментных картинках, углы не растягиваются, боковые сегменты растягиваются только по одной оси, а центральный пропорционально. При этом совершенно не важно растровый он или веркторный, в векторном действительно удобнее масштабировать все на другую резолюцию, но масштабирование UI элементов это не отменяет.
Причем если 9-сегментное масштабирование сделать легко в растре, то в векторе это нетривиальная задача. Представьте себе, что у вас границу сегментов пересекает фигура с градиентной заливкой. Как вы её нелинейно смасштабируете или разрежете на куски? Все равно, скорее всего, придется её растеризировать, а потом все делать так-же как и в растровой картинке.
Я так и не понял, это .NET Introspection (вроде того, что в GTK3, вживую видно в JS-консоли гнома3) или только JS и только для интерфейса?
Windows разрабатывался в группе Windows Division (WinDiv), а .NET — в группе Developer Division (DevDiv), которая в свою очередь являлась частью группы Server and Tools business.
… И работники Windows Division обнаружили в .NET фатальный недостаток.
Спасибо за перевод очень интересно.
Искренне желаю Microsoft успеха в построении новой современной красивой системы. Очень хочется чтобы программы и интерфейсы в виндовс были такими-же продвинутыми и единообразными как в Mac.
На хабре принято ругать Microsoft. Большинство искренне желают им провала. Я этого не понимаю. Вы что мне предлагаете переходить на мак? Мак мини 30 000, мак бук про 60 000, ай мак 70 000. У меня уже есть 2 китайских десктопа и ноутбук ASUS. Я бы хотел запустить современную красивую и эффективную платформу на них.
Неужели вы не хотите покупать компьютеры дешево? Пусть Microsoft сопутствует удача!
Искренне желаю Microsoft успеха в построении новой современной красивой системы. Очень хочется чтобы программы и интерфейсы в виндовс были такими-же продвинутыми и единообразными как в Mac.
На хабре принято ругать Microsoft. Большинство искренне желают им провала. Я этого не понимаю. Вы что мне предлагаете переходить на мак? Мак мини 30 000, мак бук про 60 000, ай мак 70 000. У меня уже есть 2 китайских десктопа и ноутбук ASUS. Я бы хотел запустить современную красивую и эффективную платформу на них.
Неужели вы не хотите покупать компьютеры дешево? Пусть Microsoft сопутствует удача!
> На хабре принято ругать Microsoft. Большинство искренне желают им провала. Я этого не понимаю. Вы что мне предлагаете переходить на мак?
Политика вендор лок-ин пагубна. Основная нелюбовь к майкрософту именно из-за этой их политики и между прочим большая часть проблем в их софте — из-за неё же.
Провал майкрософта означает активное развитие других операционных систем. В идеале хотя бы еще 2-3. Если рынок ОС будет примерно поровну поделен между хотя бы тремя игроками — будет здоровая конкуренция, что означает кроссплатформенность программ, повышение их качества и снижение цены.
Политика вендор лок-ин пагубна. Основная нелюбовь к майкрософту именно из-за этой их политики и между прочим большая часть проблем в их софте — из-за неё же.
Провал майкрософта означает активное развитие других операционных систем. В идеале хотя бы еще 2-3. Если рынок ОС будет примерно поровну поделен между хотя бы тремя игроками — будет здоровая конкуренция, что означает кроссплатформенность программ, повышение их качества и снижение цены.
Нет это означат что на PC не будет современной системы. Можно конечно попробовать deskpoр linux, но это сильно на любителя. Я например не вижу, кто-бы сегодня смог написать свой виндовс, который могли бы использовать люди.
Вы предвзяты.
Во первых если под «современной системой» вы подразумеваете виндоус — то он в любом случае никуда не денется в ближайшие… много лет. Даже в случае очень серьезных проблем у майкрософта вполне очевидно, что за виндоус долгие и долгие годы будет сохраняться лидирующая позиция и он явно будет одной из этих трех-четырех ОС. Так просто выбраться из виндор лока не получится.
Во вторых написать ОС — не такая уж невыполнимая. Основные проблемы это софт и драйвера. Софт, при наличии posix-совместимости, достаточно просто портируется. Нужно всего лишь портировать gcc и сделать пару патчей для основных тулкитов, дабы умели работать с твоей графической оболочкой.
Намного хуже ситуация с драйверами. Фактически сейчас она не решается никак. Писать все драйвера самостоятельно слишком трудозатратно и никто не может себе этого позволить, к тому же драйвера для многих устройств отсутсвуют в открытом виде и спецификации закрыты, а производители плевать хотели на любые ОС кроме виндоус.
Но, если позиции виндоус будут не так крепки как сейчас — почему бы и нет? У альтернативных ОС появится шанс. А у пользователей — выбор.
А выбор — это замечательно.
Во вторых написать ОС — не такая уж невыполнимая. Основные проблемы это софт и драйвера. Софт, при наличии posix-совместимости, достаточно просто портируется. Нужно всего лишь портировать gcc и сделать пару патчей для основных тулкитов, дабы умели работать с твоей графической оболочкой.
Намного хуже ситуация с драйверами. Фактически сейчас она не решается никак. Писать все драйвера самостоятельно слишком трудозатратно и никто не может себе этого позволить, к тому же драйвера для многих устройств отсутсвуют в открытом виде и спецификации закрыты, а производители плевать хотели на любые ОС кроме виндоус.
Но, если позиции виндоус будут не так крепки как сейчас — почему бы и нет? У альтернативных ОС появится шанс. А у пользователей — выбор.
А выбор — это замечательно.
> а производители плевать хотели на любые ОС кроме виндоус
Порою даже хуже: одни плевать хотели на любые ОС, кроме 32-разрядных Windows 7, другие плевать хотели на любые ОС, кроме 64-разрядных Windows 7 (см. например страницу скачивания драйверов для Windows-версии Acer ICONA), третьи выложили в своё время драйвера для Windows XP, а для Windows 7 обновлять отказываются (см. всех производителей ноутбуков), заставляя покупать те же устройства, но в новом корпусе, только из-за наличия у новых моделей драйверов, совместимых с Windows 7.
Тут есть желающие сказать «в Windows всё замечательно с драйверами и никогда нет никаких проблем с их работой!»?
Порою даже хуже: одни плевать хотели на любые ОС, кроме 32-разрядных Windows 7, другие плевать хотели на любые ОС, кроме 64-разрядных Windows 7 (см. например страницу скачивания драйверов для Windows-версии Acer ICONA), третьи выложили в своё время драйвера для Windows XP, а для Windows 7 обновлять отказываются (см. всех производителей ноутбуков), заставляя покупать те же устройства, но в новом корпусе, только из-за наличия у новых моделей драйверов, совместимых с Windows 7.
Тут есть желающие сказать «в Windows всё замечательно с драйверами и никогда нет никаких проблем с их работой!»?
А не кажется ли вам, что словосочетание «современная система» в одном контексте с POSIX выглядит странно? Сколько лет посиксу? Мне кажется если уж писать альтернативу, то надо спроектировать современную систему, для современных задач, под современно оборудование. Тем более у нас уже есть Linux — зрелая посикс совместимая свободная ОС. Если считать посикс венцом развития для ОС, то можно более ничего не писать =)
Хочу внести ясность. Я ни в коем случае не против Posix и unix в целом. Просто эта статья о том, что делает Microsoft чтобы сделать систему более продвинутой, более удобной для разработки с более богатыми API. Все это, как мне кажется, находится на более высоком уровне нежели системные вызовы и архитектурные решения POSIX. Тот-же .NET и WPF теоретически можно было запустить и на Linux.
То есть написание очередного юникса никак не приближает нас к созданию нового продвинутого виндовса.
То есть написание очередного юникса никак не приближает нас к созданию нового продвинутого виндовса.
Какое отношение имеет стандарт api для достаточно ограниченного числа системных приложений к какому то «венцу развития»? Наличие посикс-совместимости всего лишь упрощает портирование имеющегося софта. При этом у вас может быть хоть какое-нибудь сверхсовременное экзо-ядро, новаторские подходы к реализации вывода и отображения графики и что угодно еще. И при этом система вполне может не быть ни юниксом ни даже юникс-лайк. Например Haiku.
Рискую кармой, но Денис Попов (автор 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»
«Вы говорите что 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»
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 лучше?
и тут не показана главная фишка WPF — биндинги.
Главная фишка WPF — это не только биндинг. Да, биндинг в WPF — это круто (это действительно круто)!
Но помимо биндинга и гибкости построения сложного визуального интерфейса там есть еще Маршрутизируемые события (RoutedEvents), Свойства и объекты зависимости (DependencyObject и DependencyProperty), прикрепляемые свойства (Attached Property).
Если копнуть глубже, то это еще использование DirectX вместо GDI/GDI+, наличие Silverlight позволяет портировать вин приложения в браузер буквально в два клика, наличие Expression Blend (Studio) позволяет именно рисовать красивые нитерфейсы, не заботясь о логике обработки.
Так что биндинг — это всего-лишь вершина айсберга.
Но помимо биндинга и гибкости построения сложного визуального интерфейса там есть еще Маршрутизируемые события (RoutedEvents), Свойства и объекты зависимости (DependencyObject и DependencyProperty), прикрепляемые свойства (Attached Property).
Если копнуть глубже, то это еще использование DirectX вместо GDI/GDI+, наличие Silverlight позволяет портировать вин приложения в браузер буквально в два клика, наличие Expression Blend (Studio) позволяет именно рисовать красивые нитерфейсы, не заботясь о логике обработки.
Так что биндинг — это всего-лишь вершина айсберга.
Автор статьи по видимому не совсем понимает что же собой представляет .NET.
.NET — это платформа которая включает очень много технологий (ADO.NET/ Windows Forms / WPF/ ASP.NET etc)
Необходимость создавать интерфейсы на JS/HTML (пусть даже и очень сильно преувеличенная) никоим образом не отменяет платформу. Максимум чего стоит ждать — появления новой технологии в составе .NET (например какой нибудь HyperUI.NET). Но отказываться от платформы и наработок которые уже много лет прекрасно существуют и интегрируются друг с другом никто не будет.
Если вспомнить историю — тот же WPF который является куда более прямым конкурентом Windows Forms не привел к отказу от последнего. Обе технологии существуют и поддерживаются по сей день.
.NET — это платформа которая включает очень много технологий (ADO.NET/ Windows Forms / WPF/ ASP.NET etc)
Необходимость создавать интерфейсы на JS/HTML (пусть даже и очень сильно преувеличенная) никоим образом не отменяет платформу. Максимум чего стоит ждать — появления новой технологии в составе .NET (например какой нибудь HyperUI.NET). Но отказываться от платформы и наработок которые уже много лет прекрасно существуют и интегрируются друг с другом никто не будет.
Если вспомнить историю — тот же WPF который является куда более прямым конкурентом Windows Forms не привел к отказу от последнего. Обе технологии существуют и поддерживаются по сей день.
Понравилось в статье: «Visual Basic [был] королем в мире корпоративных приложений <...> И тут появилась платформа .NET и всё изменила»
Мне нравилось писать на Win32 API. Особенно после появления утёкших исходников и wine (вместо документации). И сейчас иногда ещё в нём копаюсь — сейчас это уже как археологический артефакт, в нём хорошо видно «культурные слои». Мне кажется, что если бы MS не стремилась всё время произвести революцию в разработке ПО, то вышло бы неплохое API.
Мне нравилось писать на Win32 API. Особенно после появления утёкших исходников и wine (вместо документации). И сейчас иногда ещё в нём копаюсь — сейчас это уже как археологический артефакт, в нём хорошо видно «культурные слои». Мне кажется, что если бы MS не стремилась всё время произвести революцию в разработке ПО, то вышло бы неплохое API.
Win32 API действительно ужасен, только начал с ним работать и уже жалею об этом. Усугубляет ситуацию обширный опыт в Android разработке. Может немного и не корректно сравнивать java и C, но по моему для вызов нескольких функций по 6+ аргументов ради какого нибудь элементарного действия это явно перебор, даже 15 лет назад.
А можете прояснить зачем вам именно напрямую нужен Win API? Мне кажется, что сейчас только очень узкий круг задач требует его непосредственного применения.
Sign up to leave a comment.
Windows 8 для разработчиков: возрождение мечты? (1/2)