On a related note -- when I see the minuscule filesize of the original Zelda game on emulators, I marvel at how little text/code/information could produce how much wonder, how far-reaching impact, and how many hours of enchantment for me.
Indeed, magic. How about the Commodore 64, there was a game (Eindeloos, Radarsoft, 1985) within 64kb that has a huge map. Someone recently (after 40 years!) extracted the map (500 screens) and the png alone is 800kb. See the story an zoom in and try finding the little heart in the map!
https://adayinthelifeof.nl/2025/03/07/endless.html
Elite on the BBC Micro - which had 32kB of RAM, a huge chunk of which was required for the screen - managed to have eight galaxies with 256 distinct planets each.
Everything about them was procedurally generated, even the names, which required some clever code to ensure none of them used rude words.
> which had 32kB of RAM, a huge chunk of which was required for the screen
People assume 10KB, with the BBC Micro¹² version's version using a mix of modes 4 & 5 (320×256×1bbp and 160×256×2bbp respectively), but as well as the split screen trickery they tweaked the graphics hardware in more detail than that to create custom modes. There were only 248 scanlines and either 256 or 128 pixels per line, so the display took 7.75KB. As well as leaving more memory for the rest of the code, this reduced the amount being drawn, so helped keep the draw speed acceptable.
This left about 24KB⁴ for the rest of the code and its working data. Still a very impressive feat!
> - managed to have eight galaxies with 256 distinct planets each.
IIRC it was originally going to be larger than that, they toned it down a bit but not due to technical limitations (the galaxy generator code would not have needed to be any larger).
--------
[1] The Electron lacked support that allowed the split screen to work (one of the chips removed meant the required timing signal wasn't available), so it was all monochrome though still with the custom resolution and taking 7.75KB.
[2] The version enhanced for the Master series use a mix of mode 1 and mode 2 to enable more colours, 2bbp for the view of space and 4bbp³ for the dashboard. This still used the custom resolution, so took 15.5KB rather than 20KB. This was achieved by using the shadow RAM bank to host the screen display (some programs instead used this feature to implement double-buffering for smoother screen drawing), allowing the screen to take twice as much space while also freeing up memory to hold things that would have been loaded from disc when needed⁵ in the Micro version.
[3] Actually effectively 3bbp as the BBC hardware did 8 colours and flashing variants instead of 16 colours (which most other systems used to provide two shades of 8 colours, using the 4th bit as an intensity flag).
[4] less a few chunks here & there needed by code in system ROMs when doing things like reading extra data from the floppy
[5] There were two chunks of code, one for in-flight and one for while docked, that were swapped in as you entered or left a space station. On the Micro these were pulled from disk each time, on the Master they could both be in RAM. If playing from cassette you had a cut-down version of the game that didn't need this split.
Perhaps not compression as we see it today. But one could argue that tile based graphics and code based music is a form of compression. Old games used a myriad of cool tricks to get around their limitations.
Modern coders will probably never experience the fun of rewriting the same thing endlessly only to discover how good some early version really was. Then some time after giving up someone else would make a similar thing go 20 times faster.
I should have worded that better, I meant no UPX-style end-to-end compression like the OPs project used. NES games had to be much more judicious than that since there wasn't nearly enough RAM to decompress everything at once.
That honestly doesn't seem too bad. Zelda 1 is relatively large but it reuses a lot of assets and honestly probably doesn't have that much text. (More than a Mario but way less than a Dragon Warrior.)
AFAIR tho im not sure its even 128k, I think disk cards themselves are more like 110k and even then FDS Zelda had separate sides mostly for main menu and saves.
My favorite slight of hand was that all the dungeons and caves were part of a single rectangular map. Designers carved out a few specific designs, then other levels were clearly what worked with the remaining map screens available so it all fit in the space they had, with caves thrown in to take up single screen gaps.
What I think is really great about The Legend of Zelda is that Breath of the Wild is very clearly a more fully realized version of the same core vision that guided the design of the original game thirty years earlier.
I extracted the linux executable and was surprised to find that both readelf and objdump choke on it despite it loading and running correctly. Some investigation reveals that the name of the dynamic linker was shoved into the "unused" fields in the PT_DYNAMIC header entry to save space:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
INTERP 0x0000000000000088 0x0000000000010088 0x0000000000010088
0x000000000000001c 0x000000000000001c 0x0
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
DYNAMIC 0x00000000000000e0 0x00000000000100e0 0x6c2f343662696c2f <-- "/lib64/ld-linux-x86-64.so.2"
0x2d78756e696c2d64 0x732e34362d363878 0x322e6f
readelf: Error: the dynamic segment offset + size exceeds the size of the file
LOAD 0x0000000000000000 0x0000000000010000 0x0000000000000000
0x0000000000001dc0 0x0000000000005660 RWE 0x1000
Two questions:
1. Was this done manually or is there a tool you're using which does this? I see other size-reduction tricks in here as well.
2. Does anybody know of a tool for examining executables which doesn't crap out on binaries like this?
In short: Compilers don't help l, but with a good macro assembler it is quite convenient. Maybe the author used custom tooling but the assembler route is the easiest if you only need this once or a couple of times.
To the second question, reverse engineering software like IDA Pro or Binary Ninja are not only made for strange and broken binaries but often used for binaries with deliberate anti-reversing measures. They are as good as it gets when it comes to not choking on unusual binaries.
ndisasm can help read it and hex editor. no tools should mangle such format, its useless savings, worth nothing. it will cause problem with AV and other things potentially.
saw some comments about DEP on windows and this and honestly i wouldnt touch this thing with a 10ft stick. if the creator want ppl to play it they can provide a normal binary. not some obfuscated mess.
This is a slippery slope. I could agree if the OS would load it. Maybe the OS shouldn't load it.
But as long as it is good enough for the OS it should be good for the malware scanner as long as it is not real malware. If we start punishing everything that deviates just a little bit from the norm we will end in no good place.
tools output validly formatted files for a reason. there is not really a good reason to mess with headers etc. , the savings are so tiny its only fun for obfuscation or tiny binary contests...
imagine, this linker name string.. its few bytes from 13K bytes. does nothing useful.
a lot of parsers of file formats do ignore most fields as do linkers/loaders. AV engines look a little more at it and might trigger on anomalies simply because its indicative of tampering (not neccesarily malicious).
deviating from the norm is fine as long as its grounded in a good reason, and clearly explained. simply pushing some weirdly formatted binary without any explanation, thats not very strategical in today's landscape of messed up binaries and threats. - just my 2 cents ofc.. im not an authority on the matter :p
Since the program opens a window I wanted to see what the dependencies were, but neither readelf nor objdump can display the contents of the dynamic section despite ld.so correctly finding and parsing it. readelf spits out the error that you can see in my post above, while objdump complains about section alignment and otherwise doesn't say anything helpful at all.
- Linux: "./snake.com: line 20: lzma: command not found". Installing the xz package makes it work (already had XWayland enabled so X11 worked, but may be needed if you have a strict Wayland session).
- Windows: As either .com or renaming to .exe I get "The application was unable to start correctly (0xc0000005). Click OK to close the application." Not sure how to make this one work, it's definitely not AV related though (I have that stripped in this sandbox VM).
Edit: Got it working in all 3 now. On Windows I still had DEP enabled on all programs to test some apps earlier, turning that back off allowed it to launch.
Hmm, Windows 11 25H2 here as well. Redbean works so there must be something about this particular approach combined with some unknown setting on my install.
If you mean lzma it wasn't immediately apparent to me it was a binary requirement, but inspecting the hex dump at the end + the message is how I figured out it was. I wonder how much space you lose dropping lzma and doing some other method as "tail -c+4294 $0|head -c 5061|lzma -dc>/tmp/a;chmod +x /tmp/a;(/tmp/a&rm /tmp/a);exit" would be more universal and the linux portion isn't all that big.
If you mean the .html rename or whatever my Windows problem was, I must be missing it. Edit: Windows was DEP.
Not out of the box, though. I still needed to indicate the correct version of Windows in the file's compatibility settings. Windows XP SP3 worked like a charm.
The fun part is that it's actually 3 executables in a single file. Meaning there is no particular reason it should have the same program on each platform.
I think you can use something similar to get the entire page contents as a blob, but I never tested with binary data in actual browsers. Perhaps even patch it to avoid the initial windows error.
I love the idea of applications which exist in one file which you can run anywhere. I've been working towards this with my serverless platform; you can build complex data-driven apps with just one .html file and mostly declarative HTML markup (thanks to web-components which are loaded from a remote server). With modern browser features, you don't need a bundling system. Once you do away with it; a whole universe is opened up.
The ability to load .html files over the file:// protocol is a powerful, often neglected feature. In practice, it means you can double-click an HTML file and it runs an app in your browser instantly.
> I implemented the game three times in total: once in C for the i686 Visual C platform using WinAPI, once in C for the x86_64 Linux platform using clang and X11, and once in JavaScript for the browser using HTML5 Canvas.
The OP actually wrote two native applications instead of just instantiating a browser.
Now I wonder when the first polyglot file was published. I kinda just assumed they'd been around forever. EICAR.COM comes to mind as a COM/plaintext polyglot
i wonder if such a mechanism could be "enhanced" to produce a true "universal" binary, using a source-to-source compiled language like Haxe?
With Haxe, you can write the application once, target both win32 and linux by compiling to C++ (which then you compile using the platform specific tooling for each paltform), and then target html by compiling to javascript. Then use the same concatenation mechanism and header abuse as described in the article to have all three targets merged into one file that can then be run on all platforms!
Semi-related: Windows EXE files are runnable in DOS (at least when DOS was a thing, so for Windows 3.1x or 9x), but most of the time the DOS part just prints "This program requires Microsoft Windows." and exits. An exception is regedit.exe, that one can use to import registry values even in DOS. (Huh, although, how does it do that without using Windows API?)
> Huh, although, how does it do that without using Windows API?
without knowing anything, i am going to guess that they could either directly import the same code that the windows api uses (either via knowing where the implementation code resides and load that), or even statically link the library! After all, regedit doesn't need to obey cleanliness rules that other non-first-party programs would need to - presumably, because if those registry editing api/format changes, regedit would get updated along with it!
This might have changed at some point. I was curious about the latter part of your question on how it made changes without the Windows API (I assumed it used an older DOS API), but my `regedit.exe` _does_ have the `This program cannot be run in DOS mode.` DOS stub in it.
> The HTML version is also packed and abuses the fact that browsers will happily process all the benign garbage at the start of the file before reaching the actual HTML content.
Long live RCE.
The thing looks interesting. Very close to a virus. Can it be used to make and spread a virus ?
What entertains me most is that the thing contains three independent implementations of a graphics-based game, strung together, wrapped into a crafty multiplatform loader... and it all still takes 13 kiB.
sure but they have a blog and a webserver that's serving html. just put the .html version there so i dont have to download anything or mess about too much. just want to click and see it
On a related note -- when I see the minuscule filesize of the original Zelda game on emulators, I marvel at how little text/code/information could produce how much wonder, how far-reaching impact, and how many hours of enchantment for me.
https://en.wikipedia.org/wiki/The_Legend_of_Zelda_(video_gam...
Indeed, magic. How about the Commodore 64, there was a game (Eindeloos, Radarsoft, 1985) within 64kb that has a huge map. Someone recently (after 40 years!) extracted the map (500 screens) and the png alone is 800kb. See the story an zoom in and try finding the little heart in the map! https://adayinthelifeof.nl/2025/03/07/endless.html
Elite on the BBC Micro - which had 32kB of RAM, a huge chunk of which was required for the screen - managed to have eight galaxies with 256 distinct planets each.
Everything about them was procedurally generated, even the names, which required some clever code to ensure none of them used rude words.
> which had 32kB of RAM, a huge chunk of which was required for the screen
People assume 10KB, with the BBC Micro¹² version's version using a mix of modes 4 & 5 (320×256×1bbp and 160×256×2bbp respectively), but as well as the split screen trickery they tweaked the graphics hardware in more detail than that to create custom modes. There were only 248 scanlines and either 256 or 128 pixels per line, so the display took 7.75KB. As well as leaving more memory for the rest of the code, this reduced the amount being drawn, so helped keep the draw speed acceptable.
This left about 24KB⁴ for the rest of the code and its working data. Still a very impressive feat!
> - managed to have eight galaxies with 256 distinct planets each.
IIRC it was originally going to be larger than that, they toned it down a bit but not due to technical limitations (the galaxy generator code would not have needed to be any larger).
--------
[1] The Electron lacked support that allowed the split screen to work (one of the chips removed meant the required timing signal wasn't available), so it was all monochrome though still with the custom resolution and taking 7.75KB.
[2] The version enhanced for the Master series use a mix of mode 1 and mode 2 to enable more colours, 2bbp for the view of space and 4bbp³ for the dashboard. This still used the custom resolution, so took 15.5KB rather than 20KB. This was achieved by using the shadow RAM bank to host the screen display (some programs instead used this feature to implement double-buffering for smoother screen drawing), allowing the screen to take twice as much space while also freeing up memory to hold things that would have been loaded from disc when needed⁵ in the Micro version.
[3] Actually effectively 3bbp as the BBC hardware did 8 colours and flashing variants instead of 16 colours (which most other systems used to provide two shades of 8 colours, using the 4th bit as an intensity flag).
[4] less a few chunks here & there needed by code in system ROMs when doing things like reading extra data from the floppy
[5] There were two chunks of code, one for in-flight and one for while docked, that were swapped in as you entered or left a space station. On the Micro these were pulled from disk each time, on the Master they could both be in RAM. If playing from cassette you had a cut-down version of the game that didn't need this split.
that is a legitimate post by itself
Zelda 1 was 128 kB, for those wondering, and that's without any compression. Double that for the sequel.
> without any compression
Perhaps not compression as we see it today. But one could argue that tile based graphics and code based music is a form of compression. Old games used a myriad of cool tricks to get around their limitations.
Modern coders will probably never experience the fun of rewriting the same thing endlessly only to discover how good some early version really was. Then some time after giving up someone else would make a similar thing go 20 times faster.
Zelda 1 has TONS of built-in compression, and it's own decompression routines.
I should have worded that better, I meant no UPX-style end-to-end compression like the OPs project used. NES games had to be much more judicious than that since there wasn't nearly enough RAM to decompress everything at once.
Yep. Each screen is just a list of prebuilt columns reused over and over. Then they used a form of crude RLE on the lists.
That honestly doesn't seem too bad. Zelda 1 is relatively large but it reuses a lot of assets and honestly probably doesn't have that much text. (More than a Mario but way less than a Dragon Warrior.)
AFAIR tho im not sure its even 128k, I think disk cards themselves are more like 110k and even then FDS Zelda had separate sides mostly for main menu and saves.
IOW might have been able to fit in 96Kb or less.
My favorite slight of hand was that all the dungeons and caves were part of a single rectangular map. Designers carved out a few specific designs, then other levels were clearly what worked with the remaining map screens available so it all fit in the space they had, with caves thrown in to take up single screen gaps.
https://ian-albert.com/games/legend_of_zelda_maps/
And created them in somewhat recognizable shapes, e.g. eagle
What I think is really great about The Legend of Zelda is that Breath of the Wild is very clearly a more fully realized version of the same core vision that guided the design of the original game thirty years earlier.
Heck Chrono Trigger on the Super Nintendo is 4 MiB! A lot is possible if you have to fit your game in a tiny space.
I extracted the linux executable and was surprised to find that both readelf and objdump choke on it despite it loading and running correctly. Some investigation reveals that the name of the dynamic linker was shoved into the "unused" fields in the PT_DYNAMIC header entry to save space:
Two questions:1. Was this done manually or is there a tool you're using which does this? I see other size-reduction tricks in here as well.
2. Does anybody know of a tool for examining executables which doesn't crap out on binaries like this?
The famous
"A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux"
tutorial has some good answers for you.
https://www.muppetlabs.com/~breadbox/software/tiny/teensy.ht...
In short: Compilers don't help l, but with a good macro assembler it is quite convenient. Maybe the author used custom tooling but the assembler route is the easiest if you only need this once or a couple of times.
To the second question, reverse engineering software like IDA Pro or Binary Ninja are not only made for strange and broken binaries but often used for binaries with deliberate anti-reversing measures. They are as good as it gets when it comes to not choking on unusual binaries.
EDIT: Forgot to mention Ghidra.
ndisasm can help read it and hex editor. no tools should mangle such format, its useless savings, worth nothing. it will cause problem with AV and other things potentially.
saw some comments about DEP on windows and this and honestly i wouldnt touch this thing with a 10ft stick. if the creator want ppl to play it they can provide a normal binary. not some obfuscated mess.
This is a slippery slope. I could agree if the OS would load it. Maybe the OS shouldn't load it.
But as long as it is good enough for the OS it should be good for the malware scanner as long as it is not real malware. If we start punishing everything that deviates just a little bit from the norm we will end in no good place.
tools output validly formatted files for a reason. there is not really a good reason to mess with headers etc. , the savings are so tiny its only fun for obfuscation or tiny binary contests...
imagine, this linker name string.. its few bytes from 13K bytes. does nothing useful.
a lot of parsers of file formats do ignore most fields as do linkers/loaders. AV engines look a little more at it and might trigger on anomalies simply because its indicative of tampering (not neccesarily malicious).
deviating from the norm is fine as long as its grounded in a good reason, and clearly explained. simply pushing some weirdly formatted binary without any explanation, thats not very strategical in today's landscape of messed up binaries and threats. - just my 2 cents ofc.. im not an authority on the matter :p
Choke how? Both work fine here
Since the program opens a window I wanted to see what the dependencies were, but neither readelf nor objdump can display the contents of the dynamic section despite ld.so correctly finding and parsing it. readelf spits out the error that you can see in my post above, while objdump complains about section alignment and otherwise doesn't say anything helpful at all.
For me:
- Browser: works after renaming to .html
- Linux: "./snake.com: line 20: lzma: command not found". Installing the xz package makes it work (already had XWayland enabled so X11 worked, but may be needed if you have a strict Wayland session).
- Windows: As either .com or renaming to .exe I get "The application was unable to start correctly (0xc0000005). Click OK to close the application." Not sure how to make this one work, it's definitely not AV related though (I have that stripped in this sandbox VM).
Edit: Got it working in all 3 now. On Windows I still had DEP enabled on all programs to test some apps earlier, turning that back off allowed it to launch.
Works for me on Windows 11
Hmm, Windows 11 25H2 here as well. Redbean works so there must be something about this particular approach combined with some unknown setting on my install.
Edit: Got it working, was DEP.
What's DEP?
Data Execution Prevention https://learn.microsoft.com/en-us/windows/win32/memory/data-...
its written in the post
If you mean lzma it wasn't immediately apparent to me it was a binary requirement, but inspecting the hex dump at the end + the message is how I figured out it was. I wonder how much space you lose dropping lzma and doing some other method as "tail -c+4294 $0|head -c 5061|lzma -dc>/tmp/a;chmod +x /tmp/a;(/tmp/a&rm /tmp/a);exit" would be more universal and the linux portion isn't all that big.
If you mean the .html rename or whatever my Windows problem was, I must be missing it. Edit: Windows was DEP.
If I ran it with just
... then it would try to use Mono to launch it: But, running it explicitly with Bash works: Pretty nifty but doesn't work out of the box on any Linux, at least :p Running Debian 13.> ... then it would try to use Mono to launch it:
That's because of the binfmt handler that Mono installs which matches the PE header.
Cosmopolitan libc binaries require a little extra config to work around the defaults most distros set for binfmt: https://justine.lol/apeloader/
Not cross-platform, but I'm reminded of the kkrieger game for Windows which was a 96k FPS game that looked visually impressive for the time.
https://web.archive.org/web/20100304155706/http://www.thepro...
> kkrieger
Related discussions:
https://news.ycombinator.com/item?id=14409210 (2017)
https://news.ycombinator.com/item?id=37383894 (2023)
https://news.ycombinator.com/item?id=41269079 (2024)
From that link: Still works on modern PCs! Was able to DL and launch.
The source code is available as well: https://github.com/jaromil/kkrieger-werkkzeug3
Not out of the box, though. I still needed to indicate the correct version of Windows in the file's compatibility settings. Windows XP SP3 worked like a charm.
if it worked on a pentium iii, it should work on a phone with webgl. who's going to port it?
I've been reminded of this while playing Metroid Prime 4.
I wonder what kinds of modern games we could make with these same ideas.
The fun part is that it's actually 3 executables in a single file. Meaning there is no particular reason it should have the same program on each platform.
It would be a lot cooler if the three could share code/assets somehow, bringing the package size down further.
Quite cool.
You could distribute it as `.html` only, and use JS to offer a local download link to itself in the correct extension. A polyglot installer, of sorts.
For example, this gist is an HTML that, when opened, offers a download zip of its DOM in whatever state it currently is:
https://gist.github.com/alganet/c904acb57282402fc0bd724f1eeb...
I think you can use something similar to get the entire page contents as a blob, but I never tested with binary data in actual browsers. Perhaps even patch it to avoid the initial windows error.
I love the idea of applications which exist in one file which you can run anywhere. I've been working towards this with my serverless platform; you can build complex data-driven apps with just one .html file and mostly declarative HTML markup (thanks to web-components which are loaded from a remote server). With modern browser features, you don't need a bundling system. Once you do away with it; a whole universe is opened up.
The ability to load .html files over the file:// protocol is a powerful, often neglected feature. In practice, it means you can double-click an HTML file and it runs an app in your browser instantly.
Sadly a lot of browser features are inaccessible from non-https contexts.
Don't most (all?) browsers consider file:// and localhost to be secure for the sake of enabling those features?
https://developer.mozilla.org/en-US/docs/Web/Security/Defens...
Unfortunately, no. CORS will block this on Chrome and Firefox.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...
The security risk : https://www.mozilla.org/en-US/security/advisories/mfsa2019-2...
You need a local webserver. Or bundle everything in one html file.
So that's why I have to keep booting a Windows 7 computer in order to use an html file I saved 10+ years ago? Some dumb shit android app.
or you could use something like caddy (https reverse-proxy, local cert), and have a dedicated ws running in the background that serves your files
> I implemented the game three times in total: once in C for the i686 Visual C platform using WinAPI, once in C for the x86_64 Linux platform using clang and X11, and once in JavaScript for the browser using HTML5 Canvas.
The OP actually wrote two native applications instead of just instantiating a browser.
How are you approaching the development of your single file html apps, is there any examples publicly available, sounds very interesting.
One of the interesting things about Polyglot is that nobody did it any sooner. It would have been feasible a decade ago or two ago.
Now I wonder when the first polyglot file was published. I kinda just assumed they'd been around forever. EICAR.COM comes to mind as a COM/plaintext polyglot
i wonder if such a mechanism could be "enhanced" to produce a true "universal" binary, using a source-to-source compiled language like Haxe?
With Haxe, you can write the application once, target both win32 and linux by compiling to C++ (which then you compile using the platform specific tooling for each paltform), and then target html by compiling to javascript. Then use the same concatenation mechanism and header abuse as described in the article to have all three targets merged into one file that can then be run on all platforms!
[dead]
Semi-related: Windows EXE files are runnable in DOS (at least when DOS was a thing, so for Windows 3.1x or 9x), but most of the time the DOS part just prints "This program requires Microsoft Windows." and exits. An exception is regedit.exe, that one can use to import registry values even in DOS. (Huh, although, how does it do that without using Windows API?)
> Huh, although, how does it do that without using Windows API?
without knowing anything, i am going to guess that they could either directly import the same code that the windows api uses (either via knowing where the implementation code resides and load that), or even statically link the library! After all, regedit doesn't need to obey cleanliness rules that other non-first-party programs would need to - presumably, because if those registry editing api/format changes, regedit would get updated along with it!
> An exception is regedit.exe
This might have changed at some point. I was curious about the latter part of your question on how it made changes without the Windows API (I assumed it used an older DOS API), but my `regedit.exe` _does_ have the `This program cannot be run in DOS mode.` DOS stub in it.
https://js13kgames.com/
> The HTML version is also packed and abuses the fact that browsers will happily process all the benign garbage at the start of the file before reaching the actual HTML content.
Long live RCE. The thing looks interesting. Very close to a virus. Can it be used to make and spread a virus ?
What entertains me most is that the thing contains three independent implementations of a graphics-based game, strung together, wrapped into a crafty multiplatform loader... and it all still takes 13 kiB.
Always Kamila! Her standing is higher than Fabrice Bellard for me. Because you can actually talk to her.
You don't need to rename it to an html file, just serve it with with the following header:
Content-Type: text/html
Any way to run that on a Mac (besides running it in the browser)?
Wonder why they don't give a demo/link to the browser version
It's the same file, you just rename it to end in '.html'
sure but they have a blog and a webserver that's serving html. just put the .html version there so i dont have to download anything or mess about too much. just want to click and see it
The binary relies on the runtime, so yes it is nice.
Forma instance, a static compiled and linked "hello world" in C on Linux is around ~785KB
> a static compiled and linked "hello world" in C on Linux is around ~785KB
Huh?
And if that's not enoughProbably 785k unoptimized and unstripped with all debug info.
I'm sure that number is using glibc, not musl.
That's just because glibc is not designed for static linking. It works, but it doesn't exclude unused code, unlike with other libcs.
It does exclude unused code. But glibc has too many inter-object-file dependencies, so too much code gets used.
I refreshed until a got a room with 2 lemons and they both disappeared after 3 steps. What a rip
Also will this even run without /tmp?
Reminds me of the Cosmopolitan project: https://github.com/jart/cosmopolitan
That was mentioned at the top of the blog post.
I have to start reading from the top instead of skimming.
Very clever!
flagged as virus
[dead]
[flagged]
I sincerely hope this type of comment isn't going to become commonplace in the future. Especially when it's someone's hobby project or labour of love.
No
[flagged]