Консоль

Applications development, KoOS API questions
  • неее... сначала надо OpenGL добавить :)
  • Речь идёт о библиотеке, которую могут использовать все программы, которые этого хотят. Типа подключаем её и становятся доступными функции типа (любителям Си и *nix) printf/scanf или (любителям Windows) ReadConsole/WriteConsole и некоторые более продвинутые. Плюс стандартный интерфейс окна консоли.
    По поводу 3, наверное, стоит уточнить: вопрос был про изменение размера окна консоли, которое нельзя сделать в винде (разве только через изменение параметров через меню), но есть в иксах под Linux.
    Ну и стандартное приложение CMD, которое этот интерфейс будет использовать. При желании уже сейчас можно "навесить" на тильду вызов CMD (немного изменив пример @numcalc).
  • Консоль нужна.
    Это позволит писать платформенно-независимую программу на языке высокого уровня(к примеру вычислительную программу).

    Вывод текста нужно сделать через 7-ю функцию.Это позволит менять размер шрифта.Если человек плохо видит,то он сможет увелить его(шрифт).
  • Кросплатферменные проги можно писать не только для консоли... Единственное что сейчас это самый простой вариант
  • Можно конечно и SDL и OpenGL(это вообще тема отдельного разговора) использовать,но нам до них ещё долековато.Пока компилятор не портируем в Колибри,пока libc не напишем(её платформенно зависящую часть) - не видать нам SDL или OpenGL(хотя OpenGL можно и на чистом ассемблере писать).



    P.S.
    Есть ещё куча других платформенно независимых библиотек,но я сказал про самые распрострвненные.
  • Предварительная версия:
    http://diamondz.land.ru/console.7z
    Оформлено как inc-файл. Все желающие динамическую библиотеку в каком-нибудь формате - действуйте.
  • Мне консоль понравилась.

    А ввод в ней будет ?
  • А как же!
  • Добавлена функция con_printf в стиле Сишной printf. Floating-point не поддерживается, возвращаемого значения нет, дополнительный первый аргумент, в остальном всё как в ANSI C.
    Ушёл к умным, знающим и культурным людям.
  • Обновление, исправлена пара ошибок в con_printf. Ссылка та же. Теперь библиотека оформлена как DLL, прилагаются примеры использования testcon.asm и testcon2.asm (собственно, они со времени дистрибутива не изменились). Загрузка DLL в testcon.asm несколько эффективнее, но в testcon2.asm несколько нагляднее.
  • Убрал первый аргумент у функций вывода, поскольку в большинстве случаев управление цветами и вывод специальных символов как обычных не нужно. Программы, которым это всё-таки нужно, могут либо использовать con_set_flags/con_get_flags, либо выводить Esc-последовательности.
    con_printf теперь возвращает количество напечатанных символов, в случае передачи NULL при спецификаторе %s выводится строка (null), теперь от ANSI C отличие разве что в отсутствии поддержки вещественных чисел.
    Ушёл к умным, знающим и культурным людям.
  • Предлагаю на рассмотрение 2 варианта консольных приложений.
    1) windows вариант
    2) nix вариант
    в первом ваианте все происходит как. В пе-заголовке есть флаг который указывает что это консольноеприложение. Собсно загрузчик создает консольное окошко и весь вывод приложение направляет туда и ввод получает оттуда.
    во втором нет разделения консольный ты или нет. Зато есть понятия потоки(впринципе как и в 1 варианте). Просто какой-нить шел(баш и подобные) пускают приложения подключаясь к их потокам(ввода, вывода и stderr).
    Не спорю, возможно я все описал в грубой форме.
    По сему есть такое предложение(по типу 2), правда которое затрагивает ядро. Нужно реализовать систему потоков. То есть с помощью какой-нибудь функции реализуется запуск приложения с подключением к потокам. допустим получаем какой-нить дескриптор(ы) и работаем с ним(и), то есть посылаем/получаем байты. В тоже время любое приложение имеет доступ к другим функциям отправить/прочитать символ в/из потока.
    И теперь пишется какой-нить шелл. Допустим он пускает приложение и подключается к потокам. Все что получил шелл - идет в stdin запущеного приложения, все что пришло из stdout приложения - показываем. Сразу получаем преимущество. Пишем в шелле prog >1.txt, пускается приложение prog....его stdin заполняется из шелла, а весь stdout шелл не выводит а направляет в файл...
    Жду пинков и одобрений:)
  • [offtop] Маладец, хорошо "разобрался" как работают консольные преложения [/offtop]
  • :) первый пинок есть

    Еще в исходниках ядра не копался, поэтому не знаю реально ли такое реализовать.
    Что-то вроде: под каждое приложение запущеное этим волшебным способом выделяется 2 буфера stdin и stdout. Пускателю отдается дескриптор потоков или же просто по ПИДу обращаться.
    Это 1 дополнительная функция....я так представляю ничего сверхестественного.
    + еще 4 функции:
    для пускателя:
    - (1)отдать символ в stdin процесса
    - (2)взять символ из stdout процеса
    (наверное лучше дескрипторы, в плане защиты, чтоб чужие процессы не могли подключаться к потокам чужих приложений)
    для приложения:
    - (3)отдать символ в stdout (а на основе ее составить putc,puts,printf,print и т.д.)
    - (4)получить символ из stdin (а тут scanf,gets,getc...)

    Сразу вижу проблемы:
    - как быть с приложениями запущеными обычным способом(то есть без потоков), а именно поведение функций 3 и 4

    думал потоки через IPC делать - ну уж больно как-то через жопу
  • Who is online

    Users browsing this forum: No registered users and 43 guests