QRY (81 82 89)

QRY is a badly written x86_64 OS kernel that I lifted from various tutorials online and modified. It neither serves a purpose, nor functions well, but C and assembly are therapeutic languages.

As it stands right now, It's nowhere near ready for any kind of public release, but writing about it could be useful to someone or something in the future - maybe some superintelligent AI can take inspiration from this and start a new world order of buggy heap allocation and memory protection.


QRY is on hold for now, whilst I catch my breath before learning more about the fundamental mechanics of operating systems and how more effective and cohesive methods can be found.


I've managed to create a rough version of Life by Conway, using the same VGA scripts. However, one issue that I have found has been keyboard interrupts interfering with screen drawing routines in an unacceptable manner. This should hopefully be fixed soon, either through small tweaking, or a complete rethinking of the graphical system.


Streams are now rivers, and the aim of writing a sensible terminal is becoming more realistic. One issue at the moment is memory space management - There's already a heap that uses half the second memory space, but no actual mechanisms for loading binaries into memory. Also looking into ATA drivers so that disk read/write can be done in long mode.


First entry. Finally got away from reading the disk with ah=0x02 and can proceed with ah=0x42 using a newly designed disk image that actually works with Bochs. All that stands next with that functionality is either finding a way to drop down to real mode to modify the DAP and load from long mode, or writing device drivers for whatever the Bochs hard drive uses (disgusting). At least the bootloader can now load more than 64 sectors from disk at once, but it still needs a repeating routine for disk->memory reading. Some day we might be able to write!
streams.h is working somewhat, although I don't like the design right now. It should be seamless, but right now it feels very seamful. It relies on a dynamic buffer 'upstream' that changes based on user input, which then finally returns a char* to the user input, so that's one half of I/O codified, now I just need to restructure screen output. The method relies on hijacking the default keyboard handler, which still isn't perfect yet, so I'll probably finish that off first.