4 ms·

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

nottorp 1y ago
Maybe we could petition the demo scene competitions to have a '64kb TODO app' category.
Borg3 1y ago
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.
jcelerier 1y ago
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.
- userbinator 1y ago
  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.
kgabis 1y ago
6502? Luxury! In my times you were lucky to have a processor.
- pineaux 1y ago
  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!
  - psychoslave 1y ago
    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.
    - deleted 1y ago
      [deleted]
    - sterlind 1y ago
      Atrus? is that you?
  - deleted 1y ago
    [deleted]
  - p0w3n3d 1y ago
    you had paper? We had to use sand and sticks!
  - p0w3n3d 1y ago
    Btw. I love how you people refer to this sketch so seamlessly!
    - deleted 1y ago
      [deleted]
mhd 1y ago
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.
deleted 1y ago
[deleted]
deleted 1y ago
[deleted]
tonyarkles 1y ago
That barely fits on a 5 1/4” floppy!
deleted 1y ago
[deleted]
stevekemp 1y ago
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.
jackjeff 1y ago
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?
p0w3n3d 1y ago
it's about ABI, also 8bit << ... << 64bit architecture. Every pointer is 8 times longer. Don't complain, just admire. It's an art.
abbeyj 1y ago
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/15.1.0-rt_v12-rev0 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.
- jedimastert 1y ago
  > 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
- azhenley 1y ago
  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.
- tomalbrc 1y ago
  They used mingw, read TFA
  - abbeyj 1y ago
    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.
  - deleted 1y ago
webprofusion 1y ago
For some reason it's built with GCC instead of using MSVC, and there are no optimizations enabled (for speed or size).
fx1994 1y ago
try to open "new" calculator on win10/win11. It's like loading another operating system... useless.
- alternatex 1y ago
  Probably JIT-ing? Compiled against native should make startup instant. No idea how they compile these.
kazinator 1y ago
I remember being thunderstruck in early 1990-something upon seeing that Nethack compiled to a 900kb+ executable.

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

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.

jcelerier 1y ago

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.

userbinator 1y ago
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.

kgabis 1y ago

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

pineaux 1y ago
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!
- psychoslave 1y ago
  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.
  - deleted 1y ago
    [deleted]
  - sterlind 1y ago
    Atrus? is that you?
- deleted 1y ago
  [deleted]
- p0w3n3d 1y ago
  you had paper? We had to use sand and sticks!
- p0w3n3d 1y ago
  Btw. I love how you people refer to this sketch so seamlessly!
  - deleted 1y ago
    [deleted]

mhd 1y ago

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.

deleted 1y ago

[deleted]

deleted 1y ago

[deleted]

tonyarkles 1y ago

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

deleted 1y ago

[deleted]

stevekemp 1y ago

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.

jackjeff 1y ago

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?

p0w3n3d 1y ago

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

abbeyj 1y ago

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/15.1.0-rt_v12-rev0 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.

jedimastert 1y ago
> 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
azhenley 1y ago
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.
tomalbrc 1y ago
They used mingw, read TFA
- abbeyj 1y ago
  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.
- deleted 1y ago

webprofusion 1y ago

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

fx1994 1y ago

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

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

kazinator 1y ago

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