4 ms·
Years ago I read some of the author's posts (they're active on HN too iirc) about it, and it seemed to me like they were relying heavily on the internals of the
by asveikau 2y ago
Years ago I read some of the author's posts (they're active on HN too iirc) about it, and it seemed to me like they were relying heavily on the internals of the loader or dynamic linker on each platform, such that a new release for any given OS could conceivably break your binary.
It's probably a very fun project to hack on but I would advise against distributing the binaries and expecting them to work over the long term.
- TimTheTinker 2y agoTo 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 agoI 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 agoSee 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.)