
	Сайт о сжатии >> Новинки \| О сервере (Compression Catalog! \| ENGLISH) Книга "Методы сжатия данных" >> Без потерь \| Изображений \| Видео Разделы >> Cтатьи \| Видео \| Arctest \| Ссылки \| Ru.compress \| Форум Проекты >> Д.Ватолина \| А.Ратушняка \| М.Смирнова \| В.Юкина \| Е.Шелвина \| Д.Шкарина

Гости редакции PC Magazine/Russian Edition

Евгений Рошал. 26 лет, живет и работает в Челябинске. Автор популярного клона Norton Commander для Windows 95 - FAR Manager.

С чего началась разработка программы?

Все началось с того, что я, как пользователь, ощущал нехватку оболочки, аналогичной Norton Commander, но способной работать с длинными именами файлов. Все, что мне удалось найти в тот момент (да и то только через две недели после начала работы над FAR), - это пакет Jet Commander, весьма "сырой" и с нестандартным для клонов Norton интерфейсом. Второй важный момент, который побудил меня заняться разработкой, - это то обстоятельство, что с распространением этой ОС резко увеличилось число просьб сделать адаптированную для нее версию моей предыдущей программы - архиватора RAR. Однако заниматься RAR к тому времени (июль 1996 г.) мне уже немного надоело, поэтому идея быстро трансформировалась в подготовку полноценной файловой оболочки.

Кстати, первоначальное название ранних, недоступных публике, версий FAR было FR (fullscreen RAR), но после смены концепции пришлось менять и название. Программа получила название FAR (_F_ile and _AR_chive manager). По идее надо было бы дать ей имя FARM, но оно мне не понравилось.

А почему было принято решение ориентироваться не на графический, а на текстовый режим работы? Вроде графическая среда, пользовательский интерфейс...

На мой взгляд, текстовый режим имеет несколько преимуществ. Например, из него намного удобнее запускать программы, которые работают в командной строке (ping creabel.com, grep abc *.txt и пр.).

Вообще, до появления Windows 95 меня вполне устраивала функциональность Norton Commander, но он не мог работать с длинными именами файлов. После того как выяснилось, что в Windows предусмотрена возможность создания 32-разрядных программ, которые работают в текстовом режиме (так называемые консольные программы), вывод был очевиден.

А чем вы пользовались "в прошлой жизни", до появления Windows 95?

Главным образом Norton Commander. Версии от 2.0 до 4.0.

Как вы относитесь к другим оболочкам?

Нормально. DOS-клоны NC (Volkov Commander и DOS Navigator) - качественные продукты, каждый со своей идеологией. Но их Win32-версий пока, к сожалению, нет, а реализация средств работы с длинными именами файлов в рамках DOS-окна Windows - полумера, такая программа не работает под Windows NT. Midnight Commander и File Commander/W существуют в виде консольных программ, хотя Midnight Commander - пакет, что называется, "на любителя", но пользователь этой оболочки должен привыкнуть к идеологии UNIX. File Commander/W в перспективе может превратиться в неплохую программу, но я бы предпочел увидеть Volcov Commander/W, если бы он появился.

Вообще, если сравнивать оболочки, то замечу, что при работе в среде DOS FAR выбывает из соревнования, а если говорить о среде NT, то там вряд ли стоит работать DOS-оболочками. Если забыть о платформе, то, пожалуй, я бы поставил рядом три оболочки: DN, VC, FAR. Просто каждая из них воплощает свою концепцию: DN - максимум функций в одной программе, VC - минимальный объем при относительно небольшой функциональности, FAR - некий компромисс между этими подходами плюс возможность наращивания функциональности с помощью подключаемых модулей. Не слишком далеко от этой тройки я бы разместил основоположника: NC 3.0-4.0. А вот пятый "Нортон", и тем более NC95, мне, честно говоря, не слишком понравился. FC/W и Win32-версия MC пока в аутсайдерах.

Как развивался FAR?

Первая версия вышла в сентябре 1996 г. и обладала только базовой функциональностью - файловые операции, просмотр и редактирование и пр. Дальше последовало несколько промежуточных версий и в версии 1.10 (декабрь) были введены такие функции, как "временная панель", FTP-клиент, "раскраска" файлов и пр. К марту 1997 г. в версии 1.20 появились сетевые функции и возможность работы с несколькими копиями редактора и программы просмотра. После выхода 1.20 я понял, что FTP, "временная панель", работа с сетью и архивами начинают занимать слишком много места в основном модуле, при том, что это не базовые функции файлового менеджера. Кроме того, в это же время меня стали просить "приделать" к FAR работу с "Арвид" (устройство резервного копирования на базе видеомагнитофона, а заниматься этим самому мне откровенно не хотелось. В итоге вышла версия 1.40 (июнь 1997 г.), которая умела работать с подключаемыми модулями и клавиатурными макрокомандами.

Дальше уже новейшая история. В версии 1.50 beta (октябрь 1997 г.) появились view and folders history, автоопределение кодировки в редакторе и программе просмотра, увеличена скорость вывода на экран. Версия 1.50 release (февраль 1998 г.) - первая коммерческая версия, для всех, кроме жителей xUSSR, FAR становится условно-бесплатной программой, были сделаны изменения в интерфейсе FTP-клиента. Версии 1.51 (март) и 1.52 (июнь) отличались мелкими изменениями и отсутствием некоторых ошибок.

Какой язык программирования использовался для создания FAR?

Cи++. Конкретно Borland C++ 5.01. Версия - это величина переменная, я начинал разработку в среде Borland C++ 4.5. В общем-то одной из целей написания FAR для меня было поближе познакомиться с Си++. До этого я использовал ассемблер и Си. Так что выбор был предопределен, и, надо сказать, я не жалею. Что касается конкретного компилятора, то меня больше всего привлекает входящий в состав Borland C++ текстовый отладчик.

Насколько велик проект с точки зрения исходных текстов?

FAR занимает примерно 52 тыс. строк, из которых 15 тыс. - это подключаемые модули, входящие в FAR, 4 тыс. занимает редактор, 8 тыс. - реализация встроенных типов панелей, 2 тыс. - API подключаемых модулей. Остальное - файловые операции, интерфейс и многочисленные небольшие функции.

Сравнительная трудоемкость разработки модулей?

Пропорционально количеству строк. Чуть больше времени отняли сеть и FTP-клиент.

Основные трудности при разработке?

Главная сложность - не поддаться на уговоры пользователей, привыкших к другим программам этого класса, которые часто хотят видеть "в лице" FAR свою любимую оболочку, но только "под Win32". Причем, в зависимости от приобретенных привычек, некоторая их часть уверена, что как минимум половина функций в FAR лишняя, а некоторые, напротив, считают, что необходимо серьезно увеличить функциональность.

Из технических трудностей - проблемы с воспроизведением конфигурации программно-аппаратных средств у пользователя. Вообще больше всего проблем вызвали FTP и сеть. Хотя сейчас появилась неплохая альтернативная версия FTP. Посмотрим, что из нее получится. Сеть я отлаживаю на псевдосетевой плате (MS Loopback adapter) в NT, а такие функции, как запрос паролей, эмулировать достаточно сложно. В итоге приходится делать отладочную версию с записью протокола соединения, просить пользователя прислать их мне, а потом разбираться.

Вообще, нужно отличать программирование для GUI и консоли, так как сходство между ними весьма отдаленное. Если говорить о консоли, то в Windows 95 она реализована через "прослойку" conagent, т.е. для ОС нет особой разницы между DOS-программами и консольными программами Win32. Кроме того, реализация API-консоли в Win95 содержит немало ошибок. Скажем, функция ReadConsoleInput может работать с мышью и расширенными кодами клавиатуры (например, с клавишами a или tc), но не может "читать" русские буквы. ReadConsole нормально принимает русские буквы, но кроме букв прочесть ничего не может, потому что и не приспособлена ни для чего другого. В итоге тривиальная, казалось бы, задача ввода русских букв в FAR для Win 95 требует немалых усилий. Приходится с помощью функции PeekConsoleInput смотреть, что находится в буфере клавиатуры и, в зависимости от этого, вызывать либо ReadConsoleInput, либо ReadConsole. А в среде NT можно просто использовать ReadConsoleInput и не задумываться над такими проблемами.

С символами, которые некоторые европейские народы вводят, используя правую клавишу t+букву в среде Windows 95, - беда. В Windows NT их можно отличить, проверяя (KeyEvent.dwControlKeyState & 9)!=0, а в среде Windows 95 для функции ReadConsoleInput они «на одно лицо» с обычными t-комбинациями. Из-за этого мне и пришлось ввести непонятную российскому пользователю опцию "Use right Alt as AltGr" в "Interface settings". Порой приходится потратить немало времени, чтобы FAR правильно заработал, скажем, со всеми клавишами немецкой клавиатуры и при этом ничего не "отвалилось" при установке финской.

Еще пример. Функция GetDiskFreeSpace в Windows 95, в отличие от Windows NT, иногда передает в вызывающую программу неправильный результат на дисках больше 2 Гбайт, причем это даже документировано. Так что в среде Windows 95 по возможности надо использовать функцию GetDiskFreeSpaceEx (она появилась в OSR2). При установке нестандартной ширины на полноэкранной консоли в Windows 95 агент консоли может аварийно завершиться при запуске DOS-программы. Я хотел сделать возможность настройки размера консоли FAR, но от этого, увы, пришлось отказаться. Вообще, большая часть проблем связана с Windows 95, в среде NT практически все функции действуют нормально.

Что вы думаете по поводу Windows 98 и NT 5.0 применительно к FAR?

В ранних версиях Windows 98 периодически появлялись и исчезали небольшие проблемы в клавиатурном вводе. Но с коммерческой версией пока каких-либо специфических проблем не замечено. Насчет NT 5.0 у меня нет достоверной информации, я ее пока не видел. Но в принципе в NT вообще более корректно реализован API консольных программ, так что если адаптация FAR и понадобится, то скорее в плане добавления новых функций. Скажем, если б там появились "символические связи" (средство файловых систем POSIX), я бы, пожалуй, не отказался добавить возможность пользоваться ими, а то от нынешних "жестких связей" (аналог "символических связей" в файловой системе NTFS) пока пользы мало. Но связываться с ранними версиями NT 5.0 я не хочу, к тому моменту как появится полноценная версия, все может не раз измениться.

Как устроен FAR изнутри?

Вообще, FAR - достаточно рутинная разработка, алгоритмов сложнее умножения там практически нет. Основа основ - класс BaseInput, который задает две виртуальные функции: ProcessKey и ProcessMouse. Это абстрактный класс, объектов типа BaseInput не существует, но от него порождаются все остальные классы, в частности ScreenObject (по сути это прямоугольник, который может рисовать "себя" на экране посредством виртуальной функции Show и восстанавливать старое изображение с помощью функции Hide). На его основе в свою очередь формируется класс Panel, который непосредственно порождает подклассы FileList, QuickView, TreeList и InfoList - встроенные типы панелей. От ScreenObject также порождается подкласс Modal, который используется как базовый для диалогов, меню, программ просмотра и редактора. Этот класс организует свой цикл обработки сообщений от клавиатуры и мыши вместо стандартного цикла, распределяющего сообщения между панелями и командной строкой. Остальные классы - KeyBar (полоса клавиш), Edit (строка ввода), Editor (редактор), Viewer (программа просмотра), CommandLine (командная строка) и MenuBar (полоска меню) - также порождены от ScreenObject. Основной цикл обработки сообщений мыши и клавиатуры располагается в объекте ControlObject - это собственно ядро FAR. Он распределяет, что послать в панели, что в командную строку и т.п.

А какое место в этой схеме занимают подключаемые модули - одна из главных "изюминок" FAR?

Подключаемые модули представляют собой иерархию классов, которые самостоятельно обрабатывают сообщения от мыши и клавиатуры и реализуют дополнительные функции.

Какие языки можно использовать для создания подключаемых модулей?

Любые, только чтобы они обеспечивали возможность создания DLL с неискаженными именами экспортируемых функций. То есть ClosePlugin именно так и должна экспортироваться, а не как _ClosePlugin или @ClosePluginSqpv. Я использую для этого Borland С, кто-то - Microsoft Visual C, есть примеры на Borland Delphi. Всего их сегодня примерно два десятка, причем спектр функций чрезвычайно широк - от таблицы AASCII-символов до редактора системного реестра.

Сколько сегодня пользователей у FAR?

Делая такие оценки без специальных исследований рынка, легко ошибиться примерно на порядок. Но можно сказать, что пользователи встречаются почти во всех европейских странах, просто везде, кроме России и Восточной Европы, в очень небольшом количестве. Я бы оценил количество пользователей в 15-20% от общего количества пользователей NC-подобных оболочек, т. е. где-то 5-10% от общего количества пользователей в xUSSR.

А кто пользуется FAR?

Тоже непростой вопрос. Очень разные люди, чтобы можно было синтезировать какой-то собирательный образ. Нужда работать с Windows объединила "зубров" UNIX, привыкших к аскетизму командной строки и пользователей пакета DOS Navigator - чемпиона по количеству функций среди всех клонов NC.

Вы придерживаетесь очень необычной политики распространения - пользователи из бывшего СССР имеют право применять его бесплатно. Почему?

Во-первых, после опыта продажи RAR я примерно представляю состояние рынка условно-бесплатного ПО в бывшем СССР. На FAR я все равно не заработал бы. Во-вторых, сейчас не так уж много местных пользователей могут позволить себе покупать программы, а оболочка - программа весьма необходимая для работы, пусть у них будет возможность использовать хотя бы ее легально.

А как вообще обстоят дела с продажей FAR?

Страны, где он наиболее распространен (Восточная Европа и бывший СССР), в данный момент наименее платежеспособны. Что касается США, то там программы типа NC никогда не пользовались особой популярностью. Впрочем, я достаточно хорошо представлял рыночные перспективы FAR с самого начала, и особо не рассчитывал на нем заработать.

Можно немного о планах?

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

PCMagazine Online