7 ms·

Win32, especially when it comes to GUI programming, is one of the worst APIs out there. MFC is also quite bad because of huge abstraction leakages; it fills li

Win32, especially when it comes to GUI programming, is one of the worst APIs out there. MFC is also quite bad because of huge abstraction leakages; it fills like Win32 with bolted on classes. It seems like Win32 happened a bit by accident, a bit by overengineering and a bit by Microsoft's attempt to lock everyone to their 'special' development environments, which did not include C as a conscious choice by Microsoft.

thrower123 7y ago
> It seems like Win32 happened a bit by accident, a bit by overengineering and a bit by Microsoft's attempt to lock everyone to their 'special' development environments, which did not include C as a conscious choice by Microsoft. Maybe I just haven't had my coffee yet, but I'm not understanding what this is supposed to mean.
- pjc50 7y ago
  I don't understand this either. They've always offered C. In many ways Win32 and NT are as much a ""C operating system"" as UNIX. The only "special development environment" might be Visual Basic.
  - dockd 7y ago
    Maybe they meant Microsoft didn't really stick to the C standard library. _strdup vs strdup. malloc vs HeapAlloc. assert, fopen, etc. The functions mostly exist but really aren't the way to program Windows.
- projektfu 7y ago
  After the p-machine era, MS was all in on C. They had some technical reason for preferring the pascal calling convention, like saving a few bytes of program text.
mschaef 7y ago
> Win32, especially when it comes to GUI programming, is one of the worst APIs out there. It's also one of the first. Win32's origins extend back over 35 years and start on machines with a tiny fraction of the capability of even the smallest of today's modern PC's. It was also built with a different set of tradeoffs and in a radically different culture of software development. (Most modern developers hadn't been born at the time of it's initial design, and most of the people who were actively writing this stuff in the early-to-mid 1980's, I'm sure have moved on. 35 years is pretty much a career.) > MFC is also quite bad because of huge abstraction leakages; it fills like Win32 with bolted on classes. That's pretty much what it was... by design. There was a more object-oriented library that Microsoft developed, prior to MFC. They tested it on developers that had essentially just come up to speed on the (then-new) Win16 API, who all complained about having to ascend another learning curve for a fancy object oriented language and framework. Microsoft's reaction was to drop the older framework (referred to as AFX) and develop MFC as a thin wrapper around Win16. (This is part of why there are AFX prefixes scattered throughout the MFC codebase.... it's a legacy of the earlier framework.) Even then, early versions of MFC had some utility, mainly around making things more type safe. Because it bound C++ instances to Window system instances, it made it easy to attach user data structures to UI components. (Otherwise, you were worrying about window or class words, which were Microsoft's original approach to that problem and used by MFC under the hood.) MFC also handled parsing of window message arguments. Win16 also sent messages with just a word and a long, when what you really might need is a set of mouse button flags and an x/y position or something. MFC helped with that too, by 'cracking' the message arguments into something closer to what you'd expect. (To this day, Win32 documentation still includes instructions on parsing WPARAMS, etc. https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-mousemove#remarks https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-m... )
jussij 7y ago
The design of Win32 is incredibly close to the design of Win16 and since Win16 dates back to early 90's you need to comparing it to GUI programming layers of that same era. So the question is, back then was there any better GUI programming layers? And the answer is yes, there was actually an API that was better and it was called OS/2. At that time Microsoft was in a partnership with IBM to develop OS/2. However, when the partnership fell apart, Microsoft just took big chunks of that OS/2 API and created a sub par version and called it the Windows API.
- Crinus 7y ago
  I'm pretty sure it is the other way around, the OS/2 GUI (Presentation Manager) API is a cleaned up version of the Windows 2.x API.
  - mschaef 7y ago
    Sort of. IBM really wanted to ensure that OS/2 had an imaging model that was compatible with what it used in some of its larger computers. This resulted in a bunch of differences between OS/2's imaging model and GDI. (Different window origin coordinates, etc.) In a more Microsoft-centric world, I'm pretty sure the OS/2 API would've been exactly as you describe it and almost strictly in parallel with Windows. In fact, Microsoft did exactly this with Win32s (and Windows 95) In their relationship with Windows NT (which was once known as OS/2 NT or OS/2 3.0). The same compiled binary could run on both the 'entry level' OS and the 'server level' OS, with a bit of care taken in the way the API was used.
    - scottlu2 7y ago
      Once Microsoft agreed to the graphics api change, it was open season to redesign the window manager api because backward compat was moot at that point. The OS/2 window manager api was designed by the same team who designed the win16 window manager apis. There were improvements and a bunch of api change but at the 10K foot level the model was the same - input loop, window messages, and window procs.
userbinator 7y ago
I think it's one of the best, because it's also the most efficient way to write GUIs on Windows. Definitely not overengineered. MFC is horrible, I agree. I've had to work with it and the indirection just gets in the way and creates bloat. That is overengineering.
- elweston2 7y ago
  MFC was built for a reason. To provide that doc/view/OLE GUI. If you wander too far away from that it becomes well, lets just say, 'interesting' to use. I would many times just include MFC just to get some of those helper classes though. CString was way ahead of the game. C++ did not get a std::string standard that most people could use until well into the 2000s. Its database classes were good in a pinch to abstract away the nitpicky junk in ODBC. Then C++ took a 15 year sideways journey into getting templates right. During that time MS created C# and basically took away any reasons to really use MFC and C++ on windows for business applications.
  - 72deluxe 7y ago
    I did some MFC for my job and disliked it. It didn't help that the software in my job was made up of thousands and thousands of COM objects and everything felt like treacle to write (got to implement those interface functions I'm never going to use!). I have used wxWidgets a lot and really like it, but for modern C++ on Windows what do Microsoft recommend? I can't seem to get any idea. Honestly, I would like to know.
    - elweston2 7y ago
      COM was not really well designed to be consumed from C++ that is why it felt horrible to you. It was designed for visual basic and Office. If I never see another VARIANT I will be soooo happy. ATL made COM better to use but not much. In visual basic a COM object was dead easy to make and manage. In C++ it came with a bunch of baggage of extra API's to fiddle with and no real clear direction how/why to do so. I do not know what MS would recommend these days. From my point of view they basically functionally abandoned it but dragged it along because most of their stuff was built with it. The .NET libs was where all the new stuff was going (WPF, WinUI). WTL may be worth a look it looks like it comes out of the ATL/MFC lineage.
that_jojo 7y ago
It's kind of interesting, when you compare WinAPI to classic Mac Toolbox, how incredibly similar their core concepts are. Especially when you take into account that the first GUI application MS made was Excel for the Macintosh. And then they more-or-less wrote Windows as a runtime environment for porting Excel to PCs. Not getting into any of that old-school MS-stole-the-GUI flamewar business, I just think it's genuinely historically interesting to note the parallels when you play with each.
- projektfu 7y ago
  A big difference is that Windows used inversion of control. You give the system a callback and it calls you with an event. The Mac toolbox was written with the idea that each application had full control of the machine. This made multiprogramming ... interesting. On the Mac, for example, when you pressed down on a button, it would go into a mode where the button’s code would take all the events until the mouseUp event.
  - that_jojo 7y ago
    > You give the system a callback and it calls you with an event Maybe I haven't done enough WinAPI programming, but where is that true? I know there are a few helper functions that automatically dispatch an event to a callback, but I thought in general all events had to be intercepted and dispatched in the message loop
    - projektfu 7y ago
      Yes but windows calls your event loop directly for WM_PAINT as well as the event loop calling a system function that calls your window procedure, again investing control. On the Mac you used to hit test the event yourself and figure out which window it was meant for.

thrower123 7y ago

> It seems like Win32 happened a bit by accident, a bit by overengineering and a bit by Microsoft's attempt to lock everyone to their 'special' development environments, which did not include C as a conscious choice by Microsoft. Maybe I just haven't had my coffee yet, but I'm not understanding what this is supposed to mean.

pjc50 7y ago
I don't understand this either. They've always offered C. In many ways Win32 and NT are as much a ""C operating system"" as UNIX. The only "special development environment" might be Visual Basic.
- dockd 7y ago
  Maybe they meant Microsoft didn't really stick to the C standard library. _strdup vs strdup. malloc vs HeapAlloc. assert, fopen, etc. The functions mostly exist but really aren't the way to program Windows.
projektfu 7y ago
After the p-machine era, MS was all in on C. They had some technical reason for preferring the pascal calling convention, like saving a few bytes of program text.

mschaef 7y ago

> Win32, especially when it comes to GUI programming, is one of the worst APIs out there. It's also one of the first. Win32's origins extend back over 35 years and start on machines with a tiny fraction of the capability of even the smallest of today's modern PC's. It was also built with a different set of tradeoffs and in a radically different culture of software development. (Most modern developers hadn't been born at the time of it's initial design, and most of the people who were actively writing this stuff in the early-to-mid 1980's, I'm sure have moved on. 35 years is pretty much a career.) > MFC is also quite bad because of huge abstraction leakages; it fills like Win32 with bolted on classes. That's pretty much what it was... by design. There was a more object-oriented library that Microsoft developed, prior to MFC. They tested it on developers that had essentially just come up to speed on the (then-new) Win16 API, who all complained about having to ascend another learning curve for a fancy object oriented language and framework. Microsoft's reaction was to drop the older framework (referred to as AFX) and develop MFC as a thin wrapper around Win16. (This is part of why there are AFX prefixes scattered throughout the MFC codebase.... it's a legacy of the earlier framework.) Even then, early versions of MFC had some utility, mainly around making things more type safe. Because it bound C++ instances to Window system instances, it made it easy to attach user data structures to UI components. (Otherwise, you were worrying about window or class words, which were Microsoft's original approach to that problem and used by MFC under the hood.) MFC also handled parsing of window message arguments. Win16 also sent messages with just a word and a long, when what you really might need is a set of mouse button flags and an x/y position or something. MFC helped with that too, by 'cracking' the message arguments into something closer to what you'd expect. (To this day, Win32 documentation still includes instructions on parsing WPARAMS, etc. https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-mousemove#remarks https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-m... )

jussij 7y ago

The design of Win32 is incredibly close to the design of Win16 and since Win16 dates back to early 90's you need to comparing it to GUI programming layers of that same era. So the question is, back then was there any better GUI programming layers? And the answer is yes, there was actually an API that was better and it was called OS/2. At that time Microsoft was in a partnership with IBM to develop OS/2. However, when the partnership fell apart, Microsoft just took big chunks of that OS/2 API and created a sub par version and called it the Windows API.

Crinus 7y ago
I'm pretty sure it is the other way around, the OS/2 GUI (Presentation Manager) API is a cleaned up version of the Windows 2.x API.
- mschaef 7y ago
  Sort of. IBM really wanted to ensure that OS/2 had an imaging model that was compatible with what it used in some of its larger computers. This resulted in a bunch of differences between OS/2's imaging model and GDI. (Different window origin coordinates, etc.) In a more Microsoft-centric world, I'm pretty sure the OS/2 API would've been exactly as you describe it and almost strictly in parallel with Windows. In fact, Microsoft did exactly this with Win32s (and Windows 95) In their relationship with Windows NT (which was once known as OS/2 NT or OS/2 3.0). The same compiled binary could run on both the 'entry level' OS and the 'server level' OS, with a bit of care taken in the way the API was used.
  - scottlu2 7y ago
    Once Microsoft agreed to the graphics api change, it was open season to redesign the window manager api because backward compat was moot at that point. The OS/2 window manager api was designed by the same team who designed the win16 window manager apis. There were improvements and a bunch of api change but at the 10K foot level the model was the same - input loop, window messages, and window procs.

userbinator 7y ago

I think it's one of the best, because it's also the most efficient way to write GUIs on Windows. Definitely not overengineered. MFC is horrible, I agree. I've had to work with it and the indirection just gets in the way and creates bloat. That is overengineering.

elweston2 7y ago
MFC was built for a reason. To provide that doc/view/OLE GUI. If you wander too far away from that it becomes well, lets just say, 'interesting' to use. I would many times just include MFC just to get some of those helper classes though. CString was way ahead of the game. C++ did not get a std::string standard that most people could use until well into the 2000s. Its database classes were good in a pinch to abstract away the nitpicky junk in ODBC. Then C++ took a 15 year sideways journey into getting templates right. During that time MS created C# and basically took away any reasons to really use MFC and C++ on windows for business applications.
- 72deluxe 7y ago
  I did some MFC for my job and disliked it. It didn't help that the software in my job was made up of thousands and thousands of COM objects and everything felt like treacle to write (got to implement those interface functions I'm never going to use!). I have used wxWidgets a lot and really like it, but for modern C++ on Windows what do Microsoft recommend? I can't seem to get any idea. Honestly, I would like to know.
  - elweston2 7y ago
    COM was not really well designed to be consumed from C++ that is why it felt horrible to you. It was designed for visual basic and Office. If I never see another VARIANT I will be soooo happy. ATL made COM better to use but not much. In visual basic a COM object was dead easy to make and manage. In C++ it came with a bunch of baggage of extra API's to fiddle with and no real clear direction how/why to do so. I do not know what MS would recommend these days. From my point of view they basically functionally abandoned it but dragged it along because most of their stuff was built with it. The .NET libs was where all the new stuff was going (WPF, WinUI). WTL may be worth a look it looks like it comes out of the ATL/MFC lineage.

that_jojo 7y ago

It's kind of interesting, when you compare WinAPI to classic Mac Toolbox, how incredibly similar their core concepts are. Especially when you take into account that the first GUI application MS made was Excel for the Macintosh. And then they more-or-less wrote Windows as a runtime environment for porting Excel to PCs. Not getting into any of that old-school MS-stole-the-GUI flamewar business, I just think it's genuinely historically interesting to note the parallels when you play with each.

projektfu 7y ago
A big difference is that Windows used inversion of control. You give the system a callback and it calls you with an event. The Mac toolbox was written with the idea that each application had full control of the machine. This made multiprogramming ... interesting. On the Mac, for example, when you pressed down on a button, it would go into a mode where the button’s code would take all the events until the mouseUp event.
- that_jojo 7y ago
  > You give the system a callback and it calls you with an event Maybe I haven't done enough WinAPI programming, but where is that true? I know there are a few helper functions that automatically dispatch an event to a callback, but I thought in general all events had to be intercepted and dispatched in the message loop
  - projektfu 7y ago
    Yes but windows calls your event loop directly for WM_PAINT as well as the event loop calling a system function that calls your window procedure, again investing control. On the Mac you used to hit test the event yourself and figure out which window it was meant for.