We&#x27;d be at the same spot, single-header files are still useful.A single-header file is not a &#x27;full-sized&#x27; library compressed into one file it&#x27;s codebase is designed to actually be minimalist. Many libraries have single files that are the same size as their alternative single-header.

With a central, curated, audited package repository where publishing rights are given to absolutely everyone then supply chain attacks in C and C++ would be even easier.

I wonder where we&#x27;d be if we&#x27;d stopped relying on system packages to provide dependencies for C &#x2F; C++. It is positively miserable to have to pollute your system when a codebase written in Go &#x2F; Rust &#x2F; your favourite modern language Just Works out of the box.

We&#x27;d be in exactly the same place because nobody wants to use an OS-dependent package manager for an OS-agnostic project.I don&#x27;t know if you noticed but no modern languages use Linux packages to provide dependencies, because that obviously sucks balls for many reasons.

Isn&#x27;t the one from Rust pretty good?

&gt; a proper package managerThose are a thing? Wasn&#x27;t aware.

Nope, most people using it know how to link and compile libraries. :)

Windows is no excuse, because many of &quot;single-header C library&quot; sinners are UNIX only folks, targeting only UNIX platforms.For me it only reveals lack of willingness to learn how to use their tools.I learned how to use C and C++ build systems at the age of 12 years old, when most of the information was on libraries, or whatever folks down at computer club could explain.In a computing landscape much more fragmented than it is today?Do you think combining Windows and UNIX is hard? Try on the glory days of 16 bit home computers.Here we are in the age of information, and some people couldn&#x27;t be less bothered.

Most of those are for installing applications, not system-wide C library source distributions (e.g. you&#x27;ll need to figure out the path of the source and header files in build scripts since there&#x27;s no standard location for that on Windows).The closest thing to a C&#x2F;C++ package manager standard on Windows is probably vcpkg: <a href="https:&#x2F;&#x2F;vcpkg.io&#x2F;en&#x2F;" rel="nofollow">https:&#x2F;&#x2F;vcpkg.io&#x2F;en&#x2F;</a>

Remind me please, which of these is shipped with a default Windows install?

scoop? chocolatey? pacman in msys2? winget?

Every time I see a &quot;single-header C library&quot;, I wonder to myself where we&#x27;d be if only Windows had a proper package manager.(Especially since that&#x27;d force the POSIX world to de-fracture itself too.)

This is strange because C99 has stdint.h so we don&#x27;t need to use &quot;short&#x2F;long&#x2F;long long&#x2F;long long long&quot; nonsense anymore.

Since you&#x27;re using C99 as the base C version, why not use the fixed-width types from stdint.h (int32_t, int64_t, ...)?You can still typedef those to i32, i64 shortcuts etc, but I would try to avoid this in libraries since it might collide with user typedefs of the same name - or at least try to avoid it in the public API declarations.

&gt; I&#x27;m pretty sure windows uses &quot;long&quot; for 64 bit but linux uses &quot;long long&quot; for 64 bitWindows long is 32bit even on 64bit CPUs.Linux long is arch dependent and is 64bit on x64, 32bit on x86.long long is always 64bit on both platforms.

It&#x27;s just that the #if checks for the MSVC compiler, not for Windows as a platform. And on that compiler you will never have LP64, but LLP64: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;64-bit_computing#64-bit_data_models" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;64-bit_computing#64-bit_data_m...</a>I just roll my own for this because I don&#x27;t need all the functionality, and generally find such cross-platform libraries to only really test on Linux, and it&#x27;s too much of a hassle.

&gt; I&#x27;m pretty sure windows uses &quot;long&quot; for 64 bit but linux uses &quot;long long&quot; for 64 bitother way around

I test Windows mainly with MINGW, that might be an issue with MSVC. Feel free to report the issue on the github repository.I&#x27;m pretty sure windows uses &quot;long&quot; for 64 bit but linux uses &quot;long long&quot; for 64 bit

For MSVC, long is 4 bytes: <a href="https:&#x2F;&#x2F;learn.microsoft.com&#x2F;en-us&#x2F;cpp&#x2F;cpp&#x2F;fundamental-types-cpp?view=msvc-170#sizes-of-built-in-types" rel="nofollow">https:&#x2F;&#x2F;learn.microsoft.com&#x2F;en-us&#x2F;cpp&#x2F;cpp&#x2F;fundamental-types-...</a>

It depends whether you&#x27;re compiling in 32-bit or 64-bit mode, MSVC has two different modes and there are different versions of MinGW for 32-bit and 64-bit

A lot of people use i64 in the global namespace, so this will affect later code. It&#x27;s basically `#define true false`. When I consider a library I will do a quick sniff test to look for very obvious mistakes, at which point I won&#x27;t look further.

I&#x27;m not sure that issue would be caught by ordinary testing. It will implicitly cast into long long, so it might make little or no difference in this case.

Not sure whether this is tested on Windows at all. I opened the header and immediately found this `typedef signed long i64`, i.e. i64 is actually i32.

Tsoding (@TsodingDaily) made a YT video named &quot;This Release is Crazy!!&quot; about the release recently: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=7ZJ9pJJnxfI" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=7ZJ9pJJnxfI</a>

This was added to raylib as a backend recently: <a href="https:&#x2F;&#x2F;github.com&#x2F;raysan5&#x2F;raylib&#x2F;releases#:~:text=RGFW">https:&#x2F;&#x2F;github.com&#x2F;raysan5&#x2F;raylib&#x2F;releases#:~:text=RGFW</a>

That&#x27;s something I plan on looking into at some point. I&#x27;m unsure if I want that in the main version or a separate branch for embedded devices.It&#x27;s low priority though because my main focus is desktop applications.

You could support mobile platforms as well. IIRC, even if Android allows creating only one window per activity, this behavior can be easily mapped on the abstraction that you provide.

Sure, but the library is also relatively small, so it compiles quickly. 
Although if you want to you can compile it on its own.It&#x27;s also possible to compile it on its own using `gcc -c -x c -D RGFW_IMPLEMENTATION RGFW.h`Nuklear is not a true single-header style library, it only uses that as a format. The difference is that the design is far less compact and lightweight than a stb-style library.I&#x27;m pretty sure GLFW has some files that are nearly the same size as RGFW, for example.

Have you actually tried? This is 287 KB of C. MSVC on computers from 15 years ago will compile C at about 60 MB&#x2F;s. I&#x27;m skeptical this is actually a problem.SQLite is distributed as a single 6 MB .c file and compiles in ... 0.1 seconds.

The one big downside I see is that if you want to actually work on the library itself, it&#x27;s a pain to have to re-compile the entire thing every time you change something.Nuklear (<a href="https:&#x2F;&#x2F;github.com&#x2F;Immediate-Mode-UI&#x2F;Nuklear">https:&#x2F;&#x2F;github.com&#x2F;Immediate-Mode-UI&#x2F;Nuklear</a>) uses separate files with a deploy script that combines them all into a single header; I think that approach is quicker for iterating on the code.

I&#x27;m aware of the errors for the micro UI (on the web), it&#x27;s something I plan on looking into soon!

I love single header libraries and I like the idea here of taking care of one necessity well. It seems like good modularity all around.A quick heads up, the micro UI emscripten example doesn&#x27;t work on chrome or firefox. The error is: DrawElements doesn&#x27;t actually prepareClientAttributes properly.

Well, I do not use them at all. But I agree that this mechanism would avoid the additional copies. I have seen other single-header libraries though...In any case, forcing me to figure out the specific XYZ_IMPLEMENTATION for each library is less user friendly that just proving a .c and .h file.

&gt; no instruction bloat via creating multiple instances for all functions.This makes me think that you&#x27;re using single-header libraries wrong. These kind of libraries usually require you to do something special prior to including it to get the actual code and you must do it only in ONE file.For example, you&#x27;d #define RGFW_IMPLEMENTATION before #include rgfw.h in exactly ONE .c. If you need the header in other files, you do NOT define RGFW_IMPLEMENTATION and no code will be produced.

The issue if if you have many such libraries and any change to the implementation forces recompilation of everything. Maybe not such a big deal for such small libraries, but an annoying trend IMHO.

Try putting GLFW&#x27;s source code into one file and then compile it. 
That will take at least a few seconds, RGFW compiles in less than a second.Where&#x27;s the bloat? :)<a href="https:&#x2F;&#x2F;github.com&#x2F;SasLuca&#x2F;glfw-single-header&#x2F;blob&#x2F;master&#x2F;example&#x2F;glfw.h">https:&#x2F;&#x2F;github.com&#x2F;SasLuca&#x2F;glfw-single-header&#x2F;blob&#x2F;master&#x2F;ex...</a>

I can&#x27;t figure out why anyone would call it &#x27;nonsense&#x27;. The definitions and functions have to be together, they may as well be a single file separated by a preprocessor definition.Include the header where you want the definitions. Include the header and use the preproccesor definition in the compilation unit you want the functions in. Done.There is no speed issue here. It would take 100x the C to make a difference and it&#x27;s actually going to be much faster and simpler to put a lot of single file libraries into one compilation unit. I always wonder if the downsides are theoretical or if people are really doing what I&#x27;ve been doing and still have a problem with it.

Too many script kiddies taking C for another scripting language.

I like simple code written in C, but when does this &quot;single-header&quot; nonsense stop? C has super nice and simple modularization via the classical .h&#x2F;.c split which ensures fast compilation, proper encapsulation, no instruction bloat via creating multiple instances for all functions.

Are you kidding? I started reading the X11 handbook series in the 1980s and now it&#x27;s 2024 and I&#x27;m nearly finished, and you want to replace it? ;-)

X11 is fine. It&#x27;s mostly just Video Games that need an alternative. It&#x27;d be nice if there was a &quot;pause X11 video card control and give exclusive access to a single application.&quot; Then there&#x27;s no need to care.

What do you expect from an alternative?

As far as I know, RGFW is the only minimal windowing of its kind. I guess I would suggest either targeting XWayland or using GLFW.The Wayland API itself also really sucks to work with, even more so than Xlib....But, RGFW&#x27;s Wayland support will probably be improved in the future. :)

Rust has a lot of those small libs, my favorite is miniquad<a href="https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;miniquad" rel="nofollow">https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;miniquad</a>

Waylands problem is that to use it, you need code generation so the wayland backend kinda hard to design for a header only lib.

Isn&#x27;t SDL itself is quite minimal already? I mean, it is definitely not high-level in any sense of the word.

Yeah, I&#x27;ve been looking for a minimal SDL alternative for a long time and I was really excited reading through this as that solution, but the lack of Wayland support is a huge dealbreaker for me.Are there any good minimal windowing utilities that support Wayland? SDL does a lot I don&#x27;t need and I try to maintain minimal dependencies. I suppose I could just use glfw &amp; libsoundio, haven&#x27;t tried that yet.

&gt; Wayland support is very experimental and brokenYou and everyone else, RGFW, you and everyone else.

RGFW: Single-header C99 window abstraction library