Why I wrote Win32 Foundation Classes

I make my living by programming for Windows/NT. More technically, I am a 
JAD/RAD (Joint Applications Design/Rapid Applications Development)
developer. I live and die by the amount of objects I can reuse between 
projects. There is no way I can make my deadlines and produce reliable
applications unless I reuse substantial amounts of code (preferably DLLs)
between dissimiliar programs.

I was a C programmer (still am) and saw that Microsoft Foundation Classes and
C++ was the way the future was heading. So, I took a C++ programming class. I
got Visual C++ and MFC and was disappointed. If you do a lot of GUI work then
MFC is great. But if you have to do non-GUI stuff (like networking, services,
etc) then MFC sucks BIGTIME! I was under the impression that MFC would play 
with the entire Win32 API and not just the pretty GUI stuff. Well, I was 
mistaken. Microsoft was telling us programmers that using MFC will make our 
transition from Win16 to Win32 much easier. They said, "Use the Registry!", 
"Use Services!" but didn't include them in MFC. What's a programmer to think? 
So, I got tired of waiting for them to do my job for me and began writing WFC.

It started so simply. I wrote a class to wrap the Registry API so I could
use it in future NT programs. Then I got a task to write an application
that would take data coming in multiple serial ports, normalize it and
ship it out another serial port. It had to run 24-hours a day, 7 days a
week, etc. In short, this program can't fail. I thought this would be a good
first-project for NT/C++/MFC. I started writing classes to model the data.
This was a breeze. Then I looked into MFC to see how to start making my
console program into a service. WHAM! MFC doesn't know anything about
services. OK, how about serial ports? WHAM! MFC doesn't know anything about
serial ports. Ouch. Well, I guess it doesn't have anything to support
TCP/IP sockets then. YEAH! MFC has a CSocket class! At least they helped me
with that. WHAM! CSocket requires a GUI. So, the three things I needed for 
this project weren't in MFC. So far, the most useful thing in MFC is the
CString class. I created the CSerialFile class to play with the serial ports,
I plagerized the CService class from the DevCD (I think). I wrote a simple,
brain dead TCP/IP socket class that doesn't require all of the hidden
dependencies of CSocket and finished my project. WFC was begining to grow.
My new service-based serial data translator was working except for one
small problem. It was disappearing! Yup. That service would just disappear.
Poof! No trace of it leaving even when I turned on all event logging. I'd
see the process load but there wasn't an entry when the processed vanished.
It doesn't leave a trace when it dies. I tried putting in the smurphy NT
exception handling. That caught nothing. So, I've now got a service that
does the impossible, it blows out of try/except blocks and stops running
without leaving a trace in the event logger (I wonder how this affects their
C2 rating). I had to write another service that would watch for magically
disappearing services and automatically restart them. CServiceControlManager
class and the WatchDog sample application were written to solve this 
problem.

Then I got a project that had to remote control a switch. The whole drawing
objects suite came into being. Then I had to remote control an oscilloscope.
CSquiggle and CSquiggleData were added.