dennis95 / dennix Goto Github PK

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

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.

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

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.

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

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

Dennix should support x86_64.

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.

Port it.

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

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

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.

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.

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)

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

This would allow running Dennix at higher resolutions.

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

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?

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.

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.

This would make the shell more convenient to use.

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

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.

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.

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

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

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

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.

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.

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.

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

Implement redirection and pipes in the shell.

Rationale: everybody loves screenshots

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

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.