Fog Creek Software
Discussion Board




Ignorant newbie questions: MFC, COM/ATL, etc.

Well, it looks like the book I bought on the Windows API, Programming Windows by Charles Petzold (the one everyone recommends -- I don't know why, it has hundreds of pages on stuff I don't care about, like graphics and multimedia and whatnot), doesn't have the information I need to make professional-looking Windows applications.

So it looks like learning the MFC is the way to go. Some of the classes, like CTreeCtrl, look like they make the task of Windows programming a lot easier.

So here's my first question: what are the best book(s) for learning MFC if one already has experience with the Windows API (from programming in C)?

Also, I have heard bits and pieces about COM. All I've gathered is that you create "interfaces" wherein you expose functionality in such a way to other components... why is that a good thing? What advantages are there to be had from programming in COM?

Warren Henning
Friday, July 04, 2003

First, make sure you really want to learn MFC, COM and ATL, and not .NET.

For MFC, I'd recommend Mike Blaszczak's Professional MFC with Visual C++ 6.

For COM and ATL, I liked Richard Grimes' books.

But really, make sure you want to learn this first. The good thing about COM and ATL is that if you can wrap your head around it, you'll probably become a better student in the process. But all of this is dead end technology that most companies will be phasing out over the next perhaps 5 years.

Big B
Friday, July 04, 2003

The Prosise MFC book follows a similar structure to the Petzold Win API book.  If you're looking for familiarity, it'd be a start.

S. Tanna
Friday, July 04, 2003

I can't recommend any MFC books -- I learned it only by coding a program and refering to the Microsoft documentation.  I already knew Win32 from previous experience, and I found the Petzold book an invaluable resource ...

Regarding COM -- well, it was designed to be the next generation in creating modular applications -- like using DLLs.  But instead of exporting functions, COM servers export objects.  Also, COM was also designed to work even if the object and the user of the object were on different machines -- that is, distributed COM, or DCOM.

Did it succeed?  Well, depends on who you ask.  I'm pretty ignorant when it comes to distributed applications, so I can't really argue for or against DCOM. 

For me, the only place where COM really shines is when you want to write language-independent objects that works in all of the Microsoft languages -- Visual Basic, Visual C++, and JScript.  I wouldn't ever use it if this weren't a given requirement.

Alyosha`
Saturday, July 05, 2003

Alyosha,

You should distinguish between being a COM client (i.e., consuming COM classes) and being a COM server (i.e., exposing COM classes). You will be a COM client when you have no choice, and it might have nothing to do with cross-language or cross-machine interoperability.

ATL includes assistance for both COM client code and COM server code, although most of the books focus heavily on the server infrastructure and are light on the client infrastructure.

Brad Wilson (dotnetguy.techieswithcats.com)
Saturday, July 05, 2003

Thanks for the replies.

Blaszczak's book looks to be out of print, but a glance at the table of contents of both his and Prosise's book suggests that it's better, even if it's not meant to be a tutorial.

Warren Henning
Saturday, July 05, 2003

These three will cover about 90+% of your needs

Best Writing:
http://www.amazon.com/exec/obidos/tg/detail/-/1572316950/qid=1057443660/sr=8-3/ref=sr_8_3/102-9403736-5546511?v=glance&s=books&n=507846

Best Details:
http://www.amazon.com/exec/obidos/ASIN/0201407213/qid=1057443736/sr=2-2/ref=sr_2_2/102-9403736-5546511

The MICROSOFT MFC Architect:
http://www.amazon.com/exec/obidos/tg/detail/-/1861000154/qid=1057443936/sr=8-1/ref=sr_8_1/102-9403736-5546511?v=glance&s=books&n=507846

Heston Holtmann
Saturday, July 05, 2003

My turn for a newbie question:
I was under the impression that, if given the option, one should avoid MFC and go (painfully) straight into ATL. Is that valid advice? Or is it "disco sucks" backlash from the group that migrated from MFC to ATL?

Philo

Philo
Saturday, July 05, 2003

Philo: MFC and ATL are two tools for two different tasks.  There is some overlap between the two, but MFC is tailored for creating applications whereas ATL is for writing COM objects and ActiveX controls.

Alyosha`
Sunday, July 06, 2003

There is a free add-on library from Microsoft called WTL, which replaces about 85% of what MFC does with a nicely templated system built on ATL's windowing classes (which are there primarily for ActiveX control support).

Personally, I found WTL much more intuitive than MFC, and it was definitely much lighter weight. At the time that I was using them (VC++ 6), the few things missing from WTL were not really important to me (doc/view, print preview... probably something else). Obviously, WTL had VERY good control container support, something that MFC was middling at at best. :)

Brad Wilson (dotnetguy.techieswithcats.com)
Sunday, July 06, 2003

Beginner Beware!!

The books that the others have suggested are fine references. If memory serves me correctly, there may also be a book about MFC in the "for dummies" collection, or in the "... in 21 days" series as well.

Realize that as far as COM and C++ is concerned, it was meant for creating things like ActiveX controls or other components (as opposed to complete apps), which could be used in Visual BASIC and other places. You would have to be crazy to create an entire app in COM/ATL when there are FAR better ways to do it -- MFC, or perhaps .NET

Yes, you certainly can create complete ATL/COM based apps, and if you have the time and endurance to do so, then feel free. Just don't expect it to be easy, or expect it in a fairly short timeframe. That is where MFC comes into the picture.

My advice, such as it is (take it for what its worth):

* Use MFC if you are creating a complete app, AND you have pre-existing C/C++ code that you'd like to reuse.

* Use ATL if you feel that you need to create one or more isolated components (either ActiveX controls or isolated business logic for COM+/MTS). Don't create an entire app in ATL. TREAD VERY CAREFULLY.

* Consider .NET if you can be satisfied with being restricted to a single platform, or need to create web apps. Note that .NET still allows you to re-use pre-existing C/C++ code via Managed C++, but there are complications.

AnMFCAndJavaProgrammer
Monday, July 07, 2003

I like how people talk about being 'restricted' to a single platform.  How many commercial apps can you count that are multi-platform?  How many if you untick the Microsoft and Adobe checkboxes?

Rick Childress (www25.brinkster.com/rchildress)
Monday, July 07, 2003

"I like how people talk about being 'restricted' to a single platform.  How many commercial apps can you count that are multi-platform?  How many if you untick the Microsoft and Adobe checkboxes?"

Certainly the number of platform-specific apps greatly exceeds the number of non-specific ones. This is true for the present, but I wonder what it will be like in the future?

They do exist: JBuilder, Idea IntelliJ, some others

Wouldn't it be nice to just develop for a single, virtual platform, and then have the code run on whatever machine implements the platform?

AnMFCAndJavaProgrammer
Monday, July 07, 2003

It'd be nice to have a million dollars (USD) , too.

Point granted. Development tools are a 'gimme'.  But what about apps that the general populace cares about?

Rick Childress (www25.brinkster.com/rchildress)
Monday, July 07, 2003

$1.0e6 would be nice, wouldn't it. Its the type of thing that would allow you to forget about the vagaries of professional development, and take up something saner, like sky diving or hang gliding.

Java is still trumpeted as the "cross-platform" solution, even though most usages don't employ it for that. As far as I can see, Java is mostly being used in enterprise environments, where J2EE plus an app server is the replacement for COBOL and a transaction processing environment.

The real cross platform environment is the server-page based app, whether it be ASP, JSP or something else.

So, here is the real question: is Java's supposed cross-platform capability ever going to be seriously used (outside of development tools), or is it just another way of avoiding the hegemony of Microsoft? You know: open software is the answer to monopoly.

AnMFCAndJavaProgrammer
Tuesday, July 08, 2003

'or is it just another way of avoiding the hegemony of Microsoft?'

In my experience, most people that use Java (TM) use it for that reason alone. 

Rick Childress (www25.brinkster.com/rchildress)
Tuesday, July 08, 2003

> Wouldn't it be nice to just develop for a single, virtual platform, and then have the code run on whatever machine implements the platform?

Depends on the app, but for something like shareware or shrinkwrap and even some consultingware - I'd say No.

All platforms are not the same.

Users don't accept applications which don't confirm to the platforms UI rules. [because the virtual machine doesn't use native features which might be available on one machine or another, or because virtual machine simulates features/controls/etc].  This can be as trivial as OK and Cancel buttons being reversed, but often goes beyond this.

Users don't like applications which don't take advantage of the best of their platform

User's don't like applications which conform to the lowest common denominator across a number of platforms.


Overall, I'd say, a non-trivial portable app is always much more work (for the developer) or less popular with users because of the above. 

I'd also say, the worst part about portability layers/tools are those which don't let the programmer break-out of the environment to use native features and combine them with cross-platform features.  It may be a logical design, but I think it sucks as a method of implementing something people are supposed to use.  Sadly though, this be increasingly common.

Incidentally the same applies to some degree for single platform apps which work with multiple backends (like databases, network protocols, etc).  It is however in these cases, usually less noticeable as it's not immediately visibly obvious, and the commonalities between "platforms" are usually higher than between GUIs.

S. Tanna
Tuesday, July 08, 2003

'or is it just another way of avoiding the hegemony of Microsoft?'

>In my experience, most people that use Java (TM) use it for that reason alone. 

Don't forget C# and .NET was not available for a long time when people chose java.

When those are available in useable form, companies already invest so much in java apps...

Rick Tang
Tuesday, July 08, 2003

Regarding Java and the "value" of cross-platform applications:

These are all great replies, and they target the major problems (or at least difficulties) with the one-size-fits-all concept:

* less than ideal conformance to UI platform conventions
* less than ideal performance relative to native
  applications.

Personally, I agree with these observations. Not meaning to pick on Java, but Java GUI apps ARE slower than native equivalents; Java database access is slower than native code access; has anybody seen any mass-marketed Java-based games? What about real-time applications?

I was going to write that Java is a much more productive language to write apps in, but I started to think about the MFC/C++, VB and Delphi work I've done, and the truth is, I'm not too sure anymore.

Certainly a managed environment has some supposed advantages, like automated memory management. And, it it is true that hunting down memory leaks in C++ apps can be a real chore; but, what about tracking down and fixing performance issues in Java apps? I'm sure that the same issues will haunt us in .NET as well.

The real question is, in my mind, do the advantages of developing in a managed environment (Java or .NET) outweigh the less-than-ideal aspects?

I know that there aren't any simple answers to these questions, and that what I've written is bound to contain over-simplifications, but I'd be interested to know what people think.

AnMFCAndJavaProgrammer
Wednesday, July 09, 2003

*  Recent Topics

*  Fog Creek Home