February 15th, 2003, 01:50 PM
win32/mfc, what's the difference?
Can anyone tell me what the difference is between Win32 and MFC? I know that MFC is the more up-to-date API for Windows programming, but is it better than Win32? Can I make good programs with Win32? How would MFC make them better?
February 15th, 2003, 02:06 PM
This is not true. MFC is a classes framework that abstracts the windows API. But you can only use it in C++, so for C programs, the winapi is your only way (afaik).
February 16th, 2003, 01:19 AM
The Win32 API is the base-level API for the Windows operating systems.
MFC is an object-oriented C++ wrapper of the Win32 API.
"Me fail English? That's unpossible!"
February 16th, 2003, 04:10 PM
Okay, that makes sense. So why would I want to use MFC in my programs?
February 16th, 2003, 04:47 PM
The level of abstraction that MFC provides makes some aspects of programming Windows much simpler. Unless you have a compelling reason NOT to use MFC, then I would recommend using it.
I definitely think you're going down the right track by learning Win32 before MFC. I applaud you for that.
"Me fail English? That's unpossible!"
February 17th, 2003, 02:28 AM
>>Can anyone tell me what the difference is between Win32 and MFC?
Apart from what has been said before;
high speed development
High control over custom elements ie controls
C or C++
The essence of Christianity is told us in the Garden of Eden history. The fruit that was forbidden was on the Tree of Knowledge. The subtext is, All the suffering you have is because you wanted to find out what was going on. You could be in the Garden of Eden if you had just kept your f***ing mouth shut and hadn't asked any questions.
February 26th, 2003, 09:43 PM
Where do I go about learning Win32? I have downloaded several tutorials about using the MFC AppWizard in VC++6, but I can't find anything about Win32.
February 26th, 2003, 11:39 PM
"Okay, that makes sense. So why would I want to use MFC in my programs?"
It's kind of like the difference between writing a business report by hand and sketching all the diagrams freehand and using a wordprocessor and generating graphs with excel. In the end, either way you have a business report.
As I'm exploring the capabilities of MFC and all the tools of VC++6, it amazes me more and more. As to what the phrases "MFC encapsulates the win API" or "MFC abstracts the win API" actually mean, it's not easy to understand without knowing about classes, and even if you do, it only describes what MFC is(i.e. just another bunch of classes) not what the VC++6 compiler and MFC can do. So, I'll describe what I've been doing lately and maybe that will shed some light on the subject.
I started off using AppWizard to generate a text editor type application without my having to write a single line of code--something that would take you around 100 lines of code with only the win api. Then I needed to add some menu items. If you look at the top of the window you have open now, you'll see menu items like File, Edit, View, Favorites, etc. I'm coding an application that allows the user to draw in a window like MS Paint, so I needed to add a menu item for Shapes and one for Colors with drop down menus with choices the user can pick.
To do that, the compiler has something called a "resource editor". I opened that up and it was like a text editor for the menu bar. I just typed in the name of the menu item on a graphical representation of a button that was provided, including the names for the choices, and then I dragged the item wherever I wanted it to be on the menu bar. I have no idea how I would program that with only the win api. If you wanted to merely change the position of the menu item with the win api, you would have to rewrite some code. I just had to drag it to where I wanted and all the code changes were taken care of for me. I was also able to indicate hot keys for each choice and indicate which choice was selected with a check mark. Then the ClassWizard directed me to the spot in the code where I only had to add a few trivial if-statements to process the user's choices. The compiler uses MFC's classes and dozens of macros so that all the messages generated by the user's choices get sent to the right areas of the code where you add your own code to take actions based on those messages.
Then I added tool bar buttons to correspond to the menu items. No one really uses menu items anymore--people want tool bar buttons with pictures they can click on. Well, the compiler took care of that too. I opened up another editor that had Paint type features, and I was able to draw little icons for my toolbar buttons and drag them to the positions I wanted them located, and once again the compiler arranged so that MFC classes were generated and objects were assigned to all the buttons, and it arranged for messages generated by user choices to be sent to the appropriate places.
Debugging the code I had so far was trivial. I only added about 20 lines of code myself to the 22 files containing 6 classes and all the source code generated by the compiler. To make things easy for me, the compiler set up the function definitions I needed with a blank body to handle each choice I created for the user with my menu items and toolbar buttons, and when I needed to add the code, the compiler took me to the exact spot. I can only surmise, but if you tried to do all that with only the win api, you would be coding and debugging for days.
Last edited by 7stud; February 27th, 2003 at 03:18 AM.
February 27th, 2003, 10:50 AM
While I'm sure there are several books out on the subject, the best known expert on programming Windows in C just using the Windows API is Charles Petzold. He has been writing "Programming Windows __" since version 2 or perhaps even before.
"Programming Windows 95" was the last of his books by that name, but now there's "Programming Windows, The Definitive Guide to the Win32 API" Edition Five. I assume that it carries on the tradition only now with a standard book title.
But to reiterate, MFC is a tool that makes the job easier. In the example that you were just given, if you were just using Win32 then you would need to edit the resource file (*.rc) in a text editor to make those changes and additions to the menu. And if you were creating a dialog box, then you would have to enter in all the coordinates and sizes and properties of each and every control by hand (with the help of copy-and-paste, of course) and could only verify what it looks like by getting the program to run.
But even if you use MFC, you can still go into the resource file and tweak it at that level. The same pretty much goes for code to handle the controls.
I would recommend also looking for a reference listing of the Win32 API, something like the Win16 "Windows API Bible". Most that I see listed on Amazon.com are either for Visual BASIC programmers or are out of print.
February 27th, 2003, 01:18 PM
The resource editor is available whether you use MFC or not. You should rarely need to hand edit the resource file. What you don't get without MFC is a simple and easy way of associating code and data with your resources.
February 27th, 2003, 03:57 PM
I've been tinkering around w/Visual C++ as well here at school, and it's pretty neat. The GUI grid and resource editor are my favorite tools. :)
If you do want to use MFC, learning Win32 w/Petzold's book is a must (even though it's not a very readable book) since all this code is placed into your program via the wizards and you will have no idea what those functions mean unless you know Win32. I started reading Petzold's book, but stopped when I figured out how to make a nice stand-alone Windows program with Python, which is A LOT easier to learn, much easier to find documentation online, and almost as portable and feature-packed as Win32 (well, at least the features I need for my project anyway). The only thing I don't like about Python is it doesn't use resources the way Win32 does. For example, (to my knowledge), you can't compiled images and sound bits into the program like you can in Win32 (which is a nice feature).
August 2nd, 2003, 01:49 AM
The Windows API is the base level programming interface of the operating system. It's written in C, not C++. It took me 3 years to learn it. When you learn the API it is simple to learn MFC, because MFC is a tiny wrapper around the API. It is easier to write applications with MFC because the framework does the very hard work for you (for example try to print a document with the API and you'll see). The best book about programming with the API is "Programming Windows 5th edition" from Charles Petzold, but also the MSDN is an excellent source (see Platform SDK section). Start with the user interface services, then Graphics services and then Base services, because it is the hardest one. It is my advice. My opinion is that programming with the API is the best choice because you can do anything you want. If you want some type of tricky control, develop it yourself from the scratch, handle messages and that's it. There are no hidden obstacles like in MFC.
Your code is not bloated, it is straightforward. You can use any C compiler and knowing the Windows API you are prepared to know how every operationg system on the planet works, they are all the same(almost). But if you want to develop really usefull application in C and the WinAPI think carefully how to organize and structure it. It's very important because the code gets very huge and complicated and you must develop a really good infrastructure if you want understand what you wrote after a month. Some guys say that the API is arcane and is not object oriented. It is far from the truth - the API is fully object oriented and not at the compiler level, but at system level. OOP is not a technology but a paradigm. Also you can do object oriented programming in plain C, it's just what the C++ compiler does. I will applaude everybody who is starting nowadays to learn C and API and not C#,VB,.NET or some other commercial technology of the day. It is hard to learn but i think it is the right way for anybody who wants to know what is really going on.
August 2nd, 2003, 05:31 PM
I have two questions...
1. What is faster MFC or Win32 API?
2. How do I make a 'nice' program like Winamp?
August 2nd, 2003, 07:33 PM
Some very good advice anatol, thanks! I agree that learning Windows programming (or any programming for that matter) is the best way. In the long run, you'll be able to do so much more than if you use tools or learn ways to do things the easiest way possible.
1--My guess would be MFC. What do you think anatol?
2--Good question! That's a great program! :)
August 3rd, 2003, 10:49 AM
API is faster. MFC is a wrapper for api, think of it like this, you write less code but mfc converts it to api, while when your callling api functions, they are called from the dll's immediatly.
For the mp3 thing, Look at this function (api): mciSendString();
you basically play a MPEG, I can't find my code but I think you send something like this first ("ALIAS TheMP3 type MPEGVideo"), I will try to find it later on. That is to write your OWN mp3 player (at least start one), but if you want to control winamp, you can look here, this lets you send messages to winAmp to play/stop..etc:
I think you should just learn API and not mfc, I never touched mfc but API isn't THAT hard and you learn more about how windows works.