- Forum
- General C++ Programming
- Beginner - Understanding Windows API( )
Beginner - Understanding Windows API( )
Hey all, I have been learning basic c++ and sort of very new.
I am trying to practice understanding windows api functions.
Though reading MSDN on the functions is very confusing and hard to understand.
1) Why are the explanations on MSDN so complex and hard to understand? - Any tips and guidance on how to overcome this? How can I learn to make myself understand it and know what parameters to put in etc?
2) Lets say I want to create a simple program that shows a text in a message box.
To do this it would require the CreateWindow or CreateWindowExA function.
But I am always getting stuck with the parameters and what to put into the parameters. It asks for the style, class name and window name. Where do I find these?
I am trying to practice understanding windows api functions.
Though reading MSDN on the functions is very confusing and hard to understand.
1) Why are the explanations on MSDN so complex and hard to understand? - Any tips and guidance on how to overcome this? How can I learn to make myself understand it and know what parameters to put in etc?
2) Lets say I want to create a simple program that shows a text in a message box.
To do this it would require the CreateWindow or CreateWindowExA function.
But I am always getting stuck with the parameters and what to put into the parameters. It asks for the style, class name and window name. Where do I find these?
Last edited on
Perhaps start here.
http://www.winprog.org/tutorial/
> Why are the explanations on MSDN so complex and hard to understand?
Perhaps because they're a reference, not a tutorial.
That is, you need to know for yourself that you may need to call say CreateWindow(), then you go look on MSDN to make sure your understanding is correct and refresh your memory as to what it actually does (parameters, results, errors etc).
As with any API, it's important to have a pretty good overview understanding, like say how windows, menus, dialogs, buttons etc relate to one another. But don't bother trying to remember every last parameter of every single API function available.
Knowing that you need a button, then looking up the detail is far better than being able to recite MSDN word for word but being utterly clueless as to how to actually use any of that information.
http://www.winprog.org/tutorial/
> Why are the explanations on MSDN so complex and hard to understand?
Perhaps because they're a reference, not a tutorial.
That is, you need to know for yourself that you may need to call say CreateWindow(), then you go look on MSDN to make sure your understanding is correct and refresh your memory as to what it actually does (parameters, results, errors etc).
As with any API, it's important to have a pretty good overview understanding, like say how windows, menus, dialogs, buttons etc relate to one another. But don't bother trying to remember every last parameter of every single API function available.
Knowing that you need a button, then looking up the detail is far better than being able to recite MSDN word for word but being utterly clueless as to how to actually use any of that information.
@codecaine1,
The "standard" book for Windows programming, of the style you're asking, is by Petzold. That book is not introductory or elementary, but it does answer the question of what is required to get a Windows programming running.
If you're confused about CreateWindow, you have no idea what pain and complexity is ahead. For a beginner in C++, it is a mind bending and corrupting exercise you are well advised to stop, and right the h*ll now.
Windows API is for C. You can fully access it in C++, but the proper response any C++ programmer would have when faced with such an API is to encapsulate it. Such a task requires a seasoned programmer.
However, several such C++ frameworks have been created that do that. MFC was Microsoft's standard for years, so any tutorial on MFC would do.
However, MFC is only for Windows. It isn't particularly great, either. It would take a year to become proficient in all aspects of MFC, but you can get a program running in a few days as a beginner.
A lot of programmers preferred Microsoft's ATL, a different framework only for Windows.
A very popular framework is Qt, which creates applications for Windows, MAC and Linux (and others).
Similarly, a very good option is wxWidgets.
All of these frameworks are for intermediate programmers. All GUI is for intermediate programmers.
The reason is how GUI applications are built. Unlike console applications, GUI applications are written as a series of responses to messages. Everything Windows or other GUI's "do" is based on messages. These are basically numeric values accompanied by a few parameters which indicate what the user or the operating system requires of the GUI application.
In a Console application, the program starts and main, calls some functions, loops (perhaps), then exits main.
In a GUI application (Windows and otherwise), the application initializes, then basically pauses. It waits for messages.
Every button click, every mouse drag, every keystroke is sent as a message. When the battery is low, GUI sends a message. When the operating system is shutting down, GUI sends a message.
For GUI applications, you write responses to these messages.
The reason for this design paradigm is that GUI applications present most or all of the users options as controls, and they can click on or otherwise operate any control at any time. This isn't run by a menu. In GUI applications, menu selections are.....messages.
One of the confusing parameters in CreateWindow is the "window process". This is a pointer to a function for that Windows....message loop. It is how that window receives its messages.
Each window in a GUI has such a loop.
Which, if you're thinking clearly, should have already informed you that there is not one, single message loop. There is one for every window.
Everything is, potentially a window. Buttons are windows. Edit controls are windows. Sliders are windows.
There is a frame window, which typically "owns" a menu and a frame that can be resized. Its interior is usually occupied by a client window. What you see in a typical Windows application isn't just a window. It is usually at least two.
If there's a status bar at the bottom, that's a separate window which shrinks the client window. The client window is the interior of the main window or other frame window in which you display what you want the user to see.
Dialogs are specialized windows in that some are modal (meaning they are on top, block input to everything below it on that application, until they are dismissed.
These are but the introductory materials about GUI programming, and I've not detailed anything of value.
You could, out of curiosity, insist on learning how to write to the Windows API. It is a gross error to think it is a good idea, especially if you have not already mastered all of the intermediate level programming study, and know fully the difference between C and C++, and can write in both (or, you switch entirely to C, which is how the Windows API is written, which I would never recommend in the 21st century). If you insist, then there's no place to go, really, other than Petzold for a serious work on the subject. There are other "gentler" introductions, which I've not seen in decades, you might find.
The only reasonable choice is to select a framework. Your first choice is whether that's platform independent or not. In the 21st century, with frameworks like Qt and wxWidgets, it makes no sense to create Windows only applications. If you insist on making Windows only applications, then ATL (and a book on it) may be a fair direction to take. MFC might be the other.
Otherwise, browse a bit on wxWidgets and Qt for tutorials and books, or other GUI frameworks which target Windows, Linux and (optionally) MAC.
Good luck.
The "standard" book for Windows programming, of the style you're asking, is by Petzold. That book is not introductory or elementary, but it does answer the question of what is required to get a Windows programming running.
If you're confused about CreateWindow, you have no idea what pain and complexity is ahead. For a beginner in C++, it is a mind bending and corrupting exercise you are well advised to stop, and right the h*ll now.
Windows API is for C. You can fully access it in C++, but the proper response any C++ programmer would have when faced with such an API is to encapsulate it. Such a task requires a seasoned programmer.
However, several such C++ frameworks have been created that do that. MFC was Microsoft's standard for years, so any tutorial on MFC would do.
However, MFC is only for Windows. It isn't particularly great, either. It would take a year to become proficient in all aspects of MFC, but you can get a program running in a few days as a beginner.
A lot of programmers preferred Microsoft's ATL, a different framework only for Windows.
A very popular framework is Qt, which creates applications for Windows, MAC and Linux (and others).
Similarly, a very good option is wxWidgets.
All of these frameworks are for intermediate programmers. All GUI is for intermediate programmers.
The reason is how GUI applications are built. Unlike console applications, GUI applications are written as a series of responses to messages. Everything Windows or other GUI's "do" is based on messages. These are basically numeric values accompanied by a few parameters which indicate what the user or the operating system requires of the GUI application.
In a Console application, the program starts and main, calls some functions, loops (perhaps), then exits main.
In a GUI application (Windows and otherwise), the application initializes, then basically pauses. It waits for messages.
Every button click, every mouse drag, every keystroke is sent as a message. When the battery is low, GUI sends a message. When the operating system is shutting down, GUI sends a message.
For GUI applications, you write responses to these messages.
The reason for this design paradigm is that GUI applications present most or all of the users options as controls, and they can click on or otherwise operate any control at any time. This isn't run by a menu. In GUI applications, menu selections are.....messages.
One of the confusing parameters in CreateWindow is the "window process". This is a pointer to a function for that Windows....message loop. It is how that window receives its messages.
Each window in a GUI has such a loop.
Which, if you're thinking clearly, should have already informed you that there is not one, single message loop. There is one for every window.
Everything is, potentially a window. Buttons are windows. Edit controls are windows. Sliders are windows.
There is a frame window, which typically "owns" a menu and a frame that can be resized. Its interior is usually occupied by a client window. What you see in a typical Windows application isn't just a window. It is usually at least two.
If there's a status bar at the bottom, that's a separate window which shrinks the client window. The client window is the interior of the main window or other frame window in which you display what you want the user to see.
Dialogs are specialized windows in that some are modal (meaning they are on top, block input to everything below it on that application, until they are dismissed.
These are but the introductory materials about GUI programming, and I've not detailed anything of value.
You could, out of curiosity, insist on learning how to write to the Windows API. It is a gross error to think it is a good idea, especially if you have not already mastered all of the intermediate level programming study, and know fully the difference between C and C++, and can write in both (or, you switch entirely to C, which is how the Windows API is written, which I would never recommend in the 21st century). If you insist, then there's no place to go, really, other than Petzold for a serious work on the subject. There are other "gentler" introductions, which I've not seen in decades, you might find.
The only reasonable choice is to select a framework. Your first choice is whether that's platform independent or not. In the 21st century, with frameworks like Qt and wxWidgets, it makes no sense to create Windows only applications. If you insist on making Windows only applications, then ATL (and a book on it) may be a fair direction to take. MFC might be the other.
Otherwise, browse a bit on wxWidgets and Qt for tutorials and books, or other GUI frameworks which target Windows, Linux and (optionally) MAC.
Good luck.
I did my first windows programming using the tool they provided (and hopefully still do) in visual studio called 'dialog based project'. This builds most of what you need for you, and gives you a single window that you can do things on. From there its not bad at all: drag and drop an edit box onto the canvas, and then a button. Double click the button. The code block it opens will happen when the button is clicked. Now connect them: you want something like editbox1->SetWindowText("hello world"); compile it and run it and you have taken your first steps. Dialog based projects are overly simple and making them do big things takes a lot of hackery, but you can get the basics down using them on how to use the various widgets and to have things talking to each other and so on.
Qt is nice but it isnt WYSIWYG and its hard to work with due to that. You get used to it, but I would not have wanted to start there as a windows guy. You do eventually tend to end up here if you want stuff to move to other OS ...
Qt is nice but it isnt WYSIWYG and its hard to work with due to that. You get used to it, but I would not have wanted to start there as a windows guy. You do eventually tend to end up here if you want stuff to move to other OS ...
Last edited on
@jonnin,
Excellent point.
It's also why I tend toward wxWidgets. It can be either. Qt is slicker - Qt Creator is quite nice. wxWidgets doesn't have a full counterpart to it.
| Qt is nice but it isnt WYSIWYG |
Excellent point.
It's also why I tend toward wxWidgets. It can be either. Qt is slicker - Qt Creator is quite nice. wxWidgets doesn't have a full counterpart to it.
@Niccolo,
Petzold's 5th Edition has a CD with Win32 code that doesn't work when compiled with Visual Studio 2017 or 2019. Most of the original code works fine, there are a few apps that crash as originally written.
Someone, not Petzold, is updating the source to work with VS, though the github project isn't complete.
https://github.com/recombinant/petzold-pw5e
There is at least one "updated" example that still doesn't work. Chapter 10's Poe Poem. It "borks" on reading the text file, and I am too lazy at this time to look at trying to fix it.
Petzold's 5th Edition has a CD with Win32 code that doesn't work when compiled with Visual Studio 2017 or 2019. Most of the original code works fine, there are a few apps that crash as originally written.
Someone, not Petzold, is updating the source to work with VS, though the github project isn't complete.
https://github.com/recombinant/petzold-pw5e
There is at least one "updated" example that still doesn't work. Chapter 10's Poe Poem. It "borks" on reading the text file, and I am too lazy at this time to look at trying to fix it.
I noticed no one mentioned the GUI framework that Stroustrup uses in his classroom lectures written into book form (Programming -- Principles and Practice Using C++):
FLTK - the Fast Light Toolkit.
https://www.fltk.org/
I really haven't tried any of the 3rd party GUI frameworks, I've stuck it out with Win32.
FLTK - the Fast Light Toolkit.
https://www.fltk.org/
I really haven't tried any of the 3rd party GUI frameworks, I've stuck it out with Win32.
@Furry Guy,
I intentionally skipped it. If the reader isn't following Stroustrup's book, it isn't likely that FLTK comes up on the radar. I find it a bit too simple, but it does work.
I just can't justify the Win32 API at this point. The only reasonable reaction a C++ programmer should have to Win32 is encapsulation.
It seems a philosophical problem to write software tied to one operating system at this point.
The benefit of being able to provide MAC and Linux/UNIX versions trivially to clients is just too important. None of us should support Microsoft's de facto monopoly.
Most of the important applications are using Qt (some on wxWidgets), like AutoDesk applications, Adobe applications, etc. While they don't generally produce Linux builds, they could, and for now that's sufficient.
The world really needs Microsoft to get out of the way. It would have nearly zero importance if the major applications were published for Linux and MAC.
I intentionally skipped it. If the reader isn't following Stroustrup's book, it isn't likely that FLTK comes up on the radar. I find it a bit too simple, but it does work.
I just can't justify the Win32 API at this point. The only reasonable reaction a C++ programmer should have to Win32 is encapsulation.
It seems a philosophical problem to write software tied to one operating system at this point.
The benefit of being able to provide MAC and Linux/UNIX versions trivially to clients is just too important. None of us should support Microsoft's de facto monopoly.
Most of the important applications are using Qt (some on wxWidgets), like AutoDesk applications, Adobe applications, etc. While they don't generally produce Linux builds, they could, and for now that's sufficient.
The world really needs Microsoft to get out of the way. It would have nearly zero importance if the major applications were published for Linux and MAC.
the only way windows will be knocked out of its position is to capture the key markets that M$ holds. Linux / opensource and even paid for software packages are not seriously trying to provide software ... like the lottery, you can't win if you don't play. M$ isnt in the way -- they provide what consumers want that is simply not available on linux or mac.
So you hit the nail on the head ... its the programs that are on windows and not on linux. And running a VM is the same as running the OS, only slower -- no one with a life wants to run stuff slower (and jumping thru hoops usually) just to get geek cred.
You can't blame M$ for that, or expect them to roll over and die in the name of progress. If linux wants to take over, they have to convince devs to publish stuff for their OS and convince home users to swap over. If they can make a better product, they will eventually convert most people --- but it has not happened, and its not due to inertia at this point. Its that lack of a better product problem. equality isnt good enough. Equality and free vs paid would be, but that is the ultra rare exception (though oft mentioned).
So you hit the nail on the head ... its the programs that are on windows and not on linux. And running a VM is the same as running the OS, only slower -- no one with a life wants to run stuff slower (and jumping thru hoops usually) just to get geek cred.
You can't blame M$ for that, or expect them to roll over and die in the name of progress. If linux wants to take over, they have to convince devs to publish stuff for their OS and convince home users to swap over. If they can make a better product, they will eventually convert most people --- but it has not happened, and its not due to inertia at this point. Its that lack of a better product problem. equality isnt good enough. Equality and free vs paid would be, but that is the ultra rare exception (though oft mentioned).
Last edited on
There is zero question that Linux is vastly superior operating system to Windows.
What most people assume is that the GUI is the operating system. It isn't.
It is technically possible to run the MAC GUI on Linux. Users of the MAC wouldn't know the difference. Most of them don't realize UNIX is under that hood.
If there were a genuine GUI (not wine) for Microsoft's GUI API for Linux, hardly anyone would know if the underlying OS was still Microsoft's or not.
It is the GUI which users complain about (when it changes). My wife would rather switch to MAC than leave Windows 7, for example.
The public actually has no idea how to compare these things. No one really cares what the Windows operating system is doing (and doing badly by comparison to Linux).
Linux does not compete. There are no advertisements. There's no real corporation competing with Microsoft the way Apple does with MAC.
MAC's operating system is vastly superior, but not because of Apple. It's because of the BSD implementation of UNIX. Even MAC users don't realize this.
Windows users despise the MAC GUI. Many don't care much about the hardware, while others do.
Apple hasn't seemed to suffer, given their direction, as a company.
Microsoft is already fading. The Windows 7 to 10 migration shows this. Users are weary, suspicious...but locked. It has less to do with Windows itself, and more to do with the applications they require.
I have reason to believe Microsoft will only get worse in this regard.
What most people assume is that the GUI is the operating system. It isn't.
It is technically possible to run the MAC GUI on Linux. Users of the MAC wouldn't know the difference. Most of them don't realize UNIX is under that hood.
If there were a genuine GUI (not wine) for Microsoft's GUI API for Linux, hardly anyone would know if the underlying OS was still Microsoft's or not.
It is the GUI which users complain about (when it changes). My wife would rather switch to MAC than leave Windows 7, for example.
The public actually has no idea how to compare these things. No one really cares what the Windows operating system is doing (and doing badly by comparison to Linux).
Linux does not compete. There are no advertisements. There's no real corporation competing with Microsoft the way Apple does with MAC.
MAC's operating system is vastly superior, but not because of Apple. It's because of the BSD implementation of UNIX. Even MAC users don't realize this.
Windows users despise the MAC GUI. Many don't care much about the hardware, while others do.
Apple hasn't seemed to suffer, given their direction, as a company.
Microsoft is already fading. The Windows 7 to 10 migration shows this. Users are weary, suspicious...but locked. It has less to do with Windows itself, and more to do with the applications they require.
I have reason to believe Microsoft will only get worse in this regard.
Microsoft is already fading. The Windows 7 to 10 migration shows this. Users are weary, suspicious...but locked. It has less to do with Windows itself, and more to do with the applications they require.
yes, this is what I was saying too, except I am not convinced it is fading. As far as 7-10 goes, I have long said that every other windows version is a bust. 3.x was good, windows for workgroups was a bust, NT 3x was awful, 95 was awful, 98 was great, nt4 was pretty good, 2k was good, me bad, xp was good, vista was junk. And there it gets weird... 7, 8, and 10 were all pretty stable and about the same to me, but 7 is king still, 8 was ignored and 10 was forced and disliked (for no reason I have found, 0 issues for me). Whatever comes next, if its done well, will probably keep the borg going.
I don't know a single non-coder home user on linux. I know a few on MAC, and most of them can't use the unix part of the OS at all, they just maccin' on the UI. Granted, most of my peers are gamers, and games are poorly supported. There is a group that will use the best available ... they would swap if the stuff worked right and was supported and released on linux. But it isnt.
Last edited on
Topic archived. No new replies allowed.