What windows/gui library would you fellas recommend for someone starting out as their first entry? I know some SFML, but I am curious what you would have recommended to someone?

There is Win32 API, SDL, SFML, ClanLib, QT, WxWidgets, Winforms, WPF, GTK+...etc

I am thinking of looking at Dear ImGui next, it is:
-Cross platform (win,unix/linux,apple,consoles, mobile...etc)
-FREE and open source
-Can incorporate with many API's (OpenGL, DirectX, Vulcan, Metal...)

It sounds like a dream come true, but is it?

Have you used ImGui, do you like it, any opinions?

Regardless of which you recommend, is knowing the Win32 API a must at some point in your opinion?

There are endless options, many of them passable, some very good.

The gold standard is probably Qt, followed closely by Gtk. If you are going to do Gtk, though, you should check out wxWidgets.

Dear ImGui is liked by many people and works very well (afaik, I haven’t used it).

FLTK is another very good, fairly simple one that is well-received by people with limited time to learn a major toolkit.

Ultimate++ is a very nice package as well, and like Qt, is an entire ecosystem to help you out with all kinds of GUI programming tasks.


There’s more. I think SO has a pretty good list, assuming some mod hasn’t decided to delete the thread because it recommends stuff.

What windows/gui library would you fellas recommend for someone starting out as their first entry? I know some SDL, but I am curious what you would have recommended to someone?

It 100% depends on what you want to make.

I am thinking of looking at Dear ImGui next [...] it sounds like a dream come true

Dear ImGUI is supposed to be easy to integrate into a program that already uses some 3D graphics API to draw itself. However a 3D graphics API will not necessarily be a good fit for a given application.

is knowing the Win32 API a must at some point in your opinion?

You could probably avoid learning it for a while. But, if your programs need to do anything on Windows, you must either call the Windows API directly, or call the same Windows API through a third-party library acting as a proxy.

In my opinion, it's best to know the underlying API so that you:
- Understand the fundamentals of the operating system you're programming.
- Understand how your library works.
- Have the knowledge to finish your task if your library can't do what you need.

What GUI framework used depends on several factors, with one point IMO being paramount.

Do you want to create GUI apps that are cross platform or not. IOWs, can the code with no changes (or very minimal ones) be compiled under Linux or MacOS or Windows.

If Windows is the sole target then using the Windows Desktop GUI could be a good idea. It gives a programmer very fine grained control over what the app does, though it requires a lot of code to do the work.

The WinAPI is C-based. Functions and structs.

An alternate Win-only is a C++ framework for GUI apps that encapsulates the C based SDK that at-times is very thin C++ layer over the C API. Microsoft Foundation Classes, MFC.

If you want a GUI framework that is cross-platform, the suggestions others have made are decent.

The thing about frameworks is they hide a lot of the nitty-gritty detail the OS requires to make it easy for the programmer to concentrate on getting the app to work.

Having a passing knowledge of the operating system's main to-the-bare-metal API is almost a requirement, though there is little need to be an old school OS API Guru any more.

A secondary factor in choosing what GUI framework to use is what is the app going to do. If you want a simple window with buttons and a menu with minimal drawing capability a framework like FLTK is a possible choice.

C++ Saint Bjarne Stroustrup uses FLTK in his Uni C++ Beginners course to create GUI apps. His "Programming Principles and Practice Using C++", Fourth Edition has a couple of chapters GUIfied.

One nice feature of wxWidgets is GUI apps created with it use the platform's native API instead of emulating the GUI. So a Windows app looks like a true Windows app, A MacOS app looks like a true MacOS app, etc.

At the onset it is probably better I look at a cross-platform library (hence ImGui), but I will feel left out if I don't at least touch upon Win32 API.

So what are Win 10/11 "windows" created using? Win32 API, MFC, .net framework, a mishmash of these?

Why are all these Win32 API books so old, is it dead or dying and just there if/when you need it?

The latest book in 2023 is so small in pages:
https://www.amazon.com/Mastering-Windows-Development-Adam-Larry/dp/B0CP468WZY/

So what are Win 10/11 "windows" created using? Win32 API, MFC, .net framework, a mishmash of these?

It depends, to be honest. There are so many frameworks that can be used to create Windows apps.

A couple that haven't been mentioned before, but are used by companies. Delphi and less used C++Builder. Rapid Application Development (RAD) IDEs.

The dearth of Windows Desktop programming books is a direct result of the explosion of frameworks available. C#, .NET, WinForms, etc.... Plus a lot of the material for using those frameworks have been moved online. And fragmented.

The age of Windows Desktop programming books is easy to Lucy 'splain. Microsoft has been trying to deprecate its use in favor of all the frameworks they cobbled together over the years and "the new shiny object. Look! A Squirrel!"

It wasn't that long ago a programmer using Visual Studio could download the latest Win32 SDK that came with offline help files and lots of code examples. ALL of the Windown API technologies.

Now the help is online and fragmented.

With lots of those older Windows Desktop code example shoved online at GitHub:

https://github.com/microsoft/Windows-classic-samples
https://github.com/microsoft/Windows-universal-samples
https://github.com/microsoft/DesktopBridgeToUWP-Samples

Here's an example of online MS Learn programming help:

https://learn.microsoft.com/en-us/windows/win32/desktop-programming

FYI, your Amazon link doesn't need all that verbiage. Everything after (and including) ref= is Amazon tracking code, you've potentially exposed your meat world identity here.

Prune all that and the essential link is:

https://www.amazon.com/Mastering-Windows-Development-Adam-Larry/dp/B0CP468WZY/

Now, doesn't that link look better?

Oh, that was ugly and spilled over. Pasted that right before I walked out the door and did not check like I normally do, thanks!

I heard QT was used more often in the work force and the bigger tech companies, but had a dual license and that you can't statically link with the free version. But I like open and free with no rules/attachments too.

This GUI stuff is like a whole new world and there are so many options. There used to be so many openGL books too, cook books and master series and all of a sudden all gone. Why do you think that is, do they want to maintain control (Win32, openGL..etc) or are they just not making much money on it with all this online references/support and 3rd party libs. Competition for OpenGL for things like Unreal & Unity?

I would love to see those books around and updated.

To start I am just going to use it on Windows, but would like the flexibility of quickly expanding.

Also, what is the most direct way to run core c++ on an Android device? Do you use one of the API's/libs from above? A wrapper from Java, or Kotlin? What is the most direct and easiest way? I would love to see a simple "Hello World" with a button on Android.

Can you create Windows GUI in Visual C++ and incorporate native C++? Is that a dying language and not worth looking at?

What ever happened to VisualBasic, is that now Visual C++? Gonna do some hunting on this now.

Mastering Windows Development - The latest book in 2023 is so small in pages

I'd advise caution. That book is only 280 pages and is independently published. Petzold's Programming Windows book is 1100 pages!

Visual Basic is now vb.net and uses the .net system (same as c#). Currently c# is MS's gui programming language of choice (both vb.net and c# are supported with VS). MS's previous Basic language was VB6 which was good but which MS stopped developing many, many years ago. There is now a project (twinBasic) to have a language/ide that is VB6 compatible. It's currently in beta with release 1.0 expected later this year. (https://www.vbforums.com/forumdisplay.php?108-TwinBASIC)

Windows GUI in Visual C++ and incorporate native C++

Yes using c-based WIN32 (it comes with VS though you might have to tell VS Installer to install it). Though if you're using C++ you might be better off with MS MFC which is a class based version of WIN32. However very few new gui programs now use these. The vast majority will use a x-platform framework (as mentioned above).

PS MS has a new gui called C++/WinRT which seems nice but unfortunately appears to have very little in the way of documenttion/examples etc. See:
https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/#topics-about-cwinrt

Thanks. That's the first thing I compared, were the pages and was bummed out!

Although, Win32 is deprecated but still partially used, I think that used book (Programming Windows Fifth Edition) I can get for $12 and won't feel left out. It also looks like fun stuff, George ur right...but for quick glances and smaller trials and gradually to look at.


I just saw a video on CLR WinForms. I may just try Visual C++, only because it is right at my finger tips but not spend too much time with it. Probably just stick with ImGui. I need something with good documentation. And then QT for industry compatibility with Win32 gradually on the sidelines.

I just saw another video where someone made their own, man I wish I had the experience to do something like that.

Kotlin has not caught on like Google intended it to and might not ever, probably just best stick to Java when wanting to add C++ as core to Android, huh? Just looked at some Java switch statements, which look so close to C++ and the Kotlin ones are so different but ultra condensed. You can write on average up to 40% smaller code with Kotlin vs Java. Plus Java has a bigger lib over K.

Still trying to get the lingo down, I think there are a few .net libs (.net sytem vs .net framework vs... .net something else???) Dunno the difference.

Win32 is deprecated

No. It's the base for Windows! it's just not promoted any more by MS or others as there are now 'better' frameworks for Windows programming - but for Windows these frameworks are all based upon WIN32 (which is also for 64 bit but is still called WIN32!).

CLR WinForms

Requires .net and compiles down to .net - not native binary.

There is also c++/cli which is c++ that uses .net and compiles to .net again not native binary.

Win32 is deprecated

MS didn't deprecate it, they can't. It is the core of Windows, from NT to Win11. They've hidden it behind ever increasing number of frameworks that obscure the at-the-bare-metal nature of the interface.

The only way to code a Windows app more "in the raw" is in assembly. Or directly in machine-code.

Frameworks are tools, designed to relieve the programmer from a lot of the burden of what is required to setup the interface of a WinApp. If you ever really look at the code for even the simplest Win compliant app you see a lot of start up code in WinMain, the starting point for every WinApp just as main is the starting point for every console app.

There are two and only two functions required in every WinApp:

1. WinMain. There is one variation to that, wWinMain, that tells the compiler your app is gonna be Unicode and not ANSI.

2. WndProc. Window Procedure, the function that tells the app what to do and how to respond to messages sent to the app by the operating system. It is a callback function.

WndProc can be renamed to whatever you want, you could name the function SniggleFritz if you want. You tell the app the name of your WndProc when you set up the guts of your WinApp in WinMain.

Visual Studio has wizards, guided dialogs, that let a programmer select the type of app is being programmed. Whether it is a console app, Windows GUI app, a DLL or static lib.

I personally prefer to use only the "Windows Desktop Wizard" project type, where I can name the project and overall solution and determine what type of app I want to create. I ALWAYS select the additional option of "Empty Project" because the 'boiler-plate' code that VS poops out is rather bulky even for a simple console app. Lots and lots of comments as if I had never programmed before.

The boiler-plate code for a WinApp is quite a lot. It has a rudimentary menu, has a dialog that displays info about the app. Along with a couple of icons.

You mentioned something about deprecation earlier. The boiler-plate code VS provides uses deprecated Win32 functions to set up the app! LoadIcon and LoadCursor. It also uses generic versions of the Win32 functions to it theoretically can be compiled for Win9x/Me machines! A hybrid 16/32 bit OS. Every Windows version based on NT has been fully 32-bit.

LoadIcon is a generic name for two separate Win32 function the compiler chooses one or the other depending on if the app is compiled for ANSI or Unicode. LoadIconA/LoadIconW.

Petzold's book does a good job of explaining what makes a WinApp different from a console app. One thing to note is the book was written for Windows 98 and uses ANSI encoding. MS recommends to use Unicode. And NOT use Hungarian Notation.

Using a framework is useful if you don't want to be bothered with the nitty-gritty details of what makes your app work. Knowing what is happening "behind the curtain" a good programmer should have a passing understanding of what is hidden away behind all the fancy obscuro-net of a framework.

.NET and its variants do not create a true machine code WinApp, they create a byte-code file that requires a run-time interpreter to execute the code. Similar to Java.

If you create one of those apps and you share it with someone who's computer doesn't have the run-time interpreter installed the app doesn't run.

Win32 isn't deprecated. Now that there is 64-bit Windows the "correct" terminology is now as Windows API or WinAPI. It covers both.

In Windows editions before Win95 the OS was 16-bit. Win95/98/Me was a hybrid 32- and 16- bit setup. Some functionality was 16-bit, a hold-over from Win 3.1, and some was 32-bit.

Win NT was true 32-bit. Every Win version since based on NT has been 32-bit. Win 11 will not run on a 32-bit CPU, unlike previous versions, but it still has backwards compatibility for running 32-bit apps.

I personally like programming with WinAPI (and Xlib, lol), but only for relatively small and simple GUIs.

I literally read somewhere that said since Win32 is deprecated, and I took it to mean that yes many parts are being used by the many frameworks but that parts of it are actually supplanted by the newer framework. And I took it to represent what is actually happening. I have no idea the extent of this yet. There have still yet been PARTS of Win32 that have been deprecated, correct?

With all these newer frameworks it sure sounds like something is cooking and being wrangled and being deprecated. The reason for some of these frameworks is for either web access, ease of use, and/or collectively faster processing. But I have also read that the Win32 is faster natively and that some of these frameworks slow it down some. I would imagine though that because of the framework nature, they are inherently easier to use...I would hope a LOT MORE easier to use?

So, Win32 API, Win32, WIN32, WinAPI, all refer to the same thing with the latter being a superset (32/64..etc).

QUESTIONS:
1) I don't know what "I think SO has a pretty good list" is from above, but is there a good source that you have found that puts this all together and describes all these nicely in one document/setting?

2) Visual C++ can incorporate many GUI libraries and frameworks, but is there a DEFAULT one that it installs with or that one typically installs with it and what is that lib/framework called?
So, it is "c-based WIN32" and most times others may use MS MFC?

I prefer to use the WinAPI Desktop model myself, 'cuz most of the GUI apps I mash up are simple. Many use the antiquated GDI and multi-media system Windows created from the early days of Windows.

Hint, hint, look at my GitHub repo for them thar Win32 GUI games I talked about earlier.*

I used to use C++Builder, an offshoot of Delphi, when it was still Borland. Easy to create a nice looking windowed app by dragging and dropping visible and invisible components and a couple of lines of code.

But ever since Borland got bought out by Embarcadero even the free versions of Delphi and C++Builder have major problems with being just plain installed.

MS released Visual Studio 2015 in the free Community edition and I've been using VS ever since.

I have Code::Blocks installed for code correctness usage. Occasionally I find what works in VS doesn't work in C::B and modify the code so both IDEs are whingeless.

*Speaking of the Win32 games.... A while back I noticed all the modern C++ enhancements I'd been making to the 2003/2004 code was making the games take a long time to close when I chose to exit the game. I had noticed that memory dump and error report files were being created when I ran the apps.

The game seemed to run Ok otherwise so I kinda ignored the problems.

Normally when I run an app in VS I select CTRL+F5 to run it without debugging. Recently I used F5. That starts debugging even with a release compiled app. Lo and behold! When the app terminated C++ stdlib errors showed up, courtesy of using smart pointers.

Removed the smart pointer use on my various class member data items, retaining other smart pointer uses in other parts of the code and now running the apps in debug mode didn't cause stdlib whining!

A very useful learning situation, I must say.

Something else I noticed, purely coincidental but nice, when running an app in debug mode even if there are issues with C++ stdlib cleanup there are no longer dump/error files created.

One drawback to using debug mode for testing games is when the game starts up it is rather laggy for a bit, 30 seconds or so. Gee, ya think? Acceptable behavior for testing I say.

I think from now on no matter what the C/C++ code is I write, console or Windows GUI app, I will be running the code in F5 debug mode to see if there are problems with the code that don't terminate it abnormally.

How much more overhead will Visual C++ with Win32 GUI have over native C++ with Win32? Is the answer, well it depends on what you are doing?

Will you see a significant difference when comparing 2 vector tables of a million values between the two? Will you see a sig diff for a game like Pac-man or Tetris?

Will it show up a lot heavier on a game like Minecraft?

Can you create Windows GUI in Visual C++ and incorporate native C++?

Abso-fragging-lutey! Look at my GitHub repo of the Win32 Games for one way to do the meld and merge.

https://github.com/GeorgePimpleton/Win32-games

WinAPI and C++ aren't just for games.

For that matter there are lots of online examples of using the Windows API in console apps, #include <windows.h> along with C++ libraries #includes.*

There have still yet been PARTS of Win32 that have been deprecated, correct?

Deprecated, yes. Removed? Nope. That whole tricky thing about backwards compatibility.

To give you an example, something I mentioned earlier. Using LoadIcon(W).

https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadiconw

The WinAPI function has been superseded by LoadImage(W).

https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadimagew

You will still see lots and lots of older code that uses LoadIcon. If you write new code you should use LoadImage.

And use the explicit explicit Unicode version of the function. LoadIconW, not LoadIcon or LoadIconA.

*Since the WinAPI is not part of C++ theoretically changing #include <windows.h> (or other WinAPI libs) to import <windows.h>; when using C++20 (or later) modules shouldn't work.

But it does in my experience. Not that I recommend treating ANY 3rd party libraries as modules unless the lib explicitly states it is modularized. So far I don't know of any. But then I haven't checked.

The WinAPI is most definitely a 3rd party lib to the C++ stdlib. :Þ

Mixing import with #include works just fine. The C library is a good example for still doing #include even though C++ encapsulated the C stdlib in C++. <stdio.h> vs. <cstdio> for example.

https://en.cppreference.com/w/cpp/standard_library (scroll down for the C stdlib discussion).