Все новости от 10 января 2003 г.

Whistler опять звучит по-новому

В четверг Microsoft еще раз изменила наименование продукта, присвоив ему уже четвертое имя: Windows Server 2003. Предполагается, что последователь Windows 2000 Server поступит в продажу в апреле.

В апреле 2001 года продукт, от рождения имевший кодовое название Whistler, получил имя Windows 2002 Server. Тогда же Microsoft впервые перенесла дату его выпуска на начало 2002 года. В августе компания переименовала серверное ПО на Windows .Net Server 2003, пообещав выпустить его в конце прошлого года. Наконец, в ноябре дата выпуска была перенесена в третий раз.

Windows Server 2003 должен стать оплотом расширения стратегии веб-сервисов Microsoft. В декабре компания изменила условия лицензирования продукта, упростив компаниям лицензирование его как по числу пользователей, так и по числу машин.

«Критика здесь вполне оправданна, — комментирует многократное изменение названия продукта аналитик Gartner Дэвид Смит (David Smith). — Но в общем-то все правильно. В долгосрочном плане это имеет смысл». На этой неделе Microsoft оповестила сотрудников и партнеров о переименовании, которое со временем затронет и другие продукты. Представительница Microsoft подтвердила, что продукты с .Net в названии, возможно, будут переименованы. «Цель в том, чтобы гарантировать отсутствие каких бы то ни было нарушений экосистемы», — подчеркнула она.

Точное определение того, что такое .Net., одна из давних проблем Microsoft. Аналитики отмечают, что софтверный гигант с самого начала не смог четко сформулировать свою стратегию .Net, в результате чего заказчики и партнеры оказались дезориентированы. Смит говорит, что, изменив название, Microsoft не внесла в продукт никаких технологических изменений. «Это вопрос чисто брендинга. У них множество проблем с объяснением .Net. А автоматическое помещение марки .Net на все продукты подряд еще больше усугубило проблему. Это явная ошибка, и теперь они ее исправляют».

Изменив названия продуктов, компания надеется четче выделить логопрограмму .Net Connected для веб-сервисов. В прошлом Microsoft использовала логопрограммы для таких продуктов, как Windows XP или портативные устройства Windows Powered, чтобы гарантировать их соответствие установленным Microsoft стандартам. Так, разработчики ПО, чтобы получить логотип Windows XP, должны обеспечить соответствие своих продуктов определенным критериям. «Существуют некоторые требования, которые имеет смысл обозначить логотипом .Net Connected, — говорит Смит. — Веб-сервисы должны доставляться с использованием .Net Framework».

.Net Framework, ключевая часть общей архитектуры разработки Microsoft .Net, автоматизирует многие задачи разработки при использовании инструментов программирования Visual Studio.Net и способствует надежной и безопасной работе ПО на разных серверах и компьютерах.

В письме, разосланном на этой неделе партнерам, Microsoft подчеркивает важность логопрограммы для общей стратегии .Net и усилий в области брендинга. «Логотип .Net Connected указывает на способность продуктов легко и согласованно сопрягать разнообразную информацию, системы и устройства, удовлетворяя требованиям индивидуальных потребителей и организаций», — говорится в письме, полученном CNET News.com.

«Они начинают понимать, как рационально преподносить все эти вещи, — считает Смит. — Для этого понадобилось всего два с половиной года». 

 Предыдущие публикации:

 В продолжение темы:

Обсуждение и комментарии

	Wintermute - devnul.ru 10 Jan 2003 2:33 PM
Задолбали! Из-за этих переименований сейчас начнется еще один круг переписки с представительством MS.
	Serge 10 Jan 2003 4:19 PM
По большому счету Win2003 до технологии .net framework и не дотягивает... Это скорее смесь COM+ и .net и странно этот продукт называть .net server. Кстати, управление через консоль MMC - это чистый COM и используется в Win2003 для управления почти всем. Вопрос к MS: Что прийдет на смену ММС?
	maq 10 Jan 2003 7:12 PM
Интересно что значит "Win2003 до технологии .net framework и не дотягивает..." Насколько я знаю Win2003 содержит встроенный .Net Framework и по идее должен быть более качественным чем тот который сейчас можно установить отдельно
	Wintermute - devnul.ru 11 Jan 2003 8:28 AM
2 Serge: MMC.Net :-) Кстати, никто не запрещает (даже приветствует) написание snap-in на C# или VB.Net 2 maq: Простое наличие Framework не превращает Windows в новый продукт. Windows.Net (IMHO) должна иметь CLR и CTS (хотя бы CTS)в _ядре_. Вот этого мы не увидим еще долгие годы. Если вообще увидим.
	glassy 11 Jan 2003 2:05 PM
Конкурс "Лучшая программа для КПК", спонсируемы МС -- кто будет лучшим в беге с препятствиями? ;) 2Wintermute: а почему нет? Completion ports ведь смогли же налабать.
	Wintermute - devnul.ru 13 Jan 2003 9:59 AM
2 glassy: Насколько помню, CP были в самой первой версии Win32 API. Правда, в многонитевой ОС они нафиг не нужны, но это уже другой вопрос. А "нет" потому, что перенос CLR в ядро будет означать _полное_ изменение идеологии этого самого ядра и _полную_ перепись всей ОС. Даже введение CTS - уже цунами, а перепись - вообще всемирный потоп. Проще создать отдельную ветку кода и неспеша ее писать с нуля. Однако и тут суффикс - а драйверы как? Их же наработано для разного железа вагон и маленькая тележка - выбрасывать это богатство? Нет, все это слишком дорого.
	glassy 14 Jan 2003 8:33 AM
Коллос на глиняных ногах, то есть :)
	glassy 14 Jan 2003 8:33 AM
очипятался колосс
	Wintermute - devnul.ru 14 Jan 2003 9:50 AM
Фрейдистские у тебя оговорочки... :)
	maq 14 Jan 2003 11:58 AM
А кто говорит что CTS и CLS должны быть в ядре? Я не вижу в этом никакой необходимости. Чтобы писать драйверы на C#? Было бы очень интересно посмотреть на драйверы которые применяют сборку мусора :) Мне кажется что .Net это технология в первую очередь прикладного уровня.
	glassy 14 Jan 2003 12:15 PM
А у тебя мысли :)
	Пётр - peterkdhotmail.com 14 Jan 2003 2:31 PM
Совершенно верно, maq. Для того она и создана, чтобы доступ предоставлять к информации. Вот в Юкон будет встроена CLR, это понятно, можно будет функции писать на различных языках, а не только на TSQL. А использовать её в ядре операционки смысла нет. Никто же не додумался яву использовать в ядре операционки. Так и тут.
	Wintermute - devnul.ru 14 Jan 2003 4:31 PM
2 glassy: Мысли у меня, скорее, оруэлловские. 2 maq: Ладно, насчет сборки мусора в ядре убедил, хотя это не такая уж дикая идея. Но вот CTS в ядре была бы полезна. Упрощение передачи данных между прикладными программами, сервисами, драйверами и ядром, большая абстракция ядра от аппаратуры (не Интелом единым...), возможность без геморроя писать драйверы не только на Си/Ассемблере.
	Ефрейтор 14 Jan 2003 6:00 PM
2 Wintermute: > возможность без геморроя писать драйверы не только на > Си/Ассемблере. Даешь драйвера на Basic! И ОЗУ 1 Гиг станет минимальным требованием. А чем Вас ядро Win2K не устраивает? По-моему это самая красивая часть Windows. Только есть проблемы с корректным удалением IRP из очереди, но они в принципе решабельны.
	DemonZla 15 Jan 2003 1:29 PM
Насчёт драйверов.... Давно бы уже придумали стандартный способ общения железа между собой.... и никаких дров тогда не понадобилось бы.... токо вот почему никто до этого не додумается....
	DemonZla 15 Jan 2003 1:31 PM
и ещё до кучи идентификацию устройств по классу, чтобы сразу было видно что видеокарта это вам не звуковуха... эээххх....
	Wintermute - devnul.ru 15 Jan 2003 2:38 PM
2 Ефрейтор: (кисло морщась) Что вы привязались к Бейсику? Я вообще не люблю этот язык, ввиду имел Паскаль. Еще раз прочти мой пост. CTS это Common Type System. Грубо говоря, декларация, что int - это int везде, со знаком, 4-байтный, в долговременной памяти и промежуточной форме записывается, допустим, в big-endian. Понятно, что CTS не завязана на железо, на язык, на .Net вообще, а жизнь разработчику (драйверов) упростит. Использовать CLR в драйверах тоже можно, даже удобно - вендор поставляет сборку IL-кода, программа установки компилирует ее в native. Если драйвер динамический, то можно и не компилировать - в одной сборке хранятся драйвера для всего мыслимого оборудования, CLR при загрузке компилирует только нужный. Нафантазировать много чего можно. В общем, идея не такая уж и дикая. Но для ее реализации нужно и идеологию разработки менять, и реализацию ядра.