locked
Unix programmer tries to learn windows environment - help please RRS feed

  • Question

  • Hello!

    Like I said I'm unix (linux) developer and a student of university of technology in Wroclaw too. Now I have some free time and I decided to improve my skills - leran Windows programming environment. After few days I have a big mess in my head and I want to ask you fo help, here are some questions. I note, that I target new Windows releases (Vista and 7).

    Maybe first my goals:
    1. Learn howt to create modern Windows GUI
    2. Learn some low level things (Winsock first)
    3. Get used to Windows programming environment, understand it's archicture
    4. Learn where (.NET, MCF, COM) to look for particular functionality (networking, file handling etc.)

    Questions mentioned above:
    1. As I see Microsoft recomends .NET platform for new developers, right?
    2. I decided to use C++/CLR and .NET, because - as I read - I'll be able too use bot all .NET features and older modules like winsock. Is this true?
    3. MFC, ATL, COM, .NET?! WTF?! Why so many technologies?! What are they do? I found that MFC is designed for C++ (it covers lower API? which exactly?) and it's still supported. Can I mix MFC calls and .NET in my code when using C++/CLR?
    4. What about GUI in Windows? We have old Windows Forms and new Windows Presentation Foundation, that's great, but which is better for 'normal' applicatins (only windows, controls etc. no 3D embeded video). Which should I use WF or WPF? WF has more controls but I haven't found any information about it's future. Will Microsoft replace WF with WPF?
    5. I found in msdn librarysection titled: "Windows User Experience Interaction Guidelines" - http://msdn.microsoft.com/en-us/library/aa511258.aspx . Nice, but where is API all these functions?!
    6. Windows SDK - what is this?

    That's all for now :)
    I"ll be very happy if you would answer on my questions
    Monday, May 11, 2009 10:01 PM

Answers

  • 1.  Yes.  But not for C++ programmers.
    2.  Yes.  But .NET has excellent socket support as well.
    3.  Different libraries at different times and different goals.  MFC is a low level class library wrapper for the Win32 API, helping you to develop GUIs in unmanaged C++.  ATL is a class library to help develop COM components.  COM is a technology to allow programs written in different languages to interact with each other.  .NET is managed code.  MFC, ATL and COM are 1990s, .NET is 2000s.
    4.  WPF is not a realistic option in C++, the IDE is missing all tool support for it.  WF is supported in the IDE but development on it has stopped, see 1.  While WPF was assumed to replace WF, this hasn't happened in practice.
    5.  It describes how your UI should act and look like, not how it is done.
    6.  A set of header files and import libraries you will need to build unmanaged C/C++ programs that run on Windows.

    If you want to pursue .NET development, you should learn to program in C#.

    Hans Passant.
    • Marked as answer by Goofacz Tuesday, May 12, 2009 10:15 AM
    • Unmarked as answer by Goofacz Tuesday, May 12, 2009 10:15 AM
    • Marked as answer by Wesley Yao Monday, May 18, 2009 2:50 AM
    Tuesday, May 12, 2009 1:25 AM
  • Development on C++/CLI has been frozen since 2005.  It was notably bypassed for LINQ and is missing many C# 2.0 features (anonymous methods, iterators).

    Yes, MFC is going to be around for a while longer.  Yes, there is not a .NET wrapper class for every Win32 API, the shell is notably absent.  But that doesn't really matter, .NET has excellent support for COM interop and P/Invoke.  Making arbitrary Win32 API calls is pretty easy.

    WPF is a class library, just like MFC.  WF too, it has nothing to do with MFC.  Like MFC, it wraps user32.dll.  WPF completely replaces the notion of a window.  Yes, there is no good tool support for MFC.  Short from dialogs, everything is done in code.  Qt, wxWidgets and GTK(?) are class libraries just like MFC.

    One of the strengths of .NET is that any .NET compliant language can use code written in another.  The most typical approach taken for your kind of project is to write the UI in C# or VB.NET and the low-level interface with C++/CLI.  Calling unmanaged code from a C++/CLI class is almost effortless.  Calling C++/CLI code from C# takes no effort.  Used this way, C++/CLI is an excellent tool to get that job done.  Using the Express edition and creating some programs that use C++/CLI for the Windows Forms user interface is a very good way to learn the language.

    Hans Passant.
    • Marked as answer by Wesley Yao Monday, May 18, 2009 2:49 AM
    Tuesday, May 12, 2009 10:54 AM
  • .NET does not wrap MFC. Both .NET (with WinForms) and MFC are wrappers around the Win32 API. Both have GUI classes for creating windows, and non GUI classes for other things.

    Although it is possible to mix them, it would not make sense to use both .NET and MFC in a new application.

    Note that it is possible to write GUI applications directly in the Win32 API, but it is very cumbersome.

    David Wilkinson | Visual C++ MVP
    • Marked as answer by Wesley Yao Monday, May 18, 2009 2:48 AM
    Tuesday, May 12, 2009 1:12 PM
  • Goofacz: You've indicated several reasons that .net is not a good choice for you.  That's fine, use MFC.  Folks have been using MFC to build GUIs and sockets for a decade+  before .net existed.  MFC builds GUIs easily, with no need for XAML.  It uses the native controls.  If you have Visual Studio with MFC you can instantly build runnable GUI programs in several styles using the File,New,Project,MFC menu command.  Welcome to MFC!

     

    • Marked as answer by Wesley Yao Monday, May 18, 2009 2:48 AM
    Tuesday, May 12, 2009 3:02 PM

All replies

  • 1.  Yes.  But not for C++ programmers.
    2.  Yes.  But .NET has excellent socket support as well.
    3.  Different libraries at different times and different goals.  MFC is a low level class library wrapper for the Win32 API, helping you to develop GUIs in unmanaged C++.  ATL is a class library to help develop COM components.  COM is a technology to allow programs written in different languages to interact with each other.  .NET is managed code.  MFC, ATL and COM are 1990s, .NET is 2000s.
    4.  WPF is not a realistic option in C++, the IDE is missing all tool support for it.  WF is supported in the IDE but development on it has stopped, see 1.  While WPF was assumed to replace WF, this hasn't happened in practice.
    5.  It describes how your UI should act and look like, not how it is done.
    6.  A set of header files and import libraries you will need to build unmanaged C/C++ programs that run on Windows.

    If you want to pursue .NET development, you should learn to program in C#.

    Hans Passant.
    • Marked as answer by Goofacz Tuesday, May 12, 2009 10:15 AM
    • Unmarked as answer by Goofacz Tuesday, May 12, 2009 10:15 AM
    • Marked as answer by Wesley Yao Monday, May 18, 2009 2:50 AM
    Tuesday, May 12, 2009 1:25 AM
  • > "If you want to pursue .NET development, you should learn to program in C#."

    That's a 30 minute job for your average C++ developer.  Ok, two hours if you want to be a guru.


    Michael Asher
    Tuesday, May 12, 2009 2:04 AM
  • I'm working on some project at my university. In general it's a network application using SCTP protocol (it's required). SCTP is a new transport protocol an it supported on most unix systems. Windows doesn't officially support it, probably because it's still under development, however mature draft were already published. I found unofficial, low-level implementation available from winsock. That's why.NET is not a solution choice for me. Morover I prefer lower, compilabe languages, unix habbit ;)

    @nobugz
    Why you say that C++ is not a good for .NET? I haven't read, that C++/CLI has limited functionality...

    Microsoft develops both MFC (they realeased future pack for visual C++) and .NET, so I understand, that MFC will be present in future Windows versions, right? After few years of development .NET still doesn't cover whole windows's API (like now, when new UI features were added to to MFC first).

    Now user inteface, I'm a bit confused abou it. Windows Forms and WPF are part of .NET framework, right? How do we call user interface in MFC, does it even have a nome? Futhermore, Windows Forms wraps MFC UI elements in .NET? I read, that creating user interface only with MFC quite painful, because there in no thechnology similar to XAML from WPF.

    I can use Qt or GTK+, but I want to learn how to create truly native programs for Windows. Maybe it will be good (if ti's possible) to use C++/CLI, create user interface using WF from .NET and handle other things using MFC an lowwe level API like winsock?
    • Edited by Goofacz Tuesday, May 12, 2009 11:01 AM
    Tuesday, May 12, 2009 10:08 AM
  • Development on C++/CLI has been frozen since 2005.  It was notably bypassed for LINQ and is missing many C# 2.0 features (anonymous methods, iterators).

    Yes, MFC is going to be around for a while longer.  Yes, there is not a .NET wrapper class for every Win32 API, the shell is notably absent.  But that doesn't really matter, .NET has excellent support for COM interop and P/Invoke.  Making arbitrary Win32 API calls is pretty easy.

    WPF is a class library, just like MFC.  WF too, it has nothing to do with MFC.  Like MFC, it wraps user32.dll.  WPF completely replaces the notion of a window.  Yes, there is no good tool support for MFC.  Short from dialogs, everything is done in code.  Qt, wxWidgets and GTK(?) are class libraries just like MFC.

    One of the strengths of .NET is that any .NET compliant language can use code written in another.  The most typical approach taken for your kind of project is to write the UI in C# or VB.NET and the low-level interface with C++/CLI.  Calling unmanaged code from a C++/CLI class is almost effortless.  Calling C++/CLI code from C# takes no effort.  Used this way, C++/CLI is an excellent tool to get that job done.  Using the Express edition and creating some programs that use C++/CLI for the Windows Forms user interface is a very good way to learn the language.

    Hans Passant.
    • Marked as answer by Wesley Yao Monday, May 18, 2009 2:49 AM
    Tuesday, May 12, 2009 10:54 AM
  • .NET does not wrap MFC. Both .NET (with WinForms) and MFC are wrappers around the Win32 API. Both have GUI classes for creating windows, and non GUI classes for other things.

    Although it is possible to mix them, it would not make sense to use both .NET and MFC in a new application.

    Note that it is possible to write GUI applications directly in the Win32 API, but it is very cumbersome.

    David Wilkinson | Visual C++ MVP
    • Marked as answer by Wesley Yao Monday, May 18, 2009 2:48 AM
    Tuesday, May 12, 2009 1:12 PM
  • Goofacz: You've indicated several reasons that .net is not a good choice for you.  That's fine, use MFC.  Folks have been using MFC to build GUIs and sockets for a decade+  before .net existed.  MFC builds GUIs easily, with no need for XAML.  It uses the native controls.  If you have Visual Studio with MFC you can instantly build runnable GUI programs in several styles using the File,New,Project,MFC menu command.  Welcome to MFC!

     

    • Marked as answer by Wesley Yao Monday, May 18, 2009 2:48 AM
    Tuesday, May 12, 2009 3:02 PM
  • I made more research and in result I decided to use C++/CLI, because it seems to be very powerful (I can both use .NET and good old WinAPI). This is theory, but how does it work in real world? Syntax is really similar to 'stock C++ and I'm very happy with it. However i read, that C++/CLI programs are very slow when .NET calls are mised with native calls (made directly, not by P/Invoke). Is this true?

    @nobugz, what do you mean saying, that C++/CLI is frozen? You mean that Microsoft may disconntinue supporting it soon or just not extending it's features? It's already pretty powerful :)
    Tuesday, May 12, 2009 10:55 PM
  • Frozen == not extending.  Usually a death-knell for a language but I reckon it will be around for a while since .NET bits depend on it.  Notably WPF.  Calling unmanaged code from C++/CLI takes about 10 CPU cycles of overhead in the Release build.

    Hans Passant.
    Wednesday, May 13, 2009 12:21 AM
  • Ok, so now I'm sure, that C++ & MFC is the best solution for my project. Thank you for help!
    Wednesday, May 13, 2009 10:25 AM
  • Ok, so now I'm sure, that C++ & MFC is the best solution for my project. Thank you for help!

    This may be the right solution for you, but MFC has quite a learning curve and is really "old" technology.

    I think you should give some thought to doing everything in .NET with C#. (Of course, this is not what I do, but I have 12 years experience in MFC and little in .NET...).

    David Wilkinson | Visual C++ MVP
    Wednesday, May 13, 2009 11:47 AM