- Forum
- Windows Programming
- Path to learn Windows API
Path to learn Windows API
Pages: 12
I am a software developer that has been retired for 5 years, but now would like to learn some Windowes API Gui programming for personal use in my hobbies. What is the best path forward? My past applications involved real-time avionic 'systems written in C, and C++. Sometime ago (1995) I started to read Petzolds Windows programing book but I am assuming this book is way out of date now. so I am looking for some path to get me started learning the Windows API and welcome all suggestions.
Not all that much out of date. Someone has done the work to update a large part of the code to modern standards, not all though:
https://github.com/recombinant/petzold-pw5e
I'd really recommend if you want to muck around with the WinAPI you get Visual Studio 2019 if you don't already have it, it has a free Community version available.
https://github.com/recombinant/petzold-pw5e
I'd really recommend if you want to muck around with the WinAPI you get Visual Studio 2019 if you don't already have it, it has a free Community version available.
I find Windows GUI to be a bit of a mess. Microsoft are currently moving to separate the UI out into its own API (WinUI 3) that is part of Windows App SDK.
See: https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/
If you are looking to learn Windows API (Win32), fifth edition Petzold is still a good starting point. Also see: https://docs.microsoft.com/en-us/windows/win32/
| Microsoft wrote: |
|---|
| The Windows App SDK is a set of new developer components and tools that represent the next evolution in the Windows app development platform. The Windows App SDK provides a unified set of APIs and tools that can be used in a consistent way by any desktop app on Windows 11 and downlevel to Windows 10, version 1809. The Windows App SDK does not replace the existing desktop Windows app types such as .NET (including Windows Forms and WPF) and desktop Win32 with C++. Instead, it complements these existing platforms with a common set of APIs and tools that developers can rely on across these platforms. |
If you are looking to learn Windows API (Win32), fifth edition Petzold is still a good starting point. Also see: https://docs.microsoft.com/en-us/windows/win32/
I've heard a number of times here and perhaps elsewhere that Petzold's old 4th and 5th edition (1995, 2000 copyright dates ) code samples might need some tweeking to get to work with 2021 software. Furry Guy alluded to that above. I was curious so I dug out my Windows 95 Petzold disk (also have his 5th edition Win98/2000 disk) to see if his samples worked with VStudio 2019's build chain. So far only got to testing his HelloWin.c sample in Chap 2 of his Windows 95 book, which would have been ansi 8 bit character set, but it built with no problems. I'll get to testing a few more chapters later as I've got to run here in a bit.
I might note I didn't use any IDEs to build the sample as I build from the command line with a command line string something like so for his CHAP02 HelloWin. c sample...
cl HelloWin.c /O1 /Os kernel32.lib user32.lib gdi32.lib winmm.lib
I didn't specify any warning level so the default was used. If one would crank the warning level up high enough perhaps there would be a warning or something.
There has gotten to be a bit more bloat now 26 years later. The HelloWin.exe on Petzold's disk was 16,896 bytes built with VC 4 in 1995. Now it's 78,336 built with VC19 (statically linked).
I might note I didn't use any IDEs to build the sample as I build from the command line with a command line string something like so for his CHAP02 HelloWin. c sample...
cl HelloWin.c /O1 /Os kernel32.lib user32.lib gdi32.lib winmm.lib
I didn't specify any warning level so the default was used. If one would crank the warning level up high enough perhaps there would be a warning or something.
There has gotten to be a bit more bloat now 26 years later. The HelloWin.exe on Petzold's disk was 16,896 bytes built with VC 4 in 1995. Now it's 78,336 built with VC19 (statically linked).
I think mainly it's the scenario of opening the project, doing the one way upgrade and hitting build can get you an output like:
hence needing a few tweaks. I'm not sure I have come across any of the code that needs tweaking.
Build started... 1>------ Build started: Project: ClipText, Configuration: Debug Win32 ------ 1>cl : command line warning D9035: option 'Gm' has been deprecated and will be removed in a future release 1>cl : command line error D8016: '/ZI' and '/Gy-' command-line options are incompatible 1>Done building project "ClipText.vcxproj" -- FAILED. ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== |
I'm going to suggest a different path.
To preface, I, too, am a developer spanning multiple epochs, starting in the late 70's as a teen. I've never retired, though. My view on your inquiry has that one benefit of witnessing the various viewpoints on GUI development, from before 32 bit Windows to the present.
While knowing the Windows API is helpful, it is not by any means the best approach to developing GUI applications if C++ is an option (where C can be included, usually as C compilation units called by C++ compilation units).
I would dare to go as far as saying studying the Windows API may be a waste of time, depending on your objectives.
Instead, I suggest using a C++ GUI library. Many will prefer Qt, but I find wxWidgets quite useful. You don't lose much of anything employing a GUI library, but you gain considerable leverage in time. Qt has been known to be full featured, but not always "native" in it's use of controls, while wxWidgets does use native controls but has an older style to its design. Qt tries to do everything, including it's own containers. wxWidgets has its own containers, but does not insist that they be used (and actually treats them, in recent versions, as nearly deprecated - they were more important prior to C++0x).
The added feature you get by going this way is that your code can be built to run on Windows, Linux and MAC targets.
The Windows API is entirely C oriented. The amount of work required just to get a basic application running is significant, and quite boilerplate. You end up with one large function that responds to messages, and that is an unorganized mess to deal with.
A C++ library allows you to get a basic GUI built in a few steps. You can build smaller executables in C targeting the API, but you can't port those applications to other operating systems, and at this point the comparative difference is a few pennies worth of RAM.
There are other frameworks. Microsoft's dated MFC was "the standard" for decades when targeting Windows only. It was described as a "thin" wrapper for the Windows API, so the leverage gained is less than that of the two I suggested.
For students of C++, Stroustrup uses a small GUI framework called "FLTK" in his introductory text. Some consider a bit too minimalistic, but it is quick to learn and is sufficient for simple targets. There is even some reason to consider this minimal approach quite liberating because the natural reaction a C++ programmer would have to a minimal framework like FLTK is to expand upon it in the direction of one's personal interests, and there's less to learn.
There is more, though, to consider than merely GUI.
The filesystem, for example, brings some puzzles in practical usage. To create a file inside a deeply nested directory tree that does not yet exist requires a loop or recursive algorithm to test for the existence of each parent leaf, and to create it if it doesn't exist, before the file itself could be created. This can be handled automatically by a library, and in modern C++ the std::filesystem can do this in a portable way. For a Windows only solution, which Petzold or similar texts might cover, the required code is a few dozens lines or more. For std::filesystem, it is one call to the library and it is portable.
Another often ignored technique is the use of memory mapped files. This technique is generally the fastest way to get data into or out of a disk resource. Literally nothing compares favorably. A Windows only approach, which I don't think Petzold ever covered, is quite complicated. The BOOST library has a pre-built solution (actually two), which then work on Windows, Linux or MAC (with a few caveats). With this technique one can consider a file merely a block of memory, and all file I/O can be handled as if writing to or reading from RAM.
The other primary use for memory mapped files is to create a window of RAM that can be shared among multiple executables. Only pipes are as fast under certain circumstances.
Petzold considered the model of a GUI application, and of the Windows operating system, as a single thread, cooperative multi-tasking design, as it was prior to Windows 95. I don't know if it was ever updated to deal with synchronization among threads.
Threaded development becomes much simpler when relying upon libraries to deal with synchronization objects like mutexes, or joining threads (or launching threads). The modern C++ libraries have these features which are portable.
In other words, at this point in time, it is more important to consider the larger view of writing threaded GUI software without specific regard to the underlying operating system. You may think to yourself that since you're only writing Windows applications you don't care about portability, but in reality the path is not singularly focused on portability, but on the practicality of using leverage from the C++ language (which covers most everything except GUI) and leverage from a GUI library (which saves considerable time) to develop modern applications in C++ incorporating that fundamental concept of leverage objects themselves provide.
You have less to learn that way, and what you do learn works harder for you with fewer bugs.
A simple example:
Painting in a GUI application.
To paint on the display at the proper time (when a message for Windows says the display must be repainted), you must create a device context through which the painting is performed.
You must then select into that context the brushes, pens, fonts or modes of operation.
When the painting is finished, you must properly de-select the last used brush, pen, font or other object before deleting the device context.
Failure to release the objects or the device context produces a leak of the resources.
This is a very, very (very, very - especially with students) common bug in C oriented Windows API applications.
In a GUI library, this is part of the RAII concept deeply practiced in C++, so you do not have to really bother thinking about it or debugging the problem it can create.
To preface, I, too, am a developer spanning multiple epochs, starting in the late 70's as a teen. I've never retired, though. My view on your inquiry has that one benefit of witnessing the various viewpoints on GUI development, from before 32 bit Windows to the present.
While knowing the Windows API is helpful, it is not by any means the best approach to developing GUI applications if C++ is an option (where C can be included, usually as C compilation units called by C++ compilation units).
I would dare to go as far as saying studying the Windows API may be a waste of time, depending on your objectives.
Instead, I suggest using a C++ GUI library. Many will prefer Qt, but I find wxWidgets quite useful. You don't lose much of anything employing a GUI library, but you gain considerable leverage in time. Qt has been known to be full featured, but not always "native" in it's use of controls, while wxWidgets does use native controls but has an older style to its design. Qt tries to do everything, including it's own containers. wxWidgets has its own containers, but does not insist that they be used (and actually treats them, in recent versions, as nearly deprecated - they were more important prior to C++0x).
The added feature you get by going this way is that your code can be built to run on Windows, Linux and MAC targets.
The Windows API is entirely C oriented. The amount of work required just to get a basic application running is significant, and quite boilerplate. You end up with one large function that responds to messages, and that is an unorganized mess to deal with.
A C++ library allows you to get a basic GUI built in a few steps. You can build smaller executables in C targeting the API, but you can't port those applications to other operating systems, and at this point the comparative difference is a few pennies worth of RAM.
There are other frameworks. Microsoft's dated MFC was "the standard" for decades when targeting Windows only. It was described as a "thin" wrapper for the Windows API, so the leverage gained is less than that of the two I suggested.
For students of C++, Stroustrup uses a small GUI framework called "FLTK" in his introductory text. Some consider a bit too minimalistic, but it is quick to learn and is sufficient for simple targets. There is even some reason to consider this minimal approach quite liberating because the natural reaction a C++ programmer would have to a minimal framework like FLTK is to expand upon it in the direction of one's personal interests, and there's less to learn.
There is more, though, to consider than merely GUI.
The filesystem, for example, brings some puzzles in practical usage. To create a file inside a deeply nested directory tree that does not yet exist requires a loop or recursive algorithm to test for the existence of each parent leaf, and to create it if it doesn't exist, before the file itself could be created. This can be handled automatically by a library, and in modern C++ the std::filesystem can do this in a portable way. For a Windows only solution, which Petzold or similar texts might cover, the required code is a few dozens lines or more. For std::filesystem, it is one call to the library and it is portable.
Another often ignored technique is the use of memory mapped files. This technique is generally the fastest way to get data into or out of a disk resource. Literally nothing compares favorably. A Windows only approach, which I don't think Petzold ever covered, is quite complicated. The BOOST library has a pre-built solution (actually two), which then work on Windows, Linux or MAC (with a few caveats). With this technique one can consider a file merely a block of memory, and all file I/O can be handled as if writing to or reading from RAM.
The other primary use for memory mapped files is to create a window of RAM that can be shared among multiple executables. Only pipes are as fast under certain circumstances.
Petzold considered the model of a GUI application, and of the Windows operating system, as a single thread, cooperative multi-tasking design, as it was prior to Windows 95. I don't know if it was ever updated to deal with synchronization among threads.
Threaded development becomes much simpler when relying upon libraries to deal with synchronization objects like mutexes, or joining threads (or launching threads). The modern C++ libraries have these features which are portable.
In other words, at this point in time, it is more important to consider the larger view of writing threaded GUI software without specific regard to the underlying operating system. You may think to yourself that since you're only writing Windows applications you don't care about portability, but in reality the path is not singularly focused on portability, but on the practicality of using leverage from the C++ language (which covers most everything except GUI) and leverage from a GUI library (which saves considerable time) to develop modern applications in C++ incorporating that fundamental concept of leverage objects themselves provide.
You have less to learn that way, and what you do learn works harder for you with fewer bugs.
A simple example:
Painting in a GUI application.
To paint on the display at the proper time (when a message for Windows says the display must be repainted), you must create a device context through which the painting is performed.
You must then select into that context the brushes, pens, fonts or modes of operation.
When the painting is finished, you must properly de-select the last used brush, pen, font or other object before deleting the device context.
Failure to release the objects or the device context produces a leak of the resources.
This is a very, very (very, very - especially with students) common bug in C oriented Windows API applications.
In a GUI library, this is part of the RAII concept deeply practiced in C++, so you do not have to really bother thinking about it or debugging the problem it can create.
Last edited on
| While knowing the Windows API is helpful, it is not by any means the best approach to developing GUI applications |
I'd go as far as saying it should be the last resort when other avenues aren't appropriate (very rare!).
| Another often ignored technique is the use of memory mapped files. This technique is generally the fastest way to get data into or out of a disk resource. Literally nothing compares favorably. A Windows only approach, which I don't think Petzold ever covered, is quite complicated. |
For this type of WIN32 API coverage (including Win32 files, multi-threading, sync etc), you need the Richter books and Hart's Windows System Programming book.
https://www.amazon.co.uk/Windows-Programming-Addison-Wesley-Microsoft-Technology/dp/0321657748/ref=sr_1_4?dchild=1&keywords=hart+windows+system&qid=1630510701&s=books&sr=1-4
https://www.amazon.co.uk/Programming-Services-Microsoft-Windows/dp/0735607532/ref=sr_1_7?dchild=1&keywords=windows+richter&qid=1630510750&s=books&sr=1-7
https://www.amazon.co.uk/Programming-Applications-Windows-Microsoft/dp/1572319968/ref=sr_1_17?dchild=1&keywords=windows+richter&qid=1630510791&s=books&sr=1-17
https://www.amazon.co.uk/Windows%C2%AE-via-C-PRO-Developer/dp/0735624240/ref=sr_1_18?dchild=1&keywords=windows+richter&qid=1630510791&s=books&sr=1-18
Last edited on
This is interesting because I don't disagree with Niccolo but I also think that learning Windows API*, starting with Petzold, has not been a waste for me...and if the OP has a copy of Petzold already...
* Not just the GDI UI parts
* Not just the GDI UI parts
Hi CGooden
Here is a good place to start. :)
https://docs.microsoft.com/en-us/windows/win32/learnwin32/your-first-windows-program
Here is a good place to start. :)
https://docs.microsoft.com/en-us/windows/win32/learnwin32/your-first-windows-program
I'd separate WIN API into the GUI and non-GUI parts. Certainly learning the non-GUI part I agree is worthwhile. We are Windows only and we extensively use the non-GUI WIN API (even over C++ - eg files, threads, sync etc). Having an overview of the GUI part is probably advantageous as well. However, writing a GUI program in WIN32 IMO should still be the last resort.
seeplus, that's kind of my view as well.
I am the sort of person that likes to get an understanding of what is going on behind the scenes to help me understand the 'automagic' parts of the higher level stuff.
When I first started programming Windows, I decided MFC was a good starting point. When I had issues and asked about them, 'read Petzold' was a frequent reply. In the end I did and it helped my understanding a lot. It also helped me understand sample code that was written in a pure WinAPI style.
seeplus, do you mind if I ask what you, as in your work, use for UI?
I am the sort of person that likes to get an understanding of what is going on behind the scenes to help me understand the 'automagic' parts of the higher level stuff.
When I first started programming Windows, I decided MFC was a good starting point. When I had issues and asked about them, 'read Petzold' was a frequent reply. In the end I did and it helped my understanding a lot. It also helped me understand sample code that was written in a pure WinAPI style.
seeplus, do you mind if I ask what you, as in your work, use for UI?
I gave up programming client UI when Vista came out and screwed everything up. When the client programs that worked great on XP produced multiple errors with Vista I didn't realise I had such a varied vocabulary with which to express my views re MS!
The client group use .net in some form with c# and vb.net and html/js et al. But we now operate in a 'thin client' way. All processing/storage is done by the back-end servers in C++ and the gui client mainly passes messages/data to/from the back-end. Only temp data is stored on the client (we use roaming profiles, AD et al). It's quite easy to re-do the client part in pretty much anything (or so they say).
The client OS is Windows. I think there's a mix of versions but I'm not sure as I don't now get involved with that. All the back-end servers are Windows 10 latest version.
The client group use .net in some form with c# and vb.net and html/js et al. But we now operate in a 'thin client' way. All processing/storage is done by the back-end servers in C++ and the gui client mainly passes messages/data to/from the back-end. Only temp data is stored on the client (we use roaming profiles, AD et al). It's quite easy to re-do the client part in pretty much anything (or so they say).
The client OS is Windows. I think there's a mix of versions but I'm not sure as I don't now get involved with that. All the back-end servers are Windows 10 latest version.
Last edited on
| seeplus wrote: |
|---|
| I gave up programming client UI when Vista came out and screwed everything up... |
At the moment I'm trying to pick apart the spaghetti documentation of modern Windows development with non-managed C++ and work out what the base layer is.
By that I mean that every now and then I spend a few minutes reading up on Universal Windows Platform (UWP), Windows Runtime (WinRT), Windows App SDK, and WinUI 3 with the knowledge that I'll want to be heading that way in the near future.
I really could do with a Petzold, Prosise, or Richter style book on this. :0)
Yeah - that's why I gave up client UI development. I've got enough to do just to keep up-to-date with C++!
The client team can have all the fun of unpicking that lot. At my time I just can't be bothered with it all now.
The client team can have all the fun of unpicking that lot. At my time I just can't be bothered with it all now.
@The Grey Wolf,
did you have a look at this title?
https://www.amazon.co.uk/Programming-Windows-_p6-Developer-Reference-ebook/dp/B00JDMPJ8E/ref=sr_1_6?dchild=1&keywords=charles+petzold&qid=1630651585&s=books&sr=1-6
did you have a look at this title?
| Reimagined for full-screen and touch-optimized apps, Windows 8 provides a platform for reaching new users in new ways. In response, programming legend Charles Petzold is rewriting his classic Programming Windows—one of the most popular programming books of all time—to show developers how to use existing skills and tools to build Windows 8 apps. |
https://www.amazon.co.uk/Programming-Windows-_p6-Developer-Reference-ebook/dp/B00JDMPJ8E/ref=sr_1_6?dchild=1&keywords=charles+petzold&qid=1630651585&s=books&sr=1-6
| thmm wrote: |
|---|
| did you have a look at this title? |
Thanks for all of the suggestions. I have copies of Petszold books being shipped to me fro,m HPB.com (lots of older computer books here for cheap prices) and have started to read C# 8.0 and .NetCore 3.0. Visual Studio2017, 2019, and 2022 is installed.
I agree with the many suggestions and comments about the Win GUI API., We always attempted to keep the gui separated from the app code at work and will do the same in my projects.
I found a relatively new book on the Windows 10 System Programming. Has anyone looked at this book and could comment? I could not find this book near me at all. Interested in the threads and interprocess communications, and shared memory in the windows world.
I agree with the many suggestions and comments about the Win GUI API., We always attempted to keep the gui separated from the app code at work and will do the same in my projects.
I found a relatively new book on the Windows 10 System Programming. Has anyone looked at this book and could comment? I could not find this book near me at all. Interested in the threads and interprocess communications, and shared memory in the windows world.
| I found a relatively new book on the Windows 10 System Programming. |
Which one? Would you post a link.
Here is the link to the book Windows System Programming Part 1. Part 2 is yet to be published.
https://www.amazon.com/Windows-10-System-Programming-Part/dp/B086Y6M7LH/ref=asc_df_B086Y6M7LH/?tag=hyprod-20&linkCode=df0&hvadid=416953777802&hvpos=&hvnetw=g&hvrand=3218944684129488173&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9021890&hvtargid=pla-910099069175&psc=1&tag=&ref=&adgrpid=93867144397&hvpone=&hvptwo=&hvadid=416953777802&hvpos=&hvnetw=g&hvrand=3218944684129488173&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9021890&hvtargid=pla-910099069175
Pages: 12