Главная страница Visual 2000 · Общий список статей

Проблема Y2K и продукты Microsoft

Андрей Колесов

© 1999, Андрей Колесов
Авторский вариант. Статья была опубликована c незначительной литературной правкой в журнале "КомпьютерПресс" № 7/99. Это — первая часть общей статьи "Проблема 2000 и технологии Microsoft".

Практически все мы...
Ошибка ошибке рознь
Что нам гарантируют производители
Microsoft заявляет, но... не гарантирует
После 2000 года мы начнем готовится к 2035-му?
Как трактовать требования 2000 года?
Выводы


Практически все мы...

Практически все мы в той или иной степени являемся пользователями технологий Microsoft. Поэтому вопрос о том, в какой степени продукты корпорации соответствуют требованиям для работы после наступления 2000 года, представляет особый интерес. Отвечая на него, Microsoft еще летом 1998 года открыла специальный сайт, посвященный этому вопросу (www.microsoft.com/technet/year2k/), а российское отделение осенью создало русскоязычную страницу (www.microsoft.com/rus/year200/) и выпустило брошюру по Y2K.

В этих материалах приводится довольно много интересной информации, которая действительно может помочь в понимании сути вопроса и путях его решения, причем для ПО в целом, а не только в отношении продуктов самой Microsoft. Однако в результате внимательного изучения этих сведений, обнаруживается, что многие аспекты проблемы Y2K не до конца раскрыты, а порой — могут даже ввести в заблуждение. Вот на этих вопросах мы сейчас и остановимся.

В начало статьи

Ошибка ошибке рознь

Говоря о проблеме работоспособности продуктов применительно к датам, нужно разделять два аспекта вопроса:

1) временной диапазон работы самого продукта (если он как-то использует текущую системную дату);

2) временной диапазон дат, обрабатываемых продуктом.

Отметим, что многие программы вообще никак не связаны с датами и в принципе должны работать, пока функционирует соответствующая операционная среда. К таким продуктам можно отнести, например, написанные под MS-DOS программы с математическими расчетами. В то же время некоторые прикладные программы будут сами по себе работать в 2000 году, но смогут ли они обрабатывать данные 21-го века — уже не факт (это зависит от их разработчика).

Несколько другим примером является, в частности, Word. Его пользователь не работает напрямую с датами, но сам Word использует текущую дату при формировании служебного заголовка документа для фиксации различных операций: создание, редактирование и пр. (Не нужно путать эти служебные данные документа с датами, фиксируемыми операционной системой в метке файла!)

Еще один типичный пример — Visual Basic (подробнее об этом см. статью "Visual Basic и проблема 2000"). Microsoft определила срок работоспособности этого продукта (всех версий) до 2030 года, но сам VB может создавать приложения с обработкой дат от 1 января 100 года до 31 декабря 9999 года. (Некоторые сомнения в правильности этого обещания Microsoft приведены в статье "Y2K: как вести календарь".)

С точки зрения пользователя крайне важным является также ответ на вопрос "кто виноват в ошибке". Ведь исходя него следует определять, кто же конкретно должен платить за модификацию программ или по искам от причиненного ущерба. В этой связи возможная неработоспособность программ в 2000 году может быть связана с ошибками двух типов:

1. продукт (программа или железо) изначально не был рассчитан на такой режим;

2. продукт был в принципе рассчитан на это, но на самом деле не работает, как было задумано (например, в свое время не было проведено тщательное тестирование).

По мнению американских исследователей, около 90% ошибок связано именно со вторым вариантом. Очевидно, что в первом случае пользователь должен винить самого себя, а во втором — имеет основания обращаться с претензиями к разработчику (если последний еще существует как юридическое лицо).

В этой связи следует подчеркнуть, что часто упоминаемая ошибка в старых BIOS (по разным сведениям, выпускавшимися кем-то почти до середины 90-х годов), которые дают сбой при переходе к 2000 году, является типичной ошибкой второго типа. Ведь в спецификациях DOS заложен диапазон системной даты 1980-2099 гг, а счетчик года в BIOS четырехзначный. Значит, либо "ляп", либо дальновидный замысел производителя.

К этому же классу ошибок относится случай, когда какие-либо приложения прочему-то считают дату 29.02.2000 недействительной. (Любопытно — ни одного конкретного приложения с такой ошибкой никто так и не назвал, хотя об ошибке в определении високосного года пишут все подряд.) Ведь если некие разработчики неким специальным образом определяют 2000 год, то значит их программы в принципе рассчитаны на работу в этот период.

Еще один подобный пример — официально объявленная Microsoft ошибка в MS Word 5.0 для DOS: в разделе информации о документе не может храниться дата после 2000 года. (Представьте себе, я недавно видел в одной весьма уважаемой организации как раз Word 5.0 и сотрудники были весьма довольны работой в нем.) Microsoft рекомендует обновить Word 5 на Word 6.0/DOS или Word 97. Но возникает вопрос: кто должен платить за такое обновление, в том числе и за приобретение новой техники для Word 97?

В начало статьи

Что нам гарантируют производители

Если отбросить явные рекламно-ажиотажные аспекты общественного обсуждения проблемы Y2K, то принципиальное значение этой темы заключается в том, что человечествое общество на рубеже веков осознало свою зависимость от информационных технологий. И стал очевидным глубинный юридический конфликт между стратегическими общественными интересами, зафиксированными, в частности, в законах антимонопольных и по защите прав потребителей, и базовыми принципами развития ИТ-индустрии на основе охраны авторских прав.

Ведь фундаментом распространения ИТ-продуктов (и программ, и техники) является принцип "As Is" — "Как есть". Стандартная фраза из практически любого лицензионного соглашения за последние 10 лет гласит "производитель не несет ответственность за нанесенный ущерб, возникающим при использовании или невозможности использования данного программного продукта" (стандартная лицензия Microsoft 90-го года, приложенная к MS-DOS 4.0). А гарантии сводятся к "надежной работе программы в соответствии с руководством к ней в течение 90 дней после покупки". Призрачность такой гарантии определяется хотя бы тем, что даже с учетом электронной справочной системы, описывается далеко не вся функциональность продукта (например, я не смог найти упоминания о том, какой диапазон дат поддерживает Windows 98).

Не менее любопытно, что на ПО гарантийный срок (обычно 3-6 месяцев) почему-то меньше, чем на технику (1-3 года). Но столь же характерно, что в документах на продаваемый ПК, как правило, вообще даже не упоминается, что подразумевается под его работоспособностью и каким характеристикам должен соответствовать продукт.

Почему в практике ИТ-рынка возобладал такой принцип, можно долго обсуждать отдельно, но в целом это является следствием того, что локализация и выяснение причины ошибки являются делом очень непростым. (Это нашло отражение в термине "глючит", который обозначает вероятностный характер проявления ошибки.) И на практике найти виновного в треугольнике "железо-ПО-пользователь" просто невозможно.

В результате вопрос каких-бы то ни было гарантий на ИТ-рынке фактически сводится не к зафиксированной законом ответственности производителя перед пользователем (доказать через суд, что продукт "глючит", практически невозможно), а чисто рыночными принципами, когда поставщик обеспокоен за свою репутацию на рынке вообще и перед конкретным пользователем, в частности (например, если пользователь — ЦБ РФ). В этой связи полезно вспомнить о знаменитой массовой замене Pentium'ов в 1994 году: Intel пошла на эту акцию стоимостью около 500 млн. долл. не под воздействием юридических угроз, а в результате такого неформального фактора как "потеря доверия со стороны рынка".

Что же касается ПО, то пользователей уже давно волнует то, что общепринятым принципом устранения ошибок в продуктах становится рекомендация "обновите старый продукт на новую версию". И проблема здесь (особенно для корпоративных пользователей) заключается не только в необходимости тратить деньги на покупку и время на само обновление. Порой гораздо более важным является то, что в новых версиях старые ошибки устраняются, но появляются новые.

В начало статьи

Microsoft заявляет, но... не гарантирует

Итак, возвращаясь в проблеме 2000 года в продуктах Microsoft, следует сразу подчеркнуть, что в документах корпорации идет речь о "Заявлении Microsoft о соответствии своих продуктов требования 2000 года", в котором подчеркивается, "Заявление не является гарантией". Фактически это означает, что информация Microsoft является лишь частным мнением корпорации, и пользователь сам несет ответственность за решение о соответствии или несоответствии приобретаемого им продукта его персональным требованиям.

Тем не менее, мнение Microsoft является достаточно авторитетным, чтобы по крайней мере принять его во внимание.

Для ориентации пользователей своих продуктов Microsoft ввела такую классификацию <*>:

1) соответствует требованиям 2000 г.; 2) соответствует с незначительными проблемами; 3) не соответствует; 4) в процессе тестирования; 5) не будет тестироваться.

Ключевым в этой классификации является то, что речь идет о "требованиях Microsoft", которые, во-первых, довольно вольно трактуются корпорацией, а во-вторых, могут совсем не совпадать с требованием конкретного пользователя. Поэтому в любом случае пользователю следует самому внимательно изучить более подробное описание "соответствия/несоответствия" конкретного продукта (для примера см. "Visual Basic и проблема 2000").

В качестве базовых критериев соответствия Microsoft определила следующие (www.microsoft.com/techten/year2k/product/criteria.htm):

1) продукт запоминает и обрабатывает даты с использованием четырехзначного формата [года];

2) если продукт позволяет пользователю вводить сокращенного обозначение года с помощью двух знаков, то продукт обеспечивает преобразование номера года в четырехзначный формат;

3) продукт будет правильно определять високосный год;

4) продукт не использует действующие даты для каких-то специальных целей [типа 09.09.99];

5) продукт будет работоспособным до конца 2035 года.

Появление даты 2035 в своих критериях представители Microsoft объясняют следующим образом. Дело в том, что язык программирования C (это стандарт ANSI) использует для вычисления времени (речь, по-видимому, идет о текущем времени) функцию Ctime, которая в свою очередь работает с длинной (четырехбайтовой) целочисленной переменной со знаком (т.е. 31 двоичный разряд) time_t, хранящей в секундах смещение относительно 1 января 1970 года. Переполнение time_t наступит в 19:14:07 18 января 2038 года.

Microsoft использует язык C для написания своих продуктов. И поскольку (как говорят представители корпорации) сегодня нет возможности точно проследить в какой степени используется функция Ctime в различных приложениях из-за большого объема наследуемого кода от версии к версии, то именно ограничение на время ее функционирования принято за основу критерия. А чтобы немного подстраховать себя в качестве ориентира выбран не 2038, а 2035-й год.

В начало статьи

После 2000 года мы начнем готовится к 2035-му?

Однако лично мое мнение таково — ограничение 2035-м годом и ссылка на Ctime звучат, по крайней мере, не убедительно и в них есть много мистики. Что-то вроде совета работника железной дороги: "Самолет, возможно, долетит, но я бы вам рекомендовал ехать поездом". ("Может быть, старый продукт и будет работать, но мы бы вам посоветовали купить новый. Правда, за его работоспособность мы тоже не отвечаем.")

Согласно своим спецификациям MS-DOS и Windows должны поддерживать работу с текущей датой с 1980 до 2099 года. И в описании системных функций MS-DOS и набора Win API ничего о 2035 годе не говорится. Совершенно очевидно, что в обеих ОС для хранения дат и времени используются совсем другие форматы данных — не time_t. Поэтому наличие ошибок с датой в указанный интервал времени является "проколом" со стороны разработчика. Это же относится и к приложениям, сделанным под DOS/Windows, тем более что при работе с датами прикладные программы (по крайней мере, в исполнении Microsoft) используют встроенные функции DOS или Win API.

Так или иначе, но при подготовке цикла статей для этого номера КП в течение недели я работал с текущей датой установенной для 2079 года 2079 года (почему именно эту дату — см. "Y2K: BIOS и Windows"). Работа выполнялась в среде Windows 98 International: Word 6.0, программы Office 97, Internet Explorer 4.0, Visual Basic (версии 3.0-6.0), графические программы фирмы Golden Software и ряд других приложений. В DOS-сессии я работал с QuickBasic 4.5 (1987 год), Лексикон 1.3 (1994), NC 5.0 (1994), собственными приложениями многолетней давности. С DOS-овскими программами отдельно упражнялся на ПК 386SX в среде MS-DOS 4.01 (еще сохранилась на дискетах).

Никаких проблем с работоспособностью программ обнаружить не удалось. Только старые программы (команда DIR в MS-DOS, NC, WinWord 6.0) выводили даты в двухзначном представлении года. Однако сортировка дат все равно там выполнялась по полному значению года, так что никаких проблем с правильным восприятием информации не было.

Разумеется, всем понятно: тест может показать ошибку, но ни один тест не может доказать отсутствие ошибок. Однако стращать народ возможностью мистических ошибок без каких-либо внятных объяснение — совсем не солидно.

В начало статьи

Как трактовать требования 2000 года?

Следует сказать еще об одном требовании Microsoft, в явном виде в критериях не приведенном, но тем не менее активно используемом. Речь идет о правилах преобразования даты из двухзначного в четырехзначное представление года. В разных продуктах реализованы разные правила (мы уже не раз отмечали, что разработчики корпорации, видимо, редко общаются между собой на производственные темы), так что здесь нужно быть внимательным (см. статью "VB и Y2K").

Изначальным правилом было прибавление 19 перед двумя младшими знаками года. Только в 1997 году Microsoft решила, что нужно ввести плавающее логическое окно в 100 лет (Windows 95 и Office 95 работают еще по старым правилам) для такого преобразования. В качестве стандартного варианта сейчас используется 1930-2029: например, 79 будет преобразовано в 1979, а 13 — в 2013. Более того, в Windows 98 Microsoft решила предоставить пользователям возможность самим определять границы этого диапазона (диалоговое окно "Control Panel|Regional Settings|Date"). Разумеется, для самой Windows это имеет косвенное значение (вряд ли кто-то будет работать с Windows 98 после 2030 года), но данная установка работает и для ряда приложений Microsoft.

Однако очень важным является то, что Microsoft по-разному оценивает использование правила преобразования двухзначных дат в четырехзначные для разных продуктов! Например, Access 95 преобразует дату 01.01.00 в 01.01.1900 (Windows 95 делает так же с текущей датой, но справедливо считает ее недействительной — в 1900 году Windows никак не могла работать). Так же делают все 16-разрядные версии VB (включая 4.0). Но тем не менее Windows 95 и Access 95 признается годными "с незначительными проблемами", а в отношении VB (16-разрядный) категорически заявляется — "не соответствует". Кроме как нелюбовью к 16-разрядным приложениям (давно прошедший этап с точки зрения Microsoft) эту разницу в оценках трудно объяснить.

В начало статьи

Выводы

Вывод из всего сказанно: решение о применении того или иного продукта в 21-м веке должен принимать сам пользователь. Для этого ему лучше познакомиться с информацией Microsoft по данному вопросу, хотя мнения о реальной пригодности продукта могут разойтись.

<*> Самая последняя информация о соответствии продуктов (включая русские версии) требованиям 2000 года находится по адресу: www.microsoft.com/techten/year2k/product/product.htm.

В начало статьи