let's resurrect these days with open.mp!

How about the event loop in its completeness?

Sort of, but IMO that module(s) is just a wrapper for video buffer.

You are right, it goes way ahead the first iteration. I call it DOS-like because of its resemblance to the Text mode-only operating systems (and to MS-DOS especially). On the other hand, it shares very little as the architecture, command set, or hardware utilization approach are concerned when compared to MS-DOS.

I am not at the moment. The goal is to keep this iteration in English for now. The first iteration was in Czech in the beginning though.

Well, the point is to experiment with Rust no_std+no_main environment while trying to educate myself on how the things work under the hood. The project itself is part "just" a rewritten system (from C to Rust), and part an enhancement of such system furthermore. It lacks the external program execution though yet.

The x86 arch is used because this system iteration derives from the first one, which relies on BIOS interrupts and inline assembly in Turbo C. I am not trying to mimic (MS-)DOS exclusively, but both systems are highly inspired by it.

IMO multiple archs could be supported as Rust compiler allows the target arch specification, so one would build a specific target before the build itself.

Booting from an EFI system partition has not been tested yet. FAT12 is the only filesystem (ok, there is a memdisk implementation, but it won't work now) supported, so GPT is not supported at the moment too (yet). Kinda aiming for FAT32 implementation to be the very next implemented (flash disks are usually FAT32 iirc). Not sure about the last question: the OS utilizes/directly writes to the VGA buffer in memory, the provided resolution is 80x25 by GRUB.

So MBR partitions? Or no partitions, like from a floppy? Or perhaps it doesn’t know because grub handles that part.

For FAT12, it reads the first sector (0 or bootsector) of the floppy provided to gather information like bytes per sector, reserved sectors count, LBA of the root directory, etc.

Afaik there is a 'DIR' command in MS-DOS. Anyway, what would be a better command to list a directory? I could think of 'ls' maybe

I would most likely end up with something like this:

  CAT          CATalogue - output the contents of current directory
  RM           to Raster Memory - load contents of named file in framebuffer
  MV           Make Virtual - map the file into memory and output the address
  LS           Load System - attempt to reboot using the named file as the kernel
  CD           Create Directory - self-explanatory
  SH           System Halt - immediately stop all processing

...and so on.

I suggest:

    RM           Relocate me - you could also use the "-rf" flag to relative fuzzy matching, for instance `rm -rf tmp` to find any temp-like folder near your current location. Pretty standard stuff.
    CD           Clear data - `cd -L /temp` would "liquidate" the directory.

This would be a much simpler command interface.

To create a file, we should take inspiration from TOPS-10 and call the command `make` [0]. When issuing `make love`, it should ask for confirmation to the user: `not war?`.

[0] https://en.wikipedia.org/wiki/Easter_egg_(media)

Very good design. Implements only the essential tasks an operator would need with concise and well-known mnemonics. I’m sure this will be immediately intuitive to anyone, with no potential for mistakes whatsoever.

CAT was on the Amstrad CPC.

Love it.

As someone old enough to have started on MS-DOS 3.3, dir has been there all time.

CATALOG, DSPFLR, Get-ChildItem

What a challenge! Need to implement some interrupts it seems then, to provide an API for filesystem and so... Thank you for such idea

Doomgeneric has a very thin platform-specific layer: https://github.com/ozkl/doomgeneric?tab=readme-ov-file#porti...

I want some TSRs and print spoolers...