• Application
• debug
• text
• window

The way ShareMemory works right now is the sender knows the recipient's shared address and by sending the message to the service registry, the appropriate recipient page tables are modified whether the recipient accepts/knows or not. Change it so the owner of the memory to be shared initiates a share memory request with its owned memory address and the task id of the recipient, the service registry then forwards the request to the recipient on the owner's behalf and if the recipient accepts then only is the memory shared.

Rewrite memset to use enhanced rep stosb similar to memcpy.

Windows/libWindows was a placeholder. Yes this is kind of a waste of an issue, but it serves as searchable part of history to mark when the name change happened.

The current heap is slow, and doesn't really support freeing memory. Add fixed-size bins with free lists for each size to optimize finding free chunks.

Need to implement an ELF loader so that all the services can be built and loaded separately which will clean up a number of issues.

Attempting to build the toolchain by running make toolchain results in the following error for me:

make[5]: *** No rule to make target 'eelf_x86_64_saturn.o', needed by 'ld-new'.

Any suggestions to allow it to compile?

Its mainly the cleanup code that needs to be revisited, including accounting for the fact that the user stack is no longer new()'d on the heap.

This system will collect events sent by other systems/applications via messages.

A Label is a UI Element that displays a block of text. The text can be changed at runtime with code, but isn't user interactive like a textbox is.

• extract experimental elf code
• separate task creation from scheduling

ReadStream takes a memory address to write to, as well as a max length. Then instead of fread issuing (dataSize / 512) separate ReadRequests, it would issue just one ReadStreamRequest. The VFS would wait until all the requested data is available, then memcpy the whole shebang into the buffer at once, and issue one response.

Apollo UI Layouts will be stored as text files formatted as s-expressions. Once the text has been loaded into a string, parse the string to get the s-expressions, and then walk through the s-expression tree to create all known containers and other ui elements.

TextRenderer::layoutText uses face->glyph->{advance, metrics}.x whether or not the glyph is cached, but if the glyph is cached then face->glyph won't be the same as the cached glyph.

Right now any read past the first 12KB of a file requires reading a sector from an indirect block, waiting on an interrupt for the data, then issuing a read sector for the actual desired data.

Applications should use the same while(peekMessage...) {} and time accumulator based loop to render itself at a fixed rate.

Now that the 64-bit rewrite is happening, Saturn needs a 32-bit loader to replace the old pre_kernel hacks. It will handle setting up the free physical page stacks and other low-level things, and ensure that the kernel starts in a stable and well-known state, or doesn't start at all and lets the user know why.

Calling Scheduler::createUserTask triple faults at kernelVMM->activate(), because the stack has grown far enough that the current page isn't mapped.

The layout should be like:

"Menu"

[command line]

{
commands
}

Commands are organized into different categories and have a unique shortcut, so for example one category could be Container [ (S)plit, (C)hange split]. Initially the text area would show:

C -> Container

pressing C would change the area to show

S -> Split C -> Change split

Dsky will need a List to display labels of user text input and the resulting output. List items don't need to be uniform in size, and will be culled to only render the items visible.

A number of new features in the works - a shell language, UI layout format ala XAML, perhaps logging and configuration files - will be based off of S-Expressions. So it is imperative that a functional parsing framework exists, and putting it in libSaturn is an easy way to make it accessible to all services/applications.

Something that shows a list of running applications that highlights the application with input focus.

QEMU has a handy feature where it can redirect everything written to COM1 to a logfile, so make use of that.