none
Difference and relation between win32 API, MFC & .NET

    Question

  • Hello all,

    I'm confused with difference and relation between these three.  This is what I'm thinking:

    1. win32 API is API for windows in C (not C++)
    2. MFC is nothing but a wrapper of win32 API for C++ . 
    3. .NET happens to be an advanced and completely different from MFC or win32 right? 
    Does .NET CLR use win32 API?
    Coding using C++ on .NET is completely different than C++ using MFC. right? or is it that "no difference between both"?

    Please clarify. If any one can give some pointers for further study that would be great. 
    Wednesday, September 09, 2009 1:44 PM

Answers

  • MFC wraps the Win32 API with C++ classes, making it easier to use.  .NET wraps the Win32 API with .NET classes, making it easier to use.  The difference between the two is that MFC requires the C++ language, .NET requires a managed language.

    The .NET framework does not completely wrap the full Win32 API.  Nor does MFC.  Much of the obscure stuff isn't wrapped, APIs that were added in Vista and Windows 7 don't have wrappers either.  That's kinda automatic with its promise that it will run your code on any recent operating system, back to at least Windows 2000.  Adding your own wrappers is pretty easy with P/Invoke.

    Both class libraries add classes beyond basic wrappers for the Win32 API.  MFC has strong support for the document/view UI model and a recent release makes things like the Office ribbon and custom UI themes available.  .NET has lots of extension classes available that help make a lot of common programming tasks simple.  Its very strong support for threading is notable.

    If you're trying to decide between raw API, MFC and .NET, the choice is obvious.  Productivity is roughly a 5 : 3 : 1 ratio, even for experienced programmers.

    Hans Passant.
    • Marked as answer by eryang Monday, September 14, 2009 6:07 AM
    Wednesday, September 09, 2009 2:49 PM
  • Hi,

    1) yes, Win32 is an API for C, Win32 API is part of Windows Operating system.
    2) yes, MFC is the wrapper for Win32 API to make GUI development easier.
    3) yes, .NET is different from MFC and Win32 API as the code written in .NET languages is managed one ( means CLR is taking responsibility) but in Win32 and MFC it is unmanaged. you can also write unmanaged code in .NET.

    C++ using .NET is called manged C++ and its different from C++ using MFC (unmanaged C++)

    .NET CLR uses Win32 API (and may be some assembly code for performance improvement). in fact both MFC and .NET use Win32, like in this relationship

    MFC --> Win32 --> Assembly Code
    .NET --> Win32 --> Assembly Code

    for further study , see links

    http://www.go4expert.com/forums/showthread.php?t=2533
       (Win32 vs MFC)

    http://www.daniweb.com/forums/thread198090.html   (MFC vs .NET)
    • Marked as answer by eryang Monday, September 14, 2009 6:07 AM
    Thursday, September 10, 2009 12:13 AM
  • Everything ultimately uses the Win32 API. 

    1. Yes.  Win32 API is the API that exposes functionality needed to interact with Windows for Windows applications.
    2. AFAIK.  I've never used MFC, but I anticipate that would be correct. 
    3. .NET relies on the Win32 API at it's root, and is a framework built around the Win32 API.  I don't believe it uses MFC at all, although I could be wrong here. 

    .NET CLR does use the Win32 API.
    C++ in .NET is different than C++ in MFC.

    To be completely honest, I would go with .NET today.  .NET has pretty much replaced MFC as the de-facto standard for writing programs in Windows.  MFC is outdated now.
    Coding Light - Illuminated Ideas and Algorithms in Software
    Coding Light WikiLinkedInForumsBrowser
    • Marked as answer by eryang Monday, September 14, 2009 6:07 AM
    Wednesday, September 09, 2009 1:56 PM

All replies

  • Everything ultimately uses the Win32 API. 

    1. Yes.  Win32 API is the API that exposes functionality needed to interact with Windows for Windows applications.
    2. AFAIK.  I've never used MFC, but I anticipate that would be correct. 
    3. .NET relies on the Win32 API at it's root, and is a framework built around the Win32 API.  I don't believe it uses MFC at all, although I could be wrong here. 

    .NET CLR does use the Win32 API.
    C++ in .NET is different than C++ in MFC.

    To be completely honest, I would go with .NET today.  .NET has pretty much replaced MFC as the de-facto standard for writing programs in Windows.  MFC is outdated now.
    Coding Light - Illuminated Ideas and Algorithms in Software
    Coding Light WikiLinkedInForumsBrowser
    • Marked as answer by eryang Monday, September 14, 2009 6:07 AM
    Wednesday, September 09, 2009 1:56 PM
  • MFC wraps the Win32 API with C++ classes, making it easier to use.  .NET wraps the Win32 API with .NET classes, making it easier to use.  The difference between the two is that MFC requires the C++ language, .NET requires a managed language.

    The .NET framework does not completely wrap the full Win32 API.  Nor does MFC.  Much of the obscure stuff isn't wrapped, APIs that were added in Vista and Windows 7 don't have wrappers either.  That's kinda automatic with its promise that it will run your code on any recent operating system, back to at least Windows 2000.  Adding your own wrappers is pretty easy with P/Invoke.

    Both class libraries add classes beyond basic wrappers for the Win32 API.  MFC has strong support for the document/view UI model and a recent release makes things like the Office ribbon and custom UI themes available.  .NET has lots of extension classes available that help make a lot of common programming tasks simple.  Its very strong support for threading is notable.

    If you're trying to decide between raw API, MFC and .NET, the choice is obvious.  Productivity is roughly a 5 : 3 : 1 ratio, even for experienced programmers.

    Hans Passant.
    • Marked as answer by eryang Monday, September 14, 2009 6:07 AM
    Wednesday, September 09, 2009 2:49 PM
  • Hi,

    1) yes, Win32 is an API for C, Win32 API is part of Windows Operating system.
    2) yes, MFC is the wrapper for Win32 API to make GUI development easier.
    3) yes, .NET is different from MFC and Win32 API as the code written in .NET languages is managed one ( means CLR is taking responsibility) but in Win32 and MFC it is unmanaged. you can also write unmanaged code in .NET.

    C++ using .NET is called manged C++ and its different from C++ using MFC (unmanaged C++)

    .NET CLR uses Win32 API (and may be some assembly code for performance improvement). in fact both MFC and .NET use Win32, like in this relationship

    MFC --> Win32 --> Assembly Code
    .NET --> Win32 --> Assembly Code

    for further study , see links

    http://www.go4expert.com/forums/showthread.php?t=2533
       (Win32 vs MFC)

    http://www.daniweb.com/forums/thread198090.html   (MFC vs .NET)
    • Marked as answer by eryang Monday, September 14, 2009 6:07 AM
    Thursday, September 10, 2009 12:13 AM
  • Hi again,

    Need little  more clarification:

    1. Can MFC do all functions that Win32 API can do?
    2. Does .NET provide libraries for all functions that Win32 API can do?
    3. What about .NET API and MFC?

    Just tell me the relations about their provision of functionalities. If there are any notable exceptions, please mention.


    Thanks a lot for clarifying. 
    Monday, September 14, 2009 2:01 PM
  • Hi,
    1. MFC does not wrap ALL the Win32 API functions, but from MFC application you can call Win32 functions (outside MFC framework)
    2. As above. Using P/Invoke you can call any Win32 function from .net, even that one which does not have it's implementation i .net
    3. .NET and MFC are two different frameworks and they do not relate each other nor one uses the other. They are like two separate programming enviroments

    Regards,
    Pawel
    Monday, September 14, 2009 3:35 PM
  • The .NET framework does not completely wrap the full Win32 API.  Nor does MFC.

    Hans Passant.
    Monday, September 14, 2009 3:52 PM
  • In any case programmer cans import Win32 API in .NET, or even load them dynamically.

    So there is no reason to wrap all the Win32 API. Managed code frees programmer from memory usage optimization, safety, threads pooling and so on. For  example fast performance network server programming, Firmware integration is not a best filed for .NET application.

    What is about MFC, the classes  may be also called/interfaces in .NET, C# for example. It is not so simple like import Win32 API, but it is possible, even without automation. And  of coarse, mixed  C++, C++.NET DLL may be built bridging ANY unmanaged C++ and .NET.

    From another hand, .NET is the main stream of Microsoft  and they see  Windows future in it.

    So, by definition they have no reason to expose any additional functions in Win32 API ( I am not talking about under carpet and undocumented calling) and, of coarse, in future .NET will be abandoned more than official Win 32 API.  

    Simon Cantor

     

    Wednesday, May 05, 2010 4:44 PM
  • For future readers of this post, I'll add something the others have not. There are many, many things that you can not do in .Net, because framework is overmanaged, and resulting code is very slow compared to applications written in C and unmanaged C++. If you plan to write programs that do compression, encryption, audio and video processing, video games, networking, or heavy on file I/O, do not use .Net. People in Redmond want everyone to believe that C++ is a dying language, but that is simply not true. Serious commercial applications are written in objective C or C++ because high overhead of managed code makes it inviable. Most competing products continue to use a variant of C; android, linux/unix, os-x etc. Advantages of managed code like simplified methods or garbage collection are far outweighed by poor performance of this programming model.

    Wednesday, January 25, 2012 9:38 PM