На днях, после того, как послал письмо с описанием внутренних структур File и Queue, опять решил вернуться к данной теме. Подумал — почему такие сложности с конвертацией файлов, в особенности TPS? Если для простого конвертирования файлов DAT можно легко воспользоваться старым добрым Filer`ом из поставки CPD21, то для TPS-файлов нет ничего подобного.
А если и есть, то все они громоздкие, сложные и, что главное для нас, дорогие. Не справедливо?!
Вот и решил написать что-то подобное. И для этого пришлось уточнить формат всех тех
структур, которые описывал.
Сразу-же предупреждение тем, кто решил воспользоваться информацией из того письма, особенно Сергею Чушкину -верен формат ТОЛЬКО заголовка файла. Все остальное очень сильно изменилось с времен CDD30/CFD31!
Пришлось, конечно, воспользоваться отладчиком, но, думаю, разработчики Клариона не будут иметь ко мне претензий! Иначе — зачем тогда в поставке идет дебагер!?
Сразу-же первое впечатление — разработчики всеми силами стараются закрыть от посторонних глаз, т.е. от нас, внутреннюю «кухню» File и иже с ним! Всем, кажеться, уже известно, что File — это простой указатель типа ULONG на заголовок файла. Но, это или не известно самому отладчику, или это намеренно скрыто. Что-бы убедиться в этом достаточно просто взглянуть в отладчике на предоставляемую инфу об File. Там дается просто какой-то «левый» адрес, который (даже!) отладчиком не преобразуется в шестнадцатеричное представление!
Второе, что хотел-бы отметить.
При переработке внутренних структур, связанных с описанием File и Queue, убрали кое-что, что было явно лишним в старых форматах, что похвально. Но, в то-же время, в стремлении уменьшить размер этих структур, совершили, на мой взгляд, явную глупость, которая рано или поэдно может выйти боком. Особенно это актуально в нынешней ситуации, когда, вероятно, происходят или произошли некоторые изменения в комманде разработчиков языка! При этом почти всегда теряются некоторые мелочи реализации, которые не документировались. Речь — о хранении в структуре описания полей записи размера строковых полей и количества элементов в каждой, из заявленных, размерностей массивов. По умолчанию, для этого используется BYTE. Это справедливо только для размера до 31 байта! Для размера от 32 до 8191 добавляется еще один байт, а в 6-ом бите первого байта ставиться об этом отметка. В этом случае, для хранения размера, используется новый байт и первые 5 бит первого байта. Уже — атас! Но дальше — больше!
Для размера от 8192 и до (15000-Size(Record(без этой строки))) добавляется еще один байт, куда переносится остаток от деления размера на 256.
Вообщем, полный бардак, если еще учесть, что добавленные два байта не представляют собой полноценный SHORT, а какой-то гибрид, который можно встретить только, пожалуй, в описаниях шифровальных алгоритмов! Главное — не понятно зачем такие сложности, если еще в старой версии этих стуктур было предусмотрено поле размером SHORT, чего явно достаточно для всех драйверов! если и пытались предусмотреть последующие изменения в сторону увеличения размера таких полей, то почему-бы не описать его как LONG!? Повторюсь — речь не идет о размере MEMO и BLOB поле, которые
описываются в отдельной структуре. Кстати, BLOB в описании трактуется как обычное MEMO-поле со спецаттрибутом.
Хотел-бы ошибиться, конечно, на счет квалификации разработчиков или планомерности развития языка! Но, все это как-то похоже на обычные ляпы, которые потом, в попыхах, без обдумывания, пытаются исправить! Что-то типа «Мы не бежим — мы планомерно отступаем!».
А что скажут спецы из АРСИС`а? Или они не в курсе?