Posted: Fri Sep 15, 2006 11:16 am
Eto budet konsol' kak v quake? T.e., nazal til'du - vyvalilas' konsol'? Bylo by interesno.
Page 2 of 4
Posted: Fri Sep 15, 2006 3:15 pm
неее... сначала надо OpenGL добавить
Posted: Fri Sep 15, 2006 4:19 pm
Речь идёт о библиотеке, которую могут использовать все программы, которые этого хотят. Типа подключаем её и становятся доступными функции типа (любителям Си и *nix) printf/scanf или (любителям Windows) ReadConsole/WriteConsole и некоторые более продвинутые. Плюс стандартный интерфейс окна консоли.
По поводу 3, наверное, стоит уточнить: вопрос был про изменение размера окна консоли, которое нельзя сделать в винде (разве только через изменение параметров через меню), но есть в иксах под Linux.
Ну и стандартное приложение CMD, которое этот интерфейс будет использовать. При желании уже сейчас можно "навесить" на тильду вызов CMD (немного изменив пример @numcalc).
По поводу 3, наверное, стоит уточнить: вопрос был про изменение размера окна консоли, которое нельзя сделать в винде (разве только через изменение параметров через меню), но есть в иксах под Linux.
Ну и стандартное приложение CMD, которое этот интерфейс будет использовать. При желании уже сейчас можно "навесить" на тильду вызов CMD (немного изменив пример @numcalc).
Posted: Mon Sep 18, 2006 5:37 pm
Консоль нужна.
Это позволит писать платформенно-независимую программу на языке высокого уровня(к примеру вычислительную программу).
Вывод текста нужно сделать через 7-ю функцию.Это позволит менять размер шрифта.Если человек плохо видит,то он сможет увелить его(шрифт).
Это позволит писать платформенно-независимую программу на языке высокого уровня(к примеру вычислительную программу).
Вывод текста нужно сделать через 7-ю функцию.Это позволит менять размер шрифта.Если человек плохо видит,то он сможет увелить его(шрифт).
Posted: Mon Sep 18, 2006 6:15 pm
Кросплатферменные проги можно писать не только для консоли... Единственное что сейчас это самый простой вариант
Posted: Fri Sep 22, 2006 3:58 pm
Можно конечно и SDL и OpenGL(это вообще тема отдельного разговора) использовать,но нам до них ещё долековато.Пока компилятор не портируем в Колибри,пока libc не напишем(её платформенно зависящую часть) - не видать нам SDL или OpenGL(хотя OpenGL можно и на чистом ассемблере писать).
P.S.
Есть ещё куча других платформенно независимых библиотек,но я сказал про самые распрострвненные.
P.S.
Есть ещё куча других платформенно независимых библиотек,но я сказал про самые распрострвненные.
Posted: Tue Oct 03, 2006 5:58 pm
Предварительная версия:
http://diamondz.land.ru/console.7z
Оформлено как inc-файл. Все желающие динамическую библиотеку в каком-нибудь формате - действуйте.
http://diamondz.land.ru/console.7z
Оформлено как inc-файл. Все желающие динамическую библиотеку в каком-нибудь формате - действуйте.
Posted: Wed Oct 04, 2006 3:45 pm
Мне консоль понравилась.
А ввод в ней будет ?
А ввод в ней будет ?
Posted: Wed Oct 04, 2006 5:38 pm
А как же!
Posted: Mon Oct 09, 2006 3:59 pm
Добавлена функция con_printf в стиле Сишной printf. Floating-point не поддерживается, возвращаемого значения нет, дополнительный первый аргумент, в остальном всё как в ANSI C.
Posted: Wed Nov 22, 2006 6:51 pm
Обновление, исправлена пара ошибок в con_printf. Ссылка та же. Теперь библиотека оформлена как DLL, прилагаются примеры использования testcon.asm и testcon2.asm (собственно, они со времени дистрибутива не изменились). Загрузка DLL в testcon.asm несколько эффективнее, но в testcon2.asm несколько нагляднее.
Posted: Mon Feb 19, 2007 5:47 pm
Убрал первый аргумент у функций вывода, поскольку в большинстве случаев управление цветами и вывод специальных символов как обычных не нужно. Программы, которым это всё-таки нужно, могут либо использовать con_set_flags/con_get_flags, либо выводить Esc-последовательности.
con_printf теперь возвращает количество напечатанных символов, в случае передачи NULL при спецификаторе %s выводится строка (null), теперь от ANSI C отличие разве что в отсутствии поддержки вещественных чисел.
con_printf теперь возвращает количество напечатанных символов, в случае передачи NULL при спецификаторе %s выводится строка (null), теперь от ANSI C отличие разве что в отсутствии поддержки вещественных чисел.
Posted: Wed Feb 21, 2007 3:25 pm
Предлагаю на рассмотрение 2 варианта консольных приложений.
1) windows вариант
2) nix вариант
в первом ваианте все происходит как. В пе-заголовке есть флаг который указывает что это консольноеприложение. Собсно загрузчик создает консольное окошко и весь вывод приложение направляет туда и ввод получает оттуда.
во втором нет разделения консольный ты или нет. Зато есть понятия потоки(впринципе как и в 1 варианте). Просто какой-нить шел(баш и подобные) пускают приложения подключаясь к их потокам(ввода, вывода и stderr).
Не спорю, возможно я все описал в грубой форме.
По сему есть такое предложение(по типу 2), правда которое затрагивает ядро. Нужно реализовать систему потоков. То есть с помощью какой-нибудь функции реализуется запуск приложения с подключением к потокам. допустим получаем какой-нить дескриптор(ы) и работаем с ним(и), то есть посылаем/получаем байты. В тоже время любое приложение имеет доступ к другим функциям отправить/прочитать символ в/из потока.
И теперь пишется какой-нить шелл. Допустим он пускает приложение и подключается к потокам. Все что получил шелл - идет в stdin запущеного приложения, все что пришло из stdout приложения - показываем. Сразу получаем преимущество. Пишем в шелле prog >1.txt, пускается приложение prog....его stdin заполняется из шелла, а весь stdout шелл не выводит а направляет в файл...
Жду пинков и одобрений:)
1) windows вариант
2) nix вариант
в первом ваианте все происходит как. В пе-заголовке есть флаг который указывает что это консольноеприложение. Собсно загрузчик создает консольное окошко и весь вывод приложение направляет туда и ввод получает оттуда.
во втором нет разделения консольный ты или нет. Зато есть понятия потоки(впринципе как и в 1 варианте). Просто какой-нить шел(баш и подобные) пускают приложения подключаясь к их потокам(ввода, вывода и stderr).
Не спорю, возможно я все описал в грубой форме.
По сему есть такое предложение(по типу 2), правда которое затрагивает ядро. Нужно реализовать систему потоков. То есть с помощью какой-нибудь функции реализуется запуск приложения с подключением к потокам. допустим получаем какой-нить дескриптор(ы) и работаем с ним(и), то есть посылаем/получаем байты. В тоже время любое приложение имеет доступ к другим функциям отправить/прочитать символ в/из потока.
И теперь пишется какой-нить шелл. Допустим он пускает приложение и подключается к потокам. Все что получил шелл - идет в stdin запущеного приложения, все что пришло из stdout приложения - показываем. Сразу получаем преимущество. Пишем в шелле prog >1.txt, пускается приложение prog....его stdin заполняется из шелла, а весь stdout шелл не выводит а направляет в файл...
Жду пинков и одобрений:)
Posted: Wed Feb 21, 2007 4:00 pm
[offtop] Маладец, хорошо "разобрался" как работают консольные преложения [/offtop]
Posted: Wed Feb 21, 2007 5:30 pm
первый пинок естьЕще в исходниках ядра не копался, поэтому не знаю реально ли такое реализовать.
Что-то вроде: под каждое приложение запущеное этим волшебным способом выделяется 2 буфера stdin и stdout. Пускателю отдается дескриптор потоков или же просто по ПИДу обращаться.
Это 1 дополнительная функция....я так представляю ничего сверхестественного.
+ еще 4 функции:
для пускателя:
- (1)отдать символ в stdin процесса
- (2)взять символ из stdout процеса
(наверное лучше дескрипторы, в плане защиты, чтоб чужие процессы не могли подключаться к потокам чужих приложений)
для приложения:
- (3)отдать символ в stdout (а на основе ее составить putc,puts,printf,print и т.д.)
- (4)получить символ из stdin (а тут scanf,gets,getc...)
Сразу вижу проблемы:
- как быть с приложениями запущеными обычным способом(то есть без потоков), а именно поведение функций 3 и 4
думал потоки через IPC делать - ну уж больно как-то через жопу