Beginning Windows Programming

This is a discussion on Beginning Windows Programming within the Windows Programming forums, part of the Platform Specific Boards category; I'm just beginning to program windows applications with Windows API, which is pretty hard, because there is a LOT of ...

  1. #1
    Registered User
    Join Date
    Jun 2006
    Posts
    30

    Beginning Windows Programming

    I'm just beginning to program windows applications with Windows API, which is pretty hard, because there is a LOT of code. Anyways, my question is - is there a difference between using MFC and Windows API. I know that there is slightly less code involved in MFC, and it is more readable for programmer. Is there a drawback of MFC? Do you have more control of your application with Windows API? I just don't know if I should bother learning MFC. Any help would be appreciated.

  2. #2
    Registered User
    Join Date
    May 2006
    Posts
    903
    You have much less control using MFC and the Win32 API is just faster. Besides, in my opinion MFC code is very ugly. There isn't that much code to make Win32 API programs. 60 lines or so for an empty application. You register a new class, create a new window with a message loop and then only specify the window's behaviour (which in the case of an empty application is as simple as handling WM_DESTROY and returning DefWindowProc() otherwise).

  3. #3
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,578
    I have a contrary opinion, I'm afraid. There's no reason not to use MFC if one wants to program exclusively for windows. Sure, some former of API direct access may be desirable here and there. But MFC wraps the API and gives it an OOP structure. This is fundamental and you would find yourself doing exactly that, if you decided to program solely with the API. It also simplifies and streamlines many of the API functions.

    Having at our disposal the MFC and insisting on using the Win32 API instead is akin to having a Ferrari and deciding to change the body to a toyota corolla because it's more... "down to earth".
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  4. #4
    Registered User
    Join Date
    May 2006
    Posts
    903
    The problem is that what MFC wraps is almost pointless. I can write a very small generic class to create all of my controls and do what MFC does to a certain extent. Of course, it has useful features but not enough for me to adapt to its ugly syntax. I mean... why would we have to use all this spaghetti code all at ? Because you don't like calling CreateWindow() ? It's just as good if not better. Chances are that what MFC does better than the Win32 API are things that you will never use or things that aren't worth using its ugly syntax.

  5. #5
    Registered User
    Join Date
    Jun 2006
    Posts
    30
    Oh, man. I was hoping that there is only one answer to my problem. The truth is, even though there are about 60 lines of code to create the Application in API, there are so many variables and Data Types involved that is very hard to remember and pretty frustrating. I forgot to say, but I started learning Windows programming 2 days ago. So my frustration might be temporary. Anyway, Desolation, are you sure that MFC applications run slower? Is there more info about that somewhere? I'm just trying to sum everything up and figure out what should I learn.

  6. #6
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,578
    I won't say a word...

    well, Ok I will say it... The vast majority of people that program in windows use the MFC. That... kinda should say something about it, don't you think?

    Although I do agree with Desolation on the ugly code part.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  7. #7
    Even death may die... Dante Shamest's Avatar
    Join Date
    Apr 2003
    Location
    Malaysia
    Posts
    970
    Benefits of MFC

    I started learning windows programming using Visual C++ and MFC. Here are some good things about it...

    1. Many tailor-made extension libraries designed to work for it.

    2. Knowing how to use it properly can lead to great productivity.

    3. Lots of articles at CodeProject.com about it.

    Disadvantages of MFC

    Today though, I almost exclusively use the Windows API. Here's why...

    1. MFC only works properly with Visual C++. The Windows API works with LCC-Win32, Visual C++ and MinGW.

    3. MFC is not object-oriented. It's class-based and is bandaged with macros. Your .EXE size can drop down by a lot if you avoid using MFC.

    4. There's nothing that MFC can do that Windows API can't.

    5. Writing your Windows API wrappers is hard in the short term, but prevents you from being tied down by new MFC versions. And once your own wrappers have matured, your productivity won't be affected.

    Desolation

    Are you RITZ?

  8. #8
    Registered User
    Join Date
    May 2006
    Posts
    903
    No. I'm tilex.

  9. #9
    Even death may die... Dante Shamest's Avatar
    Join Date
    Apr 2003
    Location
    Malaysia
    Posts
    970
    Quote Originally Posted by Desolation
    No. I'm tilex.
    Ah, I was wondering about the link in your sig.

    And now that I think of it, you once told me you were Desolation. Silly me.

  10. #10
    Hardware Engineer
    Join Date
    Sep 2001
    Posts
    1,398
    WARNING - I'm not an expert on either of these....

    My take:

    If you want to learn and understand what's going-on "under the hood", learn the Windows API. I suspect that most professional programmers who use MFC also know WinAPI programing.

    If you wan't to create useful, impressive, programs right away, learn MFC. (Or Visual BASIC ).

    ...there are so many variables and Data Types involved that is very hard to remember and pretty frustrating.
    Yeah, there's a lot to it. But, you don't have to remember everything. Most of us paste-in "boilerplate" for those "60 lines" (with a little editing). Just keep your Petzold book handy, and use MSDN. Even if you use MFC, you're going to need some of the WinAPI types, functions, and structures.

  11. #11
    Codebot
    Join Date
    Jun 2004
    Location
    Toronto
    Posts
    195
    Quote Originally Posted by Newbeee
    I'm just beginning to program windows applications with Windows API, which is pretty hard, because there is a LOT of code. Anyways, my question is - is there a difference between using MFC and Windows API. I know that there is slightly less code involved in MFC, and it is more readable for programmer. Is there a drawback of MFC? Do you have more control of your application with Windows API? I just don't know if I should bother learning MFC. Any help would be appreciated.
    In my opinion, MFC is an evil cousin to Win32. It may look flashy and Easy but deep inside its hard to use because it doesnt allow control. If you want to pump out applications fast, you might want to look into a RAD coding environment like VB, Java, etc. If you want to write applications that have control over everything, then go the Win32 Route.

    There are many books out there that provide a nice overview of the API but if your not a book person (like me), your better off just diving in, using this board for help whenever you get stuck and just getting your hands dirty. There are vast resources out there for beginners that cover the basics of win32. Also there are code outlets such as Koders.com which let you look at code other people have written and that is open source .

    But if you really want a book, There are a few I can list that are a must on any bookshelf. Firstly, The bible itself, Windows Programming, by Charles Petzold. It contains everything from form creation to threads and DLLs. Secondly, Programming Applications for Windows, Fourth Ed. by Jeffrey Richter. Also a great book. Lastly, If you read those books and want to get into books that deal with the ugly side of windows, there are a number of books that have been written about Services, Networking, RPC etc.....

    I hope this gives you some insight into the maddness that is Win32 Programming.

    EDIT: This may sound shocking to all the people that are pro-.NET and pro-MFC, but none of the heavy duty apps are written in MFC or .NET. Word, Photoshop, even World of Warcraft is written using straight C++ and straight win32 API. Why?? because its fast and its simple. MFC served its purpose (not well in my oppinion) and i believe that .NET might go the same route. All the apps that are written in Win32 are not going to be re-written in .NET, just because they require speed and power. those are my two cents
    Last edited by Mastadex; 06-23-2006 at 02:26 PM.
    Founder and avid member of the Internationsl Typo Associateion

  12. #12
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    I also hate MFC. One reason of course is that I don't use Visual C++ (normal API-s should work with EVERY COMPILER as Win32 does). MFC code is not easier to read, I think it is very messy and ugly. MFC and .NET are just some simplifications for people who are too dumb to understand Win32.

    MFC and .NET "make things easy" and this means you can do things easily, but you don't have control over them and you can't do very much with them.

    I strongly recommend to start with Win32 and never start using those "easy" things.
    Last edited by maxorator; 06-25-2006 at 01:44 AM.

  13. #13
    Disrupting the universe Mad_guy's Avatar
    Join Date
    Jun 2005
    Posts
    258
    Quote Originally Posted by maxorator
    MFC and .NET "make things easy" and this means you can do things easily, but you don't have control over them and you can't do very much with them.
    I guess I'll be the first to call BS. First, control is very situational. In languages like ruby you may have a lot more 'control' over your object model than you would in, say, C++. Just being able to access the hardware a little easier doesn't directly translate to more control. In this instance, yes, you might have a little more 'control' by creating the window manually than using a wrapper. However, control is a very generalized term these days. What you're using dictates what you can control and at how much of a price that control will cost. Second, you can make a lot of stuff using a platform like .NET. If you don't believe me, check out CodeProject. Tons of people write complex and graphical software for .NET every day, it's not just bells and whistles, .NET provides many powerful APIs that range from graphics to debugging applications.

    Maybe I'm playing devil's advocate here, but you have to understand that platforms like .NET and wrappers such as the MFC aren't just hobbies for MS developers. If you cannot understand their differences and their abilities, along with their 'control' factors, how can you intelligently make a decision about what framework or even language to use in a project?
    operating systems: mac os 10.6, debian 5.0, windows 7
    editor: back to emacs because it's more awesomer!!
    version control: git

    website: http://0xff.ath.cx/~as/

  14. #14
    Registered User
    Join Date
    Jun 2006
    Posts
    30
    Well, I've done a little research and got more familiar with windows API. After a while, it does not seem so awful to me anymore. This is my opinion, I think that .NET is the future and Windows Forms is the way to go. Win32 API will still be available in Vista, but only for backward compatibility. So, if you want to use full power of Vista, learn Windows Forms. However, I decided to learn win32 API first, before diving into WinForms. The reason for that is - win32 API lets you know what is going on in your programs. To be a good programmer, you have to understand how Windows works and interacts with your programs. Besides, many functions in MFC and WinForms come from win32, so it wouldn't hurt to learn win32. It's not that hard anyways.

  15. #15
    Even death may die... Dante Shamest's Avatar
    Join Date
    Apr 2003
    Location
    Malaysia
    Posts
    970
    Quote Originally Posted by Newbeee
    I think that .NET is the future and Windows Forms is the way to go.
    I'd say the future of Windows Forms is pretty iffy.

    Analysis of .NET Use in Longhorn and Vista
    Is Windows Forms dead?
    Windows Forms to Developers: I’m not Dead Yet

Page 1 of 3 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Anyone using Windows 7?
    By Sharke in forum General Discussions
    Replies: 60
    Last Post: 07-12-2009, 09:05 AM
  2. Just starting Windows Programming, School me!
    By Shamino in forum Windows Programming
    Replies: 17
    Last Post: 02-22-2008, 08:14 AM
  3. Manipulating the Windows Clipboard
    By Johno in forum Windows Programming
    Replies: 2
    Last Post: 10-01-2002, 10:37 AM
  4. shutting down windows
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 3
    Last Post: 01-02-2002, 12:28 PM
  5. Beginning Windows programming
    By Thunderstruck in forum Windows Programming
    Replies: 2
    Last Post: 11-18-2001, 07:48 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21