Windows C++: a bit shocked
-
I have Visual Studio 2019 installed on my machine. I just built a C++ desktop app from template. I will continue the shocking part of this story but first a little history... Around 1993 Long ago (1993) I started learning C++. The developers in my group at that time were writing a large program using Visual Studio 1,2,3, etc. and developing on the Windows SDK -- SDK style programming which was basically C wrapped up in Microsoft's way of doing things. MFC : I Thought It Was Fantastic Okay, but at that same time a fantastic thing was born: MFC (Microsoft Foundation Classes) This was true C++ wrappers around the API calls. It was quite fantastic and I began to learn it. It was kind of like C# before C# was released. I was stuck between these amazing devs who knew Win API SDK style programming and the MFC (which used true OOP). The generation in front of me wanted little to do with these "unnecessary wrappers around the API" But I continued into MFC. Finally, around 1999 Microsoft announces C# and I am angry. :mad: Java-like? Throw away this investment into the MFC? :mad: Well, it'll be okay, because people will come to their senses and see that MFC is already doing all this stuff they're only promising with C#. Yeah, that's the ticket! I Jump On Board C# Finally, I jump on board the C# train and it becomes a rocket. It's the Windows API wrapped in OOP. There are missing things (as the .NET libraries become mature) and I understand how to get to those with pinvoke which is based upon my experience with (yes, Visual Basic) and knowing the Win API from MFC, etc. We Now Return To My Original Shock So, now, it's like 20 years later and I build a desktop app from the Visual C++ template and what do I see? Original Windows API stuff!!!! :wtf: :wtf: It's the unwrapped, unvarnished message loop!!!
// Main message loop:
while (GetMessage(&msg, nullptr, 0, 0))
{
if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}It's the old RegisterClass (not related to OOP and classes but related to WNDCLASS).
//
// FUNCTION: MyRegisterClass()
//
// PURPOSE: Registers the window class.
//
ATOM MyRegisterClass(HINSTANCE hInstance)
{
WNDCLASSEXW wcex;wcex.cbSize = sizeof(WNDCLASSEX); wcex.style = CS\_HREDRAW | CS\_VREDRAW; wcex.lpfnWndProc = WndProc; wcex.cbI had a look at my VS2019 installation. I had to install the Visual C++ MFC x86 and x64 before I could create a MFC desktop application. All working as expected now.
-
Maybe this is an effort to force C++ people to use WinRT/UWP instead of MFC. They will end up forcing everyone to switch to Qt.
-
I notice the event loop in the template still doesn't deal with the return from GetMessage being TRUE, FALSE or -1. For details on this little treasure of the Win32 API see the middle-bottom of the following page (under return value): GetMessage function | Microsoft Docs[^] Regarding MFC, I always found it a bit of a cludge in places and fairly incomplete. I often had to resort to Win32 calls to get stuff done. I recently had to do some additions to an old MFC project and started to think this wasn't all that bad...until I realised that a list control needs each line measuring to determine whether to show a horizontal scrollbar! Mercifully, you get a vertical one automatically. When the .NET framework/Forms/WPF came along this sort of thing just went away. The API was much more complete, along with the revelation that you can still use something that looks like C++ (C++/CLI, NOT managed C++ which needed taking out the back and shooting) to program it - it seemed like a whole new world! I still use C++/CLI rather than p/invoke as I find it much cleaner where I need to get down to low level stuff or interface with pure C++ libraries.
-
standard microsoft practice. they do what they want and they don't care. if there is popular unrest that will imply negative $ outcome they'll think about it, but still do what they know is "for the good of the world". they can sustain negative $ outcome for a couple of years before they cancel the "for the good of the world" action, but in those years they will support countless trolls in the fight for their "good of the world" view. interestingly, my developing path was the opposite of yours. i switched from turbo pascal on dos to c++ on windows programming with mfc, that's what we used in the firm. we could do some things but i soon discovered that nor me nor the seniors knew how things worked and just to say that, in c or pascal, pointers are one of my strongest points and i knew (1998 year) c++ well enough so virtual destructors, copy constructors and assignment overloading were a piece of cake for me. then i got me the win32 forgers tutorial and later the petzold's programing windows. i never looked back at mfc or even oop for that matter. c++ is okay because you can switch to plain c anytime you decide. it is not c here that is important, it is the liberty to chose your style to organize the code and the liberty to pass by value or pass by reference as you like. unlike java that puts a constraint on you. oop and graphical user interfaces got popular at the same time and they are a perfect match. gui's best match for a data type would be a hierarchy of objects. other than that it has more weak points that strengths compared to common good programming practice. of course "in matters of taste, there can be no disputes". my taste is for freedom. i fight for a standard where c compilers would not issue a compile time error if you pass a "wrong" type of argument to a function without type casting, but a warning would be mandatory. let the juniors learn programming in the most strict type safe languages, but when they come to work in c they'll have to face complete freedom and responsibility.
Great post and interesting experience.
sickfile wrote:
then i got me the win32 forgers tutorial and later the petzold's programing windows. i never looked back at mfc or even oop for that matter.
Very interesting.
sickfile wrote:
let the juniors learn programming in the most strict type safe languages, but when they come to work in c they'll have to face complete freedom and responsibility.
Interesting philosophy. I like compilers to warn me about things as much as possible. And type checking is quite helpful. I think of "string programming" often and how that if everything is based upon a string then you can hurt yourself terribly because the "string" is only evaluated at run-time and then maybe that string has the wrong type in it and everything fails. I lean as far away from that idea as I can because those types of things can be very difficult to find in production code. By saying this I'm not saying your advocating "string programming", it's just a way of explaining why I do like modern frameworks and compilers to a certain extent...but not beyond that extent as some things try to take it to the place where devs "dont ahve to think".
-
Nice post. I understand exactly where you're coming from. One bit I can add is that I can remember, about 15 years ago, taking a relatively large application written in C++/MFC and recompiling it with C++/CX, adding .Net features, hooking it up to WCF, and even having it support auto-install when new versions were available. As far as I was concerned, that was the future. Little did I know how strongly Microsoft was hated. Why didn't C++/CX catch on? Because it was Microsoft-only, and that meant you couldn't write software for the 5% Mac/Linux market that zealots struggled mightily to target. Then Java comes along and, though it does have some strong points, it really has nothing over VB other than it's not Microsoft. Finally, someone figures out the right coding gymnastics and mystical incantations to get javascript to work in a browser. True, the resulting software was and still is vastly inferior, but it does have one thing going for it: It's not Microsoft! So now a generation of developers is condemned to a world where javascript is actually considered capable of making production-quality code because the users have been conditioned to accept it. So here we are now writing software whose responsiveness would make the 90's VB guys laugh all while laboring under platform burdens: *Types, what's that? *Threads, you mean link on my shirt? *Oh, F5? Yeah, don't touch that. *No, don't use that menu, that's the browser's menu. Use the menu within the menu. *No, that window can't be moved. It's just drawn to look like a window. *Sorry, you need Internet access to use the software, but have I mentioned that it doesn't require Windows to run? Yeah, I know most people still run Windows, but Windows isn't open source!
Great post. It is very interesting that the weakest language choice of all (JavaScript) has become the defacto standard for coding. I really, really like JavaScript but I also hate a lot of it. There are still no great debuggers for it -- setting them up is annoying and you don't get the kind of debugging you get from other compiled languages. JavaScript teaches many anti-patterns of coding that have to later be torn out. And, as Internet rumors go sometimes those anti-patterns are vehemently fought for and almost become an issue of, "well, who can say really?" Meanwhile we had these better stronger languages that got ignored because of ease. Python is kind of the same travesty. Anyone can Python something. Just add a library. :rolleyes:
-
I had a look at my VS2019 installation. I had to install the Visual C++ MFC x86 and x64 before I could create a MFC desktop application. All working as expected now.
-
Super Lloyd wrote:
And UWP is better used in C++
Hmm...I was trying to find out if you could build XAML (UWP basically XAML) UI and C++. WPF never did get to C++ you were stuck in C# basically. And I'm not sure that moderncpp is still going. It mentions Win/RT which I believe was left behind by MS also. You really can't tell where MS is going with C++. They're kind of leaving it behind....but they're kind of supporting it via Win API /SDK type of framework which is weird and old. MS probably has no idea theirselves. :laugh:
Well.. UWP is a failure but.. it has some redeeming qualities nonetheless. - All new devices API (like GPS, accelerometer, etc..) they are UWP - (relatively) easy to mix and match DirectX and XAML (i guess if you are a game developer might be good? dunno you might go 100% Unity anyway) - Best Microsoft provided API to write GUI application in C++ IMHO, or at the very least the most modern one - easy deployment, but stringent limitations, so it's a tossup
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Nice post. I understand exactly where you're coming from. One bit I can add is that I can remember, about 15 years ago, taking a relatively large application written in C++/MFC and recompiling it with C++/CX, adding .Net features, hooking it up to WCF, and even having it support auto-install when new versions were available. As far as I was concerned, that was the future. Little did I know how strongly Microsoft was hated. Why didn't C++/CX catch on? Because it was Microsoft-only, and that meant you couldn't write software for the 5% Mac/Linux market that zealots struggled mightily to target. Then Java comes along and, though it does have some strong points, it really has nothing over VB other than it's not Microsoft. Finally, someone figures out the right coding gymnastics and mystical incantations to get javascript to work in a browser. True, the resulting software was and still is vastly inferior, but it does have one thing going for it: It's not Microsoft! So now a generation of developers is condemned to a world where javascript is actually considered capable of making production-quality code because the users have been conditioned to accept it. So here we are now writing software whose responsiveness would make the 90's VB guys laugh all while laboring under platform burdens: *Types, what's that? *Threads, you mean link on my shirt? *Oh, F5? Yeah, don't touch that. *No, don't use that menu, that's the browser's menu. Use the menu within the menu. *No, that window can't be moved. It's just drawn to look like a window. *Sorry, you need Internet access to use the software, but have I mentioned that it doesn't require Windows to run? Yeah, I know most people still run Windows, but Windows isn't open source!
CygnusBMT wrote:
Little did I know how strongly Microsoft was hated. Why didn't C++/CX catch on? Because it was Microsoft-only
I sure recognize that. It frustrates me even more in another area, one that is not MS-only, just that MS was the first major company to adopt it: When I for the 17th time that day have to specify a password to get access to some service, I expel words that migth cause my post to be censored, if I wrote them down here. For 25+ years, we have had a very well designed solution for that. Every time I read about another passord leak, where x million passwords have come out in the wild, I sigh: For 25+ years, we have had a very well designed solution for that. Why should a cleartext password ever be transmitted over Internet? There is no need whatsoever for that! It is like every border crossing insisting on a specific passport for that crossing. Or a movie theater ticket where I have to specify a secret code before being allowed to use it to enter the theater. MIT did an excellent job designing the Kerberos system. Sure, version 5 does have some functional limitations, such as safe forwarding of authorization to backend servers - but none of the solutions used today handle that! Those limitaions is definitely not the reason why Kerberos authentication was not adopted on a wide scale. Nor is it explained by any sort of "proprietary" arguments - it is free and open source code. Its origins are in the Unix world, and it standardized in the RFC series - it is not steered and controlled by some commercial company (the way e.g. Java is). It has been thoroughly testet on a wide range of operating systems. There are several (very well written) articles describing the principles, and these are well known in the academic communities. So why are we still fighting with umpteen daily password entries, with lots of password leaks, with every service making different requirements for "secure" passwords... The is one essential reason: When Kerberos 5 arrived, Microsoft was the first major commercial vendor to adopt it, before it had gained foothold on other platforms (notably *nix and open-source). Rather than saluting the early MS adoption, MS antagonists concluded that "If MS is going to use it, we, sure as h*** are not going to!" In theory there shouldn't be a Not Invented Here syndrome - MIT isn't Microsoft. Yet, being the first major adopter had that effect. My guess is that if
-
Nice post. I understand exactly where you're coming from. One bit I can add is that I can remember, about 15 years ago, taking a relatively large application written in C++/MFC and recompiling it with C++/CX, adding .Net features, hooking it up to WCF, and even having it support auto-install when new versions were available. As far as I was concerned, that was the future. Little did I know how strongly Microsoft was hated. Why didn't C++/CX catch on? Because it was Microsoft-only, and that meant you couldn't write software for the 5% Mac/Linux market that zealots struggled mightily to target. Then Java comes along and, though it does have some strong points, it really has nothing over VB other than it's not Microsoft. Finally, someone figures out the right coding gymnastics and mystical incantations to get javascript to work in a browser. True, the resulting software was and still is vastly inferior, but it does have one thing going for it: It's not Microsoft! So now a generation of developers is condemned to a world where javascript is actually considered capable of making production-quality code because the users have been conditioned to accept it. So here we are now writing software whose responsiveness would make the 90's VB guys laugh all while laboring under platform burdens: *Types, what's that? *Threads, you mean link on my shirt? *Oh, F5? Yeah, don't touch that. *No, don't use that menu, that's the browser's menu. Use the menu within the menu. *No, that window can't be moved. It's just drawn to look like a window. *Sorry, you need Internet access to use the software, but have I mentioned that it doesn't require Windows to run? Yeah, I know most people still run Windows, but Windows isn't open source!
Thank you, sometimes its good to read some sanity.
Quote:
So here we are now writing software whose responsiveness would make the 90's VB guys laugh all
Oh god, we now have web-browser based text editors! Type key, wait 300 ms (on a 2019 i9 with 64 GB RAM) and then the text shows on screen. I hate it.
-
I have Visual Studio 2019 installed on my machine. I just built a C++ desktop app from template. I will continue the shocking part of this story but first a little history... Around 1993 Long ago (1993) I started learning C++. The developers in my group at that time were writing a large program using Visual Studio 1,2,3, etc. and developing on the Windows SDK -- SDK style programming which was basically C wrapped up in Microsoft's way of doing things. MFC : I Thought It Was Fantastic Okay, but at that same time a fantastic thing was born: MFC (Microsoft Foundation Classes) This was true C++ wrappers around the API calls. It was quite fantastic and I began to learn it. It was kind of like C# before C# was released. I was stuck between these amazing devs who knew Win API SDK style programming and the MFC (which used true OOP). The generation in front of me wanted little to do with these "unnecessary wrappers around the API" But I continued into MFC. Finally, around 1999 Microsoft announces C# and I am angry. :mad: Java-like? Throw away this investment into the MFC? :mad: Well, it'll be okay, because people will come to their senses and see that MFC is already doing all this stuff they're only promising with C#. Yeah, that's the ticket! I Jump On Board C# Finally, I jump on board the C# train and it becomes a rocket. It's the Windows API wrapped in OOP. There are missing things (as the .NET libraries become mature) and I understand how to get to those with pinvoke which is based upon my experience with (yes, Visual Basic) and knowing the Win API from MFC, etc. We Now Return To My Original Shock So, now, it's like 20 years later and I build a desktop app from the Visual C++ template and what do I see? Original Windows API stuff!!!! :wtf: :wtf: It's the unwrapped, unvarnished message loop!!!
// Main message loop:
while (GetMessage(&msg, nullptr, 0, 0))
{
if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}It's the old RegisterClass (not related to OOP and classes but related to WNDCLASS).
//
// FUNCTION: MyRegisterClass()
//
// PURPOSE: Registers the window class.
//
ATOM MyRegisterClass(HINSTANCE hInstance)
{
WNDCLASSEXW wcex;wcex.cbSize = sizeof(WNDCLASSEX); wcex.style = CS\_HREDRAW | CS\_VREDRAW; wcex.lpfnWndProc = WndProc; wcex.cbChances are about zero that MS would drop MFC at this point, but I am still only going on indicators. 1) MS has recently redesigned all the MFC code generation templates. They were looking pretty outdated. They now have the slick look of the VS Installer now. VS 2019 Preview is their first attempt at redesigning the rest of the project creation wizard. I think it has promise. MS is even experimenting with the Office-style semantic ribbon for the aging menu-based Visual Studio. (See WinDbg x64 Preview). 2) MS has in the last year released a very critical piece of technology called ARM64 meaning your exact same MFC code re-compiled should be able to run on SnagDragon chip sets with no overhead. Think MFC for the mobile market. What framework did they release it on? MFC. See VS Installers' Individual components. 3) IMO, it was inevitable that MS would eventually migrate back to ISO standard C++. MS finally realized it shouldn't be in the business of inventing (and maintaining) computer languages. The computing world has legitimate teams of well-qualified people that do this in the ISO standards org. And MS got out, but only after trying everything else. My point is, MFC provides a "very efficient way of connecting (windows) messages to (your) message handlers (in C++)" as Jeff Prosise wrote in his MFC book many years ago, while staying within the standard maintained by the rest of the world. And according to Herb Sutter, chair of ISO C++, the number of academic papers submitted to the committee this year has increased from 120 to 200 in one year. The one thing MS has over its competitors is backwards compatibility and MFC does just that with the added plus of the world advancing it for them. I write all my code in C++17 MFC. Never left it. I have been nervous for 15 years that MS would "embrace, expand, extinguish" MFC, but to their credit, they haven't, or more likely, they couldn't after many many attempts. It is paramount that my code be maintainable and the advances C++ has made over the years have let me do that. For example, my current app contains a real-time recursive parser which can be destructed without leaks for any depth or recursive complexity thanks to the std::shared_ptr C++ smart pointer innovation. And there are many more such innovations in the language I get for free in MFC.
-
Chances are about zero that MS would drop MFC at this point, but I am still only going on indicators. 1) MS has recently redesigned all the MFC code generation templates. They were looking pretty outdated. They now have the slick look of the VS Installer now. VS 2019 Preview is their first attempt at redesigning the rest of the project creation wizard. I think it has promise. MS is even experimenting with the Office-style semantic ribbon for the aging menu-based Visual Studio. (See WinDbg x64 Preview). 2) MS has in the last year released a very critical piece of technology called ARM64 meaning your exact same MFC code re-compiled should be able to run on SnagDragon chip sets with no overhead. Think MFC for the mobile market. What framework did they release it on? MFC. See VS Installers' Individual components. 3) IMO, it was inevitable that MS would eventually migrate back to ISO standard C++. MS finally realized it shouldn't be in the business of inventing (and maintaining) computer languages. The computing world has legitimate teams of well-qualified people that do this in the ISO standards org. And MS got out, but only after trying everything else. My point is, MFC provides a "very efficient way of connecting (windows) messages to (your) message handlers (in C++)" as Jeff Prosise wrote in his MFC book many years ago, while staying within the standard maintained by the rest of the world. And according to Herb Sutter, chair of ISO C++, the number of academic papers submitted to the committee this year has increased from 120 to 200 in one year. The one thing MS has over its competitors is backwards compatibility and MFC does just that with the added plus of the world advancing it for them. I write all my code in C++17 MFC. Never left it. I have been nervous for 15 years that MS would "embrace, expand, extinguish" MFC, but to their credit, they haven't, or more likely, they couldn't after many many attempts. It is paramount that my code be maintainable and the advances C++ has made over the years have let me do that. For example, my current app contains a real-time recursive parser which can be destructed without leaks for any depth or recursive complexity thanks to the std::shared_ptr C++ smart pointer innovation. And there are many more such innovations in the language I get for free in MFC.
Great post, very interseting.
rtischer8277 wrote:
ARM64 meaning your exact same MFC code re-compiled should be able to run on SnagDragon chip sets with no overhead.
Very cool. I hadn't heard about that.
rtischer8277 wrote:
IMO, it was inevitable that MS would eventually migrate back to ISO standard C++
That's exactly what I was thinking and hoping to always be true.
rtischer8277 wrote:
"very efficient way of connecting (windows) messages to (your) message handlers (in C++)" as Jeff Prosise wrote in his MFC book many years ago,
I always thought so. Also, that Prosise book is one of my knock-down, all-time greatest favorites of the tech book world. It covered stuff like no one else did and the "story of the technology" was presented so well. It felt like he was Charles Petzold II. But sometimes better.
-
Chances are about zero that MS would drop MFC at this point, but I am still only going on indicators. 1) MS has recently redesigned all the MFC code generation templates. They were looking pretty outdated. They now have the slick look of the VS Installer now. VS 2019 Preview is their first attempt at redesigning the rest of the project creation wizard. I think it has promise. MS is even experimenting with the Office-style semantic ribbon for the aging menu-based Visual Studio. (See WinDbg x64 Preview). 2) MS has in the last year released a very critical piece of technology called ARM64 meaning your exact same MFC code re-compiled should be able to run on SnagDragon chip sets with no overhead. Think MFC for the mobile market. What framework did they release it on? MFC. See VS Installers' Individual components. 3) IMO, it was inevitable that MS would eventually migrate back to ISO standard C++. MS finally realized it shouldn't be in the business of inventing (and maintaining) computer languages. The computing world has legitimate teams of well-qualified people that do this in the ISO standards org. And MS got out, but only after trying everything else. My point is, MFC provides a "very efficient way of connecting (windows) messages to (your) message handlers (in C++)" as Jeff Prosise wrote in his MFC book many years ago, while staying within the standard maintained by the rest of the world. And according to Herb Sutter, chair of ISO C++, the number of academic papers submitted to the committee this year has increased from 120 to 200 in one year. The one thing MS has over its competitors is backwards compatibility and MFC does just that with the added plus of the world advancing it for them. I write all my code in C++17 MFC. Never left it. I have been nervous for 15 years that MS would "embrace, expand, extinguish" MFC, but to their credit, they haven't, or more likely, they couldn't after many many attempts. It is paramount that my code be maintainable and the advances C++ has made over the years have let me do that. For example, my current app contains a real-time recursive parser which can be destructed without leaks for any depth or recursive complexity thanks to the std::shared_ptr C++ smart pointer innovation. And there are many more such innovations in the language I get for free in MFC.
"Chances are about zero that MS would drop ..." That's what we said about OleDB back in 2012 when they announced that they were dropping it... And of course they had to bring it back last year. Maybe they've learned?
-
Great post and interesting experience.
sickfile wrote:
then i got me the win32 forgers tutorial and later the petzold's programing windows. i never looked back at mfc or even oop for that matter.
Very interesting.
sickfile wrote:
let the juniors learn programming in the most strict type safe languages, but when they come to work in c they'll have to face complete freedom and responsibility.
Interesting philosophy. I like compilers to warn me about things as much as possible. And type checking is quite helpful. I think of "string programming" often and how that if everything is based upon a string then you can hurt yourself terribly because the "string" is only evaluated at run-time and then maybe that string has the wrong type in it and everything fails. I lean as far away from that idea as I can because those types of things can be very difficult to find in production code. By saying this I'm not saying your advocating "string programming", it's just a way of explaining why I do like modern frameworks and compilers to a certain extent...but not beyond that extent as some things try to take it to the place where devs "dont ahve to think".
i am talking about providing people who have learned programming (3+ years) in the most strict type safe languages the ability to work in a language that permits to call a function defined as having one integer parameter with a floating point argument. or something else like this: float f; char funct1(char c); char b = funct1(f); without a compile time error, only with a warning. i ask this because you can call an assembly subroutine that does logical floating point operations on some address in memory regardless i you put in that address something that for you is logically an integer. the subroutine will do it's job. and because the compiler sees that the function parameter should be of type char it will push to the stack frame for the function only char size data from the address of the float f. i advocate to make C more powerful not by moving it in the java (ex-hype) direction, but in the assembler direction on one side and on the other side by working on the preprocessor to make it as powerful as LISP is. the above floating point example is trivial and meaningless, but if you have structures composed of other structures that are hierarchically alined i am getting at something. and of course i am not going to hire for a C programmer someone who has not learned every bit of strict data types, but when this guy starts working in C i don't want the compiler to impose restrictions on him, only warnings. there is a big difference between a guy who values every byte and a guy who converts everything into string to avoid type errors.