ELF supports loading a shared library to some arbitrary memory address and fixing up references to symbols in that library accordingly, including dynamically after load time with dlopen(3).
a.out did not support this. The executable format doesn't have relocation entries, which means every address in the binary was fixed at link time. Shared libraries were supported by maintaining a table of statically-assigned, non-overlapping address spaces, and at link time resolving external references to those fixed addresses.
Loading is faster and simpler when all you do is copy sections into memory then jump to the start address.
Shameless plug: Some of my hobby projects written in C (e.g. https://github.com/pts/bakefat) can be built reproducibly for Linux >=1.0 (1994), FreeBSD (same ELF executable program file as for Linux) and Win32 working on all versions of Windows (Windows NT 3.1 (1993)--Windows 11). The C compiler (running on Linux i386 and amd64 host) used for the release build is self-contained and included in the project, along with the libc.
Doing such backward compatibility is definitiely possible for command-line tools. Once set up, it's automatic, and it needs extra testing after major changes.
If a text-mode process monitor is larger than about 200 KiB, then it sounds bloated to me. If it's loaded with tons of features, then my upper limit is 1 MiB.
This video doesn't explain what the project does and how it does it. Also it's deliberately misleading the viewer, for example it purposefully incorrectly states that C++ is an interpreted language.
The video is a compliment to the Github repository, the presenter even shows code and brings up the repo in the video. I guess you didn't watch that part and unfortunately you didn't get the joke either.
It's more of a "just in case" thing for the most part... the actual risk of an escape as part of a sequence showing up over TCP without the rest for over a fraction of a second today is highly unlikely. That said, so many systems seem to add a delay well over half a second like we're using dialup.
I'd probably tune the delay to 100-200ms if I ever really felt it and have the option to change it.
In hindsight this convention seems weird to me by the way. I didn't question it for the decades I was paid money to write C, but after adopting Rust it jumped out more that it's weird how monocase the C and C++ standard libraries are.
Maybe there's a reason I'd never run into, but this seems like a missed opportunity. Even if I have no idea what Goose is, I can see it's a type, that seems like a win.
Yeah I don't know why so many C programmers ended up on a convention where case is entirely unused. I wonder if it's some ancient compatability thing that they have just been keeping self-consistent with forever. To me not using case is like designing a road map in black-and-white just because you didn't have any ideas for what colors should represent.
I find this style overy verbose, disrepectful, offensive and dumb. (See example dialogue in the screenshot on the project page.) Fortunately, it's possible to change the prompt above.
Interesting, and thanks; that's not how it's supposed to look for sure. I'll ask someone to look at the whole mobile experience, definitely not my area.
reply