... That is way before the C++ language was standardized. The compilers have advanced and that edition relies heavily on pre-standard C++.
...
Much of the code will not even compile on a modern compiler.
Pre-standard C++ ... true, back when it was called C.
Everything I've tried from the CD compiles fine on VS2013, BTW.
Win32 isn't that bad, but it is C, so you are constantly struggling against a lack of type-safety when decoding message structures. Its okay.
Re the high performance thing though, libraries that wrap Win32 (Qt, WxWidgets) and take a great deal of pain out of the process don't really preclude any of the performance. You have to bear in mind which bits need to be high performance - they are hardly likely to be related to the GUI. I doubt you need to shave any cycles off what happens when a button is pressed, or when a scroll bar is rendered.
It is more likely your high performance will be required in either calculation or rendering. In the first case, the GUI library you use is entirely irrelevant. In the latter case, GDI, which is the graphical part of Win32, is not an appropriate choice for high performance rendering in the modern world - you want to look at an API (OpenGL, Direct3D, Direct2D or whatever it is called, etc) that will take full advantage of graphics hardware, so again the library wrapper around the GUI is not important.
That all said, Win32 can be quite satisfying in a perverse sort of way and I still prefer it to underpin full-screen game applications since the Win32 needed is quite minimal. Since getting proficient with Qt at work though, I'd never write a raw GUI application again, but I've already had my years of fun with Win32 and you haven't so the best of luck to you.
Win32 isn't that bad, but it is C, so you are constantly struggling against a lack of type-safety when decoding message structures. Its okay.
Re the high performance thing though, libraries that wrap Win32 (Qt, WxWidgets) and take a great deal of pain out of the process don't really preclude any of the performance. You have to bear in mind which bits need to be high performance - they are hardly likely to be related to the GUI. I doubt you need to shave any cycles off what happens when a button is pressed, or when a scroll bar is rendered.
It is more likely your high performance will be required in either calculation or rendering. In the first case, the GUI library you use is entirely irrelevant. In the latter case, GDI, which is the graphical part of Win32, is not an appropriate choice for high performance rendering in the modern world - you want to look at an API (OpenGL, Direct3D, Direct2D or whatever it is called, etc) that will take full advantage of graphics hardware, so again the library wrapper around the GUI is not important.
That all said, Win32 can be quite satisfying in a perverse sort of way and I still prefer it to underpin full-screen game applications since the Win32 needed is quite minimal. Since getting proficient with Qt at work though, I'd never write a raw GUI application again, but I've already had my years of fun with Win32 and you haven't so the best of luck to you.
I see people here treats winapi as as GUI library - but winapi is not gui
(it has some gui in it but the most important thing is a 'base program
skeleton' window interaction with system by messages, input (keyboard /mouse) and some system things - "winapi gui" is only side thing in winapi imo [im using winapi abou 4 years, its program skeleton know
like some ancient inscryption (almost by heart) but never did yet any gui in this )
nice thing in win32 coding is that you can produce very smal exe with no redistribuable, for example recently i was tinkering with some basic raytracer code and its exe had 14k bytes and it worked (now i got it grow to 28k)
Agreed, GUI is the wrong term. I call Qt a GUI library but it is also far more so the term is not sufficient.
What we call it makes little difference to the points made in the thread though. Everything that applies to "drawing controls on the screen" also applies to "using the file system", or "using OS synchronization features" etc etc. A lot of pain in a C API for no real advantage other than interest and, as fir points out, the small corner case of requiring a small distributable - hardly a frequent concern these days but a valid point.
Yup, there is a lot of pain ;)
It's not worth it for the effort involved even if there is some performance gain. Use the right tools for the job. Win32 API is fine for small dialog apps it gets unwieldy very fast.
EDIT: Although I thought it was a good book, it's how I learnt to program Windows (actually OS/2, but noone does than anymore)
Win32 is many purposes system api which specyficaly includes api calls and some massage event system intended for creation and management of the window (or windows) and controls (also its contents and overall system resources)
personaly i wouldlike if winapi will still be going on yet for some years,
i was learned it, its my primary environment, it costed me some experience, proved that it works and give some fun finally so i would like it not to be spoiled or removed to fast.
