What does "Windows" mean?

From my book:

"I’ll mention a caveat about terminology that you need to be conscious of before I move on. Users tend to think of a window as the thing that appears on the screen with a border around it, and, of course, it is, but it is only one kind of window. In Windows a window is a generic term covering a whole range of entities. Many entities that are displayed are windows — for example, a dialog is a window and each toolbar and dockable menu bar are also windows. I will generally use terminology to refer to objects that describe what they are, buttons, dialogs, and so on, but you need to have tucked in the back of your mind that many of them are windows too, because you can do things to them that you can do with a regular window — you can draw on a button, for instance."

What the author mean by you can draw on a button?
What the author mean by you can draw on a button?
Exactly what it says, you can draw text, images, etc... on buttons. In Win32 all controls (buttons, text boxes, toolbars, etc..) are all child windows of the main window.
Oh you can? Wow thats cool lol, never knew that was possible.
Last edited on
Also I assume you use the MFC, so well do you think its obsolete and I should learn QT instead?
Last edited on
Also I assume you use the MFC, ...

To draw on a button, you mean?

Not necessaily. MFC is a wrapper around the core of the Win32 API (plus other stuff, like the Document-View support). It uses GDI (the Graphics Device Interface) for its drawing. Anything you can do with MFC, you can do using the GDI API directly (sometimes with a bit more effort.)

Windows also supports a number of other drawing mechanisms, all (or at least most) of which are usable by an MFC application (but not directly supported by MFC) or a native Win32 app. For example, GDI+ or Direct2D (from Windows 7 -- Windows 8 includes it as shipped, but Windows 7 requires a platform update)

do you think [MFC is] obsolete and I should learn QT instead?

When it comes to the choice between MFC and Qt, it's more a question of whether you want to write Windows-specific or cross-platform code. MFC is not dead yet! (See PS)

But MFC is only easy to use with the paid-for editions of Visual Studio. The MFC headers and libraries are included in the Windows Driver SDK, so it's possible to build MFC apps with the express editions -- or with g++, etc, but not the MFC tools/wizards which make it simpler to handle all the required boiler plate code.

(The merits of the different cross-platform GUI toolkits have been discussed in a number of cplusplus.com threads -- search this site for more info.)

Also note that a lot of Win32 GUIs these days are written using the Windows Presentation Foundation (WPF). This is .NET so must be used from a managed language like C# or C++/CLI, rather then (native) C++.

The current stats for job ads (in the UK, looking at the last 3 Months) is:

  Desc  Rank  Rank    Avg      Salary  Matching       Jobs
              Change  Salary   Change  Jobs           Found
  WPF    99   +11     £42,500  +6.25%  2955 (2.734%)  Jobs (362)
  MFC   637   -34     £37,500   0       226 (0.209%)  Jobs ( 35)
  Qt    686   +48     £37,500  -6.25%   176 (0.163%)  Jobs ( 32)

From: IT Jobs Watch, Tracking the IT Job Market


PS As far as Microsoft are concerned, both GDI and GDI+ are legacy.

Legacy Graphics

But Direct2D is only available from Windows 7 and there is not only a lot of pre-existing MFC code out there, but companies still want to write code to support pre-Windows 7 computers (support for Windows XP is ending on April 8, 2014; for Windows Vista it's April 11, 2017.)

Windows lifecycle fact sheet




MFC Direct2D Hello World sample

Windows Presentation Foundation
Last edited on
Well thanks!

What does "Windows" mean?

Of course, some people think it means:

Will Install Needless Data On Whole System

Also hey, what does integrating factor mean in this context?

"The integrating factor in your Windows desktop application is Windows itself, which links to both WinMain() and WindowProc(). After looking into what the pieces are that make up WinMain() and WindowProc() you will assemble them into a working example of a simple Windows program."

To be honest, why the term "integrating factor" is used there is unclear to me. When I googled for it, the first few pages of hits were all about maths, where the term does make sense (a factor you use when integrating, in the maths sense.)

Anyway, dictionary.com defines "integrating" as "to make up, combine, or complete to produce a whole or a larger unit, as parts do.", etc. So I guess (he) means that an application relies on Windows message routing functionality to join the app up.

It does sort of make sense as:
- Windows adds messages to your apps message queue (or queues -- you can have more than one)
- the app retrieves each message in turn (using GetMessage) and preprocesses it (TranslateAccelerator, etc.) or discards it, as required
- then the app passes the message back to the system (DispatchMessage)
- the system then calls the app back using the WinProc for the window class.
- the message arrives at your app's WinProc and you app does something

But I wouldn't put it that way. Maybe like this?

"Windows plays an integral part in the operation of your application in that it routes messages between (the message loop in) your application's WinMain and its WindowProc. After looking into the pieces that make up WinMain() and WindowProc(), you will assemble them into a simple Windows program."

Not sure that's any better??

Last edited on
Yea same, I was confused as well because of that.

Well thanks!
Topic archived. No new replies allowed.