5 ms·

It’s funny because back in the day these were these kind of discussion points thrown around in the Lisp forums when folks would balk at “executable sizes”. Spe

It’s funny because back in the day these were these kind of discussion points thrown around in the Lisp forums when folks would balk at “executable sizes”. Specifically about how C leverages the “free” runtime of the OS while Lisp has to bundle is own. This idea of container runtime sizes would be an amusing thread. A good test of something like Nix or Guix to a very fine grain. “We don’t need bash or ls so we removed it. “ “The VM only simulate a single network card, so we’ll scrap all the other driver. “

kazinator 3y ago
C doesn't leverage the free run time of the OS, when that OS is Windows. Your hello.exe size has to include the run-time DLL's required for it from the C implementation that was used to build it. Windows has only recently been moving toward providing a public run-time for C; the "Universal C Run-Time" (UCRT) that has been introduced in Windows 10.
- ChrisSD 3y ago
  The ucrt is included as far back as Windows 7 (if you install updates).
  - kazinator 3y ago
    The increment in disk space usage caused by the update has to count toward the effective size of the hello program, experienced by the user of that installation.
- ziml77 3y ago
  For some reason, even with the UCRT, binaries seem overly bloated. I've been toying with Zig over the past couple weeks and I really like that it doesn't rely on a C runtime on Windows. Plus it makes it easy to operate entirely with UTF-16 strings, which is a nice to have when I'm writing a utility that is specific to Windows.
- mananaysiempre 3y ago
  > C doesn't leverage the free run time of the OS, when that OS is Windows. Stdio, no. Printf, no (unless you’re an adherent of LIBCTINY[1] or one of its descendants[2] and need only a minimal set of features). Malloc, yes—MSVC’s malloc() on Win32 has always been a thin wrapper around kernel32!HeapAlloc. Strlen or memcpy or whatnot—also possibly yes, but it’s not like minimal implementations of those are large anyway. [1] http://bytepointer.com/resources/pietrek_libctiny_1996.htm http://bytepointer.com/resources/pietrek_libctiny_1996.htm [2] https://www.benshoof.org/blog/minicrt https://www.benshoof.org/blog/minicrt

kazinator 3y ago

C doesn't leverage the free run time of the OS, when that OS is Windows. Your hello.exe size has to include the run-time DLL's required for it from the C implementation that was used to build it. Windows has only recently been moving toward providing a public run-time for C; the "Universal C Run-Time" (UCRT) that has been introduced in Windows 10.

ChrisSD 3y ago
The ucrt is included as far back as Windows 7 (if you install updates).
- kazinator 3y ago
  The increment in disk space usage caused by the update has to count toward the effective size of the hello program, experienced by the user of that installation.
ziml77 3y ago
For some reason, even with the UCRT, binaries seem overly bloated. I've been toying with Zig over the past couple weeks and I really like that it doesn't rely on a C runtime on Windows. Plus it makes it easy to operate entirely with UTF-16 strings, which is a nice to have when I'm writing a utility that is specific to Windows.
mananaysiempre 3y ago
> C doesn't leverage the free run time of the OS, when that OS is Windows. Stdio, no. Printf, no (unless you’re an adherent of LIBCTINY[1] or one of its descendants[2] and need only a minimal set of features). Malloc, yes—MSVC’s malloc() on Win32 has always been a thin wrapper around kernel32!HeapAlloc. Strlen or memcpy or whatnot—also possibly yes, but it’s not like minimal implementations of those are large anyway. [1] http://bytepointer.com/resources/pietrek_libctiny_1996.htm http://bytepointer.com/resources/pietrek_libctiny_1996.htm [2] https://www.benshoof.org/blog/minicrt https://www.benshoof.org/blog/minicrt