105 karma · joined June 15, 2026
Since the low-level Windows kernel API is undocumented and non-public, using these system DLLs is your only option on Windows.
It's just like linking against libc.so on any POSIX systems.
That's probably because there's a bug in the linker, which puts uninitialized variables in the data segment instead of bss. This means unlike the bare metal variant, the Windows executable is full of zeros.
This is a well known bug (see https://github.com/msys2/MINGW-packages/issues/18612 for example) which also affects my projects: https://gitlab.com/bztsrc/skandi The Linux CLI version is 216K, the Windows CLI version is 5.4M and the only difference is the lack of bss.
Besides UEFI, it has a Windows GDI port, but if it were FOSS one could add SDL backend for example and then one could compile it for Linux and Webassembly as well.
Yes. The UEFI Simple Filesystem Protocol is transparent to the UEFI app. The protocol gives you open/read/write/close calls, without needing to know the underlying fs.
Then I've created an engine in it to create very similar text-based adventure games like this one. I've also used a similar low-level language to describe the game logic. Later I've ported the engine into a native app (Win, Linux, WASM) with more features, like point'n'click interface (the bytecode remained backward compatible, it can play games created with the fantasy console).
https://gitlab.com/bztsrc/meg4_advgame
As a demonstration, I've ported a classic C= 64 game, you can try it out here (runs in the browser too). This game was a pretty big deal in my country in the '80s, and its creator was legendary.
https://bztsrc.gitlab.io/meg4_advgame/idoregesz.html
The description of the language, the bytecode, and the engine et al can be found here https://bztsrc.gitlab.io/meg4_advgame/ for those who are interested. The C= 64 game's source also available in the repo.
Full disclosure: my solution is 100% AI-free.
Nothing. This is for those who already understand the benefit of shrinking images and animations using indexed palettes, and just looking for a tool to do it.
> I'm not sure how to trigger the recolorize method
You can't, that's not part of the tool. You need to implement it in your app that displays such images. That's the whole point.
To see recolorization in action, check out one of my other projects here: https://bztsrc.gitlab.io/ludchr/ (select the icons on the right, if a layer has color options, you'll see a pop-up menu with the color variants, clicking on a color will recolorize the layer on-the-fly)
> Also, they show a strange pallete. I'd prefer a version that shows
That's exactly what the image shows.
First figure: original image minus the palette equals decolorized image.
Second figure: decolorized image plus palette equals multiple colorized outputs.
The palette can be provided in many formats, but the palette on these figures is the actual palette image I've used with paltool. It is an image of 8 x 4 pixels, so it has 4 different gradients. Out of the 8 possible colors in each gradient only 6 used in the example, so the last 2 colors were replaced with a checkerboard on the preview (in the actual palette image these are fully transparent).
> A few years ago, my wife wanted a few gif or animals with different colors. I used gimp to find the correct entry in the pallete and then I changed the value of that entry in the pallete directly in the files.
That's exactly what decolorization and recolorization is for. I needed this for the ludchr project above.
> Can your program find the optimal pallete?
No such thing exists, except for pixel art maybe.
My program uses multiple methods, calculates scores for each (depending on the distance to the original) and picks the one with the best score. Otherwise it is built around the libimagequant library. https://github.com/ImageOptim/libimagequant
The palette might contain fixed colors, and free slots are filled with quantized colors from the image. If the image has no more different colors than the specified maximum, then yes, the palette will be optimal, otherwise you must make peace with some information loss.
> A long time ago I had to transform a color 256^3 image to a 256 colors image. IIRC I used gimp and paint and perhaps a few more programs. But the palette choice was bad and caused too many quirks.
Yes, that's exactly why I've created this tool. I was also struggling with GIMP (unable to handle alpha channel in palettes) and Imagemagick (unable to handle animated PNGs).
My tool does not reinvent the wheel, it just provides an easy to use interface (CLI as well as a free web-service) around already existing and known to work methods.
Thank you for your kind advice. But the thing is, I'm not a blogger guy, I've never ever written any blog in my life. If you take a look at my repos, you'll see my focus is on writing code.
Also I honestly don't know what to write.
I've always though that speeding up page load by shrinking images into indexed images is a common knowledge (smaller page = faster page), never occurred to me this needs explaining. I mean, there are already lots of tools for that (tinypng dot com, ImageMagick, pngquant, etc.), it's just neither can handle APNGs, much less animated WebP, so here's paltool to save the day.
As for the algorithms, all I've used (weighted color distance and median cut) has a loooong literature, explaining these much better than I could. I did not invent any of it, these are standard image processing algorithms, although I've used some tricks for better performance and some heuristics to increase output quality.
Do you have any source? I'm not french and all I can hear from the news is that France's nuclear electricity is cheap, for example:
https://thenextweb.com/news/france-energy-advantage-ai-data-...
Now I'm curious what the truth is. Are these articles just fake-news trying to ride the AI wave? (not suggesting, just asking)
Definitely not. That page is the web service. And if you meant the HN post, that's no place for long explanations either, imho.
The info you seek is in the README of the repo, where it belongs.
For example, you can say, take a true-color animated WebP, quantize it to 64 colors max, but make sure the first 16 colors is the same as the default VGA palette, then save the result as an animated GIF.
There's no point in example images, because the power of this tool is, you have full control on specifying how the conversion should be done. Just quantize to 256 individual colors? Sure. Convert to web-safe palette? Got you covered. Limit the colors to 8 for each 4 x 4 pixel blocks? Smooth sailing.
Full disclosure: it generates much better results than Imagemagick "png8:", and it handles animated PNGs too.
You say ttf and otf are the same, but that's not true, one utilizes quadratic curves, the other cubic curves. Also one is patented, the other isn't (most notably its bytecode vm).
Also, you say curve and spline is the same. They are not. Spline is a series of curves where you don't store the starting points, because those are the same as previous curve's ending points. So a spline requires less space to store than a list of the same curves, hope this makes sense to you.
I've also implemented a very fast font renderer, which supports bitmap, pixmap, quadratic and cubic curves, even mixed. I took a different path though: I've designed a very efficient font format, and provided a tool to convert ttf, otf, ps, etc. fonts into that format. This way the computational heavy parts are done beforehand, and the renderer can be small and fast (it's just a single header library, with source of 32k).
https://gitlab.com/bztsrc/scalable-font2
Using GPU for rasterizing is a good idea, but my font renderer is extremely portable so it's deliberately dependency-free and uses CPU integer arithmetic only. So it had a different design goal than yours, but still, it might be useful to study and it might give you ideas on further optimizations.
https://news.ycombinator.com/item?id=48538174
After adding X11, SDL and GDI backends, now I'm working on a native Wayland support (for now, running through the SDL backend works on Weston).
> Warning: This overwrites data starting at sector 64! Use a dedicated blank USB.
This would be much more usable if you'd put a file system on the USB stick with a sufficiently large, empty, bianco file.
Note, you don't need to implement a file system driver. Just create it with a big enough file and use that file's starting sector instead of 64. You could even update the file's size with the data written (just one more sector write, and again, you don't need to interpret the file system, just patch one integer in a sector).
I'd recommend ext2 (FAT is not good, because it limits files to 2G, and exFAT is in patent hell). Create with mkfs.ext, add a large file with dd, then save the data as a bunch of "db" lines into your asm source. You'd then assemble the file system along with stage1/2 without the need to interpret what you're writing.
Oh, one more thing: some BIOS checks the first bytes of the boot sector as well (not just the last two bytes), so you should start your boot sector with a short jmp and a nop. Also it's not guaranteed that direction flag is cleared, add a cld after cli.
To get some ideas, here's a boot sector that loads an EFI PE/COFF executable from a FAT file system (without interpreting the fs), sets up long mode and executes it:
https://gitlab.com/bztsrc/easyboot/-/blob/main/src/boot_x86....
(Notes: written for the flatassembler, which uses a very very similar Intel syntax like nasm, and the 2nd stage EFI executable is written in C very carefully so it doesn't matter if it's loaded by this boot sector on BIOS or by the UEFI firmware, the same binary just works everywhere.)
As for developing EFI apps, I don't use EDK2, because it's messy and bloated, instead I've written my own UEFI SDK: https://gitlab.com/bztsrc/posix-uefi it's much easier to use, you might find it useful too.
https://news.ycombinator.com/item?id=48538174
But it's multi-platform (Linux, Windows and some BSDs), more capable and even skinable so looks even cooler than this.
https://gitlab.com/bztsrc/smgui
I don't like immediate-mode, because you must handle everything in the same thread, so mine is a state-mode GUI.
For immediate-mode and ANSI C, there's also Nuklear:
https://github.com/Immediate-Mode-UI/Nuklear
This latter has all the bells and whistles.
https://bztsrc.gitlab.io/skrellm/
It is a minimal, multiplatform rewrite of gkrellm, because my distro dropped glib2 and gtk2 support, so I can't compile gkrellm any more (gtk3 rewrite is just a myth, couldn't find it on the official site), and none of the panels my DE has was as sophisticated as I'm used to with gkrellm.
I've checked multiload-ng (doesn't compile) and Conky (too bloated and doesn't compile either, couldn't set up its build env so many dependencies) which didn't work, so I had to implement my own truly lightweight version.
SKrellM is free and Open Source, licensed under GPLv3+, less than 400K single portable binary, hope you like it!