The Teensy Executable Revisited(muppetlabs.com)
muppetlabs.com
The Teensy Executable Revisited
https://www.muppetlabs.com/~breadbox/software/tiny/revisit.html
7 comments
System calls on Linux are stable ABI. They have to be, because you can statically link libc. This is different from Windows.
I can (in fact, must when using MSVC) statically link kernel32.lib on Windows as well. It's not a C runtime/standard library, of course, but who ties their OS's user-level API to a particular implementation of a standard library of some random programming language anyhow?
kernel32.lib is an "import library" for kernel32.dll. This is a windows toolchain concept. The import library contains the placeholder references to the DLL loaded at runtime.
If you actually statically linked kernel32.dll somehow it'll break on future windows versions. kernel32 doesn't contain any syscalls anyway since they're all in ntdll.
If you actually statically linked kernel32.dll somehow it'll break on future windows versions. kernel32 doesn't contain any syscalls anyway since they're all in ntdll.
I don't think a file can actually take less than 4 KiB of disk space on most popular file systems. Can it?
Some have methods for reducing the effect of small files.
NTFS stores small files (how small depends on the amount of metadata associated with them, technically up to approximately 1KB but the limit could be <700 bytes).
Depending on options at filesystem creation time, ext4 can store small files inline in the file's inode (up to 128 bytes by default IIRC, again less depending on the presence of extra metadata, more if you have inodes larger than the default 256bytes).
Some filesystem (ZFS for one) support block sub-allocation for small files. Tail packing is available in some filesystems which not only affects small files but larger files that are just a little over a multiple of the current blocksize in length (heuristics are commonly used to determine if this is a good idea rather than applying it to all files, as it can lead to notable latency due to fragmentation on traditional storage (less so with solid-state storage)).
NTFS stores small files (how small depends on the amount of metadata associated with them, technically up to approximately 1KB but the limit could be <700 bytes).
Depending on options at filesystem creation time, ext4 can store small files inline in the file's inode (up to 128 bytes by default IIRC, again less depending on the presence of extra metadata, more if you have inodes larger than the default 256bytes).
Some filesystem (ZFS for one) support block sub-allocation for small files. Tail packing is available in some filesystems which not only affects small files but larger files that are just a little over a multiple of the current blocksize in length (heuristics are commonly used to determine if this is a good idea rather than applying it to all files, as it can lead to notable latency due to fragmentation on traditional storage (less so with solid-state storage)).
https://www.muppetlabs.com/~breadbox/software/tiny/somewhat....