В качестве сервера использовался Novell NetWare, а в качестве базы – NetWare SQL, и по этому случаю код библиотечки «векторов» пополнился многочисленными #ifdef NWSQL. Так как мы озаботились целостностью данных, то на Watcom C был написан серверный модуль NLM [99] , обеспечивавший механизм пессимистичных блокировок и даже рассылавший сообщения о модификации данных, что проводило к автоматическому обновлению векторов.

Кроме того, у нас появился программист, отвечающий за GUI [100] . Он разрабатывал довольно своеобразный редактор форм. Впрочем, у нас все было своеобразным.

СБ: «Ниеншанц» решил, что VAX – это слишком дорого для собственной КИС. Вот тогда возникли Novell и Btrieve, которые были бесплатным к нему приложением.

Новым программистом GUI был Юрий Дымов по прозвищу «папа», потому что, даже будучи младше нас, в 1992 году он уже был женат, имел дочь. Юра обладал богатым арсеналом приёмов программирования, о котором говорит тот факт, что один раз утечку памяти он пытался исправить сменой компилятора

C. Он написал собственный менеджер памяти, то, что современным языком называется small memory heap [101] , и заставил конструкторы сторонней графической библиотеки работать через него. Без этого память у нас кончилась бы гораздо раньше…

ДЦ: Конечно, программисты такого типа не смущаются вставлять в код уродливые подпорки «чтобы работало». Они обычно плохо работают в длинных проектах, слишком много энтропии вносят в код. Зато если «кровь из носу» надо сделать так, чтобы работало сегодня к 16 часам, – они лучше всех.

ИП: В России наступала эра персональных ЭВМ, а я не мог бросить заниматься VAX-ами. Прямо, как чемодан без ручки. Правда, там были общедоступные исходники. Я имею в виду общество DECUS (Digital Equipment Corporation User Society). Поэтому пришлось сделать выбор.

#ifdef BTSQL (1992-93 год)

ДЦ: NetWare SQL был лишь надстройкой к СУБД Btrieve [102] , встроенной в Novell-овскую серверную операционную систему. Причём эта надстройка выполнялась на клиенте в специальной резидентной программе brequest . Она занимала 280 килобайт. Современный человек не поймёт, о чем речь. Он занимал целых 280 из 640 килобайт! Плюс MS-DOS и драйверы, а в оставшихся 300 килобайтах как хочешь, так и крутись… Кроме того, почему-то начальство считало полезным отказаться от «платного» NetWare SQL, будто в России тогда за что-то платили.

В итоге был написан небольшой слой, который находился под CST и транслировал узкое подмножество SQL без соединений ( joins ) в запросы к Btrieve. Наверное, это худший код, который я написал за свою жизнь, потому что он целиком находился в файле btsql.c – пара тысяч строк на чистом C. Oт обилия глобальных флагов я впадал в панику и вводил новые, только чтобы не трогать старый код. Ну а векторы, как и положено, обросли #ifdef BTSQL.

Работа с Btrieve была ещё тем удовольствием, поскольку отсутствовало понятие логического поля. Например, при создании индекса указывалось, что индекс включает байты с 3-го по 9-й, а второй сегмент – с 22-го по 25-й. Список таблиц, полей, смещений к началу полей в записи приходилось вести самостоятельно.

Интересно, что Btrieve имела уникальный двухверсионный уровень изоляции, который я нигде больше не встречал. Процессы-читатели никогда не блокировались и не считывали «грязные» [103] данные, а если напарывались на них, то брали предыдущую чистую версию. Понятно, что какая-либо целостность этой версии по времени не гарантировалась: каждая таблица хранилась в своем файле. Журналов транзакций не было, «грязные» данные хранились в специальных страницах ( ditry pages ) в той же самой таблице.

СБ: Кроме первой пробной установки Novell, за все остальные компания честно платила. Поэтому стоимость лицензий NetWare SQL была серьёзным аргументом в дополнение к его слабому быстродействию. CST на «голом» Btrieve работал в разы быстрее.

Кроме системы учёта для «Ниеншанца», на CST в 1992 году была сделана система для Молодёжной Биржи Труда. Как минимум год мы её сопровождали. В том же году сервер CST демонстрировался на выставке в ЛенЭкспо.

NDL, или Java в миниатюре (1993–94 год)

ДЦ: Между тем система, построенная на всем перечисленном, уже активно использовалась в компании и назвалась Seller 1.0. Написана она была, кроме интерфейса, опять-таки на голом C, а из-за ограничения в 640 килобайт представляла несколько разных исполняемых модулей: pay.exe для бухгалтерии, seller.exe для продавцов, store.exe для склада… Универсальную программу по причине размера собрать было уже нельзя.

Однако ограниченность платформы была ясна, и мы предприняли попытку разработать свой, как говорят сейчас, фреймворк. Да, мы создали в кратчайшие сроки свой язык NDL [104] , компилятор, компоновщик и исполняющую систему, независимую от ОС. Она была переносима без каких-либо серьёзных проблем, в переходный период код исполнялся одновременно и под DOS, и под Windows. В ней была даже реализована бесконечнозначная арифметика с фиксированной точкой, хотя в самом NDL количество знаков ограничивалось 64.

Но Windows будет потом, а пока исполняющая система под DOS научилась грузить NDL-программу в расширенную оперативную память ( extended memory ), освобождая под данные почти всю память основных 640 Кбайт минус исполняющая система, это был грандиозный прорыв. Кроме того, в NDL были исключения ( exceptions ) и куча полезных функций для работы именно с базами данных, так что мы бодро принялись писать новую систему Seller 2 на ней.

СБ: Если Seller 1 делался по наитию Д. Разгуляева, уточнявшего каждую неделю техзадание, то Seller 2 мы делали «правильно». Месяца 2–3 мы практически «бездельничали» – то есть придумали и обсудили приличное количество идей, оставив то, что нам казалось лучшим. Нарисовали схему базы данных и даже составили список ключевых функций. И только после этого приступили к реализации.

Сам NDL начинался с интерпретатора. Был придуман мета-код, первые бизнес-функции писались прямо на нем, но через месяц стало ясно, что без нормального языка дальше жить нельзя. Тогда появился NDL, компилятор и компоновщик. За основу синтаксиса был взят Паскаль. Код компилятора генерировался по описанию грамматики конвейером из 2 утилит, lex и yacc, под FreeBSD, установленной на одном из серверов. Полученный код на C затем компилировался в среде Borland под Windows. Компоновщик NDL собирал проект по описанию в makefile с разрешением имён глобальных и локальных ссылок и объектов. При этом он мог оставлять комментарии, которые позволяли исполнять код в режиме отладки с позиционированием на строки исходного кода. Всё было по-взрослому, несмотря на то, что сделано командой из 3 человек менее чем за год.

Закат Novell

ДЦ: Начиналось все хорошо. Вышел новый Btrieve версии 6, где появились интерактивное резервное копирование ( online backups ) и поиск без индексов. В пятой версии можно было либо читать все данные, либо искать по индексу. А для проверки типа «Сумма=123» необходимо проверять записи на клиенте. Теперь можно было эти проверки перенести на сервер.

Поначалу я этому обрадовался: задал сложный поиск, и сервер думает минуту. Пока не заглянул на заднюю панель компьютера. Лампочки, показывающие активность сетевой карты непрерывно горели! Маленький резидент на клиенте непрерывно посылал запросы типа «Готово? – Ещё нет». Иначе он и не мог, ведь раньше все обращения к Btrieve были короткими, и ждать не предполагалось…

Но тут вышла Windows 95 под кодовым названием «Чикаго». Novell почему-то не торопилась делать 32-разрядные драйверы и вообще как-то реагировать на новый тренд. В итоге Microsoft сама сделала 32-битные версии драйверов для IPX/SPX, но воспользоваться ими было невозможно, так как пресловутый brequest работал в 16-разрядном режиме DOS.

Наконец, я нашёл файл с говорящим именем breq32.dll (в «догугловую» эпоху это было делом дней и недель, а не секунд) и… выяснилось, что она представляет собой лишь 32-разрядный интерфейс для обращения к пресловутому brequest.