What’s the difference in practice compared to every other OS where app is just a “int main() { … }” function?
But I don’t think that’s really that significant… you could, e.g., enumerate all the implicit things the OS provides, express them in a structure, and now you’ve got your explicit context. The “fomos” context is only as simple as it is because the OS provides a small number of simple things. Expand those to full OS capabilities and the context will get full OS complex.
The odd thing about this “OS” is that a running app is just the start function called repeatedly in a loop. This makes one app call a single coherent slice of app execution. That’s kind of interesting, but makes this pretty limited. E.g., it looks like apps are entirely cooperative. It’s maybe more of a cooperative execution environment.
Maybe it would be good for some embedded uses?
So you get the benefits of simplicity of a static binary and the size benefit of a dynamically linked binary.
Well that's the way I understood it anyway.
/* Create function pointer of appropriate type, initialised. */
int(*foo)(int, int) = NULL;
int main()
{
void * ha;
if ((ha = dlopen("A", RTLD_LAZY|RTLD_NODELETE)) != NULL) {
foo = dlsym(ha, "foo");
dlclose(ha);
}
/* if "foo" is non-NULL you can call it now. */
...Your premise is wrong: in, say, Windows or GNU/Linux an application is, say, a PE/COFF or ELF executable, both non-trivial file formats. The int main(...) function in C is just a very leaky abstraction of all this.
There is no such thing as "program is just a function" unless it's compiled with the OS, like on some microcontrollers. For programs residing on storage, the OS needs a way to load them into memory along with its resources which means it needs to read some kind of format, even if it's trivial.
The "app is a function" distinction is simply about the `Context` struct passed it, otherwise it loads and runs executables as expected (load ELf memory segments in, jump to entrypoint)
Edit: I guess I'd also add that on Linux or other OSs it's possible to construct and run process completely from memory with no on-disk executable file. JIT compilers do effectively this, the produce the executable code completely in memory and run it.
This is rather likely true. But since writing such code is much harder than, say, writing FizzBuzz, I assume that somewhere in the OS code, a "wrong" abstraction is used which makes this task far too complicated.
I'm not really sure what you're looking for or expecting unless you want the OS to compile your code for you (which this OS doesn't do either).