Портирование Autodesk Animator Pro будет кроссплатформенным

Question

предыдущий вопрос от меня здесь Обратный инжиниринг старых программ рисования

Я настроил свою базу операций здесь: http://animatorpro.org Вики скоро появится.

Хорошо, теперь у меня есть устаревшая кодовая база MSDOS на 300 000 строк. Это своего рода ситуация «будь осторожен с тем, что ты желаешь». Я не опытный программист на Си. Я тоже не совсем неопытен, но во всех смыслах и целях я новичок в языке и, в частности, в тонкостях его библиотек. Я особенно не осведомлен о капризах различий между программами на C, написанными специально для MSDOS, и программами, которые являются кроссплатформенными. Однако я изучаю эту кодовую базу уже больше года, и вот что я знаю об Animator Pro:

Используемые компиляторы и инструменты:

• Компилятор Watcom C
• tcmake (создать программу из Turbo C)
• 386asm, специализированный ассемблер для дозатора Phar Lap
• и, конечно, сам дозатор Phar Lap.
• подборка непонятных утилит

Большая часть компиляции, похоже, основана на пакетных файлах. Хотя я получил копии всех этих инструментов, мне пока не удалось его скомпилировать. (хотя я собрал его старшего брата, autodesk animator original.

У него есть система плагинов, которая реплицирует DLL до того, как библиотеки DLL стали доступны, на основе REX. Система плагинов обрабатывает:

• Видеодрайверы (с множеством включенных драйверов VESA)
• Драйверы ввода (включая планшеты Wacom и клавиатуры)
• Инструменты рисования
• Чернила (например, фильтры фотошопа или режимы наложения)
• Скриптовые аддоны (по сути скомпилированные скрипты)
• Форматы файлов

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

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

1. Компиляция с использованием оригинальных инструментов.
2. Переключитесь на использование DJGPP и внесите необходимые изменения для его компиляции вместе с оригинальным ассемблером.
3. Включите библиотеку Allegro.cc «Игра» и переключите в нее как можно больше функциональных возможностей - возможно, просто написав новые видео и драйверы ввода, которые используют Allegro API. Я имею в виду allegro, а не SDL, потому что: существует версия Allegro для DOS, и, что интересно, одной из его основных функций является возможность воспроизведения родного формата Animator Pro FLIC.
4. Надеюсь, после 3-го года я устраню большую часть или весь Ассемблер в проекте. Надеюсь, я говорю, потому что это на неясном диалекте, который не собирается ни в каком современном свободном ассемблере без существенных изменений. Я перепробовал их все. Все, что осталось, преобразуется для сборки в NASM или в код на C, если я могу определить действительную функцию ассемблера.
5. Переключите удлинитель dos с Phar Lap на HX Dos http://www.japheth.de/HX.html,, который обещает воспроизвести как можно большую часть API WIN32. Затем внесите все необходимые изменения кода, чтобы это работало.
6. Переключитесь на версию allegro.cc для win32, предполагая, что версия win32 может работать поверх HXDos. Внесите любые дальнейшие необходимые изменения
7. Модифицируйте систему плагинов, чтобы использовать какую-то стандартную кроссплатформенную библиотеку плагинов. Что это будет, я понятия не имею. Может быть, вы можете предложить несколько предложений? Я поговорил с разработчиком, который изначально написал систему плагинов, и он сказал, что некоторые вещи, которые он делает, невозможны в современных ОС из-за ограничений сегментации. Я не уверен, что это значит, но я предполагаю, что это означает, что все плагины нужно будет переписать практически с нуля.
8. Магическим образом, я выполнил все вышеперечисленное, и мы можем попробовать запустить его в windows, osx и linux, в то же время имея дело с другими кроссплатформенными проблемами, такими как длинные имена файлов, и вещами, о которых я даже не думал.

У кого-нибудь есть проблемы с этим? Аллегро хороший выбор? если нет, то почему? что бы вы сделали с этой системой плагинов? Что бы вы сделали по-другому? Разве все это глупо, и я должен просто переписать его с нуля, используя оригинал как вдохновение? (очевидно, потребуется оригинальный разработчик "Около месяца", чтобы сделать это)

Одна вещь, которую я не рассмотрел выше, это система текста / шрифта. Не уверен, что с этим делать, но Animator Pro имеет свой собственный формат шрифтов, но также может использовать шрифты Postscript Type 1 и некоторые другие форматы.

Answer 1

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

Если бы я занимался портом, мой подход состоял бы в том, чтобы отключить как можно больше кода, чтобы запустить SOMETHING в современной среде, и вернуть части в оперативное состояние, по одной части за раз. Напишите простую программу тестирования, которая загружает драйвер дисплея и рисует некоторые вещи, и скомпилирует их для DOS, чтобы убедиться, что вы понимаете интерфейс. Затем напишите некоторый код C, который реализует тот же интерфейс, но с Allegro (или SDL или SFML), и заставьте эту программу работать под Windows или Linux. Если выходные данные отличаются, у вас есть простой тестовый пример для работы.

Вся ваша работа на этом порту заключается в замене реализаций различных интерфейсов и функций на совершенно новые. Это работа, в которой модульное тестирование превосходит. Не пишите новый код без какого-либо теста, который выполняется на старом коде под DOS! Сделайте ваши потенциальные проблемы настолько маленькими и простыми, насколько это возможно. Портируйте код ассемблера вместо того, чтобы переписывать его, только если вы достаточно уверены, что он действительно облегчит вашу работу (т. Е. Алгоритмический материал, который прекрасно компилируется с помощью нескольких настроек в NASM). Не откусывайте больший кусок, чем вы можете удобно разместить в своем мозгу.

Я, например, с нетерпением жду вашего прогресса! Я думаю, что вы пытаетесь сделать, это здорово. Спасибо за это.

Answer 2

Хммм - я мог бы подойти к этому, написав для него видео-драйвер OpenGL. и современные машины достаточно быстры с тоннами оперативной памяти, чтобы вы могли сделать все пиксельные алгоритмы на главном ЦП в резервный буфер, и это сработало бы. Поскольку «универсальный» VGA-драйвер только что отобразил видеобуфер на указатель, это было бы место для начала. В пользовательском интерфейсе был режим масштабирования, поэтому вы можете смотреть на пиксели на экране с высоким разрешением.

Answer 3

Часто очень трудно взять существующую нетривиальную кодовую базу, которая не была написана с учетом переносимости - вы упомянули несколько - и затем попытаться сделать ее переносимой. На пути будет много проблем. Вероятно, лучше начать с нуля и переписать код, используя существующий код только для справки. Если вы начинаете с нуля, вы можете использовать существующее решение для переносимого пользовательского интерфейса в вашем новом проекте, таком как Qt.