Smart default - if we don' know what to do with an argument, we just convert it to a Time and then back again. This won't let us do anything about differences between Bahá'í dates, yet.

Manually manipulating calendar dates, rather than Time objects, to convert back to Gregorian, so we avoid day-light savings problems.

Converting back to Gregorian - works, except loses an hour to daylight savings sometimes.

tiny convenience for getting bools out of syscall results safely

In the end, it worked out to be just as efficient to index on the string alone. Even if I use an integer-based hash table, it's still another hash table! And the only way to not use one is to use a plain array.. which then has its problems in the start. I could re-use indices, I suppose, but do I want to? Here's a new LinkedList, STL-style, hope it works. I really should test these. CppUnitLite or CxxTest?

Oh right, destructors!

class methods are now not CamelCase, but mixedCase

going all out and writing a HolyArray. I probably should unit test this.

Don't use bochs anymore.

use __SIZE_TYPE__ = size_t instead of just a u32 for operator new

well done! forgot to actually initialise the hash table

adding strings and name registration.. currently dying.

removing protection on a whole bunch of things, and reworking the way we do that

it appears I don't have to do the first In now

Oh, hello! Returning from ISRs, so a syscall can cause an immediate task switch. It actually returns, though, so the next time the task runs, it's not mid-syscall, but actually at the next instruction. Thus, we handle the cleanup of the irqWaiting irqListenHits, etc. states in the task handler (AssignInternalTask or whatever...). Note that the ISR and IRQ (non-timer) handlers run on the kernel stack, not at 0xE000/0000, as that would be impossible. Yay!

I've decided that ISRs really shouldn't be allowed to do a task switch at the same time...

baby steps at using different rings than just 0 and 3

iomap works!

Hello, IOPL and TSS iomaps!

refactoring information out

being careful about this.

clean up µkernel, and fix the debug output by updating r (and using it too; why not?)

clean up µkernel, and fix the debug output by updating r (and using it too; why not?)

Booyeah! I had to correct for the new TSS.ESP0 position (i.e. needed it to go back to the end of the stack) - without correcting, it'd keep going forward (!) because we keep setting it to the start of the new position, not the end.

great! it multitasks one usermode (initial) task fine!

we need to bootstrap tasks fairly differently

trying to work out this kernel mode stuff.. I'm leaving stuff on the stack!

three processes; changed the test case so it actually uses the stack more

that works too!

tasking two user processes works! let's try to get one kernel and one user