We should be able to run multiple graphical applications at the same time rather than just one fullscreen application.

A major performance issue of the GUI is that frames are sent over a socket and then get buffered. Then the GUI needs to process several frames that overwrite the same pixels until it gets to the newest frame.

Once #16 is resolved we will be able to share memory between the GUI and the application so that there are no outdated frames being processed.

Rationale: everybody loves screenshots

This would allow running Dennix at higher resolutions.

Every time I move the mouse or type something in the terminal (while running the GUI), there is ~1 second delay between me moving the mouse, and the cursor actually moving on the screen.
The issue is happening to me in QEMU while using multiple computers for virtualization (Linux x64 host, and macOS m1 host with emulated x86_64 hardware). Not sure if it happens with any other hypervisors.

Sockets would be useful for #20 to allow GUI processes to communicate.

This would make the shell more convenient to use.

Hi man!
you have made great strides, congratulations.

As said in the title, It would be nice if the CI provides the built ISO of DennixOS.

It isn't difficult to upload the image at the end, as I do in my CI

Keep going!
I want to play with your OS

Implement redirection and pipes in the shell.

Repl.it is able to run QEMU, which have been used to help other users make their own OSes. But is there anyway this OS could be ported to repl? or perhaps make a guide to do so?

I think it should work, but it would be really great if it could be done as it means many others can see and use the OS without needing to do anything locally.

This was requested in a comment to bug #19.

Nano depends on ncurses, so porting that might be some work but it should be doable.

A process that changes the display mode should become the owner of the display and when that process dies the display should reset itself.

The current way of resetting the display mode in a signal handler is not very robust.

The following parts of Dennix need to be made aware of UTF-8:

• The keyboard
• The terminal buffer (for backspace)
• The editor

Features needed in the shell that are used by configure scripts:

• : builtin
• redirection needs to work with all commands
• case statements
• command substitution
• set builtin
• eval builtin
• exec builtin
• shell functions
• here-documents

Also some utilities like sed and grep are needed.

We should allow multiple threads per process.

Some code in the kernel is not thread-safe yet, so this will need to be fixed before threads are implemented.

Polese, consider spending some time writing documentation.
Documentation should cover: initialization and state of registers after boot.
How virtual memory is managed and others important algorithms.

Currently when the kernel panics before the log has been initialized, a triple fault will occur because the panic tries to write a message on the screen.

The shell should be able to run commands from files and from sh -c.

Dennix should support x86_64.

This will be needed for running terminal applications inside a GUI (#20) once we have one.

This is needed to make the ATA driver (#19) useful.

Hi, there are any plans for support the features in the title? They would improve a lot the capabilities of the system.

Keep it up, very good project

This will be needed to find out whether BGA (#10) is supported.

This is problematic because gcc assumes that new can never return NULL. Also there is the problem that constructors cannot fail on allocation failure.

Port it.

Currently the kernel does halt whenever a CPU exception occurs. It should instead kill the current process if the exception happened in userspace. Maybe implement signals and then send the appropriate signal for the execption.

Disk access is currently slow. There are a few changes that could improve performance significantly.

• Disk caching: We should cache blocks that have been accessed on disk in memory. This will improve read access to blocks that have been accessed before. Since the ext2 driver is reading important data structures repeatedly, this will improve both read and write performance of ext2 filesystems.
• Do not flush the ATA device cache on every write. Instead flush the ATA cache when unmounting a filesystem and provide a utility to manually flush caches. This will improve write performance.
• Use DMA transfers instead of PIO. This should also improve performance.

ACPI is needed for many things including shutdown and proper hardware detection.
Also my new laptop is missing some legacy devices that Dennix is using and fixing that will require ACPI.
Unfortunately fully implementing it (including AML) will be rather complicated.

Even today the floppies are still being used, for example - as virtual floppies inside the coreboot open source BIOS. Just imagine: your wonderful OS could be a part of someone's BIOS build! (for coreboot supported motherboard, maybe you have or could get one - see https://www.coreboot.org/Supported_Motherboards )

If you already have a coreboot-supported motherboard, or a real chance to get one, - wouldn't it be cool to be able to launch your own OS straight from the BIOS chip? ;) With one simple command its possible to add any floppy to coreboot BIOS build - and then you see it as a boot entry! Multiple floppies could be added this way (as long as you have enough space left inside the BIOS flash chip, luckily LZMA compression could be used for the stored floppies to reduce their occupied size)

The current shell implementation is very primitive and does not even support quoting.

Syscalls currently don't check whether pointers they were given are accessible from userspace. This is a security issue since a userspace process might overwrite kernel code and other things it should not access.

This allows some features like mouse integration.

How to import an external file into the system?
I want to copy some projects into the system Dennix running on it and run them.
how to do it?

Applications should have the ability to draw to the screen directly. Some API needs to be developed for this.

This would give us the ability read and write files on permanent storage.