3 ms·

To my recollection, at least on *nix operating systems, they got some changes made to the POSIX standard to formalize behavior the binaries rely on. So going fo

To my recollection, at least on *nix operating systems, they got some changes made to the POSIX standard to formalize behavior the binaries rely on. So going forward, mere POSIX compliance and ongoing ABI compatibility guarantee the binaries will continue to work on *nix operating systems. On Windows, backwards ABI and executable compatibility has always been an extremely high priority, so I think the danger of future breakage is low. Neither of those speak to macOS, but maybe someone who knows more can help clarify.

asveikau 2y ago
I disagree with your assessment in all cases. You simply do not know what you were talking about. Standardization efforts and backward compatibility assumes a well-behaved application. If you explicitly depend on really weird hacky stuff like abusing corner cases in the object file format, you risk breakage and you will break. In the Unix world, firstly, platforms that aren't Linux typically say that if you don't do syscalls through system libc, all bets are off. Second, if they standardized a few things here and there, they are likely standardizing stuff that will formed applications linked with typical libraries will exercise. Standardization does not imply explicitly listing all possible corner cases of your object file format. On Windows, I happen to be a former Microsoft dev who worked on Windows in 2008-2011. If an app were trying to push the limits of the PE format, I don't think it would get fixed on the platform side... I've seen popular applications do much less bad things and get broken.
- yjftsjthsd-h 2y ago
  > I disagree with your assessment in all cases. You simply do not know what you were talking about. No need to be rude. > Standardization efforts and backward compatibility assumes a well-behaved application. If you explicitly depend on really weird hacky stuff like abusing corner cases in the object file format, you risk breakage and you will break. Sure, but if you get the standard to include your use then it's not a hacky edge case anymore. Ex. https://justine.lol/cosmo3/ https://justine.lol/cosmo3/ "POSIX even changed their rules about binary in shell scripts specifically to let us do it" > https://austingroupbugs.net/view.php?id=1250 https://austingroupbugs.net/view.php?id=1250
  - oguz-ismail 2y ago
    See https://news.ycombinator.com/item?id=40775600 https://news.ycombinator.com/item?id=40775600 POSIX doesn't sanctify this use.
  - asveikau 2y ago
    > No need to be rude. It was appropriate criticism. The comment above just said "like, people really value binary compatibility and stuff" -- as if it's OK to code against a very specific moment in time with internal dynamic linker constants and such. No. "It works with how ld.so is written right now" says nothing about standards conformance. Not everything that happens to work is conformant to an ABI. Not every emergent behavior is a feature of an ABI. You would have to not understand what is going on at process load time to think that. Even the highly regarded Microsoft binary compatibility does not work against the model that someone is creating an ELF and PE executable in the same file, they would rightly call that crazy town and mark any bugs as "won't fix".
    - yjftsjthsd-h 2y ago
      > I disagree with your assessment in all cases. Is 100% reasonable. > You simply do not know what you were talking about. Is where it crosses the line into personal attack. If you just left that part out I think the rest of your comment would be quite good. (I mean, I don't agree with it, but it's a fine argument to make.)
- jart 2y ago
  Cosmo author here. Could you please clarify what specific object file features we're abusing? The only hacky thing I did was remove the shebang line, and POSIX was awesome enough to change their rules to let us do it. https://austingroupbugs.net/view.php?id=1250 https://austingroupbugs.net/view.php?id=1250 Beyond that, we just depend on stable ABIs and APIs. We don't link NTDLL for example. It's just straight up WIN32. On MacOS ARM we use the dynamic linker. I want Cosmo programs to stand the test of time. That's why I stopped building apps with NodeJS and wrote this instead. The whole reason this release is on the HN front page, is probably because it got rid of MAP_FIXED mappings and page size assumptions. So if you can tell me where we're still exposed, then I'd love to fix it. Thanks!
  - asveikau 2y ago
    I would need to dig up blog posts I read several years ago to get specific. I recall reading a blog post of yours where you describe hardcoding particular constants to play nice with some loaders and/or dynamic linkers. My impression having worked in this area was "this person is playing with fire, the whole mental framework of operating here is high risk, they will break in a Windows or macOS release and they will deserve to be broken." I know when I played similar tricks with my binaries in the Windows world, they were broken with new OS releases. Emergent behavior from a loader is not an ABI contract, and in that old blog post, which I know I am being vague here, you were definitely treating it as such.. The HN audience at large doesn't know the C world very well and they might mistake your thing for something useful in prod. That's kind of unfortunate.
    - E39M5S62 2y ago
      When asked, by the author, to cite specifics, you're instead claiming something isn't "useful in prod" based on an impression you formed years ago while reading blog posts.
      - asveikau 2y ago
        Doesn't make the conclusion incorrect. I don't feel the need to convince anyone else of this. I also don't have time to dig up that original material and I don't have time to reassess the library to see if it has improved, though I doubt it, because I am still certain it is philosophically an unsound idea. I suspect most experienced C coders if they get one look at that they'd say "ok that's kinda cool but seriously don't do that".

asveikau 2y ago

I disagree with your assessment in all cases. You simply do not know what you were talking about. Standardization efforts and backward compatibility assumes a well-behaved application. If you explicitly depend on really weird hacky stuff like abusing corner cases in the object file format, you risk breakage and you will break. In the Unix world, firstly, platforms that aren't Linux typically say that if you don't do syscalls through system libc, all bets are off. Second, if they standardized a few things here and there, they are likely standardizing stuff that will formed applications linked with typical libraries will exercise. Standardization does not imply explicitly listing all possible corner cases of your object file format. On Windows, I happen to be a former Microsoft dev who worked on Windows in 2008-2011. If an app were trying to push the limits of the PE format, I don't think it would get fixed on the platform side... I've seen popular applications do much less bad things and get broken.

yjftsjthsd-h 2y ago
> I disagree with your assessment in all cases. You simply do not know what you were talking about. No need to be rude. > Standardization efforts and backward compatibility assumes a well-behaved application. If you explicitly depend on really weird hacky stuff like abusing corner cases in the object file format, you risk breakage and you will break. Sure, but if you get the standard to include your use then it's not a hacky edge case anymore. Ex. https://justine.lol/cosmo3/ https://justine.lol/cosmo3/ "POSIX even changed their rules about binary in shell scripts specifically to let us do it" > https://austingroupbugs.net/view.php?id=1250 https://austingroupbugs.net/view.php?id=1250
- oguz-ismail 2y ago
  See https://news.ycombinator.com/item?id=40775600 https://news.ycombinator.com/item?id=40775600 POSIX doesn't sanctify this use.
- asveikau 2y ago
  > No need to be rude. It was appropriate criticism. The comment above just said "like, people really value binary compatibility and stuff" -- as if it's OK to code against a very specific moment in time with internal dynamic linker constants and such. No. "It works with how ld.so is written right now" says nothing about standards conformance. Not everything that happens to work is conformant to an ABI. Not every emergent behavior is a feature of an ABI. You would have to not understand what is going on at process load time to think that. Even the highly regarded Microsoft binary compatibility does not work against the model that someone is creating an ELF and PE executable in the same file, they would rightly call that crazy town and mark any bugs as "won't fix".
  - yjftsjthsd-h 2y ago
    > I disagree with your assessment in all cases. Is 100% reasonable. > You simply do not know what you were talking about. Is where it crosses the line into personal attack. If you just left that part out I think the rest of your comment would be quite good. (I mean, I don't agree with it, but it's a fine argument to make.)
jart 2y ago
Cosmo author here. Could you please clarify what specific object file features we're abusing? The only hacky thing I did was remove the shebang line, and POSIX was awesome enough to change their rules to let us do it. https://austingroupbugs.net/view.php?id=1250 https://austingroupbugs.net/view.php?id=1250 Beyond that, we just depend on stable ABIs and APIs. We don't link NTDLL for example. It's just straight up WIN32. On MacOS ARM we use the dynamic linker. I want Cosmo programs to stand the test of time. That's why I stopped building apps with NodeJS and wrote this instead. The whole reason this release is on the HN front page, is probably because it got rid of MAP_FIXED mappings and page size assumptions. So if you can tell me where we're still exposed, then I'd love to fix it. Thanks!
- asveikau 2y ago
  I would need to dig up blog posts I read several years ago to get specific. I recall reading a blog post of yours where you describe hardcoding particular constants to play nice with some loaders and/or dynamic linkers. My impression having worked in this area was "this person is playing with fire, the whole mental framework of operating here is high risk, they will break in a Windows or macOS release and they will deserve to be broken." I know when I played similar tricks with my binaries in the Windows world, they were broken with new OS releases. Emergent behavior from a loader is not an ABI contract, and in that old blog post, which I know I am being vague here, you were definitely treating it as such.. The HN audience at large doesn't know the C world very well and they might mistake your thing for something useful in prod. That's kind of unfortunate.
  - E39M5S62 2y ago
    When asked, by the author, to cite specifics, you're instead claiming something isn't "useful in prod" based on an impression you formed years ago while reading blog posts.
    - asveikau 2y ago
      Doesn't make the conclusion incorrect. I don't feel the need to convince anyone else of this. I also don't have time to dig up that original material and I don't have time to reassess the library to see if it has improved, though I doubt it, because I am still certain it is philosophically an unsound idea. I suspect most experienced C coders if they get one look at that they'd say "ok that's kinda cool but seriously don't do that".