Введение

OmegaT -- это свободная система автоматизированного перевода, поддерживающая память переводов, написанная на языке программирования Java. Эта система предназначена для профессиональных переводчиков. OmegaT не переводит вместо человека! (В отличие от программ, выполняющих «машинный перевод», OmegaT лишь помогает переводчику и упрощает его работу.) Возможности OmegaT включают:

подбор неточных совпадений;

размножение совпадений;

одновременная обработка проектов с большим числом файлов;

одновременное использование нескольких памятей переводов;

использование внешних глоссариев;

Поддерживаемые форматы файлов документов: - XHTML и HTML - Microsoft Office 2007 XML - OpenOffice.org/StarOffice - XLIFF (Okapi) - MediaWiki (Wikipedia) - неформатированный текст;

поддержка уникода (UTF-8): используется для алфавитов без латиницы;

поддержка языков с письмом справа налево;

совместимость с другими программами автоматизированного перевода (TMX).

Начиная с версии 2.04 OmegaT также может переводить текущий абзац текста через Google Translate.

Для работы OmegaT требуется версия Java 1.4, которая доступна для ОС Linux, Mac OS X и Microsoft Windows, Windows NT. Может работать с OpenJDK. В век информационных технологий, постоянного потока информации нехватки времени актуально внедрение программ, позволяющих делать переводы нескольких языков. Рассмотрим одну из них. Цель данной работы рассмотреть принцип работы программы и медоты ее улучшения.

Проблемы совместимости программного обеспечения. Основные методы и способы их разрешения

Рассмотрим запуск OmegaT в Windows 8

Копируем папку установки OmegaT с другого ПК. Для нас это наиболее предпочтительный способ обновления программы, поскольку в этом случае можно быть уверенным, что вы не забудете установить все самые последние плагины и скрипты. Помимо этого, копируем папку конфигурации OmegaT в папку, находящуюся по адресу c:Usersuser nameAppDataRoamingOmegaT. Программа не запустилась. В командной строке отобразилось следующее сообщение об ошибке:

«Java is not recognized as an internal or external command» (Java не является внутренней или внешней командой)

Способ исправления этой проблемы:

На панели, которая появляется при наведении курсора на правый нижний угол меню Start, выберите Settings > Control Panel > System > Advanced system settings.

Перейдите на вкладку Advanced и нажмите Environment Variables

В окне System Variables найдите Path и нажмите Edit.

Добавьте точку с запятой и укажите путь к папке bin, находящейся в вашей папке установки Java. Например, в моем случае это c:Program Files (x86)Javajre6bin.

Три раза нажмите OK.

Кроме этой, других проблем с работой OmegaT в Windows 8 не возникает.

Новая версия позволяет отображать неразрывные пробелы: выберите меню «Вид» > «Mark Non-breakable Spaces». В предыдущих версиях тоже можно было вставлять неразрывные пробелы, пользуясь обычным способом (Alt+0160 в Windows), однако в окне редактора они не отображались. Теперь пробелы отображаются серым цветом, и их намного легче вставлять и проверять.

Взаимодействие OmegaT с Dйjа Vu.

Дать перевод в формате Dйjа Vu. Это можно сделать (для Dйjа Vu DVX), используя формат Dйjа Vu «External Views».

Формат «External View» поддерживается программой Dйjа Vu DVX. Благодаря этому формату редакторы, у которых не установлена Dйjа Vu, могут корректировать переводы таким образом, чтобы их правки можно было легко импортировать обратно. Точно так же пользователи других систем автоматизированного перевода (например, OmegaT) могут переводить созданные в Dйjа Vu файлы без использования этой программы.

Файл Dйjа Vu «External View» представляет собой RTF-файл, внутри которого содержится таблица из нескольких столбцов, включая столбцы для оригинального и переведённого текстов. Каждый сегмент текста находится в отдельной ячейке. Если «External View»-файл ещё не переведён, столбец для переведённых сегментов пуст. «Переведённый» «External View»-файл можно получить, просто введя сегменты перевода в этот столбец. Для работы с этим файлом в OmegaT нужно сделать следующее:

1. Сконвертируйте RTF-файл в формат OpenOffice.org.

2. Сделайте копию файла «External View», а затем удалите содержимое всех столбцов, кроме столбца с сегментами оригинала.

3. Переведите файл в OmegaT. Теги внутри сегментов представлены в виде цифр, заключённых в фигурные скобки, т.е. {1}, {2} и так далее. Обращайтесь с ними также осторожно, как и с тегами OmegaT (возможности OmegaT по работе с тегами, как то, проверка тегов, в данном случае работать не будут).

4. После того, как вы закончите перевод и создадите переведённые документы, скопируйте столбец переведённых сегментов из переведённого файла в столбец переведённых сегментов исходного документа.

5. Для того, чтобы всё это работало, пользователь Dйjа Vu должен подготовить файл с исходным текстом и отдать его переводчику в формате Dйjа Vu «External View». Более подробная информация о самом формате и о способах его создания, как для пользователей Dйjа Vu, так и для пользователей других систем автоматизированного перевода, представлена на соответствующей странице веб-сайта Atril и в чрезвычайно полезном блоге Кевина Лосснера (Kevin Lossner)

Аннотация
Если во время тестирования приложения были выявлены возможные проблемы его совместимости с операционной системой Microsoft® Windows® XP, необходимо найти решение, которое позволило бы этому приложению работать должным образом. Такие решения проблем совместимости можно собрать в оболочки совместимости и распространить с помощью инструмента Администратор совместимости.

На этой странице

Введение

Одним из самых важных новшеств в Microsoft® Windows® XP стало добавление целого ряда технологий совместимости приложений, доступных даже конечным пользователям через оболочку Windows XP. Распространение исправлений совместимости приложений на большом количестве компьютеров может быть трудным или невыполнимым, если оно предоставлено каждому пользователю компьютера. К счастью, есть более простой способ собирать группы исправлений совместимости и распределять их путем автоматической установки на компьютеры, работающие под управлением Windows XP.

Администратор совместимости

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

Создание собственных оболочек совместимости с помощью Администратора совместимости

В этом разделе обсуждается как можно создавать и подготавливать файлы собственной базы данных с помощью Администратора совместимости, для поддержания множества приложений на одном или нескольких компьютерах, работающих под управлением Windows XP.

Администратор совместимости может компоновать исправления и оболочки совместимости для множества приложений в один файл базы данных совместимости (*.sdb), который потом может быть перенесен на другие компьютеры, работающие под управлением Windows XP. Это особенно полезно в большом сетевом окружении, где несколько человек должны обеспечивать поддержку программного обеспечения огромному числу пользователей.

Установка Администратора совместимости

Администратор совместимости, поставляемый с операционной системой Windows XP, может быть найден в папке Support Tools на установочном компакт-диске. Администратор совместимости распространяется как часть Пакета средств обеспечения совместимости приложений (Application Compatibility Toolkit) версии 2.0 и выше.

Для установки Пакета средств обеспечения совместимости приложений (Application Compatibility Toolkit) в Вашей ОС Windows XP:

1. Вставьте установочный компакт-диск Windows XP в привод компакт-дисков
2. Используя Мой компьютер (My Computer ) или Проводник (Windows Explorer) , перейдите на привод, в который Вы вставили диск с ОС Windows XP, и откройте папку Support Tools.
3. Щелкните дважды файл ACT. EXE для начала установки программы. Примите настройки, предложенные по умолчанию программой установки.

После установки Пакета средств обеспечения совместимости приложений (Application Compatibility Toolkit) его можно будет найти в меню Пуск . Администратор совместимости находится в группе Пакета средств обеспечения совместимости приложений (Application Compatibility Toolkit) в меню Пуск.

Использование Администратора совместимости

Windows XP содержит информацию о распространенных проблемах совместимости, которые могут происходить с некоторыми приложениями. Исправления совместимости приложений, предоставляемые Microsoft в Windows XP, созданы, чтобы помочь Windows XP должным образом поддерживать нормальную работу этих приложений, не ставя при этом под угрозу стабильность системы.

Четыре библиотеки DLL содержат все исправления совместимости
Четыре библиотеки DLL, расположенные в папке % WINDIR% AppPatch, содержат все исправления совместимости. Файлы APPHELP.SDB и SYSMAIN.SDB обеспечивают работу справочных сообщений приложений, а исправления приложений являются частью Windows XP.

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

• Антивирусные программы
• Программы, которые требуют доступа на уровне ядра операционной системы
• Программы, которые устанавливают специфические драйверы файловой системы

Причины неправильной работы приложений
Приложения, которые были созданы для работы с предыдущими версиями Windows, могут неправильно работать в ОС Windows XP Professional. Причины, по которым это может происходить:

• Приложение не запускается, когда Windows сообщает ему о новой версии операционной системы. Зачастую приложение работает нормально, если пользователь сможет обойти этот момент.
• Приложение обращается к старым версиям функций Win32 API, которые возвращают непредсказуемые значения на компьютерах с большим количеством ресурсов, таких как дисковое пространство
• Приложение ожидает старых форматов данных Windows.
• Приложение ожидает, что информация пользователя, такая как личные и временные папки, будет в определенном месте или в определенном формате.

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

Создание собственной базы данных совместимости

Администратор совместимости позволяет Вам просматривать исправления совместимости приложений, хранящиеся в защищенных системой базах данных, чтобы применять нужные исправления для сотен приложений. Основной интерфейс Администратора позволяет контролировать приложения с исправлениями совместимости путем просмотра их в базе данных ОС Windows XP Professional. Эта информация отображается в верхней левой части (части системной базы данных) окна Администратора совместимости.

Системная база данных совместимости является составляющей операционной системы Windows XP Professional, обеспечивающей идеальную совместимость для сотен Windows-приложений. Эта база данных и соответствующие компоненты защищены операционной системой.

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

Чтобы создать новую собственную базу данных с помощью Администратора совместимости:

1. Откройте Администратор совместимости выбрав в меню Пуск (Start) , Программы(All Programs) , Пакет средств обеспечения совместимости приложений (Application Compatibility Toolkit) , Администратор совместимости
2. Если у Вас открыта собственная база данных, в меню Файл (File) выберите Новый (New) .
3. Зайдите в меню База данных (Database) и нажмите Изменить название базы данных (Change Database Name ) . Как только Вы измените название базы данных, оно будет отображаться в заголовке собственной базы данных. Если пункт меню Изменить имя базы данных (Change Database Name ) не активен, щелкните по области базы данных окна.
4. В меню Файл (File) нажмите Сохранить (Save) и дайте название своему.sdb файлу. Теперь можно добавить исправления в Вашу собственную базу данных.

Как только Вы создали собственную пустую базу данных, которая будет содержать Ваши исправления совместимости приложений, можно добавить оболочку совместимости.

Для добавления оболочки совместимости

1. Выберите Создать исправление приложения (Create Application Fix ) в меню База данных. Появится диалоговое окно Создание исправления приложения (Create an Application Fix ) .
2. Выберите Применить режим совместимости (Apply Compatibility Mode ) и нажмите кнопку Далее (Next) .
3. Введите название приложения, для которого Вы будете определять режим совместимости, и нажмите кнопку Далее(Next) .
4. Введите название файла, к которому будет применен режим совместимости. Вы можете набрать название файла вручную или использовать кнопку Обзор (Browse) , чтобы указать его.
5. Выберите из выпадающего списка режим совместимости, который нужно применить, и нажмите Далее (Next) .
6. Нажмите кнопку Добавить файл (Add File) , чтобы выбрать файлы, которые помогут точно определить нужный файл на целевых компьютерах (Выберите файлы, связанные с приложением, которые будут установлены в то же место. Например, выберите файл.hlp, находящийся в одной папке с.exe файлом. Постарайтесь однозначно определить Ваш файл, не выбирая большое количество соответствующих файлов).
7. Когда выберете все необходимые файлы, нажмите Далее (Next) .
8. Если Вы хотите проверить приложение с примененным исправлением, нажмите Выполнить тестирование (Test Run). В противном случае нажмите Готово (Finish) .

Тот же процесс может быть использован для добавления индивидуальных исправлений совместимости в собственную базу данных, за исключением того, что в окне Создать исправление приложения (Create an Application Fix ) Вы должны выбрать вариант Применить определенное исправление совместимости (Apply Specific Compatibility Fix ). Как только всеисправления и оболочки будут добавлены в базу данных, сохраните базу данных и проверьте приложение.
Совпадение имен файлов

Применение собственной базы данных к системе

Как только Вы создали Вашу собственную базу данных исправлений совместимости приложений, она должна быть применена к системе компьютера, на котором это приложение будет работать. Общий процесс развертывания исправлений совместимости на нескольких компьютерах под управлением Windows XP включает следующие действия:

• Определите и проверьте исправления для необходимых приложений.
• Создайте файл выборочной базы данных с нужными исправлениями.
• Перенесите.sdb файл на нужные компьютеры под управлением Windows XP.
• Используйте команду SDBINST.EXE, чтобы зарегистрировать базу данных. Она автоматически установит и добавит информацию об исправлениях в реестр на выбранных компьютерах.

Перенос файла собственной базы данных на другие компьютеры под управлением Windows XP
Перенос файла собственной базы данных на другие компьютеры под управлением Windows XP может быть проведена разными способами:

• Можно поместить файл базы данных в программу установки и распространить его с помощью Групповой политики в сети с Active Directory, но это требует дополнительной работы.
• Файл может быть скопирован вручную на каждый удаленный компьютер, или это можно сделать с помощью сценария входа в систему.
• Еще одной возможностью является размещение файла.sdb на общем сетевом ресурсе, к которому имеют доступ все пользователи Windows XP.

Несмотря на то, что файл перенесен на удаленные компьютеры, содержащаяся в нем информация должна быть зарегистрирована на каждом компьютере. Это делается с помощью запуска команды SDBINST.EXE из командной строки, за которой следует полный путь и имя созданного.sdb файла. Например:

Sdbinst c:WindowsAppPatchmyapp.sdb

Как только база данных зарегистрирована на компьютере, информация о совместимости будет использоваться каждый раз при запуске приложения.

Заключение

Windows XP предоставляет улучшенную поддержку приложений по сравнению с предыдущими версиями операционных систем Windows. Помимо встроенной поддержки для решения огромного разнообразия известных проблем совместимости приложений, новые средства, включая Пакет средств обеспечения совместимости приложений (Application Compatibility Toolkit), позволяют системным администраторам осуществлять поддержку всех их приложений.
Администратор совместимости является инструментом из Пакета средств обеспечения совместимости приложений. Администратор совместимости позволяет системным администраторам брать информацию, полученную путем тестирования, и упаковывать её в индивидуальную базу данных совместимости. Эта база данных может использоваться для поддержки множества приложений, и может быть легко распространена на другие компьютеры, нуждающиеся в исправлениях совместимости. Для регистрации файла базы данных совместимости на удаленных компьютерах используется команда SDBINST.EXE, после чего информация будет доступна в Windows XP каждый раз при запуске приложения.

26.02.2007 Алексей Гриневич, Денис Марковцев, Владимир Рубанов

Если вернуться в конец 90-х и окунуться в мир операционных систем того времени, то вряд ли у кого возникнет сомнение в безраздельном царствовании Unix-совместимых систем. На стороне Unix все — семейство этих операционных систем изучают в университетах, для него созданы сотни тысяч приложений, оно успешно применяется в различных отраслях экономики, о нем написано море книг и документации. Правда, нельзя приобрести именно Unix, а можно купить IBM AIX, BSD, HP-UX, Sun Solaris и т.д. При этом требуются дополнительные усилия для того, чтобы программа, созданная, скажем, для AIX, заработала под Solaris. Различные клоны Unix оказались слабо совместимы. Аналогичные проблемы имеются сегодня и для ОС Linux.

Для решения инфраструктурной проблемы слабой совместимости различных версий Unix в 1985 году в рамках IEEE была начата работа над стандартом, обеспечивающим переносимость программного обеспечения. В 1990 году увидел свет стандарт IEEE 1003, также получивший название POSIX , который регламентировал программные интерфейсы (API) и перечень команд Unix-клонов. Однако для игроков рынка Unix унификация породила сложные политические проблемы: любое решение, любой выбор между альтернативными вариантами для достижения согласия ведет к тому, что «более стандартным» признается решение одного производителя по сравнению с решением другого. В результате стандарт изобилует многозначными утверждениями типа «в данном случае возможен один из двух альтернативных вариантов поведения» и белыми пятнами наподобие «стандарт не регламентирует поведение функции в этом случае». В конце концов, фрагментация стала одной из основных причин поражения мира Unix. Игроки этого рынка конкурировали не только с другими типами операционных систем, но и друг с другом, вводя частные расширения и закрытые интерфейсы, ограничивая круг возможных приложений каким-либо одним клоном.

Появившаяся в начале 90-х годов ОС Linux, вобравшая в себя код, созданный в рамках движения GNU, и впитавшая основные идеи Unix, благодаря открытости и независимости стала универсальным компромиссом. Ее код реализовывался с нуля, не опираясь на какую-либо реализацию, а только на текст стандарта POSIX. В результате система получилась изначально POSIX-совместимой, а независимость позволила объединить усилия различных игроков рынка Unix в борьбе за «возврат» упущенного сегмента операционных систем для ПК. Однако проблема фрагментации осталась актуальной и для Linux: наличие конкурирующих между собой дистрибутивов вызывает опасения в вероятном повторении судьбы Unix.

На первый взгляд, сама опасность фрагментации выглядит довольно призрачной - фактически имеется общий код, большинство дистрибутивов работают на основе одного и того же ядра, одних и тех же библиотек, что во многом определяет совместимость. Казалось бы, и приложения должны сохранять работоспособность и совместимость между различными версиями Linux. Но это не получает подтверждения на практике. Наряду с фрагментацией рынка дистрибутивов Linux по подходам и дополнительной функциональности, наблюдаются существенные перекосы в поддержке различными клонами даже распространенных и стандартных приложений - в различных дистрибутивах используются разные версии ядра и системных библиотек (в первую очередь, glibc). Это ведет к тому, что состав и поведение системных интерфейсов, предоставляемых системой приложениям, меняются от дистрибутива к дистрибутиву. Для того чтобы не повторить печальный опыт клонов Unix, в 1998 году в рамках специально созданной организации Free Standards Group (сейчас Linux Foundation ) началась работа над стандартом LSB (Linux Standard Base - «базовое семейство стандартов Linux»). Благодаря усилиям со стороны организаций X/Open, IEEE и ISO, открывших стандарт POSIX и часть тестов для свободного доступа, был заложен фундамент в дело стандартизации Linux.

Но что именно и зачем нужно стандартизовать? Неужели единый открытый код сам по себе не является единым и открытым стандартом?

Проблемы совместимости приложений

Как проявляются различия между дистрибутивами Linux на практике и насколько серьезна проблема? Приведем пример. Основу коммерческих предложений корпорации IBM составляют пять линеек программных продуктов: DB2, Websphere, Rational, Tivoli и Lotus. Практика показывает, что поддержка всех пяти линеек для одного дистрибутива Linux обходится ежегодно в миллионы долларов, которые идут на разработчиков и тестировщиков, ответственных за поддержку приложений под конкретный дистрибутив Linux. Следовательно, поддерживаются те дистрибутивы, для которых прибыль от продажи продуктов превышает эти миллионы; фактически это только дистрибутивы SuSE и Red Hat. Так возникает ситуация несоответствия - то, что работает на одних дистрибутивах, не запускается на других.

Совсем другая ситуация наблюдается для Sun Solaris. Прежде всего, в Sun Microsystems гарантируют, что программа, скомпилированная для Solaris 2.6, будет работать без перекомпиляции и под версией 10. Разработчики Sun прилагают огромные усилия для этого; при каждом изменении кода прогоняется набор более чем из 2400 приложений различного назначения и состава. Более того, если кто-то обнаруживает, что приложение перестало работать по причине несовместимости между версиями Solaris, то в Sun берут на себя ответственность и расходы на исправление этого несоответствия. В случае с ОС Linux данная работа долгое время не велась, приложения и дистрибутивы жили своей собственной обособленной жизнью. Самым печальным при этом является отсутствие универсального способа написания программы таким образом, чтобы гарантированно обеспечить переносимость. На решение этой проблемы и направлены усилия консорциума Linux Foundation, представляющего интересы основных игроков Linux-рынка.

Структура Linux

Нередко под Linux понимают лишь его ядро, но имеется множество вещей, которыми ядро заниматься не должно. Работа с документами, посылка почты, обработка XML, отрисовка окон - для всего этого есть специальные библиотеки, входящие в состав практически всех дистрибутивов. Эти библиотеки, так или иначе, приводят к вызову ядра, но проблемы и ошибки могут возникать не только в ядре, но и в самих библиотеках.

Бытует мнение, что если программа перестала работать при смене дистрибутива Linux (или его версии), то, имея исходные коды, ее очень легко подправить, а потому и проблемы с совместимостью нет. Прежде чем обсуждать, так это или нет, рассмотрим сначала структуру ОС Linux.

«Обобщенная» модель системы на базе Linux представлена на

Рис. 1. Модель системы на базе ОС Linux

Каждая конкретная Linux-система создается для работы одного или нескольких приложений, однако кода самого приложения недостаточно, чтобы извлечь необходимый пользователям сервис из аппаратуры - большинство приложений использует в своей работе обращения к функциям библиотек. Стандарт LSB Core 3.1 определяет следующие системные библиотеки: libc, libcrypt, libdl, libm, libpthread, librt, libutil, libpam, libz, libncurses. В современных Linux-системах интерфейсы этих системных библиотек реализуются библиотеками glibc, Linux-PAM, zlib и ncurses, которые на самом деле реализуют больше интерфейсов, чем определено в LSB Core.

По степени взаимодействия с ядром Linux функции системных библиотек можно классифицировать так:

• реализация функции полностью содержится в библиотеке, и ядро не используется (например, strcpy, tsearch);
• в библиотеке реализуется тривиальная «обертка» (wrapper) для вызова соответствующего интерфейса ядра (например, read, write);
• реализация функции содержит как вызовы системных интерфейсов ядра (причем возможно нескольких разных), так и часть кода в самой библиотеке (например, pthread_create, pthread_cancel).

Само ядро Linux содержит много экспортируемых точек входа, однако подавляющее большинство из них является внутренним интерфейсом для использования модулями и подсистемами самого ядра. Внешний интерфейс содержит порядка 250 функций (версия 2.6). Из них, к примеру, в своей реализации библиотека glibc 2.3.5 использует 137.

Конфигурации

Под конфигурацией системной части дистрибутива понимается комбинация версии ядра (включая отдельные заплаты), версий системных библиотек, параметров их сборки и архитектуры, на которой это все работает. На приведен пример конфигурации сборки двух гипотетических дистрибутивов, представляющих собой совокупность версий компонентов и заплат. Между версиями компонентов добавляется новая функциональность, а также убираются морально устаревшие интерфейсы и функции. Так, на данной диаграмме легко видеть, что поскольку дистрибутивы 1 и 2 используют различные версии GCC, совместимость по исходным кодам между ними отчасти утеряна - не все, что собиралось с помощью gcc 3.4, может быть собрано с помощью gcc 4.0 без доработки.

Рис. 2. Пример конфигурации сборки дистрибутивов

Дистрибутивы

По адресу lwn.net/Distributions/ можно найти перечень известных дистрибутивов Linux (на момент написания статьи их было 542), открытых для широкой публики. Здесь не учитываются версии, сделанные для внутреннего применения индивидуальными энтузиастами, а также различными компаниями, ведомствами и т.п. Согласно лицензии GNU, можно взять произвольный дистрибутив, внести в него модификации (как минимум в компоненты, подпадающие под GNU) и распространять далее.

Дистрибутивы можно классифицировать по ряду признаков.

• По базовым производителям. К примеру, Red Hat, Slackware, SuSE, Debian, Asianux, Mandriva, Gentoo представляют собой основные «ветви» Linux-индустрии. Эти дистрибутивы не являются наследниками других (хотя между ними есть некоторые исторические зависимости). Их можно считать стратегическими направлениями развития в Linux вообще. Большинство остальных дистрибутивов явно принадлежат к одной из упомянутых ветвей, - в основном наследуя исходный код и приложения и добавляя специфическую функциональность.
• По локализации. Во многих странах присутствует локальный производитель Linux (скажем, в России всем известны дистрибутивы ASP Linux и ALT Linux).
• По применению. Дистрибутивы для встроенного применения в мобильных устройствах; дистрибутивы, работающие без поддержки файловой системы; облегченные версии для использования в КПК; переносные версии для запуска с ограниченных носителей (Linux на дискете, Linux на компакт-диске и т.п.).
• По специализации. Дистрибутивы для поддержки определенной аппаратной архитектуры (AlphaLinux с поддержкой процессорной архитектуры Alpha, ARM Linux с поддержкой ARM и т.п.).

Процедура сборки Linux

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

Многообразие различных входящих в Linux компонентов и множество зависимостей между ними может проиллюстрировать процедура сборки ядра. Проект Linux From Scratch содержит последовательность шагов, необходимых для сборки дистрибутива Linux «с нуля». Упрощенная последовательность сборки дистрибутива LFS Linux версии 6.0 выглядит так:

1. Binutils-2.15.94.0.2.2 - Pass 1
2. GCC-3.4.3 - Pass 1
3. Linux-Libc-Headers-2.6.11.2
4. Glibc-2.3.4
…
87. Util-linux-2.12q
88. Конфигурация загрузки
89. Linux-2.6.11.12 - Ядро

Сборка ядра осуществляется на самом последнем шаге с помощью собранных перед этим бинарных утилит. Важно учитывать версии компонента, приведённого в каждом элементе списка. Замена одной версии компонента на другую не всегда тривиальна - сборка системы может оказаться невозможной из-за отсутствия или изменения какой-либо функции, либо усложнена. Сборка многих компонентов требует дополнительных действий, например, инструкция по сборке flex для данного дистрибутива содержит замечание :

Flex contains several known bugs. These can be fixed with the following patch:
patch -Np1 -i ../flex-2.5.31-debian_fixes-3.patch

В процесс сборки включается сборка средств компиляции, которые также претерпевают существенные изменения во времени. Даже базовые компоненты Linux нередко оказываются устаревшими. Так, версия компилятора gcc 4.0.0 не годится для сборки ядра 2.6.11 (хотя они и современники) и требует использования специальной заплаты для устранения этой несовместимости.

В плену зависимостей

Фрагментация на уровне библиотек - серьезнейшая проблема современного мира Linux. Частый выход новых версий библиотек Linux обычно считается хорошим явлением и, действительно, только так возможно быстро применять и апробировать новые идеи и делать доступными последние достижения «инженерной мысли»: в широком использовании иногда находятся десятки версий одной и той же библиотеки. При этом неотъемлемой отличительной чертой разработки отдельных компонентов ОС Linux является ее децентрализованный характер. Часто почти одновременно вышедшие новые версии различных компонентов заведомо несовместимы, а это означает, что совершенно невозможно обеспечить адекватное тестирование различных комбинаций библиотек на совместимость и гарантировать стабильную работу системы при всех возможных комбинациях. Как следствие, вся тяжесть проблем ложится на пользователя, решившегося установить программу или библиотеку, для которой явно не гарантируется способность работы в окружении, существующем на его машине, и такая ситуация складывается довольно часто.

Категория проблем, связанных с несовместимостью версий библиотек, получила название dependency hell («ад зависимостей», en.wikipedia.org/wiki/Dependency_hell ). С какими проблемами может столкнуться пользователь, установивший в свою версию ОС Linux какую-либо новую библиотеку? В этом случае приложения, работавшие с предшествующей версией, могут перестать корректно функционировать, так как эти приложения могли полагаться явно или неявно на определенные ошибки и побочные эффекты, присутствовавшие в старой версии. Также вполне реальна обратная ситуация, когда новая версия просто содержит новую ошибку. Но настоящая проблема возникает тогда, когда в системе должны работать несколько различных приложений, которые существенно полагаются на различные версии одной и той же библиотеки; может так оказаться, что совместная работа этих приложений просто невозможна. Иногда существует возможность иметь несколько версий одной и той же библиотеки в системе, и это будет вполне безопасным решением, однако это совершенно не рекомендуется делать в случае библиотеки glibc.

Основной эволюционный путь к достижению совместимости различных дистрибутивов Linux - стандартизация . Зрелый и всесторонне поддерживаемый стандарт позволит снизить затраты на обеспечение переносимости Linux-решений, что будет способствовать росту числа приложений для этой платформы, а значит и популярности Linux в целом. Сегодня в качестве такого «спасительного» стандарта выступает Linux Standard Base .

LSB - основной стандарт, определяющий требования совместимости к Linux-системам. Основные сведения по этому стандарту уже публиковались, например, в работе , в которой, однако, освещалась старая версия стандарта и несколько преувеличивалась роль интерфейсов ядра. В действительности стандарт LSB не специфицирует интерфейсы ядра, а определяет более высокоуровневые прикладные интерфейсы, реализуемые различными библиотеками. LSB не пытается быть заменой существующих стандартов, а наоборот, опирается на все основные стандарты, уже прижившиеся в Linux. Он фиксирует версии и подмножества составляющих стандартов, чтобы обеспечить согласованность, и дополняет описания тех интерфейсов, которые присутствуют де-факто в большинстве дистрибутивов Linux, но не вошли в какие-либо существующие стандарты. Основную часть стандарта LSB составляют требования к системным интерфейсам, которые должны поддерживаться всеми дистрибутивами Linux (своего рода «общий знаменатель» всех Linux-систем). В этой части LSB во многом ссылается на стандарт POSIX.

Основное отличие LSB в том, что разработчики приложений могут ориентироваться на одну платформу, скажем LSB 3.1, и этого достаточно для обеспечения работы на всех совместимых с LSB 3.1 дистрибутивах. То же самое действует и для поставщиков дистрибутивов: как только достигнуто соответствие с LSB 3.1, автоматически дистрибутив поддерживает все совместимые с ним приложения. К примеру, IBM в рамках инициативы Chiphopper предоставляет аппаратные решения под управлением только LSB-совместимых дистрибутивов. Во многом благодаря активности крупных игроков основные поставщики дистрибутивов уже прошли сертификацию по LSB или объявили о своих намерениях сертифицироваться (www.linux-foundation.org/en/LSB_Distribution_Status ).

Сейчас основной слабостью стандарта LSB является недостаток тестов. Встречаются случаи, когда описанный в стандарте интерфейс работает иначе, и тем не менее система успешно проходит сертификацию. Это объясняется тем, что теста на данный интерфейс просто нет, либо он слишком слаб, чтобы полноценно проверить работоспособность интерфейса. Очень уместно процитировать высказывание Яна Мердока, создателя Debian, а сегодня директора по технологиям Linux Foundation: «Известно, что интерфейсный стандарт хорош настолько, насколько хорошо тестовое покрытие, которое проверяет соответствие этому стандарту».

В Open Group открыли для включения в сертификационный набор тестов LSB некоторые из своих тестов для стандарта POSIX. В набор LSB включены свободные тесты стандартной библиотеки GNU C++ Runtime Library Test Suite, адаптированы тесты для libgtk и libxml. Консорциум Linux Foundation рассматривает возможность выкупа для открытия и включения в LSB различных платных тестовых наборов.

Занимаются решением этой задачи и в нашей стране. Так на базе Института системного программирования РАН создан Центр верификации ОС Linux, где разрабатывается открытый тестовый набор OLVER, который планируется включить в официальные тесты LSB. Между Центром и Linux Foundation заключено соглашение о сотрудничестве, в рамках которого продолжаются работы по улучшению тестового покрытия LSB и идет разработка новой инфраструктуры для развития этого стандарта.

Заключение

Для того чтобы предотвратить фрагментацию, уже имевшую место в отношении ОС Unix, необходимы меры обеспечения совместимости дистрибутивов - по крайней мере, в рамках некоторого подмножества функциональности. Переносимость приложений в рамках этого подмножества позволит объединить Linux как единую платформу и заметно понизить стоимость разработки и поддержки приложений, что должно положительно сказаться на их количестве и популярности Linux-решений в целом.

Сегодня основной инициативой по обеспечению переносимости является открытый стандарт LSB, принятый ведущими производителями дистрибутивов (Red Hat, SuSe, Mandriva) и приложений (MySQL, RealPlayer, SAP MaxDB). За этим стандартом стоит мощный консорциум Linux Foundation и такие его активные члены, как компании IBM, Intel, HP и Oracle, что позволяет надеяться на его успешное развитие и повсеместное внедрение в реальную жизнь. Таким образом, в лице стандарта LSB заложен надежный фундамент единой, нефрагментированной платформы Linux, обеспечивающей переносимость приложений как на основе исходного кода, так и в бинарном виде.

Однако даже очень хорошие стандарты остаются лишь благими пожеланиями, пока нет удобных и надежных способов проверять соответствие им. Именно поэтому улучшение качества покрытия тестов LSB является одним из важнейших приоритетов сотрудничества Центра верификации ОС Linux и Linux Foundation.

Тестовый набор основан на автоматической генерации тестов из формальных спецификаций требований и соответствующих тестовых сценариев с применением технологии UniTESK.

К концу 2006 года основная фаза проекта была завершена; все результаты проекта опубликованы на сайте Центра. Сейчас проект находится в стадии поддержки и расширения спектра целевых платформ (комбинации аппаратной архитектуры с конкретным дистрибутивом).

* Flex содержит несколько известных ошибок. Они могут быть исправлены при помощи следующей заплаты…- англ.

Проблемы совместимости Linux-систем

Если вы используете в своей работе операционную систему Windows 7, то возможно уже сталкивались с ситуацией, когда при запуске старой программы она выдаёт какие-то сообщения об ошибке или вообще не запускается. И при этом вы точно знаете, что раньше, когда в компьютере была установлена другая версия Windows (например, Windows XP) эта программа у вас работала нормально.

В чем же дело? И как можно выйти из подобной ситуации?

А всё дело в несовместимости операционной системы Windows 7 и некоторых программ, написанных для ранних версий Windows. Т.е. если мы запускаем в Windows 7 какую-либо программу, изначально написанную для Windows XP, то такая программа может не запуститься, а может закрываться сама по себе или же выдавать ошибки во время работы.

При этом сообщения могут выдаваться самые разные. Например, такое:

… а может и любое другое.

Чтобы исправить подобные проблемы, в Windows 7 предусмотрена возможность запуска таких программ в специальном режиме – режиме совместимости с более ранними версиями Windows.

Обратите внимание!

- этот режим нельзя использовать для антивирусов, а также программ, работающих с дисками или реестром («твикеры», «чистильщики» и т.п.), т.к. это может привести к повреждению системы или нарушить её безопасность.

- прежде чем использовать режим совместимости проверьте обновление проблемной программы (или драйвера) на сайте производителя, т.к. всегда есть вероятность, что уже вышла новая версия программы для Windows 7.

- режим совместимости не панацея, и в некоторых случаях его использование не даёт положительных результатов.

Итак, чтобы запустить программу в этом режиме, щелкаем её значок правой кнопкой мыши и выбираем пункт Исправление неполадок совместимости :

Нажимаем кнопку Запуск программы… (1) и смотрим, что происходит.

Если программа запустилась – отлично! Если нет, то расстраиваться пока рано! В любом случае нажимаем кнопку Далее (2) и в следующем окне выбираем нужный вариант:

Если программа запустилась, то щелкаем пункт Да, сохранить эти параметры для программы и в следующем окне выбираем пункт Закрыть модуль устранения неполадок :

Если же программа не запустилась (или опять выдала ошибку), то выбираем пункт Нет, попытаться использовать другие параметры :

После этого (в зависимости от того какие галочки были поставлены) нам будет предложено ответить на некоторые вопросы (выбрать варианты):

Опять нажимаем эту кнопку и проверяем работоспособность программы. Если программа запустилась, то закрываем режим совместимости (как было описано выше), а если нет, то можем данную процедуру повторить ещё несколько раз, используя другие параметры (пока программа не запустится или пока не будут использованы все возможные варианты).

Таким образом, мы попытались запустить программу с помощью Мастера совместимости.
Следует отметить, что те же действия можно проделать и другим способом (вручную). Если есть желание, то можете попробовать это проделать.

Для этого надо щёлкнуть значок проблемной программы правой кнопкой мыши и выбрать пункт Свойства , после чего перейти на вкладку Совместимость :

Здесь после установки флажка Запустить программу в режиме совместимости с: из раскрывающегося списка (1) можно выбрать операционную систему, в которой данная программа работала нормально.

Ниже при необходимости можно установить дополнительные параметры экрана (2):

Использовать 256 цветов

Данный параметр ограничивает количество цветов в программе до 256 (такое количество использовалось в старых программах).

Использовать разрешение экрана 640 × 480

Запуск программы в окне с разрешением 640х480. Можно попробовать включить этот параметр, если изображение в программе появляется очень долго («тормозит») или имеет неровности.

Отключить визуальное оформление

Можно включить при наличии проблем с меню или кнопками программы.

Отключить композицию рабочего стола

Отключение прозрачности и других визуальных эффектов. Включите, если имеются неполадки изображения или проблемы с отображением окон.

Отключить масштабирование изображения при высоком разрешении экрана

Включите этот параметр, если есть проблемы с размером шрифта или размером окна программы.

Ещё ниже можно поставить галочку Выполнить эту программу от имени администратора (3), если программа блокируется службой контроля учётных записей. Этот параметр даст программе полный доступ к системе (некоторые программы этого требуют).

Кнопка Изменить параметры для всех пользователей откроет ещё одно такое же окно, но настройки в нем будут применены для всех пользователей компьютера. Если вы единственный пользователь вашего компьютера, то эта кнопка вам не нужна.

После всех настроек нажимаем Ok и снова пробуем запустить программу.

Вот и все! Надеюсь, что теперь у вас получится запустить любимую (но устаревшую) программу в современной операционной системе.

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

Как правило, приложения и аппаратное обеспечение, работающее на Windows Vista, продолжит работать и на Windows 7. В следующем примере показано несколько проблемных областей совместимости приложений Windows 7.

1. Запуск и установка приложения : во время запуска и установки приложения помешать установке должным образом могут две распространенные проблемы:

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

Приложения пытаются сослаться на компоненты Windows, которые в Windows 7 были переименованы.

2. Контроль пользовательской учетной записи (UAC) : UAC увеличивает безопасность Windows, ограничивая доступ к компьютеру без уровня администратора, что ограничивает запуск приложений большинству пользователей, в качестве обычных пользователей. Также UAC ограничивает контекст, в котором выполняется процесс, чтобы свести к минимуму возможность пользователей непреднамеренно подвергнуть свой компьютер заражению вирусами или другими вредоносными программами.

UAC может иметь следующие проблемы совместимости:

Некоторые установщики, деинсталляторы и обновление не будет работать без повышения статуса до администраторского.

Стандартные пользовательские приложения, требующие для выполнения своих задач прав администратора, могут не выполнять свою задачу для стандартных пользователей.

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

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

DLL библиотеки приложений, которые запускаются с помощью RunDLL32.exe, если они выполняют глобальные операции, могут работать неправильно.

Запись стандартным пользователем приложений в глобальное расположение будет перенаправлено для каждого пользователя с помощью виртуализации.

3. Windows Resource Protection (WRP) : WRP предназначен для защиты ресурсов Windows (файлов, папок, реестра) в режиме только для чтения. Установщики приложений пытавшиеся заменить, изменить или удалить находящиеся под защитой WRP файлы операционной системы и/или ключи реестра могут вызвать сбой с сообщением об ошибке, указывающем на невозможность обновления ресурса.

4. Защищенный режим Internet Explorer : Защищенный режим Internet Explorer помогает защититься от атак с несанкционированным получением прав, ограничивая возможность записи для любой зоны ресурсов локального компьютера, за исключением временных файлов Интернета.

Приложения, использующие Internet Explorer и пытающиеся сделать запись непосредственно на диск во время нахождения в Интернете или интрасети, могут вызвать сбой.

5. 64-битная архитектура : Windows 7 полностью поддерживает 64-битную архитектуру. Приложения или компоненты, использующие 16-битные исполняемые файлы, 16-битные установщики или 32-битные драйвера ядра, могут вызвать сбой при запуске или будут неправильно функционировать.

6. Windows Filtering Platform (WFP) : WFP интерфейс прикладного программирования (API), позволяющий разработчикам создавать код, взаимодействующий с фильтрацией, происходящей на нескольких уровнях сетевого режима и во всей операционной системе. Если вы в своей системе пользуетесь предыдущей версией API, у вас могут возникнуть сбои при работе приложений связанных с безопасностью, таких как сканеры сети, антивирусные программы или фаерволы.

7. Изменение версии операционной системы : номер версии операционной системы изменяется с каждым новым релизом. Для Windows Vista внутренний номер версии - 6, в то время как у Windows 7 внутренний номер версии - 6.1.

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

8. Драйвера ядра: драйвера ядра должны поддерживать операционную систему Windows 7 или быть обновлены с помощью User-Mode Driver Framework (UMDF). UMDF - это платформа усовершенствования драйверов устройств, которая была введена в Windows Vista.