Which would you....

[Solar]

Data corruption in the brain during transit from laptop "man signal" output to desktop browser window input.

I apologize.

[bewing]

It's finally time to make my OS a self-compiling system.
I used tcc ...
Any suggestions?

You're about a month or two ahead of me, I think.

OK, it looks like my time estimate was bad. It seems you are 10 days ahead of me. My first deal is that while I am still completely in Ring0 mode, all my executables need to be position independent code. So I think I have figured out that the first thing I need to do is to rewrite TCC to compile itself into PIC. Then the same for NASM. Then, once I've built the most simplistic linker in the world, I can port it all onto my testbench machine, running my own OS -- and I'll be self-hosting.

@OrOS -- have you made any decisions/progress in this sort of direction in the last 10 days?


@Combuster -- When I said I'd have userapps "catch" hardware exceptions, I didn't mean it literally. Yes, the kernel will do the literal catching -- then call the userapp's error termination routine (if it exists) for the sole purpose of making sure to preserve as much of the user's work as possible before death.

I personally don't like the concept of taking a standard and then adding non-standard crap to it. Sort of like the concept of "if it doesn't do the same thing as the C library function -- then don't give it the same name!" It's one of the things that's always irritated me about M$ stuff. Redefining all the commands to create non-POSIX C, and non-JAVA m$-java, etc.

Plus, I don't like the basic way that signal() works, with catching and returning to the app as the "normal" outcome. I will name my routine something other than signal(), and its guaranteed outcome will be the death of the app, on return from the error handler.