Hello, This was made to submit to the itch.io jam
People ask "what IS jamos?". It is jam-operating-system: JamOS. But it is not a *real* operating system it is only a pretend one.
Inside the program there is a command-line and a RAM-based virtual file system. Normal CLI apps can be used by replacing main() with a new thread, change printf() with JamPrintf(), and fopen with JamFopen() etc. It does ANSI codes just like in linux.
I no longer have this working. Generation 1 is dead but it used to be designed after MacOS Classic. It uses allegro4 lib and could probably run on MS-DOS (it does compile using DJGPP but would easily crash due to not enough RAM and had lots of graphical glitches and low performance). It had only cooperative sub processes. But on windows debugging was hard so I modified allegro4 to run on top of allegro5 (driver backend). That worked fine except sound because of symbol clashes.
So I swapped from allegro5 to SDL2 which worked perfectly. However gen1 codebase was too complicated and progress was incredibly slow and difficult, so I gave up, quit, and started fresh with generation 2.
I wanted to make a smaller scope version. So I started fresh. But then I copy-pasted huge chunks of the gen1 codebase over into the gen2 folder. Still at least half of gen1 was left behind forever.
JamOS can no longer compile with standard allegro4, instead I included the allegro4 codebase inside my project and deleted parts that I don't use, fixing bugs that I found, and adding new functions. Now allegro4 system cannot run on any platform natively as all allegro4 drivers have been deleted. I wrote new custom drivers, which I have made using the SDL1 and again with the SDL2 API, and I choose which one to build in using a tickbox inside of cmake.
I have deleted some of allegro4's vtables and replaced them with switch statements where appropriate, this allows the compiler to do a better job of inlining (with whole-program-optimization / link-time-code-generation). Also I made the blender drawing modes use thread-local-storage for their internal state. Now one thread can do transparent bitmap rendering at the same time that another thread does normal solid mode rendering.
Each sub-program runs as a separate pre-emptive thread and does its own terminal input / output. They render their graphics independently to their own fake screen. Then the main thread runs a compositor routine which keeps track of which "screen" the user is currently on, and shows that one in the app window. So it is similar to an operating system but it is just a single process.