Snapshots and VMachine report ...

A first attemp of making Clicker running on virtual hardware.

From it's very early versions, Clicker has always ran on real hardware. It makes more sense because noone would buy an Operating System if it don't even run on an existing machine.
However - and i don't know if it's due to a buggy kernel of mine or a buggy vmachine of Bochs - the first attemp of making Clicker run in a sandbox was a kind of Code War ...

Lots of weird things occured and i can't completely explain them. I'll try to talk with Bochs maintainer to see where it could come from. By the by, at least, i've made nice snapshots of the situation.

Clicker kernel booting
Here comes a snapshot of Clicker's early stage of boot-up.
At this point, the system has entering the kInit() function and has performed the critical basic initialisation (turning into pmode, initializing interrupt management, setting up display structures)

It's gently waiting you to press space to continue to boot.
This is a snapshot of Clicker's debug console.
When the system is running, it dumps loooooot of messages on the so-called "green console" so that you can follow "step by step" progression of the system even if you don't have a powerful virtual machine.

Of course, this slows down the execution. You can usually select the messages you want to appear on this console, but only when the "debug" module has been loaded - and on my 1Ghz machine, it takes bochs about 5 minutes to reach that point (even more)!!

Fortunately, you can compile the kernel without __DEBUG__ to make it faster.

Note that on a 300MHz "real" system, reaching the debug screen don't even take a second !-)
Clicker debug console
a nasty crash
Sometimes, when you are really too tired to code, you can see clicker stopping itself and showing three columns of hex number: a stack dump!
Don't trust it even if it says "Termination Successful": it just means you're back to ms-dos and that you should be able to run analyzis tools.
One of them - - allow you to look at the system log.
Hereby is a snapshot of that log after a very werdy crash in the BOCHS (never seen something that weird on real hardware).
Log usually stores warning messages. Sometimes, a thread crash and you'll have a nice summary of its state (including fault report, backtrace, registers content, etc.)

Here, there have been so many of such problems (and curiously, without a valid thread id !?) that you don't see anything else on the log.

Bochs session #2

While working on the linux development kit for Clicker, i've had to do more attemps with Bochs. It now works quite fine as long as you give enough RAM in your description. Also, i changed a few compile options so that keys are useable (no interference with ALT+F4 :) Here are a few shots of that sessions, mainly focussed on the debug panels.
KDS inspector
KDS inspector
debug controller
Debug controller
KDS inspector
paging debugger panel, showing the content of a page frame selected by the user
KDS inspector
paging debugger panel, comparing the content of two page frames selected by the user (well, the debugger shows and the user compares -- sounds fair, no ?)
KDS inspector
tables debugger panel, displaying the GDT content (IDT and LDTs are also available).
KDS inspector
tables debugger panel, highlighting a specific thread. By pressing [ENTER] when a thread is highlighted, you'll get a display of its variable on the right panel and select it for debug (green console) output.