Comment by yjftsjthsd-h
1 month ago
https://os8088.com/how-it-works/multitasking/
> Pre-emptive multitasking on an 8086
> Twelve task slots, 1,536 bytes of stack each, and a timer interrupt that takes the CPU away from whatever is running 18.2065 times a second. No task is asked to cooperate and no task can refuse.
If you don't have protected mode, can't any program just rewrite the interrupt handler? It's not a bad system, but it sounds easy to break.
The original MacOS lacked memory protection too. It had cooperative multi-tasking, starting at version 7. Before that, the only thing that could be launched next to the main application were "desk accessories", which were a bit of a pain to write, as they had to stay out of harm's way.
MultiFinder existed before System 7. It was just optional.
MultiFinder was introduced in System 5.
Before that, there was Switcher - not a multitasker, but did keep multiple (non-DA) applications in memory at the same time.
> If you don't have protected mode, can't any program just rewrite the interrupt handler?
Yes? It's still possible to make it safe if you ensure that all programs are written in a memory safe language. Aside from throwing out a ton of existing code it's not as bad as it sounds. The Birth and Death of JavaScript touches on it towards the end.
https://www.destroyallsoftware.com/talks/the-birth-and-death...
Yeah, that works for making sure the machine isn't constantly crashing.
Although from a security point of view it's still very bad. Every compiler / JIT has bugs, and bugs that let you write to random or arbitrary memory adresses are a rather common kind.
Doesn't really matter for a hobby project though
It's debatable! Most system software is written in memory unsafe languages right now and probably has more bugs than something like V8. Keep in mind that JavaScript runtimes are built for downloading and running untrusted code on your system.
Yes, it's easy to break. There's no memory protection. However, building packages, drivers, and kernel modules for it has been a fun and educational exercise in memory management.
This would be exactly like the original Mac--all processes had full heap access at all times. There was a special debugger extension that watched address zero because writing through to null was so common. (IIRC the original Mac intentionally left address zero alone for these reasons as well.)
It's a toy, easy to break is what vintage software was. A very different era with users of a very different mindset.
Not just rewrite the interrupt handler either, can rewrite the timer itself :)
Part of the fun of real-mode is the absolute god like power you have. Downside is the 20bit segmented memory model.