Haven't worked with it much yet, not really my point either. They were talking about OS package managers, most likely the typical Linux package managers, and so did I.

Maybe, but those providing it apparently not.

I realize you asked sarcastically, but as of relatively recently WinGet is shipped by default with the latest versions of Windows 10 and in Windows 11. [1]

But why is being installed by default important?

[1] https://www.petergirnus.com/blog/how-to-use-windows-package-...

The same that shipped with a default UNIX install.

I don't know why you're being downvoted, but distributions for Windows would be really popular. A server distribution of Windows would help its adoption a lot.

I use those by default although I read that MSVC's support for those are iffy. I'm pretty sure STB does the same thing for the same reason.

Source: https://handmade.network/forums/articles/t/7138-how_to_write...

Okay, thank you.

Yes, because MSVC may or may not have stdint.h

:( That's disappointing, but I understand.

Why do you claim Nuklear is not a "true single-header style library"? And who gets to say what that even means?

That may be true for extremely simple source code, but it's almost too good to be true. Your number sounded so impressive that I tried with gcc (12.2) on my Linux VM. With -O0, it takes around 27s, with -O2 it's 1m07s.

With -E (only preprocess) we are at around 0.320s for the 260K lines of sqlite3.c. Which makes sense, 1M lines/s for the preprocessor and maybe also the AST should be doable (that may be where you got your 60MB/s number from). But compiling is something else.

MSVC may be faster here or not, I haven't tested it.

A more modern machine (mine is a i5-7600K from 2018) may be 2x or more faster, and running on multiple threads will speed up the build as well.

I actually agree with you that single-header libs are often not ideal. They're kind of neat in concept: just copy paste and done!

But after being burned a few times by naming or linking conflicts or you cloned your .c and forgot to remove the #define and now you have two implementations or having to debug any BSS/DATA/TEXT issues (because now lib and user code end up in the same .o and the linker can't do its magic for your esoteric architecture), I just took the habit of always manually creating a matching .c that only contains:

    #define BLAH_IMPLEMENTATION
    #include "blah.h"

Well for one you're able to easily use macros to customize features you want and don't want. Plus "forcing me to figure out the specific XYZ_IMPLEMENTATION" is a big of a weird compliant. You could say the same thing about linking a library. Besides, it's not hard to figure out and is usually one of the first lines of the file.

The single-header format also gives you MORE ways to compile the library and control which features to use or not use.

You just described X11's DRI (direct rendering infrastructure).

https://en.m.wikipedia.org/wiki/Direct_Rendering_Infrastruct...

This actually doesn’t work with modern expectations.

Modern games are expected to work in multi-monitor setups and render in “borderless windowed” mode, so you can alt-tab out to multitask, or have a comms overlay. Single monitor single process gaming still happens, but a good 85% of setups (according to the Steam Hardware Survey) are not that. There are five games I know or that actually handle multimonitor natively of the hundreds I’ve played. So we need some form of cooperative multitasking for graphics with the window manager.

X11 is utterly broken for multi-monitor setups with different resolutions at different scales (e. g. builtin laptop screen @1.25x, external display at 1x or some variation of that). With high resolution screens (e g. 4k at only 27"), that setup is not uncommon anymore.

(Wayland is broken in very many other ways, though, so you trade one evil for... 5 others).

- Better API design - Not being experimental after 11 years

I think that Wayland actually has some steps in the right direction, but overall I don't think it's actually a very good alternative. It's way more low-level than X11 and a lot of higher level features, like window decorations, are not even officially supported.

Other alternatives: pixels, minifb, softbuffer.

I've seen some interesting work in doing Wayland by hand:

https://gaultier.github.io/blog/wayland_from_scratch.html

I'd also look at the work done on minimal wayland projects like [foot](https://codeberg.org/dnkl/foot), which supports wayland well and seems to be written by hand (see: https://codeberg.org/dnkl/foot/src/branch/master/wayland.c)

I just have the Makefile do the code generation, it would be annoying for the user, but they can complain to Wayland if they don't like it.

SDL provides..

..an image decoding library.

..an audio input/output library.

..a multi-channel audio mixer.

..ttf and rtf font rendering.

..networking.

..runtime shader cross-compilation

..its own entire graphics abstraction layer / API.

..its own shader language, shader compiler, and shader bytecode format.

I don't know at which point something becomes 'high level', but SDL is only 'minimal' if you use a subset of its functionality.

Not minimal in the sense of "just give me a window, a minimal event loop, and a GPU context/swapbuffers function".