6 ms·
> The end result is that if you switch your Linux build process to use cosmocc instead of cc then the programs you build, e.g. Bash and Emacs, will just work on
by eatonphil 3y ago
> The end result is that if you switch your Linux build process to use cosmocc instead of cc then the programs you build, e.g. Bash and Emacs, will just work on the command prompts of totally different platforms like Windows and MacOS, and when you run your programs there, it'll feel like you're on Linux. However portability isn't the only selling point. Cosmo Libc will make your software faster and use less memory too. For example, when I build Emacs using the cosmocc toolchain, Emacs thinks it's building for Linux. Then, when I run it on Windows:
> It actually goes 2x faster than the native WIN32 port that the Emacs authors wrote on their own. Cosmo Emacs loads my dotfiles in 1.2 seconds whereas GNU Emacs on Windows loads them in 2.3 seconds.
Impressive stuff.
- AYoung010 3y agoThat was the most interesting part of the article for me. I don't understand how it can be faster, given that there's syscall translation going on. Is this more of a commentary on the quality of the `libc` available on Windows? Or on the quality of the GNU Emacs Windows port?
- PrivateButts 3y agoCould be like the improvements seen when running applications using DXVK. My understanding is that sometimes these translation layers can use newer and more efficient methods than the path that a native implement for the time would use. I'm not a subject matter expert though, and could be completely off base.
- vitiral 3y agoIIUC there is no syscall translation, it's more like there are separate libc implementations and the correct one gets selected at program start based on the OS.
- ReactiveJelly 3y agoSo like in-process WINE?
- kevincox 3y agoYes, this seems fairly accurate. In fact I think Wine supports this mode where you link Wine into a "windows program" at build time to produce a "native" Linux executable. So basically the difference is that you target a POSIX API rather than Win32 and the backend implementation is selected at runtime rather than build time. But both projects have the same idea that they will implement a particular API on multiple platforms.
- stephc_int13 3y agoThis is all super impressive especially for such a small team. But we should keep in mind that this project is what POSIX should have been, this is a big patch to make things right, as they should have been more than 20 years ago. It seems magical because of the failure of numerous other teams and people who never managed to tackle the portability issue with the right mindset and skills.
- zik 3y agoIs it the job of linux OS people to provide multi-platform executable compatibility with every other OS? That seems like a stretch considering that no OS has ever done that.
- uncomputation 3y agoYou have it backwards on two counts. First count is the point of POSIX is any OS vendor doesn’t need to worry about any other OS compatibility. Just implement POSIX interfaces. Second count is that is OP’s exact point: it never has been done before, because too many OS vendors give POSIX very little thought. This helps realize the original vision of POSIX.
- CharlesW 3y ago> First count is the point of POSIX is any OS vendor doesn’t need to worry about any other OS compatibility. Just implement POSIX interfaces. I must be missing something. How are you getting from "just implement POSIX interfaces" to "compile once run everywhere"? Wouldn't the former just promise that you could compile the same source on any POSIX-compliant OSs and get a binary that runs on that OS, on that architecture?
- gavindean90 3y agoIt's because cosmos implements POSIX in a portable way
- rhizome 3y ago