Smaller C compiler
Posted: Sat Jul 30, 2016 10:49 am
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.
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.
