Андрей Колесов
Эта история началась полтора года назад. В начале 1997 г. многие пользователи столкнулись с серьезной проблемой: на ПК с микропроцессорами AMD5k86-P90 при запуске программ, написанных на CA Clipper, выдавались сообщения об их аварийном завершении с диагностикой ошибок “деление на ноль” или “переполнение”. Поскольку речь шла о новых процессорах, только появившихся на рынке, и программах, работавших уже давно, то первое подозрение пало на K5. Письма с вопросами по этому поводу стали все чаще попадаться в нашей редакционной почте. В них отмечалось, что на процессорах Intel этой проблемы не наблюдается. На тезисе “лучше использовать Pentium” тогда вроде бы и сошлись. Но в середине этого года обозначилась новая волна вопросов: “Clipper-программы не работают на новых моделях процессоров Intel”. А это уже серьезно - систем, написанных на Clipper, и сегодня используется немало.
К сожалению, еще тогда попытка выяснить ситуацию в российских представительствах Computer Associates и AMD не увенчалась успехом - они хранили молчание. Чтобы как-то докопаться до истины, пришлось провести исследование с помощью читателей. Версия относительно дефекта K5 сразу оказалась довольно сомнительной, так как было отмечено, что ошибка пропадает, если отключить кэш-память (но при этом заметно снижается быстродействие процессора). Через некоторое время поступили письма, где были более серьезно проанализированы причины данной ошибки, а наиболее подробным был отчет о проведенном исследовании московской компании “Техника-Сервис”.
Суть проблемы вот в чем. В Clipper-приложении определяется индекс производительности компьютера. Для этого подсчитывается число пустых циклов, выполненных за определенный промежуток времени. Проще говоря, для хранения величины индекса в Clipper зарезервирована байтовая целочисленная переменная. На “быстрых процессорах” величина 255 перекрывается и... происходит переполнение и аварийное завершение.
“Вина” создателей Clipper заключается в том, что они не думали, что их программы проживут так долго, а производительность процессоров рванет в заоблачные высоты (очень похоже на “проблему 2000-го”). Процессоры AMD столкнулись с неработоспособностью Clipper-программ потому, что в силу своих архитектурных особенностей они были лучше оптимизированы именно для таких режимов работы. Тогда же (полтора года назад) было показано, что Pentium столкнется с этой проблемой в районе частот 220 МГц.
Прежде чем перейти к вопросу “как устранить ошибку”, хотелось бы обратить внимание на один весьма важный момент. Не вполне понятно, зачем Clipper вычисляет производительность процессора. Но важнее другое - а что понимается под “производительностью”? Тактовая частота? Скорость выполнения определенных операций? Однако такой подход совершенно неверен, и это видно из того, что критерий, заложенный в Clipper, показывал семикратное превосходство K5-P90 по сравнению с Pentium-90 (что явно далеко от истины). Вывод прост: критерий производительности (короткий пустой цикл), нормально работавший во времена 286-х процессоров, для другой архитектуры уже не подходит.
А что же делать все еще многочисленным пользователям Clipper-приложений? Здесь следует отметить, что официальных рекомендаций от CA получить (или найти на Web-узле) не удалось. Приходится ориентироваться на опыт самих пользователей.
Первый вариант - замедлить производительность процессора, например, понизив его тактовую частоту, отключив кэш-память или сделать более тонкие настройки, типа исключения механизма ветвления.
Второй - скорректировать программный код Clipper-приложения. Идея проста - вместо вычисления индекса производительности (по не очень точному алгоритму, как было показано выше), можно, скажем, просто заменить его некоторой константой. Здесь также существует два решения. В одном случае можно напрямую скорректировать код исполняемого модуля. Место ошибки находится отладчиком (или еще удобнее - с помощью Clipper Developer Kit), анализируется ассемблерный код и вносятся соответствующие исправления. В другом случае исправления делаются на уровне объектных модулей.
Вот что посоветовал нам читатель (Алексей Терентьев из Ростова-на-Дону): “В библиотеке Clipper Tools (ct.lib или ct2.lib) необходимо найти три байта "BA 05 00" в шестнадцатеричной системе и заменить их на "BA FF 00", что позволяет отключить процедуру проверки скорости процессора. После такой замены (после перекомпиляции) все мои программы заработали”.
Второй вариант решения проблемы сообщили специалисты компании “Софт Сервис”. Они много лет занимаются поддержкой пользователей различных средств разработки, в том числе и Clipper. В коллекции их свободно распространяемых программ имеется объектный модуль __wait_b. obj (найден в Internet, размер - 259 байт), присоединив который к проекту в ходе его компоновки, пользователь решает указанную выше проблему. Его можно переписать из раздела “download” Web-узла www.softexpress.ru.
Обратите внимание, что оба предложенных варианта не являются “фирменными” - результат их применения никто не гарантирует. Но общественное тестирование и применение подтверждает их достоверность. Попробуйте сами и сообщите нам о результате. Или поделитесь с нашими читателями (вашими коллегами) своим способом решения проблемы использования Clipper-программ на современных ПК.
С автором статьи, обозревателем PC Week/RE, можно связаться по адресу: akolesov@glasnet.ru.
