Greetings, everyone!
Recently I've been contemplating the idea of porting my Smaller C compiler to KolibriOS to run it natively in the OS. I've played with the system a little and I've also taken a look at its system calls and other things. The system looks OK (for something this minimalistic), but the system calls and libraries around them appear somewhat limited.
The major problem that I'm seeing is the lack of a traditional console/shell, in which one could run non-GUI apps that would use 3 (or at least 2) special file handles/descriptors for stdin/stdout(/stderr). Effectively, the console/shell should provide these special file handles/descriptors and share its window with the programs started in it. For example, my compiler driver (smlrcc) executes 4-5 other programs when compiling a C file: preprocessor (smlrpp), core compiler (smlrc), assembler (NASM or n2f (n2f converts code from NASM syntax to FASM syntax and executes FASM)), linker (smlrl). If any of these 4-5 stages completes with an error, the error message should remain in the window and the window must not close by itself or the user won't see it. Separate windows for each stage is ugly and when an error occurs, they must be manually closed by the user.
There's quite a bit of non-GUI software (not just my compiler) that could be ported to the OS or further developed within the OS if only the OS somehow provided the console functionality that can be found in DOS, Windows, Linux, etc etc.
Anyway, here's my question. OK, two questions. What would it take to implement such a shell/console, IOW, how would you do it? And... Would you do it? I might contribute to it (I'd definitely test it!), but I first need to have a clear idea of how to do it, e.g. what can be leveraged, what needs to be rewritten, what needs to be implemented from scratch in the kernel or wherever. On the compiler side not much needs to be done. The compiler comes with its own standard(ish) C library that communicates with DOS/Windows/Linux using system calls and it shouldn't be much of a problem to adapt it when there's a sufficiently functional console/shell that works like those of other common OSes. Generating KolibriOS executables in addition to all other formats should be easy (I believe, we can do it today without even modifying the linker, just use the flat format and link the file that contains the executable header first, before other object files or libraries).
P.S. we can communicate either in English or in Russian. I chose to make the initial post in English, so it can be readily understood by those who don't speak Russian.
Smaller C compiler
Сейчас в наличии есть:
gcc 4.8.2, кросс-компилятор, полная libc, stdc++
tinyc, кросс компилятор и родной компилятор для КОС, сокращенная libc
c--, кросс компилятор и родной компилятор для КОС
Еще в каком то виде SCC (simple c compiler), я не проверял
Не уверен, что нужен еще один компилятор С
А вот удаленный отладчик для gcc не помешал бы
В системе есть три способа межпроцессного взаимодействия - IPC, shared memory, clipboard.
gcc 4.8.2, кросс-компилятор, полная libc, stdc++
tinyc, кросс компилятор и родной компилятор для КОС, сокращенная libc
c--, кросс компилятор и родной компилятор для КОС
Еще в каком то виде SCC (simple c compiler), я не проверял
Не уверен, что нужен еще один компилятор С
А вот удаленный отладчик для gcc не помешал бы
В системе есть три способа межпроцессного взаимодействия - IPC, shared memory, clipboard.
See related thread: viewtopic.php?f=2&t=2197
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
Нашёл в отдельном архиве, думал нет вовсе, так как на wiki не смог найти концов.Siemargl wrote: tinyc, кросс компилятор и родной компилятор для КОС, сокращенная libc
c--, кросс компилятор и родной компилятор для КОС
OK.Siemargl wrote: Не уверен, что нужен еще один компилятор С
Тут я пас.Siemargl wrote: А вот удаленный отладчик для gcc не помешал бы
Я догадался, что по крайней мере два из них есть. Дьявол в деталях, как говорится. Потому и спросил, как бы вы это сделали. Подразумевается чуть больший уровень деталей, чем в одну строку "у нас есть X, Y, Z", хотя до псевдокода доходить наверное не стоит.Siemargl wrote: В системе есть три способа межпроцессного взаимодействия - IPC, shared memory, clipboard.
Я бы предложил использовать именованную область памяти и у дочерних процессов вывод перенаправлять туда.alexfru wrote:Я догадался, что по крайней мере два из них есть. Дьявол в деталях, как говорится. Потому и спросил, как бы вы это сделали. Подразумевается чуть больший уровень деталей, чем в одну строку "у нас есть X, Y, Z", хотя до псевдокода доходить наверное не стоит.Siemargl wrote: В системе есть три способа межпроцессного взаимодействия - IPC, shared memory, clipboard.
Набрасывал пример тут viewtopic.php?f=40&t=3289#p65606
Посмотри еще эту тему про shell viewtopic.php?f=48&t=1111
Who is online
Users browsing this forum: No registered users and 3 guests