консольное приложение с возможностью прикрутки внешнего GUI

[kvas]

Хочу написать программу так, чтобы она была:
1) консольной - пользовательский интерфейс вроде ДОСовского debug (это будет эмулятор некоей виртуальной ЭВМ)
2) допускала запуск под внешней программой, которая перехватит её Stdin,Stdout,Stderr и оформит вывод уже в виде оконной графики (сам реализовывать п.2 не планирую, но надо чтобы это было реализуемо)
3) переносимой (путём перекомпилляции, естественно) не теряя свойств между разными ОС, как минимум - windows/linux/freebsd
4) потребуется вывод и русских символов, в однобайтовой кодировке
Как мне лучше осуществлять ввод и вывод текста чтобы не вступить в потиворечие с пунктами 2 и 3? Ну и чтобы переносимость минимально повлияла на п.4?
Стандартные writeln/readln так же, как в турбо-паскале, от модуля Crt дико зависят?

P.S. с паскалем уже 25 лет знаком

[bormant]

Соберите общую функциональность в библиотеке, которую будете использовать из текстового и графического интерфейса.

[kvas]

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

[Снег Север]

Это не обход проблемы, а единственный реальный путь ее решения.

[Дож]

Общее правило: в stderr стоит писать только данные для пользователя (ошибки, trace, verbose и т.д.), а в stdout только полезную и ожидаемую информацию. Тогда программе не придётся чистить от мусора вывод, а пользователь сможет увидеть важную информацию.

По задаче: самый простой способ решить проблему — это ввести ключики для контроля форматов и режимов работы программы (и пользователь будет запускать просто ./prog, а надпроцесс — ./prog --input-format external --output-format external). (Ну, или вообще просто один ключ ./prog -e) Тогда будет полная свобода в продумывании своего API, не влияющего на человеческую версию.

По пункту 3 — нужно соблюдать стандартные требования на кроссплатформенные приложения. В FPC есть много стандартных кроссплатформенных модулей, следует их выбирать при прочих равных.
http://wiki.lazarus.freepascal.org/Mult ... ming_Guide

По пункту 4 — по умолчанию программе следует использовать стандартную системную (консольную) кодировку, а для внешних вызовов ввести ключики для выбора (опять же ./prog --input-encoding cp1251 --output-encoding cp1251).

Стандартные writeln/readln так же, как в турбо-паскале, от модуля Crt дико зависят?

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

[Mirage]

Виртуализируйте ввод/вывод, чтобы программа использовала некий API, а далее можно было менять реализацию.
Например, реализация через read/write. А для GUI-морды через TCP, например. Или другой какой способ IPC.

[kvas]

Написал тестовую программу и начал её мучать. Итог:
"ReadLn(Str);" - читает из стандартного входа
"WriteLn(Output,Str);" - направляет в стандартный файл вывода
"WriteLn(StdErr,Str);" - направляет в стандартный файл вывода сообщений об ошибках
команда "ConsoleTest.exe <ConsoleTest.txt >ConsoleTest.res1 2>ConsoleTest.res2" отрабатывает все три переназначения как полагается.

Добавлено спустя 22 часа 32 минуты 49 секунд:
Re: консольное приложение с возможностью прикрутки внешнего GUI
... и, чтобы уж поставить последние точки над "ё", замечу, что функции "SetStdHandle" и "GetStdHandle" не работают (компилятору не известен тип "hwnd"), если в секции "Uses" не упомянут модуль "Windows", наличие которого ставит под угрозу переносимость под юниксы.

[Дож]

Ну да, эти функции — чистое WinApi.