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. 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.then
> Memory-safe language.
What's the point? Looks like today Rust is like 3D printing was. As if it makes something better. Printing was hyped and advertised by printers sellers and manufacturers. Finally they run out of money.
As for project, it's cool if compatible with old soft. Otherwise suitable mostly for education and masochism. Long way to become practical anyway even if it gets traction.
- unsafe code plus modules that support it (the "trusted base")
- all the rest
Rust's promise is that there is no way to trigger any undefined behavior from bugs happening in "all the rest" of the code. If that code makes for more than 95% of the total, then that's a huge win compared to a completely unsafe language.
Also, Rust's support for inline assembly is in my opinion better than C's, it's much easier to specify and figure out the constraints on the boundary between Rust/assembly.
Also if you look at the repo, only 3% of the codebase is in Assembly. IMO if >95% project is in Rust, you can definitely claim it's a Rust project.
I was playing with a toy TCP/IP stack, and decided using SLIP over a pty on Linux was a great way to interface with the kernel. Unfortunately it looks like macOS previously shipped with slattach(1) a very long time ago, but no longer does.
I'm curios if other people have used SLIP on macOS to get a dead-simple, cross-platform API to the networking stack?
The alternative would be to use tun/tap on Linux and utun on macOS, but SLIP would be so much nicer.
> A support for the ARM architecture (aarch) is coming soon too.
Wow! How do you support a DOS-like OS across multiple architectures when DOS itself is tightly tied to interactions among the program, the system code, and the architecture?
It is much harder to bootstrap a simple OS in ARM, and it won’t stay very simple unless you accept significantly more limitations than you would under x86. (For example, you can’t do very much with the MMU off on ARM, and you also don’t have convenient BIOS interfaces that allow you to, say, read a sector, or wait for a keypress, with just a few lines of assembly).
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.
Could this run from an efi system partition? Seems to support fat12, what about gpt?
Does it poke video hardware like DOS, or have a terminal like output?
NGL one of my long term projects was/is something exactly like this but UEFI and secure boot. The idea being to use the VM extensions to create IBM-PC and DOS compatible environments. For anything using DPMI[1] I'd probably do the same trick as Win95 did and just replace it with my own implementation so it's not too overburdened with layers.
[1] https://en.wikipedia.org/wiki/DOS_Protected_Mode_Interface
On the other hand, did you see https://github.com/FlyGoat/csmwrap when it came up a few weeks ago?
* https://news.ycombinator.com/item?id=44101828
There are already projects to provide replacements for the vanished Compatibility Support Module.
My goal was more "What if DOS hadn't ended and but kept up support for modern hardware" along with emulation of common things in DOS gaming. So for example you would be able to set up a PIV that mapped certain resources directly or emulated them depending on the need.
Could I use DOSBox for this... yes, but this is a "why not" sort of thing. I figured it would be a good excuse to learn OS dev. But life has kept me busy for now.
I.e.: runs Alley Cat and Dune 2 - and Doom.
:-))
Ultimately, it's an eye of the beholder type thing, but it seems very fair to call it DOS-like to me. The DOS inspiration is pretty blatant all throughout it from its aesthetic, commands (more than just dir and cls is shared), booting from a 1.44 floppy, etc. And if you are coming from a primarily windows computing background, then "DOS-like" is entirely appropriate to me.
It looks like a fun project.
Fun project indeed.
Note the “guest” username in the prompt is a const, not multi-user: https://github.com/krustowski/rou2exOS/blob/6f85955dd339f09d...