Board.KolibriOS.org

k@sTIg@r
В системе есть отладочная доска (Board) куда любое приложение может выводить сообщение, по сути общий stdout.
>- как быть с приложениями запущеными обычным способом(то есть без потоков), а именно поведение функций 3 и 4

Обычно приложение само запрашивает дескрипторы стандартных потоков у ядра, этим занимается стартап-код.

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

Ну отладочная доска на крайний случай для stderr подойдет. Мне вообще странно такое недопонимание потоков (stdin, stdout, stderr) и консоли в системе. Все эти особенности нужно было учитывать еще при проектировании системы, по сути системы именно с таких интерфейсов и начинаются. Конечно, кому то он не нужен, и ктото может сразу перейти к работе с гр. интерфейсом, но вот объясните, как вы будите организовывать сборку и тестирование приложения когда требуется:

1. Компиляция.
2. Линковка.
3. Конвертирование формата.
4. Создание образа.
5. Перенос полученного кода на образ.
6. Запуск эмулятора с монтированным образом.

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

• ps -A | grep nginx
• ls | more

..по вашему, мне тоже не понятно. А GUI приложения для такой мизерной задачи врядли кто-нибудь будет писать либо корректированить (а ведь исправлений без новых ошибок не бывает).
Я этот вопрос тоже планирую решать, но видимо по своему.

..bw

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

Ку.

p.s. Да и не все согласны. Я решил что не стоит вывешивать список тех кто поддерживает идею и тех кто нет, а просто высказал свое мнение в адрес тех кто отрицательно смотрит на совершение подобной работы.

..bw

bw

>Все эти особенности нужно было учитывать еще при проектировании системы

Тот кто придумал систему давно на неё забил и делает другую. А проектирования и в помине не было.
И это не наша идеология. Если можешь написать потоки для ядра - сделай это. Это идеология.

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

Согласен, но что теперь поделаешь... это тяжелое наследие Menuet. У меня по этому поводу был один вопрос к разработчикам Kolibri, но я его не стал задавать раньше и теперь задавать не буду.

Обещанный ввод. Функции con_getch (аналог _getch()) и con_gets (аналог fgets(...,stdin)). Ссылка та же: http://diamondz.land.ru/console.7z

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

Хочу попробовать реализовать одну идейку по поддержке консоли. Если кто видит в этом что-то нереализуемое или вовсе неправильное, пишите.
Консольный сервис - функция ядра с несколькими подфункциями создает и управляет буферами stdin/out, которых должно быть несколько (8 например), но для начала 1
На каждый stdin/out могут зарегистрироваться две программы с разными правами. Одна регистрируется как терминал, другая - как консольное приложение.
Терминал имет право получать информацию об активности в stdin/out, читать из stdout и писать в stdin ... . (Механизм ещё полностью не продуман, могут быть логические ошибки).
Консольное приложение получает при запуске параметр с номером stdin/out в котором ее ожидают увидеть. Эти sdtin/out оно и должно открыть соответствующей подфункцией.
(Stdin - только чтение, stdout - только запись. Ну как обычно.)
Функция чтения строки из stdin может работать подобно системной функции ожидания события. Приложения просто "висит" пока в stdin не появится строка (если, конечно, на момент вызова функции чтения stdin был пуст).

Igor

Консольное приложение получает при запуске параметр с номером stdin/out в котором ее ожидают увидеть. Эти sdtin/out оно и должно открыть соответствующей подфункцией

А если оно не захочет открывать именно этот sdtin/out или откроет по ошибке другой. Пусть лучше наследует родительские. Для этого можно задействовать биты флагов ф70.7

Я сейчас занимаюсь портированием линуховой VFS. Оно за собой тянет и stdin/stdout (не знаю нужен ли stderr). А также pipeFS.
Твоя сисетма, как-то сложновато выглядит, если честно. В линуксе все просто и эффективно.

Если хочешь, присоединяйся ко мне. Но придется подучить ядро линукса (исходники открыты + есть 2 неплохие книжки). Также готов поделится знаниями в свободное для меня время!

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

О "настоящих" никсовых stdin/stdout речь не шла.

Что касается VFS. Я понимаю её полезность. Но внедрение
такого механизма предусматривает перестройку
половины ядра. Это не только API по работе с файлами.
Сколько времени займет реализация поддержки файлов устройств
и заточка под них соответствующих функций ядра?
Колибри изначально не задумывалась как unix подобная ос.
И не стоит всё радикально менять.

P.S: А может быть стоит... Надо подумать над твоим предложением.

k@sTIg@r
А можно подробнее про VFS, что там будет и как должно работать ?

Так а никто не собирается превращать колибри в юникс-подобную ось.
Наличие linux-like VFS не делает ее unix-like OS. Так же как и оконный интерфейс не делает ее windows-like OS (ну или macOS-like, кому как нравится).

Да, работы немерянно, тут я соглашусь. Но я думаю оно того стоит.
Да функции ядра тоже изменятся. Сразу нафиг полетят текущие ф-ции работы с файлами (хотя для них можно написать обертки, тока это не эффективно). Появится понятие дескриптора файла (добавится открытие/закрытие файла), писать/читать можно будет только открытые файлы.
Нужно будет поменять ф-ции запуска/остановки приложения. Ф-ция exec уйдет из файловой системы... И т.д. и т.д.
Поддержка файловых у-в? У нас их не много поддерживается Зато абстракция позволит просто добавлять поддержку новых у-в, а так же новых файловых систем. Причем прозрачно для ф-ций ядра. А не так как щас.
В итоге радикально ничего и не поменяется(для пользовательского уровня). Только работа с файловой системой.

Единственное с чем я щас борюсь - это структура VFS. Мне близка корневая структура, как в unix-like осях. Она очень эффективна (кто не юзал тот не поймет). Дисковая структура (как в windows) для меня не эффективна. А в колибри она такова, только диски называются не буквами латинского алфавита, а физическим расположением.
Уже с ребятами был спор по этому поводу. Корневую никто не хочет принимать Но до этого еще далеко, че-нить придумаю.

<k@sTIg@r> Мне близка корневая структура, как в unix-like осях.

Мне тоже близка. Но привыкших к Windows пользователей она почему-то сильно напрягает.

<k@sTIg@r> Если хочешь, присоединяйся ко мне. Но придется подучить ядро линукса...

На сколько я понимаю, BSD тоже пойдет. В плане VFS больших отличий от Linux-а быть
не должно. Просто у меня на компе FreeBSD, так сказать всегда под руками.
Короче, могу помочь, если смогу. Заодно вопрос с консолью как-нибудь решим.