refterm VS scratch

refterm, a terminal emulator proof of concept.

> licensing it so that they couldn’t even look at it

https://github.com/cmuratori/refterm/blob/main/LICENSE

It’s just GPL 2.0, what are you talking about!?

Are Microsoft employees vampires that will burn up instantly if they merely glance at GPL code or something?

This is sour grapes nonsense from Microsoft. “We don’t like your tone so we won’t even dignify your argument by considering it.”

At one point an MS employee said they would love to fix their code as suggested by Casey but he refused to even look at the YouTube video!

“I would love to hear your arguments but I refuse to listen to the sound of your voice.” is next-level dismissive.

You might also find https://github.com/cmuratori/refterm interesting.

Casey Muratori made a renderer/terminal a short while back. Might be a good reference of you intend to go that route. https://github.com/cmuratori/refterm

You keep complaining that it's not a fully working terminal. Casey, on the other hand, writes here: [1]

> These features are not designed to be comprehensive, since this is only meant to be a reference renderer, not a complete terminal.

[1] https://github.com/cmuratori/refterm#feature-support

After that post they did implement a full reference implementation:

https://github.com/cmuratori/refterm/commits/main

And there is movement in getting changes into the terminal itself:

https://github.com/microsoft/terminal/issues/10461

For a basic example of why you would want GPU acceleration, have a look at refterm: https://github.com/cmuratori/refterm

Even processes that you wouldn't think would be impacted by a terminal can be hurt relaly bad by your terminal's performance: your compiler's logs, etc. The GPU rendering part merely guarantees that your terminal sticks at 60FPS (or, whatever your refresh rate is) if the processing behind is efficient.

pbmview, an image viewer (windows subsystem).

For comparison (for those following along): https://github.com/skeeto/scratch/blob/master/parsers/qoi.c https://github.com/skeeto/scratch/blob/master/parsers/ini.c

Another option I learned a couple years ago is embedding a UTF-8 manifest ([details])[https://github.com/skeeto/scratch/tree/master/libwinsane]. Also put the console in UTF-8 mode (SetConsoleOutputCP(CP_UTF8)), and you're done. Works on Windows 10 and later. This covers everything: argv is UTF-8 and fopen accepts UTF-8 paths. (This is exactly how CRTs should have worked all along.)

I was thinking more about this and I realized it's quite easy to do it in arbitrary precision, so here's my take: https://github.com/skeeto/scratch/blob/master/misc/bswap.c

As was linked from my QOI article, here's my full decoder with comments: qoi.c. Each pixel decodes to a 32-bit integer, ABGR. That corresponds to SDL's SDL_PIXELFORMAT_ABGR8888. SDL_UpdateTexture copies that data into the texture's internal storage, and font is no longer needed. (In a real program I'd allocate it in a scratch arena, reset after initialization.)

A recent, interesting experience with function+context allocation: For more than a decade, Windows accidentally exposed part of zlib in a public DLL, and (overly-)clever applications can exploit this as a "system zlib." Though it doesn't export the "end" functions, so cleanup seems impossible. However, custom allocation works, so doesn't matter. I plugged it into an arena.