[koonsolo]

> MFC had its set of quirks, and development was quite painful

I had the same experience. And then I learned win32, the C predecessor of MFC, and it all started to make sense.

MFC is basically a horrible attempt to put an Object Oriented layer on top of win32. But they failed miserably at it. The API was so bad that I preferred just writing it in win32.

And no, this was not a failure of OO, this was a failure of understanding and applying OO.

[becurious]

The message map macros were the equivalent of the switch statement in a WndProc. They couldn’t add every Windows message as a virtual override because every derived class would have needed thousands of vtable entries. At the time memory was still very limited (4MB systems for Windows 95 and they also had support for 16 bit Windows where it would have been even worse).

Also the template support in the compiler was limited at the time. Later on there were other libraries that used templates like ATL and WTL.

You did get a lot for free from MFC when implementing document editing applications for OLE support, but that was an increasingly small portion of development.

I think Borland went a different way with compiler extensions for producing a Win32 application with their OWL library.

[int_19h]

It wasn't a failure of understanding. It was a deliberately low-level architecture that could be mapped extremely close to the underlying Win32 API for minimal overhead, and give the developer full control over what happens when, while providing some convenience layer especially to deal with common / recommended patterns at the time (document-centric UI, drag and drop, OLE etc).

I agree that this particular combination of features was not as useful in practice as the higher-level and more free-form approach offered by e.g. Delphi. But that's a different story.