Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The 6502 programmer in me is dying inside that 278kb now passes as lightweight.


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.


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.


> 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


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


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.


Oh! I arrived late...


They used mingw, read TFA


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.


A lot of it is due to the platform and executable format. Things can be much more lightweight when there's no information for stack traces, no dynamic linking infrastructure, no exception handling tables (necessary even in C in case exceptions traverse a c function,) etc.


no dynamic linking infrastructure

You get that for free on Windows.

no exception handling tables (necessary even in C in case exceptions traverse a c function,

Not necessary if you're using pure C. SEH is rarely necessary either.


Maybe we could petition the demo scene competitions to have a '64kb TODO app' category.


I’m surprised it’s that big to be honest. I was expecting it to be smaller or half the size to be taken by some app icon. I remember writing this kind of stuff back in the days and it was smaller.

Is it due to MinGw maybe?


This reminds me of the days when all of a sudden win32 programming in assembly became hip enough, probably as a response to the increasing size of shareware downloads ('twas the dark time of MFC).

Combined with early Palm Pilot 68k programming, those were the last hurrahs of non-retrocomputing asm I can remember.


6502? Luxury! In my times you were lucky to have a processor.


A processor? Luuuxury! In my time we worked twenty-six hours a day, did all the calculations with pen and paper and would be thrilled to use an abacus!


Ah, back in my early existence, we didn't have time and all these superficial dimensions. Ontological creation out of nothing was all one needed, but it looks like it's all lost art now.


Atrus? is that you?


you had paper? We had to use sand and sticks!


Btw. I love how you people refer to this sketch so seamlessly!


Hehe :) Okey.. I have sth easier to write.. but smaller:

15kB quickrun.exe :) C, pure Win32 API.. No hacks to shrink binary, Mingw32 compiler.

Its GUI app to quickly launch any application via alias.


I'm spending some time this evening debugging a failure I have with an emulator I've written - it emulates a system running a Z80 processor with 64k of RAM.

Sometimes I too take a step back and look at the way things have changed. But then again we've made a lot of progress for the size-changes I guess.


I remember being thunderstruck in early 1990-something upon seeing that Nethack compiled to a 900kb+ executable.


For some reason it's built with GCC instead of using MSVC, and there are no optimizations enabled (for speed or size).


it's about ABI, also 8bit << ... << 64bit architecture. Every pointer is 8 times longer. Don't complain, just admire. It's an art.


That barely fits on a 5 1/4” floppy!


try to open "new" calculator on win10/win11. It's like loading another operating system... useless.


Probably JIT-ing? Compiled against native should make startup instant. No idea how they compile these.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: