I had a similar experience. I'd been doing C++ for DOS with some x86 assembly for a couple years when I somehow got access to Visual C++ (probably version 5) with MFC. Just getting to Hello World took me a solid week. Eventually I wrapped my head around it, but moved to C#/WinForms as soon as that came out.

Boggled my mind in university that c# was so smooth to get an application running, and the same ideas could not be applied to C++, in basically the same Coding environment. Tried for 4 separate times, always threw the towel.

I tried to switch from Delphi to Visual C++ around the same time, which made me appreciate even more how easy it was to build a GUI app with Delphi as opposed to the way VC++ did it (having a barebones visual designer and other than that forcing you to use all the gnarly APIs directly), how straightforward Object Pascal was compared to C++, and how much faster the compiler was, and decided to just stick with Delphi for the time being. The later .NET IDEs improved the usability quite a bit (thanks Anders Hejlsberg!), but those were for .NET, they didn't generate native code.

They do generate native code at installation time via the NGEN tool, and Managed C++ (later C++/CLI) can created mixed mode Assemblies, where native code is embedded on the file, which is the reason why mixed mode Assemblies can't be considered safe from CLR point of view.

Then let me tell you that programming X Windows is even worse, from the point of view of someone that knows Windows since Windows 3.0, and learned it via Turbo Pascal for Windows and Turbo C++ manuals.

X Windows at least has the "advantage" that you can download the code for Xlib or the Xorg server itself to see what's going on under the hood.

Although, you're going to have to be fairly proficient to get your head around that stuff too.

Agree that X11 has a dreadful API.

Which wasn't necessarly how X Windows worked in commercial UNIX, so having the source code wasn't of much help.

And that O'reilly X Windows book series, The Definitive Guides to the X Window System, a "tiny" set of 8 books, only for the UI stack.

Its a been a while since I did any X development but as far as I recall as an application (client) developer you generally only needed to know about the client library you were using together with some lower level details from Xlib?

Only if using something like Gtk+, which is mostly a cross-platform kind of approach anyway.

X Windows with the X Athena Widgets, or Motif, you better have all those books.

There was a period of time when Microsoft were very enamoured of the document-view model of desktop applications; you could choose to build MDI (multiple document interface) or SDI (single ...) applications, complete with menu management, so if you want to do a Word clone, knock yourself out. however if you just wanted a simple doohickey with a few buttons and whatnot - like the vast majority of cases - you were out of luck. There was of course a way to do this (and it became easier in later releases of Visual C++), but you had to fight the stupid M/SDI model the whole way.

> The Visual Studio 6 box had an introduction book to win32 and MFC ... Nothing made sense to me, a lot of boiler plate code was there without much explanation about why it was there.

Some of this is a symptom of the fact that Microsoft was still fumbling in the darkness regarding its Windows developer experience.

First generation windows programming was a complicated affair involving a number of command line tools, textual languages, and switching back and forth from the GUI to DOS. The first Visual BASIC product fixed all of that, and made it possible to achieve good results with just point and click and (more or less) scripting code.

My read on Visual C++ (predecessor to Visual Studio) was that Microsoft was pushing hard to graft the Visual BASIC style of point and click development onto its old school Windows development tools. The result was an IDE with a form editor that could superficially work a lot like Visual BASIC. You could drag a button, double click it, and be dropped into a blank C++ (rather than BASIC) function to handle the click event at runtime.

They did this with specific features in MFC, but also with a huge amount of default code generation. Double clicking that button in the form designer would update message maps, write a function, and make a number of other changes in the source text of what was already a large body of generated code.

The trouble is that while this worked, it didn't actually teach people what was going on. The development environment wound up being very brittle and hard to understand, particularly if you did anything that confused the IDE integration.

Do you think they took this approach because it wasn’t yet common wisdom in the industry that tons of generated code is a terrible idea, or because they didn’t want to fragment the developer ecosystem by adding a more comprehensive framework above Win32?

I suppose it could’ve been a bit of both.

They introduced this system with Visual C++ v1, which is also known as Microsoft C v8. (There are nuances, but that captures the gist.)

The preceding version, MSC v7, was the first version of the Microsoft C compiler to support C++. It's also where Microsoft introduced the first version of Microsoft Foundation Classes.

My understanding of the history of MFC is that MFC is Microsoft's second attempt at a C++ class library for C7. Prior to MFC, they had developed a significantly more object oriented framework, but found it in testing to be confusing to developers of the time. (Who had just ascended the Win16 learning curve itself.) Micsoroft retrenched, and the MFC 1.0 they shipped with C7 was a much thinner layer over the Win16 API than what they had initially planed. (The earlier framework was AFX, which is why there are AFX prefixes in the MFC codebase.)

My presumption with respect to Visual C++ 1 is that Microsoft found themselves short on time and facing dual mandates of maintaining MFC 1.0 source compatibility and producing a C++ development experience a little like Visual BASIC. So a bunch of IDE trickery and codegen logic was the logical path forward. (IIRC, the Visual BASIC compatibility mandate extended as far as enabling VB custom controls to work in Visual C++ projects.)

I haven't used it, but Borland Delphi post dates all of this, and gets it better. Borland was able to specifically build a class library and extend the programming language itself in a way that supported visual design tools. My understanding is that this can give some of the Visual BASIC style point-and-click, but also makes it easier to delve into the underlying framework code and make your own components. (Also important to note that Delphi was Borland's second attempt at a Pascal based windows development tool.... the earlier Turbo Pascal for Windows was a lot closer to the Win16/MFC-like experience)

Win32 programming was more akin to the X-windows protocol/API and boy.. let me tell you that Win32 was kids play in comparison to the fragmented mess that is raw X-windows (It's not for nothing that KDE is/was built on QT and Gnome on GTK).

Yes, the auto-generated boilerplates was stupid (and obscured so much) but it was their way of trying to get people ahead in an "easier" way.

When I messed around with X programming I thought the base layer was primitive, but straightforward for the most part. You had to do damn near everything my hand, but it was clean and orthogonal.

Where the nightmare started is the X toolkit. It slathered on three extra layers of complexity before providing any benefit for the programmer and was so damn confusing even when you did get it working. And what did you get out of it? Athena widgets.

GTK is a dream in comparison.

It’s funny how different this was ~10 years later. Visual studio was basically best-in-class as an ide (I think) and you could throw together a simple app pretty easily just using the mouse to design the form and writing functions in C# with a bit of google or just looking through the autocomplete list. But maybe that’s a bit rosy and if one wants something more complicated, it all drops back into win32 api stuff.

And then there are people who tell you with a straight face that Windows is a great development environment.