2 <META HTTP-EQUIV="Content-Type" "text/html; charset=utf-8">
3 <TITLE>True Unix GUI</TITLE>
4 <META NAME="DESCRIPTION" CONTENT="Размышления о том, какими
5 принципиальными свойствами обладает текстовый интерфейс Unix, и почему
6 ни один из современных графических интерфейсов не может считаться
7 полноправным наследником этого интерфейса">
10 <H1>True Unix GUI</H1>
12 В последнее время много шума раздается вокруг идеи о вступлении
13 Linux (и вообще Unix-подобных систем) в войну за место на рынке
14 настольных систем. В качестве разведки боем в этой войне возникли и
15 развиваются такие системы, как KDE и GNOME. Но, по моему мнению, эти
16 системы обречены на провал. Я не считаю, что Linux не место на десктопе
17 пользователя. Просто атаковать позиции Windows надо с другого фланга.
19 Что такое KDE и GNOME — это всего лишь попытка построить над ядром
20 Unix и X-Window систему, основанную на тех же принципах, что и Windows -
21 документ-ориентированная модель, взаимодействие между приложениями на
22 базе drag'n'drop и Object Request Broker, куча бесполезного
23 украшательства. Фактически для такой системы все преимущества
24 нижележащей многозадачной, многопользовательской, прозрачно
25 интегрированной в сеть системы становятся недостатками, приводящими
26 только к ненужному расходу ресурсов. Ресурсов сейчас, как правило
27 избыток, но это же не повод транжирить их без пользы.
29 В результате, мы получаем монстра, в котором работа с удаленными
30 ресурсами ограничена лазаньем по Web, возможностей расширения — не
31 больше чем в Windows. Хорошо хоть компилятор бесплатный, но ведь и в
32 Windows его уже портанули, а так для написания минимальной примочки к
33 нужно писать на C, или в случае KDE на C++.
35 Пользователь этой системы опять отдается на милость программистам — он
36 может пользоваться только тем что для него написали, поскольку изучать C
37 и, тем более писать на нем, у него нет времени. У него свои,
38 пользовательские, задачи — отчетик красивый сваять, посчитать
41 Заметим, что и программисты в наше время, во всяком случае то
42 подавляющее большинство их, которое обслуживает задачи
43 бизнес-пользователей, пользуется для разработки всяческими системами
44 Rapid Application Development, то есть по отношению к самому Desktop
45 Environment выступают скорее как пользователи, чем как программисты.
46 В то же время ни KDE ни GNOME не начинались с идеи — давайте напишем
47 RAD-среду, в которой можно сделать все. Что, кстати, сильно ограничивает
48 и количество их разработчиков, и продуктивность каждого из них.
50 Разработчики NextStep лучше продумали свою политику в этом отношении, но
51 и они потерпели неудачу в войне как за десктопы пользователей, так и за
54 Сравним это с ситуацией в начале 70-х годов — эпохи победного шествия
55 Unix по университетам США. Почему эта система смогла тогда вытеснить
56 гораздо более «дружественные к пользователю» LISP-машины?
58 На мой взгляд потому, что она последовательно проводила одну
59 незамысловатую идею — <strong>«не хочешь общаться с программой сам — заставь это
60 делать другую программу»</strong>. Я уверен, что на этом месте каждый из
61 читателей вспомнил что-то типа <tt>ls -l|grep root</tt> или
62 <tt>find . -name "*.bak"|xargs rm</tt>. Да, речь именно об этих конструкциях.
64 Основное их достоинство заключается в том что они, во-первых, вполне
65 доступны пользователю, умеющему работать в командной строке, а во-вторых
66 являются полноценными программами на языке shell. Их можно записать в
67 файл, объявить этот файл исполняемым и пользоваться наряду с прочими
70 Если вспомнить, что отчеты в те времена писали на troff, который весьма
71 подходит для обработки sed-ом и awk, то окажется что
72 пользователи вполне могли легко адаптировать систему к своим нуждам.
73 Причем этот процесс скорее напоминал обучение — сделал что-то один раз,
74 дал этой операции имя, и дальше требуешь сделать операцию с таким-то
77 Результатом этого явилось практически полное отсутствие барьера между
78 использованием системы и программированием в ней. И дальнейшее развитие
79 в общем-то не привело к его увеличению. В ответ на X-Window появился Tk,
80 в ответ на интерактивные программы типа ftp — expect.
82 Другое дело что практически неизменным остался барьер между человеком,
83 видящим компьютер в первый раз и квалифицированным пользователем, в
84 снятии которого преуспели другие системы, в особенности MacOS.
86 Памятником тому славному времени служит O'Reilly-вская книжка
88 awk</em>», которая фактически является летописью верстки серии про X window.
90 Каковы же составляющие интерфейса командной строки Unix, которые
91 оказались в свое время настолько удачные, что живут уже 30 лет, и до сих
92 пор находится немало людей, предпочитающих их разнообразным GUI?
94 На мой взгляд их четыре:
98 Универсальная форма представления информации — текстовый файл,
99 понимаемый как последовательность символов, некоторые из которых имеют
100 специальный смысл — разделяют строки(записи), поля и слова.
101 Его командно-строчные программы выдают на экран человеку (stdout),
102 его же ожидают в качестве ввода (stdin). Не будь этого стандарта
103 бесполезен был бы следующий пункт
104 <li> Переназначение ввода-вывода. Этот инструмент в Unix знают по-моему
106 <li> Toolbox Phylosophy. Это свойство тоже широко известно. Во-всяком
107 случае именно на нем заостряет внимание Ричард Столлман в
108 info-документации на textutuls. Идея состоит в наличии многих маленьких
109 утилит, которые хорошо интегрируются, вместо огромного монстра, который
110 умеет все. Это единственный урок Unix, который усвоили разработчики
112 <li> Регулярные выражения. Это тоже пункт, о котором многие забывают,
113 но без них идея «заставить одну программу читать вывод другой» была бы
114 бессмысленной. Это формальный, достаточно гибкий и более-менее
115 интуитивный способ указать программе, что следует искать в потоке
116 данных. И стандартные средства текстовой обработки, и такие
117 инструменты как expect, появившиеся в ответ на появление программ,
118 отказывавшихся честно взаимодействовать со стандартными фильтрами,
119 опираются именно на этот механизм.
122 Очевидно, что модель обработки данных, основанная на этих четырех китах,
123 не покрывает потребностей современного пользователя.
125 Наиболее слабым местом оказывается текстовый файл как универсальный
126 способ представления информации в сочетании с регулярными выражениями
127 для его обработки. Во-первых, кроме текста есть картинки и звук.
129 оперировать с текстом на уровне символов не всегда удобно — хочется
130 оперировать на уровне предложений, абзацев, а то и глав. В-третьих,
131 существуют табличные данные, которые не всегда удобно обрабатывать в
132 awk — иногда нужен sql. В четвертых, есть элементы оформления — шрифты,
133 начертания и пр., которые иногда несут существенную тематическую
134 нагрузку. (Здесь мы вступаем на театр военных действий между
135 сторонниками логической и физической разметки, к борьбе между которыми
138 Другим слабым местом являются регулярные выражения, как встроенный в
139 систему способ распознавания образов. Они во-первых, сложны для
140 пользователя — недаром AltaVista ими не пользуется, во-вторых очень
141 ограничены по своим возможностям — переставьте местами два слова и все.
143 Есть ограничения и у концепции переназначения ввода-вывода. Она
144 принципиально линейна, хотя пространство на экране принципиально
145 двумерно. Мне очень часто хочется написать что-то вроде
148 gzcat /var/log/httpd/access.log.gz | tee v | grep одно
153 В командной строке так нельзя. Хотя со стороны ядра Unix принципиальных
154 возражений нет. Другое дело что пытаясь записать это с каким угодно
155 синтаксисом на втором-третьем уровне вложенности обязательно
156 запутаешься. А если не писать, а рисовать на экране мышкой стрелочки?
157 Тогда можно охватить взглядом довольно сложную схему потоков данных. С
158 ветвлениями, слияниями и много чем еще.
160 Отвлекаясь немного от темы: А не кажется ли вам, что время
161 графических интерфейсов как таковых заканчивается? Грядет время
162 интерфейсов голосовых, которые, как ни странно куда ближе к командной
163 строке Unix, чем к графическому интерфейсу Windows. Ведь речь линейна, и
164 буде надлежащим образом распознана, превращается в тот самый поток
165 текстовой информации, который так любят традиционные утилиты Unix.
166 Что же касается синтеза речи, то эта задача просто уже решена — берете
167 festival и переназначаете вывод на него. Потребуется, правда немного
168 изменить синтаксис shell'а и, особенно, регулярных выражений, чтобы
169 команды было удобно произносить, а выдачу — воспринимать на слух.
171 Но голосовой ввод — пока еще туманное будущее. Ближайшие года два-три
172 нам предстоит жить с мышкой, окошками и иконками, которым кстати,
173 примерно столько же лет, что и Unix.
175 Итак, каким же должен быть истинно юниксячий графический интерфейс?
178 <li> Должен существовать единый способ представления информации.
179 Это позволит направлять выдачу любой программы на вход другой.
180 <li> Должно существовать средство поиска шаблонов в этом потоке
181 информации, причем такое, чтобы видя нечто на экране, пользователь легко
182 мог сформулировать задачу «найди мне все, похожее на это»
183 <li> Не должно существовать монстров типа Microsoft Word или Netscape
185 Должна быть маленькая утилитка для показа форматированного текста,
186 другая маленькая утилитка для показа таблиц (которой будет заодно
187 пользоваться и средство доступа к sql-базе), отдельная утилитка для
188 доступа к удаленным ресурсам, больше похожая на wget,
190 <li> Должен существовать нелинейный способ интегрирования этих утилит,
191 такой, что с одной стороны, пользователь способен с ним справиться
192 сам, с другой — он позволяет сцепить wget
193 с показывалкой текста и получить эквивалент Netscape. Этот способ
194 должен иметь интуитивно ясное интерфейсное выражение.
197 Естественно, что реальная среда, построенная на этих принципах, не будет
198 состоять из одних голых кирпичиков. В дистрибутив должно входить
199 несколько сотен скриптов, которые будут создавать у пользователя
200 впечатление, что у него есть и Netscape и Word и Excel. Но если ему
201 вдруг захочется оторвать считалку формул от электронной таблицы и
202 воткнуть ее (вместе с sql-интерфейсом) внутрь текстового документа, это
203 должно делаться даже не написанием пяти строк, а несколькими движениями
204 мыши. Интересная метафора на эту тему была реализована в свое время во
205 FrameWork — у каждого окна была лицевая сторона (примерно то, что
206 окажется на принтере) и изнанка (макрос который это генерирует).
208 Интересно, что последовательная реализация этой концепции может привести
209 к существенному уменьшению размеров дистрибутива. Вы никогда не
210 задумывались сколько разных http-клиентов входит в типичный дистрибутив
211 Linux? Сходу: Netscape, Lynx, wget, http-пакет для Tcl, libwww-perl.
212 А ведь хватило бы одного, но хорошего. И так для всего остального.
214 Предвижу возражения, что описанная система — рай для программиста, но не
215 для пользователя. Пользователю не нужны reusable components — ему
216 подавай готовые приложения. Да, но... Если система представляет собой
217 одно большое средство для быстрой разработки приложений, то за
218 последними дело не станет — найдется немало (гораздо больше чем
219 участников «базара» сейчас) людей которые за деньги, для удовлетворения
220 собственных потребностей, и просто ради самовыражения будут эти самые
221 приложения клепать. Правда, это должна быть среда разработки приложений,
222 которая соотносится с существующими Delphi и C Builder-ами, примерно как
223 «Среда программирования Unix» времен Кернигана и Пайка
224 (shell+awk+yacc+C) соотносилась с распространенными в те времена языками
225 типа Fortran и Basic.
227 Посмотрим, какими же средствами мы располагаем сейчас, для того, чтобы
228 попытаться реализовать подобную идею. Начнем с универсального способа
229 представления информации. В NextStep попытались с этой целью
230 использовать Display Postscript. К сожалению, крупным недостатком
231 Postscript является то, что это полноценный процедурный язык, и
232 представить себе как выглядит постскриптовский файл, не
233 проинтерпретировав его полностью, принципиально нельзя. Поэтому
234 Postscript совершенно не подходит для программной обработки.
235 Кроме того, Postscript совершенно не заботится о сохранении
236 высокоуровневой содержательной информации — деления на какие-либо
237 логические части, например.
240 остальных смыслах он совершенно замечателен — широко распространен, есть
241 свободно распространяемый код для интерпретации (Ghostscript), картинки
242 передаются в том же потоке, что и текст.
244 Display PDF уже гораздо лучше, чем Display Postscript, поскольку PDF -
245 язык преимущественно декларативный, а программы на декларативных языках
246 гораздо лучше поддаются автоматизированному анализу, чем программы на
247 процедурных. Есть в PDF и минимальные средства структурирования,
248 например гиперссылки. Но тут гораздо хуже как со средствами рендеринга, хотя
249 Alladin (а теперь уже и GNU) Ghostscript с этим справляется, и особенно
250 со средствами генерации. Кроме pdftex и того же Ghostscript ничего и
253 Попробуем зайти с другой стороны — со стороны языков логической
254 разметки. Сразу же в голову приходит SGML с его наиболее
255 распространенным вариантом HTML и наследником XML. Похоже, что это
256 именно то, что нам надо. Правда, в HTML картинки хранятся отдельно от
257 текста, но кто мешает придумать другую DTD. Зато есть средства сколь
258 угодно высокоуровневого логического структурирования, существенно
259 упрощающие объяснение программе того, что нам от нее нужно.
261 Еще одним, неожиданным, кандидатом на роль универсального способа
262 представления является X-протокол. С очевидностью, все что можно
263 показать на экране, можно представить в виде последовательности команд
264 этого языка. Более того, с появлением Xprt он теперь годится и как язык
265 описания страниц. Любая существующая программа под Unix умеет его
266 генерировать. Единственный недостаток — никто не пытался написать
267 программу обработки, которая не была бы X-сервером. К тому же, в
268 X-протоколе поток событий от пользователя к программе очень не похож
269 на поток событий от программы к пользователю (Х-серверу).
271 И еще один нетривиальный кандидат:
273 .c create rectangle 107.0 81.0 203.0 172.0 -disabledwidth 0 -tags {Rectangle obj utag1}
274 .c create line 108.0 81.0 158.0 18.0 202.0 82.0 -joinstyle miter -tags {Line obj utag2}
275 .c create rectangle 121.0 102.0 144.0 172.0 -disabledwidth 0 -tags {Rectangle obj utag3}
276 .c create rectangle 164.0 109.0 191.0 143.0 -disabledwidth 0 -fill #bfbfbf -tags {Rectangle obj utag4}
277 .c create text 155.0 207.0 -font {Helvetica 10 {}} -text {House, which Jack build
278 } -tags {text obj utag5}
281 Что это такое по-вашему? Векторный графический формат? Программа?
282 И то и другое — это рисунок, сделанный в графической программе tkpaint,
283 который на самом деле является программой на языке Tcl (на котором
284 написан сам Tkpaint).
286 Теперь о том, что не является документом — меню, диалоговое окно.
287 Заметим, что на программирование подобных вещей уходит львиная доля
288 труда пользователей RAD-систем, хотя казалось бы вот что RAD-инструменты
289 делают хорошо, так это диалоговые окна.
291 На самом деле это не так.
292 Порочен сам подход к интерфейсу как к картинке. Пользователь типичного
293 Delphi рассуждает так «разместим здесь вот этот интерфейсный элемент. Он
294 будет делать то-то и то-то». При этом минимальные изменения, такие как
295 переход к другому шрифту при создании национальной версии программы, или
296 увеличение размера поля БД приводят к полному развалу тщательно
297 продуманного внешнего вида окна.
299 Несколько более разумным подходом
300 представляется использование geometry manager, как в Tk или Xview, когда
301 расположение видимых элементов определяется в терминах их относительного
302 положения «вот эта кнопка под этой строкой ввода, выравненная по ее
303 правой границе». Очевидно, что такой способ более устойчив к изменениям
304 размеров шрифта или полей базы данных.
306 К сожалению, мощные geometry manager'ы имеют один существенный
307 недостаток — они отучают пользователя пользоваться графическими
308 application-designer'ами. Зачем, спрашивается рисовать на экране десять
309 полей ввода, когда трехстрочный скрипт с циклом foreach сам их
310 замечательно нарисует. Хотя, на самом деле разумной была бы гибкая
311 комбинация обоих подходов. Проблема в том, что для этого нужно то, что
312 не обеспечивается на данный момент ни одним средством RAD — возможность
313 переключаться между графическим дизайном и писанием кода в любой момент.
315 Но это только одна сторона вопроса. Вторая заключается в том, что мы,
316 имея готовую программу с диалоговыми окнами и прочим графическим
317 интерфейсом, хотим управлять ей из другой программы. На данный момент
318 существует только один способ решения этой проблемы — встраивание в
319 программу макроязыка, т.е. набора команд, которые можно тем или иным
320 способом вызывать, будь то встроенный язык типа WordBasic, или методы
321 объекта OLE или CORBA, когда сам по себе язык реализован где-то
322 отдельно, а программа предоставляет только набор функций.
324 И в том и в другом случае, набор функций как правило сильно отличается
325 от набора позиций меню, а набор их параметров от набора полей ввода в
326 соответствующих диалоговых окнах. Да, конечно, есть операции, которые
327 могут быть интересны разработчикам приложений, но совершенно не нужны
328 пользователям, например «открыть файл и получить его дескриптор».
330 Но, принцип первый: все что может сделать пользователь, должна иметь
331 возможность сделать программа. Без реализации этого принципа реализовать
332 базовую идею разработки приложения как интеграции существующих
333 инструментов, не удастся.
335 Принцип второй: Если существуют операции, доступные только из языка
336 программирования, но не через GUI, то должна быть консоль, с которой
337 команды этого языка можно ввести. Без реализации этого принципа будет
338 неудобно отлаживаться и изучать поведение существующих приложений.
339 Известно, что первым пунктом в разделе BUGS любого man должно идти
340 «User never reads documentation». Поэтому надо дать пользователю
341 возможность изучать систему экспериментальным путем.
343 Обратите внимание, что в DOS существовал командный язык, слабенький, но
344 язык. В Windows 3.1 был Macro Recorder — попытка реализовать идею записи
345 сценариев работы. В Windows 95 его уже нет. Попытка реализовать писание
346 скриптов путем протоколирования действий пользователя в GUI-среде
347 блистательно провалилась. Почему? Потому что фиксировались слишком
348 низкоуровневые события — нажатия кнопок мыши в таких-то координатах. Это
349 существенно отличается от тех понятий, которыми оперирует пользователь
350 «Вытащим наверх окно Word и выберем позицию Open в меню File». Если бы
351 макрос записанный макро-рекордером выглядел бы как
354 MaximizeOrStart "winword.exe"
355 Menu.File.Open invoke
356 Filedialog.Filename insert "myfile.doc"
357 FileDialog.OpenButton invoke
360 может быть этим и можно было бы пользоваться. Особенно если при
361 последующем редактировании макроса можно было бы предоставить
362 пользователю свободу действий на каких-то этапах, например
365 Menu.File.Open invoke
366 Wait window.close "Filedialog"
367 if Filedialog.Exitcode=Ok then
372 или наоборот, поместить эти действия внутрь цикла, скажем по всем файлам
373 в текущей директории.
375 Здесь мы сталкиваемся с той же проблемой, что и при проектировании
376 диалоговых окон — пользователь никогда не мыслит в терминах координат
377 экрана, даже когда он рисует мышкой линию в графическом редакторе.
379 Таким образом, складывается концепция принципиально нового подхода
380 к устройству десктопной OS, которая состоит в следующем:
382 Имеется базовый скриптовый язык, имеющий графический интерфейс.
383 Все необходимые компоненты реализуются как расширения для этого языка.
384 Они могут быть как объектно-ориентированными, так и нет. Я считаю, что
385 ООП это не панацея, тем более в ситуации когда работать с этим языком
386 зачастую будет конечный пользователь, которому легче в качестве
387 собеседника воспринимать компьютер в целом и формулировать свою мысль
388 как «Сделай то-то вот с этим объектом», а не «Эй, объект, сделай вот
389 это», особенно в ситуациях когда задействовано несколько объектов.
390 Например, не очевидно, чьим методом должно являться копирование из
391 объекта в объект — источника или назначения.
393 Уровень абстракции, на котором пользователь работает с этим языком
394 должен быть несколько выше, чем тот, который предоставляют Tcl/Tk или
397 Для часто выполняемых операций, таких как создание диалогового окна,
398 связывание формы с базой данных, должны существовать графические интерфейсы.
399 В идеале у каждого приложения данной системы должна быть кнопочка в
400 заголовке окна «Показать внутреннее устройство», которая превращает
401 окно приложение в окно RAD-системы. Последнее, видимо представляет собой
402 диалог с закладками, где можно посмотреть иерархию видгетов внутри окна,
403 связи с другими объектами в системе, текст который в результате
406 Для всех объектов в системе, которые по смыслу являются документами (а
407 таких будет не так много, как в MacOS или Windows) должен существовать
408 способ получить их стандартное представление, видимо на чем-то типа XML,
409 и должны существовать средства обработки этого XML, по простоте и
410 эффективности подобные grep, awk и sed, но учитывающие в удобных для
411 пользователя терминах структуру этого XML.
413 Мне кажется, что идеальным языком для реализации такой системы является
414 Tcl. Его преимущества:
416 <li> Гибкий синтаксис, вплоть до возможности реализации собственных
417 управляющих структур, что облегчает создание языка верхнего уровня.
418 <li> Простота разбора скриптов на Tcl средствами самого Tcl, что облегчает
419 создание RAD-компонент, способных прочитать и графически представить
421 <li> Наличие мощных интроспективных функций, которые делают ненужным
422 разбор кода, например для показа иерархии видгетов — проще спросить у
424 <li> Наличие системы соподчиненных интерпретаторов, что позволяет не
425 засорять пространство имен приложения функциями и объектами RAD-системы
426 <li> Наличие большого количества готовых компонент, хотя Python и Perl в
427 этом отношении несколько превосходят Tcl.
430 Все вышеперечисленное не означает, что на Tcl должны быть написаны все
431 компоненты системы. Скорее наоборот, большая часть вещей, для которых
432 критична производительность, должны быть написаны на C или C++, но в
436 <h2>Комментании читателей</h2>
438 From zappa@isssph.kiae.ru Fri Jun 2 19:34:41 2000
439 From: Andrei M. Zaparii <zappa@isssph.kiae.ru>
440 Subject: http://www.ice.ru/~vitus/ice/thoughts/true_unix_gui.txt
441 X-Mailer: Mozilla 4.61 [en] (Win95; I)
443 Доброго времени суток!
444 Если Вас интересует моё мнение, то:
445 1. Вы, как мне кажется, упустили один из важных моментов. Или, во всяком
446 случае, не акцентировали на нём внимание. А именно, пропорциональность
447 возможностей затраченному на обучение времени. UNIX way тем мне и нравится,
448 что я могу изучать ровно столько, сколько мне надо. С другой стороны в
449 существующих на сегодня UNIX-ах я могу разобраться на столько, на сколько мне
450 это нужно для решения задачи. И этот факт и делает для меня UNIX концепцию
451 наиболее привлекательной. По крайней мере с точки зрения эффективности, то
452 есть — отношения сэкономленного времени ко времени разработки.
453 2. Именно раздробленность стандартных средств UNIX на маленькие инструментики
454 позволяет таким как я людям заботиться о будущем. Я не могу повлиять на то,
455 какие инструментальные средства будут доступны в ближайшем будущем в среде MS
456 Windows. Если моё решение будет удачным, то оно быстро будет подхвачено в
457 среде UNIX, и не только fsf, и я в итоге получу инструмент, который мне
458 понадобится, именно в момент такой необходимости, а не тогда, когда для этого
459 созреет «рынок».
461 Что же до универсального представления потоков данных, то это напоминает мне
462 Structured Task Description Language — вещь в принципе возможную, но как-то
463 пока нигде не реализованную (Забудем про всякие Jinie и пр. неработающую муру)
464 Уже объяснить «простому пользователю» на какого xyz нужен sql довольно трудно.
465 Успешное объяснение, зачем нужен такой монстр, как язык описания произвольных
466 данных, представляется мне маловероятным, в терминах «простого пользователя».
468 Подводя итог, хочу отметить, что на сегодняшний день для UNIX community и
469 развития инструментария было бы гораздо полезнее определиться, кто такой -
470 этот «простой пользователь». И определиться с отношением к
471 этому «простому пользователю»
472 В частности, GUI должен быть прежде всего функционален, пропорционален в смысле
473 обучения, и только потом удобен, в той мере, в которой это нужно для первых
480 <b>Из моего ответа Андрею</b></p>
482 Смысл в том, что пользователю и не надо это объяснять, так же как не
484 ему объяснять того, что буква A представляется в текстовом файле
485 байтом со значением 65. Это должно быть в компетенции системы.
488 <b>А вот еще одна интересная статья на сходную тему.</b><br>
489 <a href="http://www.itc.kiev.ua/article.phtml?ID=2149">
490 http://www.itc.kiev.ua/article.phtml?ID=2149</a>
projects / sites / home_page.git / blob