6 ms·

I'm not sure what problem Cosmopolitan is trying to solve. I think it's an interesting research project, but from a practical perspective - there are significa

I'm not sure what problem Cosmopolitan is trying to solve. I think it's an interesting research project, but from a practical perspective - there are significantly better (and more mature) ways to achieve cross-platform compatibility that don't involve many of the compile-time and run-time hacks required to get Cosmopolitan to work. "Actually Portable Executables" are not any more "portable" than a statically compiled .exe running natively on Windows, or using Wine[0] on a Linux, as an example. [0] https://en.wikipedia.org/wiki/Wine_(software) https://en.wikipedia.org/wiki/Wine_(software)

jart 6y ago
I'm sorry but WINE is the kind of interpreter that gives me enough time to take a coffee break as it loads solitaire.exe. I needed to use it a few weeks ago because I'm supporting someone who needs it for their CI environment. I discovered that APIs for things as fundamental as things like memory that Microsoft introduced back in 2006 hadn't been implemented in the WINE release Debian installed on my machine that was made in 2019. As far as I can tell the project wasn't funded for the longest time, which is unfortunate, because a once great tool then succumbed to tragedy of the commons. That's why I hope Cosmopolitan can have a positive impact. Because interpreters are great but we shouldn't need to rely on them as much as we currently do. The only thing your Actually Portable Executables need is the canonical stock preferred kernel interfaces that have indefinite stability promises backed by the most powerful technology corporations on earth. No one got fired for depending on the IBM's of the world. Your software is going to have a long life with little maintenance and best of all it's going to be fast.
- VMG 6y ago
  I'm surprised by this. I'm using WINE to play League of Legends on Linux and it works surprisingly well.
  - jonathanstrange 6y ago
    Once an application is running it's reasonably fast but Wine has always taken endlessly time to start up, at least on my machine. It feels similar to Java VMs in that respect.
    - VMG 6y ago
      Ah yes I can attest to that part. It does take quite a long time to start.
- throwaway525142 6y ago
  Wine is actually quite similar to this: It's not an interpreter or an emulator, it natively runs the executable on the host CPU. What it does is provide the WinAPI dynamic libraries that the programs expect (so they can call functions like CreateFile) and a loader that can load the exe files (PE) into memory and knows where to jump to.
- t0astbread 6y ago
  For the record, I've tried running a recent game (made in Unity, I believe) on WINE a while ago and it worked like a charm. So I guess it's hit or miss?
- deleted 6y ago
  [deleted]
- csmpltn2 6y ago
  Thanks, but I still can't tell from your response what problem Cosmopolitan is trying to solve. I came across some of the following statements in your website (https://justine.lol/cosmopolitan/index.html https://justine.lol/cosmopolitan/index.html): > "Cosmopolitan makes C a build-once run-anywhere language, similar to Java, except it doesn't require interpreters or virtual machines be installed beforehand" Glancing at the code so-far, Cosmopolitan is really just an alternative libc implementation. It's important we acknowledge that there's only so much you can do with a libc implementation: it's a paper-thin abstraction layer for a small subset of rudimentary APIs. It's common for software today to depend on operating system interfaces (which are platform-specific), either directly (via static/dynamic linking with operating system libraries) or indirectly (delegating to a runtime environment such as Java, Python, .NET Core, Mono, Wine, and others). I don't see how Cosmopolitan caters for these scenarios, and I don't see why you would make that comparison in the first place. > "Cosmo provides the same portability benefits as high-level languages like Go and Rust, but it doesn't invent a new language and you won't need to configure a CI system to build separate binaries for each operating system" Cosmopolitan doesn't change anything about the C language itself, right? How portable a certain C project is depends entirely on the business logic within the code. Any C code using nothing but libc is pretty much guaranteed to be "portable" (it can be built using almost any combination of hardware, operating systems and compilers) - I'm not sure what Cosmopolitan contributes to the portability story? > "What Cosmopolitan focuses on is fixing C by decoupling it from platforms" C is already "decoupled from platforms", so I'm confused by this statement. There are a lot of projects out there that don't use libc at-all, or use their own custom abstractions on-top of platform-specific code (#ifdefs, fancy buildsystems, etc). There's nothing about Cosmopolitan itself that makes it somehow "decoupled from platforms": the decoupling happens by virtue of writing code that relies on the public interfaces exposed by libc, and the ability to swap libc at both compile- and runtimes.
  - dvt 6y ago
    HN has been obsessed with this project for the past few days, and that might be why you're getting so aggressively downvoted. Cosmopolitan is interesting from a technical perspective, but doesn't really bring anything new to the table. Packaging multiple entry points in the same file is a clever hack but is extremely brittle (for example, archiving/re-archiving can mangle relevant sections which ZIP doesn't care about -- this will break your binary), ELF uses a pre-processing step which renders the binary non-portable once it's run, and the cross-platform libc stuff has been done since time eternal. Not to mention that, as you say, just C is nigh useless these days, anyway. It's kind of funny to see people comparing this to Electron.
bkmeneguello 6y ago
I think the major problem it solves is to not require multiple binaries to be distributed, one for each OS since them all runs on the same architecture. By distributing a single binary that really runs anywhere without requiring another solution, like a VM, an emulator or a compatibility layer, it simplifies the installation process, and allows the projects to be available for more users without increase the build complexity.
GordonS 6y ago
I tried to get Wine to run a dotnet framework console app last week. It was the first time I've tried to use Wine, but it was way more complicated than I thought it was going to be - many magical incantations are needed, which vary by OS, hardware platform, OS platform and binary platform. And it's very slow. I spent about 4 hours trying to get it working, and after all that time, all I'd achieved was bombing on a Crypto API error. I gave up.
cfstras 6y ago
Yes, as they require a significantly less amount of stuff you need to deal with. WINE needs to implement vast amounts of Windows APIs to make something like .net work, while cosmopolitan limits you to low-level C (and things built on it, like lua) at compile time.
- csmpltn2 6y ago
  > while cosmopolitan limits you to low-level C (and things built on it, like lua) at compile time You can build very little with the C Standard Library alone, wouldn't you agree? Things like graphics, anything beyond the most rudimentary I/O, etc - are not a part of the C Standard Library.
A12-B 6y ago
This is a theoretically more pure solution because you are trying to break down compatibility to its common factors, the processor, and then do as little work as possible to get it to the point of portability. Less abstraction than other solutions. The holy grail would be a generalised solution for any processor, using nothing but electrical engineering first principles, but I don't know if that's possible and maybe the better solution is to just not have the frankenstein's monster of hardware we have today.
alisonatwork 6y ago
You're thinking in the wrong direction. WINE can let Linux users run Windows binaries, but then as a programmer you need to write Windows-y C. What makes this appealing to me is that as a Windows user I can write UNIX-y C and it will just work. Obviously Windows could also be supported by recompiling under Cygwin, or MSYS2, but those tools are challenging. Compiling code designed for a UNIX on Windows is a pain in the ass, and sometimes the end result has strange behaviors. Upstream projects tend not to care much about Windows support, so trying to fix it you're on your own. Nowadays we have WSL so we can just run Linux binaries on Windows as-is, but that's still a fairly heavyweight solution. Wouldn't it be better to just compile once on UNIX, link to a magical portability library, and now you have a binary that just works everywhere? I think so.
- jancsika 6y ago
  > Obviously Windows could also be supported by recompiling under Cygwin, or MSYS2 MSYS2 is a dream. You install it, specify your dependencies using Arch's pacman, and go to town. No fiddling with Windows configuration files or paths, it just works. In fact it has been easier to get new devs up and running in that environment than in Linux, where they tended to smear build-time dependencies across the bare metal install. Of course there are solutions for that, but those solutions are more of a pain to set up than MSYS2.
  - 1996 6y ago
    I'd like to see an MSYS2 compiled with cosmopolitan
    - alisonatwork 6y ago
      The cool thing is that it wouldn't really be MSYS2. It would just be coreutils, or binutils. The dream is that a programmer can just write their tool, using standard ISO C, maybe some POSIX, then compile and link it to Cosmopolitan and they're done. No need to set up any special configs or ifdefs. No need for any platform specific distributions. You just compile once and now you have the canonical version.

jart 6y ago

I'm sorry but WINE is the kind of interpreter that gives me enough time to take a coffee break as it loads solitaire.exe. I needed to use it a few weeks ago because I'm supporting someone who needs it for their CI environment. I discovered that APIs for things as fundamental as things like memory that Microsoft introduced back in 2006 hadn't been implemented in the WINE release Debian installed on my machine that was made in 2019. As far as I can tell the project wasn't funded for the longest time, which is unfortunate, because a once great tool then succumbed to tragedy of the commons. That's why I hope Cosmopolitan can have a positive impact. Because interpreters are great but we shouldn't need to rely on them as much as we currently do. The only thing your Actually Portable Executables need is the canonical stock preferred kernel interfaces that have indefinite stability promises backed by the most powerful technology corporations on earth. No one got fired for depending on the IBM's of the world. Your software is going to have a long life with little maintenance and best of all it's going to be fast.

VMG 6y ago
I'm surprised by this. I'm using WINE to play League of Legends on Linux and it works surprisingly well.
- jonathanstrange 6y ago
  Once an application is running it's reasonably fast but Wine has always taken endlessly time to start up, at least on my machine. It feels similar to Java VMs in that respect.
  - VMG 6y ago
    Ah yes I can attest to that part. It does take quite a long time to start.
throwaway525142 6y ago
Wine is actually quite similar to this: It's not an interpreter or an emulator, it natively runs the executable on the host CPU. What it does is provide the WinAPI dynamic libraries that the programs expect (so they can call functions like CreateFile) and a loader that can load the exe files (PE) into memory and knows where to jump to.
t0astbread 6y ago
For the record, I've tried running a recent game (made in Unity, I believe) on WINE a while ago and it worked like a charm. So I guess it's hit or miss?
deleted 6y ago
[deleted]
csmpltn2 6y ago
Thanks, but I still can't tell from your response what problem Cosmopolitan is trying to solve. I came across some of the following statements in your website (https://justine.lol/cosmopolitan/index.html https://justine.lol/cosmopolitan/index.html): > "Cosmopolitan makes C a build-once run-anywhere language, similar to Java, except it doesn't require interpreters or virtual machines be installed beforehand" Glancing at the code so-far, Cosmopolitan is really just an alternative libc implementation. It's important we acknowledge that there's only so much you can do with a libc implementation: it's a paper-thin abstraction layer for a small subset of rudimentary APIs. It's common for software today to depend on operating system interfaces (which are platform-specific), either directly (via static/dynamic linking with operating system libraries) or indirectly (delegating to a runtime environment such as Java, Python, .NET Core, Mono, Wine, and others). I don't see how Cosmopolitan caters for these scenarios, and I don't see why you would make that comparison in the first place. > "Cosmo provides the same portability benefits as high-level languages like Go and Rust, but it doesn't invent a new language and you won't need to configure a CI system to build separate binaries for each operating system" Cosmopolitan doesn't change anything about the C language itself, right? How portable a certain C project is depends entirely on the business logic within the code. Any C code using nothing but libc is pretty much guaranteed to be "portable" (it can be built using almost any combination of hardware, operating systems and compilers) - I'm not sure what Cosmopolitan contributes to the portability story? > "What Cosmopolitan focuses on is fixing C by decoupling it from platforms" C is already "decoupled from platforms", so I'm confused by this statement. There are a lot of projects out there that don't use libc at-all, or use their own custom abstractions on-top of platform-specific code (#ifdefs, fancy buildsystems, etc). There's nothing about Cosmopolitan itself that makes it somehow "decoupled from platforms": the decoupling happens by virtue of writing code that relies on the public interfaces exposed by libc, and the ability to swap libc at both compile- and runtimes.
- dvt 6y ago
  HN has been obsessed with this project for the past few days, and that might be why you're getting so aggressively downvoted. Cosmopolitan is interesting from a technical perspective, but doesn't really bring anything new to the table. Packaging multiple entry points in the same file is a clever hack but is extremely brittle (for example, archiving/re-archiving can mangle relevant sections which ZIP doesn't care about -- this will break your binary), ELF uses a pre-processing step which renders the binary non-portable once it's run, and the cross-platform libc stuff has been done since time eternal. Not to mention that, as you say, just C is nigh useless these days, anyway. It's kind of funny to see people comparing this to Electron.

bkmeneguello 6y ago

I think the major problem it solves is to not require multiple binaries to be distributed, one for each OS since them all runs on the same architecture. By distributing a single binary that really runs anywhere without requiring another solution, like a VM, an emulator or a compatibility layer, it simplifies the installation process, and allows the projects to be available for more users without increase the build complexity.

GordonS 6y ago

I tried to get Wine to run a dotnet framework console app last week. It was the first time I've tried to use Wine, but it was way more complicated than I thought it was going to be - many magical incantations are needed, which vary by OS, hardware platform, OS platform and binary platform. And it's very slow. I spent about 4 hours trying to get it working, and after all that time, all I'd achieved was bombing on a Crypto API error. I gave up.

cfstras 6y ago

Yes, as they require a significantly less amount of stuff you need to deal with. WINE needs to implement vast amounts of Windows APIs to make something like .net work, while cosmopolitan limits you to low-level C (and things built on it, like lua) at compile time.

csmpltn2 6y ago
> while cosmopolitan limits you to low-level C (and things built on it, like lua) at compile time You can build very little with the C Standard Library alone, wouldn't you agree? Things like graphics, anything beyond the most rudimentary I/O, etc - are not a part of the C Standard Library.

A12-B 6y ago

This is a theoretically more pure solution because you are trying to break down compatibility to its common factors, the processor, and then do as little work as possible to get it to the point of portability. Less abstraction than other solutions. The holy grail would be a generalised solution for any processor, using nothing but electrical engineering first principles, but I don't know if that's possible and maybe the better solution is to just not have the frankenstein's monster of hardware we have today.

alisonatwork 6y ago

You're thinking in the wrong direction. WINE can let Linux users run Windows binaries, but then as a programmer you need to write Windows-y C. What makes this appealing to me is that as a Windows user I can write UNIX-y C and it will just work. Obviously Windows could also be supported by recompiling under Cygwin, or MSYS2, but those tools are challenging. Compiling code designed for a UNIX on Windows is a pain in the ass, and sometimes the end result has strange behaviors. Upstream projects tend not to care much about Windows support, so trying to fix it you're on your own. Nowadays we have WSL so we can just run Linux binaries on Windows as-is, but that's still a fairly heavyweight solution. Wouldn't it be better to just compile once on UNIX, link to a magical portability library, and now you have a binary that just works everywhere? I think so.

jancsika 6y ago
> Obviously Windows could also be supported by recompiling under Cygwin, or MSYS2 MSYS2 is a dream. You install it, specify your dependencies using Arch's pacman, and go to town. No fiddling with Windows configuration files or paths, it just works. In fact it has been easier to get new devs up and running in that environment than in Linux, where they tended to smear build-time dependencies across the bare metal install. Of course there are solutions for that, but those solutions are more of a pain to set up than MSYS2.
- 1996 6y ago
  I'd like to see an MSYS2 compiled with cosmopolitan
  - alisonatwork 6y ago
    The cool thing is that it wouldn't really be MSYS2. It would just be coreutils, or binutils. The dream is that a programmer can just write their tool, using standard ISO C, maybe some POSIX, then compile and link it to Cosmopolitan and they're done. No need to set up any special configs or ifdefs. No need for any platform specific distributions. You just compile once and now you have the canonical version.