5 ms·

What’s the difference in practice compared to every other OS where app is just a “int main() { … }” function?

by nnx 3y ago

mepian 3y ago
Make two apps A and B with their respective main() functions. Add some function foo() to app A. Now try to call A's foo() from B's main(). How many hoops do you need to jump through in every other OS to do this?
- xcdzvyn 3y ago
  The amount of (wonderfully) horrible doors this opens is awesome.
- duped 3y ago
  None, because this exists outside the scope of an operating system. This is the domain of an executable/linkage format and language compiler.
  - wyldfire 3y ago
    Maybe the complexity lies in that possessive qualifier "A's foo()" - if this foo() can manipulate the callee state in some other virtual memory domain then it might not be sufficient to link against it in B's application.
- Karellen 3y ago
  Not many hoops, why? /* 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. */ ...
  - mepian 3y ago
    If you control the development of both A and B apps, then not so many. But generally you are not expected to load symbols from another application, you are expected to either use various IPC mechanisms or load symbols from a shared library instead of touching another application at all.
ben-schaaf 3y ago
I'd suggest reading the linked readme, it does a great job explaining the differences. In other operating systems apps do dynamic linking & syscalls. Those don't exist in Fomos.
jmull 3y ago
In a regular OS there would be a bunch of implicit things provided by the OS that the app can access, while in this OS those things are explicit in the context. 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?
- lostmsu 3y ago
  Seems similar to Singularity https://en.wikipedia.org/wiki/Singularity_%28operating_system%29 https://en.wikipedia.org/wiki/Singularity_%28operating_syste...
- benj111 3y ago
  My takeaway was that compared to a dynamically linked binary, you don't need to literally patch it to get the correct addresses. 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.
aleph_minus_one 3y ago
> What’s the difference in practice compared to every other OS where app is just a “int main() { … }” function? 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.
- optymizer 3y ago
  As opposed to what? Code that can be directly loaded into memory with no headers? That's how .COM files worked. 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.
  - aleph_minus_one 3y ago
    But you can separate the file format of the executable from the loading process, i.e. implement "doing what the OS loader does" on your own. This way, you can define your completely own executable format instead of being forced to use the one that your OS wants you to use, or even decide that it doesn't have to be a file format (e.g. stream the data from a network stream).
- DSMan195276 3y ago
  I think you're making a wrong assumption about how this OS works, its programs are still loaded from ELF executables, the parser is here: https://github.com/Ruddle/Fomos/blob/91cf732f173a01cdec3df438617c87b6dd8dcf8e/bootloader/kernel/src/app.rs#L70 https://github.com/Ruddle/Fomos/blob/91cf732f173a01cdec3df43... 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.

What’s the difference in practice compared to every other OS where app is just a “int main() { … }” function?

by nnx 3y ago

What’s the difference in practice compared to every other OS where app is just a “int main() { … }” function?

Make two apps A and B with their respective main() functions. Add some function foo() to app A. Now try to call A's foo() from B's main(). How many hoops do you need to jump through in every other OS to do this?

xcdzvyn 3y ago
The amount of (wonderfully) horrible doors this opens is awesome.
duped 3y ago
None, because this exists outside the scope of an operating system. This is the domain of an executable/linkage format and language compiler.
- wyldfire 3y ago
  Maybe the complexity lies in that possessive qualifier "A's foo()" - if this foo() can manipulate the callee state in some other virtual memory domain then it might not be sufficient to link against it in B's application.
Karellen 3y ago
Not many hoops, why? /* 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. */ ...
- mepian 3y ago
  If you control the development of both A and B apps, then not so many. But generally you are not expected to load symbols from another application, you are expected to either use various IPC mechanisms or load symbols from a shared library instead of touching another application at all.

ben-schaaf 3y ago

I'd suggest reading the linked readme, it does a great job explaining the differences. In other operating systems apps do dynamic linking & syscalls. Those don't exist in Fomos.

jmull 3y ago

In a regular OS there would be a bunch of implicit things provided by the OS that the app can access, while in this OS those things are explicit in the context. 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?

lostmsu 3y ago
Seems similar to Singularity https://en.wikipedia.org/wiki/Singularity_%28operating_system%29 https://en.wikipedia.org/wiki/Singularity_%28operating_syste...
benj111 3y ago
My takeaway was that compared to a dynamically linked binary, you don't need to literally patch it to get the correct addresses. 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.

aleph_minus_one 3y ago

> What’s the difference in practice compared to every other OS where app is just a “int main() { … }” function? 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.

optymizer 3y ago
As opposed to what? Code that can be directly loaded into memory with no headers? That's how .COM files worked. 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.
- aleph_minus_one 3y ago
  But you can separate the file format of the executable from the loading process, i.e. implement "doing what the OS loader does" on your own. This way, you can define your completely own executable format instead of being forced to use the one that your OS wants you to use, or even decide that it doesn't have to be a file format (e.g. stream the data from a network stream).
DSMan195276 3y ago
I think you're making a wrong assumption about how this OS works, its programs are still loaded from ELF executables, the parser is here: https://github.com/Ruddle/Fomos/blob/91cf732f173a01cdec3df438617c87b6dd8dcf8e/bootloader/kernel/src/app.rs#L70 https://github.com/Ruddle/Fomos/blob/91cf732f173a01cdec3df43... 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.