First of all, cool project! I've done some less ambitious stuff in regards to mashing together scripts and zip archives to create what I'd describe as "dynamically linked python executables", and what you've managed to achieve with compiled code is awe inspiring.
Pure computation and file/socket based IO is enough to solve many problems, but I'm curious what the plan is down the road to support more exotic forms of IO like high performance graphics, audio, human input devices, etc. in a portable way?
It seems like the fully-statically-linked approach can only get as far as the common subset of all supported platforms, which is probably a tautology, but means that the cosmopolitan library will have to not only provide APIs for any possible type of IO someone might want to do, but also bake in all the userspace code to implement it on every platform. For a lot of things that seems currently very difficult, as many hardware vendors only provide dynamic libraries as their interface. I suppose statically linking isn't mutually exclusive with dynamically loading, though?
The other route seems to be targeting a virtual machine of some sort, whether it's running the code and providing a consistent ABI like qemu, or communicating over files/sockets like rendering graphics and sound in a web browser. I get the impression that's the less interesting route to go down though.
I appreciate the holistic nature of the project, and it seems like you've approached it with a pragmatic mindset. Myself thinking pragmatically, it just seems like you'll eventually want to at least support opengl or a GUI library or something, to appeal to the types of programs that really benefit most from easy portability.
One of Cosmopolitan's demo programs is an NES emulator that runs in the terminal: https://justine.lol/nesemu1.html It plays audio by piping raw audio samples into an ffplay or sox subprocess. Another demo program is PRINTVIDEO.COM which can do things like play 4K MPEG videos in the terminal. https://justine.lol/printvideo.html Cosmopolitan is also able to dynamically link things like KERNEL32.DLL so you can create GUI applications. See https://justine.lol/apelife/index.html See also this issue where people have requested hardware accelerated graphics: https://github.com/jart/cosmopolitan/issues/35
Cosmopolitan can be doing more if game studios are willing to back the project. Remember how John Carmack dipped his toes in the water with Quake on Linux decades ago and was promptly scared off by the chaos and complexity of the open source development process? Cosmopolitan brings the kind of order to Unix interfaces that game developers need. Games can't rely on people like distro maintainers to patch and recompile their codebases every time there's a change to some dynamic library. They need to be able to compile their programs once and have game enthusiasts be able to enjoy those programs for years to come. Right now anything you build with Cosmo will run on every Linux distro since 2007. That means there's a good chance your programs will continue to work perfectly and natively on every Linux distro in the future. You might not be able to run shaders on Nvidia chips yet. But what we've accomplished so far is a big leap forward compared to the status quo.
Pure computation and file/socket based IO is enough to solve many problems, but I'm curious what the plan is down the road to support more exotic forms of IO like high performance graphics, audio, human input devices, etc. in a portable way?
It seems like the fully-statically-linked approach can only get as far as the common subset of all supported platforms, which is probably a tautology, but means that the cosmopolitan library will have to not only provide APIs for any possible type of IO someone might want to do, but also bake in all the userspace code to implement it on every platform. For a lot of things that seems currently very difficult, as many hardware vendors only provide dynamic libraries as their interface. I suppose statically linking isn't mutually exclusive with dynamically loading, though?
The other route seems to be targeting a virtual machine of some sort, whether it's running the code and providing a consistent ABI like qemu, or communicating over files/sockets like rendering graphics and sound in a web browser. I get the impression that's the less interesting route to go down though.
I appreciate the holistic nature of the project, and it seems like you've approached it with a pragmatic mindset. Myself thinking pragmatically, it just seems like you'll eventually want to at least support opengl or a GUI library or something, to appeal to the types of programs that really benefit most from easy portability.