[abbeyj]

I tried to reproduce this binary to see what the 278 KB was being taken up by. The first obstacle that I ran into was that the build.bat file doesn't work if you have git configured to use core.autocrlf=false. Changing that to core.autocrlf=true and recloning was sufficient to get me building.

I'm using x86_64-15.1.0-release-win32-seh-msvcrt-rt_v12-rev0.7z from https://github.com/niXman/mingw-builds-binaries/releases/tag... as the toolchain. This produces a 102 KB .exe file. Right off the bat we are doing much better than the claimed 278 KB. Maybe the author is using a different toolchain or different settings? Exact steps to reproduce would be welcome.

We can improve this by passing some switches to GCC.

    gcc -Os => 100 KB
    gcc -Oz => 99 KB
    gcc -flto => 101 KB
    gcc -s => 51 KB
    gcc -s -Oz -flto => 47 KB

If all you are interested in is a small .exe size, there is plenty of room for improvement here.

[azhenley]

If you had a blog or YouTube channel where you just went around to open source projects optimizing them down, I’d be very interested.

[jedimastert]

> Maybe the author is using a different toolchain or different settings?

I wonder if they are compiling with debugging symbols? I don't know how much this would change things in vanilla C but that would be my first guess

[tecleandor]

I think there's a typo somewhere. The repo and the release says 27KB (not 278).

[debugnik]

The v0.1 release from yesterday, at the time of posting, was 278 KB. The latest release, v0.3 from 9 hours ago, adds -Os -s and UPX to compress down to 27 KB.

[tecleandor]

Oh! I arrived late...

[tomalbrc]

They used mingw, read TFA

[abbeyj]

I also used mingw and yet I arrived at different results. Maybe it was a different version, or a different distro of MinGW, or a 32-bit vs. 64-bit issue, or I'm linking against a different CRT. Without details from OP, we can't really tell.