|
Unsorted
|
|
Обновите ArcaOS до уровня NeoWPS
- Установите набор PNG иконок, нарисованных дизайнером, специализирующемся на оформлении OS/2
- Установите eSchemes 2018, чтобы менять цвета и кнопки на рабочем столе
|
Структура файлов сообщений |
TITLE: Структура файлов сообщений
DATE: 2004-10-07 19:05:18
AUTHOR: Yuri Prokushev
В данной статье приведено описания строения файлов *.MSG, библиотеки MSG.DLL.
Дано описание компилятора MKMSGF.EXE и формата исходных файлов сообщений.
Внутренности NLS
В рамках проекта osFree стоит задача разработки полнофункциональной замены
стандартных утилит разработки. Одной из таких утилит является аналог
компилятора файлов сообщений с открытым исходным кодом. В результате данной
работы было проведено исследование структуры файлов *.MSG.
Подготовка исходных файлов сообщений
Исходным файлом для компилятора файлов сообщений является обычный текстовой
файл. Формат файла довольно простой.
; Коментарий начинается с символа ';'. Строка с данным символом пропускается.
MSG
MSG0001I: Информационное сообщение %1.
MSG0002E: Сообщение об ошибке %1 %2.
MSG0003H: Большое
многострочное
сообщение
MSG0004P: Сообщение без перехода на новую строку %0
Здесь MSG - это идентификатор файла сообщений. Идентификатор должен
состоять из 3-х символов латинского алфавита. Оригинальный компилятор
не позволяет вставлять коментарий между идентификатором файла сообщений и
идентификатором сообщения. Аналог данного компилятора позволяет использовать
коментарий в любой части файла.
MSG0001I - составной идентификатор сообщения. Первые три символа - идентификатор файла сообщений.
Следующие четыре символа - номер сообщения. Последний символ - тип сообщения.
Может быть любым латинским символом из
|
I
|
Информационное сообщение
|
|
H
|
Справочное сообщение
|
|
E
|
Сообщение об ошибке
|
|
W
|
Предупреждение
|
|
P
|
Prompt
|
|
?
|
Нет сообщения
|
Идентификатор сообщения заканчивается символами двоеточия и пробела.
Для вставки параметров в сообщения предусмотрены модификаторы %?, где
? равен числу от 1 до 9. Специальный символ %0 используется для типа сообщения
Prompt, для предотвращения вывода символа перевода строки. Сообщение Prompt
в обязательном порядке содержит в конце последовательность %0.
Компиляция файла сообщений
Для компиляции файла сообщений необходима утилита MKMSGF из
OS/2 Developer's Toolkit. Так как Toolkit не распространяется свободно
(исключая владельцев eComStation), была написана аналогичная по своим
возможностям утилита под osFree License. Использование
обеих утилит полностью одинаково.
Предположим, что файл с исходными сообщениями называется NOS_RU.txt, а
двоичный файл сообщений имеет имя NOS_RU_RU.MSG.
Тогда для компиляции необходимо использовать команду
MKMSGF NOS_RU.txt NOS_RU_RU.MSG
При этом файл будет создан с кодом текущей страны. Для создания прочих
языковых файлов необходимо использовать дополнительные ключи:
| /V | Вывод дополнительной информации |
| /D | подмножество DBCS или код страны с DBCS |
| /P | Кодовая страница. Может быть указано до 16 страниц |
| /L | Идентификатор языка и диалекта |
| /? | Вывод справочной информации |
Многоязычные файлы сообщений
Файлы сообщений не были бы так интересны, если бы могли содержать только
сообщения одной страны, в одной кодировке. Поэтому существует возможность
создания многоязыковых файлов сообщений. При этом подготавливаются аналогичные
исходные файлы сообщений с одинаковыми идентификаторами сообщений, но с
различным текстом сообщений. Прежде чем начинать компиляцию файлов сообщений,
необходимо подготовить управляющий файл. Например, файл NOS_UNI.txt:
NOS_EN.txt NOS_UNI.MSG /L1 /P437
NOS_RU.txt NOS_RU_RU.cp866.MSG /L7 /P866
NOS_RU.koi8r.txt NOS_RU_RU.koi8r.MSG /L7 /P878
NOS_RU.win1251.txt NOS_RU_RU.win1251.MSG /L7 /P1251
После запуска компилятора
MKMSGF @NOS_UNI.txt
создаются файлы сообщений NOS_UNI.MSG и NOS_RU_RU.*.MSG. Файл
NOS_UNI.MSG будет являться опорным файлом и содержать информацию об остальных
файлах сообщений, то есть в дальнейшем не потребуется перебирать все варианты
файлов для поиска необходимого.
Встраивание файлов сообщений в исполняемый файл
Возможно встраивание файла сообщений в исполняемый файл. Для этого предназначена утилита
MSGBIND.EXE. Данная статься не рассматривает данный процесс, отметим только,
что сообщения сохраняются в сегменте MSGSEG.
Использование файлов сообщений
Для управления файлами сообщений используется библиотека MSG.DLL. Данная
библиотека содержит четыре функции:
- DosTrueGetMessage
- DosInsertMessage
- DosPutMessage
- DosIQueryMessageCP
Функция DosTrueGetMessage обычно напрямую не используется. Различные
компиляторы обычно оспользуют механизмы runtime-библиотек для предоставления
функции DosGetMessage, которая не содержит параметр MsgSeg, указывающий на
сегмент с сообщениями, встроенными в исполняемый файл.
Аналогичный подход, по тем же самым причинам, выполняется для функции
DosQueryMessageCP, которая скрывает вызов функции DosIQueryMessageCP.
Функции DosInsertMessage и DosPutMessage используются напрямую без
необходимости какого-либо вмешательства со стороны runtime-библиотек.
Более подробное описание данных функций и пример реализации runtime-части
для конкретного компилятора может быть получено из Developer's Toolkit и
исходных текстов runtime для OpenWatcom, EMX, VirtualPascal, FreePascal, Sibyl
и ряда других компилятороа.
Формат двоичного файла сообщений
Заголовок двоичных индексированных файлов сообщений OS/2 имеет следующую структуру:
Magic : Array[1..8] of Char; // Сигнатура файла
Identifier : Array[1..3] of Char; // Идентификатор сообщений
// (SYS, DOS, NET и пр.)
MessagesNumber : Word; // Количество сообщений
FirstMessageNumber : Word; // Номер первого сообщений
Offsets16bit : Boolean; // Размерность таблицы смещений
Version : Word; // Версия файла 2 - Новая 0 - Старая
IndexTableOffset : Word; // Смещение таблицы индекирования
CountryInfo : Word; // Смещение информации о стране
NextCountryInfo : DWord; // Смещение списка информации
// для многоязычный файлов сообщений
Reserved2 : Array[1..5] of byte; // Назначение неизвестно
Файлы старой версии сейчас практически не используются. Единственное
приложение, использующее формат старой версии (OS/2 1.x) - это Software
Installer. Все поля, начиная с Version, для версии 0 заполняются нулями.
Для многоязычных файлов сообщений поле NextCountryInfo содержит смещение
на список файлов сообщений и информацию о стране для этих файлов. Данный
список содержится в одном, главном, файле сообщений. Остальные файлы данного
списка не содержат. Список начинается со следующей структуры
BlockSize : Word; //Размер блока информации о стране
BlocksCount : Word; //Количество блоков
Блок информации о стране имеет следующую структуру:
BytesPerChar : Byte; // Байт на символ (1 - SBCS, 2 - DBCS)
Reserved : Array[0..1] of byte; // Неизвестно
LanguageFamilyID : Word; // Семейство языков
LanguageVersionID : Word; // Диалект языка
CodePagesNumber : Word; // Число кодовых страниц
CodePages : Array[1..16] of Word; // Список кодовых страниц (макс. 16)
Filename : Array[0..260] of Char; // Имя файла сообщений
Новый формат исходного файла сообщения
Вы могли заметить, что исходный формат файла не очень-то и удобен.
Синхронизировать файлы на различных языках довольно сложно. Известные
автору прочие подходы к исходным файлам (например, tmf, gettext) либо вообще
не поддерживают отличную от 850 кодовую страницу, либо поддерживают всего
одину кодовую страницу на файл. Поэтому предложен свой формат, который
использует кодировку UTF-8, а следовательно, поддерживает практически
неограниченное число кодовых страниц. Кроме того, поддержка национальных
файлов значительно упрощается за счет совмещения всех языков в одном файле.
Поленившись изобретать велосипед, автором предложено использовать язык xml
для разметки файла сообщения, тем более, что в наличии имеются различные
библиотеки для работы с xml.
<?xml version="1.0" encoding="UTF-8"?>
<!-- osFree message file -->
<!-- -->
<!-- Messages from 0000 to 7999 are reserved for compatability reason with -->
<!-- future versions of OS/2 and eComStation. If you want add new messages, -->
<!-- then add them starting to 8000-9999 range. -->
<messagefile id="SYS">
<languages>
<language id="en" codepage="850" countrycode="1" countrysubcode="1"/>
<language id="ru" codepage="866" countrycode="7" countrysubcode="1"/>
</languages>
<messages>
<msg number="0" type="I">
<lang id="en">Y N A R I<br /></lang>
<lang id="ru">1 2 1 2 3<br /></lang>
</msg>
<msg number="1" type="I">
<lang id="en">Incorrect function<br /></lang>
<lang id="ru">Неверная функция<br /></lang>
</msg>
</messages>
</messagefile>
Как вы можете видеть, здесь два логических блока:
- Блок определения языков
- Блок описания сообщений
Блок определения языка аналогичен файлу ответов для многоязычных
файлов сообщений.
Расширение API
Наверное, единственное, что хотелось бы расширить - это ввести аналогичную
GNU gettext функцию. Т.е. получать сообщение не только по индексу, но и
по сообщению первого языка. Предлагаемый прототип функции:
APIRET APIENTRY DosGetMessage(PCHAR* pTable,
ULONG cTable,
PCHAR pBuf,
ULONG cbBuf,
PSZ pszMessage,
PSZ pszFile,
PULONG pcbMsg);
Таким образом, при вызове функции DosGetMessage(nil, 0, buf, sizeof(buf), "English message\n", "OSO001.MSG", nil) будет получено,
например "Русское сообщение\n". Недостатком такой функции является более низкая скорость
работы, но улучшение читаемости кода, а также возможность автоматического
получения строк из исходного кода.
Пришлите ваши коментарии
Автору интересны предложения и замечания по новому формату файлов
сообщений, равно как и предложения по расширению существующего API.
Читайте также
|
Попробуй программу:
|
Panorama VESA - быстрый видеодрайвер для многопроцессорных компьютеров.
|
Комментарии: Юрий Пронякин 
2004-10-08 16:07:13 | (Куда-то мой комментарий пропал. Попробую ещё раз.)
Конечно, иметь единую точку для доступа к сообщениям на разных языках - очень полезно. Но, к сожалению, нынешний API имеет серьёзный идеологический недостаток, значительно снижающий его ценность. Сейчас в качестве критерия при выборе сообщения из многоязычного файла система использует его номер и кодовую страницу. И всё!
Нам, пользователям CP866, сразу не понятно, в чём тут подвох. Но подумайте о европейцах, у которых на практически все их языки одна кодовая страница - CP850. В результате - как программа может объяснить системе, что сообщение ей нужно на немецком языке, а не на французском?
В общем, совершенно очевидно, что функции извлечения сообщений из файла должны учитывать, что:
а) для разных языков может использоваться одна и та же кодовая таблица;
б) в одной стране может использоваться несколько разных языков;
в) один и тот же язык в разных странах может быть разным (вспомните о десятке диалектов английского);
г) для одного и того же языка могжет использоваться несколько разных кодовых страниц.
Так что необходимость в новом API сомнений не вызывает. И в этих новых функциях программа должна иметь возможность указывать страну и язык, для которых извлекается сообщение. Думаю, что для этого следует использовать не числа, а текстовую строку (как в переменной окружения LANG).
А вот возможность указания кодовой страницы обязательной не является - необходимое преобразование программа может выполнить и сама. Но, естественно, лучше, если это будет сразу делаться системой - чтобы прикладным программистам было проще жить.
В связи со всем вышеизложенным можно также обсудить вопрос о хранении сообщений в MSG-файлах в Unicode. Тем более, что существующий формат файла этому не препятствует. | Sergey Posokhov
2004-10-08 21:01:38 | Существующий двоичный формат файла:
1. Разбирается только с помощью DOS API,
2. Хранит все числа в "little-endian".
Чтобы читать сообщения в Java-апплетах (например), более подходит как раз XML и запись строк в UTF-8.
Так что все верно. | Yuri Prokushev
2004-10-09 08:28:45 | 2Юрий Ну, я не уверен в том, что текущий формат использует только номер сообщения и кодовую страницу. Правда, опыта сделать такую проверку небыло.
Давать программе возможность указывать язык и страну. Я вообще против того, чтобы программа сама это выбирала. В противном случае мы опять получаем кучу различных механизмов поддержки многоязычности. Причем каждая реализация со своими недостатками. По поводу использования текстовой строки типа EN_us. Согласен, что пользователю лучше оперировать именно такой строкой. А вот система все-равно должна оперировать кодами страны и языка.
По поводу кодировки тоже согласен. Можно смело хранить в Unicode, а потом преобразовывать. Правда, все это усложняет первоначально простой механизм. Однако, в принципе, все это имеет смысл.
В качестве вывода по всему этому:
1. Двоичный файл сообщений лучше всего подходит для функций API, т.к. см. коментарии Сергея
2. Текстовой файл сообщений лучше максимально абстрагировать от всяких кодовых страниц, кодов стран. кодов языков и прочая.
Т.е. большинство операций по обработке этих двух уровней должно упасть на компилятор файлов сообщений.
2Сергей
А также XML в UTF-8 может неплохо послужить исходным текстовым файлом сообщений. А вот двоичный оставить почти тем же.
2Всем: В принципе, эти заметки были накиданы года 2 назад, просто попались под руку. Вообще, меня просто перестало устраивать то, что начали плодится "новые API" которые кроме проблем никаких преимуществ не дают, при этом забывая, что уже есть нужные штатные API.
Вообще, я хочу привести в порядок и немного расширить текущий API файлов сообщений, дабы он стал штатным и достаточно удобным как для переводчика. так и для программиста.
| Юрий Пронякин
2004-10-09 23:59:20 | >Ну, я не уверен в том, что текущий формат использует только номер сообщения и кодовую страницу. Правда, опыта сделать такую проверку небыло.
Я проверял (правда, для сообщений, засунутых внутрь EXE, но это ничего не меняет) - система тупо использует первый блок, в котором найдётся нужная кодовая страница. Косвенным подтверждением этого является также и то, что коды языков и диалектов для MKMSGF не имеют ничего общего с кодами стран для строки COUNTRY. Второе подтверждение - документация от IBM:
"When an application requests the message retriever for text associated with a message number, a test is made to determine if there is a bound message segment with this executable file. If true, each bound message segment is searched for a match with the current session's code-page number.
If a match is made, then the message number is searched for. If it is found, the message will be returned to the caller.
Otherwise, the search of remaining bound message segments will continue."
Как видишь, сравнение идёт только по номеру CP.
>Давать программе возможность указывать язык и страну. Я вообще против того, чтобы программа сама это выбирала.
А куда мы от этого денемся? Ведь должно же быть какое-то указание системе, на каком языке извлекать сообщения. Причем пользователь должен иметь возможность либо перед запуском программы, либо во время её работы дать системе это указание (мы же хотим дать пользователю возможность выбирать язык, не так ли?). Что в твоём варианте будет таким указанием? Единственное, что мне приходит в голову - какая-то информация в окружении программы. Но тогда что помешает программе залезть в своё собственное окружение и поправить его? Таким образом, мы всё равно оставляем программе возможность выбора, но очень неудобную и негибкую. Нет, лучше уж пусть у функции извлесения будет соответствующий параметр.
>В противном случае мы опять получаем кучу различных механизмов поддержки многоязычности.
Какую же кучу? Сейчас у нас есть всего один механизм - обсуждаемый в статье. Как мы видим, он нас не устраивает. Я предложил его развитие, причем максимально совместимое с имеющимся. Совместимое настолько, что даже MSG-файлы переделывать не нужно: старые будут совместимы с новым API, а новые - со старым. Собственно, всё, что я предложил - при выборе сообщения использовать информацию о языке и диалекте, которые и сейчас есть в файлах, но игнорируются системой.
>По поводу использования текстовой строки типа EN_us. Согласен, что пользователю лучше оперировать именно такой строкой. А вот система все-равно должна оперировать кодами страны и языка.
Проблема в том, что сейчас официально никаких кодов языка не существует вообще. Что делать? Вводить эти коды? А зачем, если у нас уже есть стандартное обозначение, которое буквенное, а поэтому легче запоминается? К тому же таким образом мы реализуем совместимость ещё с одним существующим системным механизмом. Давай подумаем, что делать в случае, когда программа хочет не задавать явно язык, а использовать системные умолчания. В таком случае при использовании числовых кодов мы передадим 0, а в случае использования строки - пустую строку. Получив их, функция API должна где-то посмотреть, что есть умолчания. И вот тут нам пора вспомнить о последней страничке блокнота программных объектов. Той, которая называется "Язык". Там ведь пользователю тоже даётся возможность выбрать язык для программы. А знаешь, что для программы меняется тем выпадающим списком? Правильно, переменная LANG в её окружении.
Таким образом, в моём варианте функция извлечения сообщения, получив в качестве желаемого языка пустую строку, поищет эту строку в окружении программы. А в твоём варианте? Реализовывать два механизма - один для обработки параметров, а другой - для определения умолчаний (причём этот второй всё равно совпадает с моим)?
>По поводу кодировки тоже согласен. Можно смело хранить в Unicode, а потом преобразовывать. Правда, все это усложняет первоначально простой механизм.
Понимаешь, всё, что я хотел - упростить механизм преобразования. Чтобы программисту не нужно было самому заниматься перекодировками, а достаточно было заказать системе вернуть текст в нужной кодировке. Поскольку информация о кодовой странице текста всё равно хранится в файле, то не имеет особого значения, из чего пребразовывать. Просто Unicode - более универсально. И к тому же позволит PM-ным программам выводить многоязычные сообщения.
>1. Двоичный файл сообщений лучше всего подходит для функций API
Правильно. Формат файла мы не меняем.
2. Текстовой файл сообщений лучше максимально абстрагировать от всяких кодовых страниц, кодов стран. кодов языков и прочая.
Совершенно верно. В предлагаемом тобой синтаксисе есть строчка <language id="en" codepage="850" countrycode="1" countrysubcode="1"/>. Я предлагаю изменить её на <language id="en" codepage="850" family="en" country="US"/>, а преобразование family и country в числовые коды (формат файла ведь не меняем!) возложить на компилятор. При этом текст в MSG-файл либо заносить в той кодировке, в которой он написан в исходном файле, либо преобразовывать в уникод. Можно даже приделать к компилятору ключик соответствующий, чтобы программист мог выбирать.
>Т.е. большинство операций по обработке этих двух уровней должно упасть на компилятор файлов сообщений.
Вот, вот. | VicTor
2004-10-15 15:27:23 | Хотя это, конечно, элементарно, но, честно говоря, для полноты ощущений не хватает явного указания того:
1. что, если значение поля, названного Offset16bit, равно 1, то используется 16-битная таблица смещений, а если равно 0, то 32-битная;
2. что таблица смещений == таблица индексирования;
3. какова структура структура блока сообщения, на который ссылается элемент таблицы смещений:
struct {
UCHAR msgType; //"I", "H", "E", "W", "P", "?"
BYTE bytes[1]; // тело сообщения
}; | Юрий Пронякин
2004-10-19 16:07:26 | Может тогда уже и исходники декомпилятора выложить? "Для полноты ощущений"? ;-)
Статья-то не об этом. | Yuri Prokushev
2004-10-20 06:40:46 | Ок. Только причешу их и могу отдвть в пользование.
| Юрий Пронякин
2004-10-20 18:50:28 | Ты не понял. Я как раз в противоложном смысле высказался. Всё-таки статья об использовании MSG для нужд NLS и о путях возможного развития, а не о внутреннем строении файлов. Оно что пользователям, что прикладным программистам должно быть малоинтересно. | VicTor
2004-10-20 22:15:00 | Как это статья не о внутреннем строении файлов? А название о чём говорит? И почему это малоинтересно программистам?
IMHO полуосевое решение NLS как раз страдает из-за своей фрагментарности, когда разные команды разрабатывали разные решения одной и той же проблемы, например, есть сообщения и есть ресурсы. Почему бы вообще не отказаться от MSG, сразу перейдя к ресурсам (тип STRINGTABLE)? И если уж хранить сообщения в уникоде, то отчего же их не перекодировать внутри функций API, воспользовавшись локалью? | Yuri Prokushev
2004-10-21 14:55:36 | 2Юрий Как раз о внутренней структуре, а уж потом о недостатках текушего API.
2VicTor Имено. Именно то, что каждый разработчик начинает изобретать свой велосипед и есть плохо. Однако, твое предложение хранить все в ресурсах не есть гут. Смысл-то как раз в том, чтобы можно было
1. Легко использовать в своей программе, не думая о том, что есть разные языки и кодировки.
2. Дать возможность легкого и простого перевода.
Исходя из этого и рассмотрения различных подходов к поддержке национальный сообщений мне понравилось два подхода:
1. GetText - за то, что он позволяет легко внести поддержку многоязычных файлов и позволяет легко их обслуживать.
2. Текстовые файлы сообщений - за легкость в добавлении переводов.
Поэтому хотелось бы иметь:
1. Обратную совместимость с принятыми в OS/2 подходами (т.е. поддержку текущего API). Посему и разбирался со структурой файлов сообщений.
2. Удобство в локализации (с точки зрения разработчика) на уровне GetText.
3. Удобство в локализации (с точки зрения переводчика) на уровне редактирования текстового файла.
А уж выбором кодировки и прочего пусть занимается система.
Хранение в ресурсах опять же не дает, ИМХО, никаких преимуществ, плю будут заморочки с декомпиляцией и обратной компиляцией оных. Оно нам надо?
| Юрий Пронякин
2004-10-21 15:55:06 | Но ведь статья называется "Внутренности NLS", а отнюди не "Внутренности MSG". И рассказывается в ней о многом: и о том, что это вообще такое и для чего, и как этим пользоваться, и как готовить исходники, и как их компилировать. Формату файлов MSG посвящён всего лишь один малюсенький раздел. (Да и то, как я уже сказал, информация эта не нужна ни пользователям, ни разработчикам. Так, просто любопытствующим).
Но это так, моя трактовка; а посему большого значения она не имеет, каждый волен расценивать статью как ему хочется. Но кое-что я всё таки хочу высказать: от идеи GetText я не то, чтобы не в восторге, - я это считаю образцом маразма. Во-первых, скорость, во-вторых, необходимость держать две копии сообщений (одну - в программе, вторую - в файле сообщений), в-третьих, опасность рассинхронизации этих двух копий при работе над программой, в четвёртых - невозможность сторонним лицам ничего исправить в сообщениях на базовом языке, даже найденную грамматическую ошибку (потому что для этого нужна перекомпиляция программы!). | VicTor
2004-10-22 00:33:49 | 2 Юрий: статья всё-таки называется по другому, если мои глаза меня не обманывают :)
2 Yuri: Вы всё правильно пишете, но я предлагаю взглянуть на проблему шире.
Давайте попробуем отделить цели от средств и реализаций. По моему мнению, правильным будет такое деление:
1. цель NLS - дать приложению возможность ввода/вывода информации в необходимом пользователю языковом и культурологическом формате. Поскольку мы рассматриваем только отображаемую текстовую информацию, то забудем про форматы даты, времени и прочее. Для текстовой информации нам важны страна, язык и набор используемых им символов (который может предоставляться различными кодовыми таблицами).
2. средством достижения этой цели предлагается считать изоляцию кода от языкозависимой информации.
3. а вот реализаций этого хозяйства, которые более-менее внятно доносят информацию хотя бы о кодовой таблице и стране, в полуоси две, по крайней мере. Это файлы сообщений и ресурсы.
Причём, как мне кажется, файлы сообщений можно рассматривать как частный случай ресурсов. Поэтому предложение хранить сообщения в ресурсах вполне логично.
С другой стороны, поскольку мы рассматриваем новое расширение API, то почему бы не реализовать его таким образом, чтобы оно могло получать сообщения как из бинарных файлов ресурсов (назовём это новым форматом), так и из бинарных файлов сообщений (назовём это старым форматом) для обеспечения совместимости.
В этом случае отпадает необходимость в таком средстве разработки как MKMSGF. Нужен будет только компилятор ресурсов (а он и так понадобится). | Sergey Posokhov
2004-10-23 18:27:50 | Т.е. надо внутри "DosGetMessage()" вызывать "WinLoadString()", если задано имя файла "*.dll", выбирая строку по номеру.
Вот когда IBM откроет исходные тексты... :-) | Yuri Prokushev
2004-10-23 19:34:43 | Я, например, против каких-либо бинарных файлов. Разве что только автокомпиляция (по типу REXX). Т.е. ресурсы и прочее мне совсем не нравится. А еще больше всего не нравится необходимость наличия вообще каких-либо утилит для компиляции файлов сообщений. Хочу все прозрачно ;)
| Eugene Gorbunoff
2004-10-23 23:58:45 | можно хранить языковые ресурсы в .zip файле myprogram.dat в xml, как описано выше. такие ресурсы легко редактировать. они занимают мало места. для считывания в программу достаточно встроить unzip и xml-парсер. | Yuri Prokushev
2004-10-24 07:35:24 | 2Eugene Это о-о-о-очень медленноё
Не пойдетё
| Yuri Prokushev
2004-10-24 07:37:05 | Блин. Выговор тому, кто поставил по умолчанию левую кодировку (я даже знаю кому)
| VicTor
2004-10-24 20:24:35 | 2 Sergey: отнюдь. ;-) DosLoadModule() и DosGetResource(). Тут, кстати, сразу же всплывает любопытная деталь - dll-то грузится в shared арену, а, следовательно, и все ресурсы, приклееные к ней, тоже разделяются всеми нуждающимися в них приложениями. А вот как это дело обстоит с MSG, мне не понятно, хотя, например, в OSO001.MSG собраны сообщения практически всех системных программ, включая инсталляцию.
2 Yuri: ну это, мне кажется, перегиб :) Бинарники не столь плохи, чтобы от них отказываться совсем. Лишь бы были нормальные средства компиляции / декомпиляции... | Yuri Prokushev
2004-10-25 06:35:28 | 2VicTor По-моему, самым таким компромисом является метод, используемый в REXX. Т.е. у нас есть текстовой файл, который в расширенных атрибутах держит бинарные данные. Просто и со вкусом. Проверяем дату, если все нормально, то читаем бинарные данные, если нет, вызывает компилятор, а потом читаем бинарные данные.
По поводу загрузки MSG. MSG файлы не грузятся в память. Совсем. И поменять я их могу на лету. Подменил файлик и все. В случае ресурсов и dll-ей всегда головняк с тем, что файлик занят уже другим процессом. И это бесит. Особенно, когда переводишь, и нет четкой уверенности, что же ты там перевел и надо посмотреть. В случае MSG все тривиально.. | VicTor
2004-10-27 06:36:10 | 2 Yuri: Rexx-овый метод безусловно хорош. Но применим ли он здесь? Код может содержать ошибки, а вот исходные данные - нет. А сообщения и ресурсы как раз и есть исходные данные для системы.
С точки зрения многозадачной системы, то что файлы MSG каждый раз открываются, считываются и закрываются, наверное, не есть гут. Хотя, конечно, всё это нивелируется за счёт буферизации... А головная боль нынче лечится с помощью SET LIBPATHSTRICT=T :))) | Yuri Prokushev
2004-10-27 12:12:35 | 2VicTor А почему он неприменим??? Никто ведь не требует стирать бынарные атрибуты до компиляции. Кроме того, компиляция работает _только_ при работе переводчика. И вывода взамен требуемого сообщения сообщения об ошибка (как это сейчас делается, если сообщение или файл сообщений не найден) вполне достаточно. Это не приведет ни к каким проблемам. И практически никак не отличается от текущей логики работы. В случае ресурсов также могут быть проблемы с отсутствием нужной строки или самой dll.
А кроме того, для компиляции ресурсов нужен stub DLL исходный код и коспилятор ресурсов. Который тоже может оказаться несовместим со своими более другими версиями. ;)
| Ord@
2005-02-24 16:48:56 | Я в этом практичиски ничего не понимаю :( ... Но желал би узнать больше ... ПИШИТЕ !!!!! |
|
OS/2 / eComStation существует и развивается уже более 20 лет. Хочешь посмотреть, как она будет развиваться в следующие 20 лет? История eComStation |
|
|
|
