Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. New Windows and MFC

New Windows and MFC

Scheduled Pinned Locked Moved The Lounge
c++question
29 Posts 16 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • B BrockVnm

    With all this talk about the new Windows I was wondering how this will affect old code and also new code going forward. Are the changes so significant that the apps we write now in MFC will not work on the new Windows? Will we have to learn all new libraries for windows programing?


    There are 10 kinds of people in this world. Those who understand binary and those who don't. We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.

    N Offline
    N Offline
    Nish Nishant
    wrote on last edited by
    #8

    Funny! I just blogged on this today! Is MFC dead? Does MFC have a future?[^]

    B J 2 Replies Last reply
    0
    • B BrockVnm

      With all this talk about the new Windows I was wondering how this will affect old code and also new code going forward. Are the changes so significant that the apps we write now in MFC will not work on the new Windows? Will we have to learn all new libraries for windows programing?


      There are 10 kinds of people in this world. Those who understand binary and those who don't. We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.

      A Offline
      A Offline
      Anna Jayne Metcalfe
      wrote on last edited by
      #9

      I wouldn't worry. MFC is likely to be supported for a long time. In fact, I wouldn't be at all surprised if Visual Studio Orcas (the successor to Whidbey/VS2005) added XAML support to MFC. :cool: Anna :rose: Riverblade Ltd - Software Consultancy Services Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.

      J 1 Reply Last reply
      0
      • N Nish Nishant

        Funny! I just blogged on this today! Is MFC dead? Does MFC have a future?[^]

        B Offline
        B Offline
        BrockVnm
        wrote on last edited by
        #10

        Thanks Nish that was very informative. Im glad to see that not everyone is just moving over to the .NET platform.


        There are 10 kinds of people in this world. Those who understand binary and those who don't. We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.

        B 1 Reply Last reply
        0
        • G Giles

          Avalon (the new gui) etc is built on top of win32, even though its .NET. For C++/MFC gyus, its business as usual. I do use .NET with C#, but as good as it is, I'm still going to be using C++ and MFC, and its seems MS have every intention of continuing with it as well.

          J Offline
          J Offline
          Judah Gabriel Himango
          wrote on last edited by
          #11

          Avalon (the new gui) etc is built on top of win32 Actually, it's built on top of DirectX more than anything. There are no Win32 common controls under the hood, as it is with Windows Forms. Avalon controls are managed code and do not have their own HWNDs (with the exception of context menus and drop down lists, which need their own HWND since they can be drawn outside the containing window).

          Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango

          G C 2 Replies Last reply
          0
          • B BrockVnm

            Thanks Nish that was very informative. Im glad to see that not everyone is just moving over to the .NET platform.


            There are 10 kinds of people in this world. Those who understand binary and those who don't. We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.

            B Offline
            B Offline
            Blake Miller
            wrote on last edited by
            #12

            The 2 million plus lines of code in our product is not going to migrate all in one day ... :rolleyes:

            1 Reply Last reply
            0
            • B benjymous

              I'd have thought that Microsoft would be really shooting themselves in the foot if they didn't include some kind of backwards compatibility layer for Win32 based code. After all, Win2k (not sure about XP) can still run 16 bit win3.1 and OS/2 applications (thanks to it's NT heritage) -- Help me! I'm turning into a grapefruit! Buzzwords!

              D Offline
              D Offline
              David Crow
              wrote on last edited by
              #13

              I just ran a program last night on my XP machine that was coded for Windows v3.0. The date on the CD was 1992.


              "One must learn from the bite of the fire to leave it alone." - Native American Proverb

              1 Reply Last reply
              0
              • N Nish Nishant

                Funny! I just blogged on this today! Is MFC dead? Does MFC have a future?[^]

                J Offline
                J Offline
                Joel Holdsworth
                wrote on last edited by
                #14

                Will MFC *really* support Avalon? I can barely believe that! Joel Holdsworth

                J 1 Reply Last reply
                0
                • J Judah Gabriel Himango

                  Avalon (the new gui) etc is built on top of win32 Actually, it's built on top of DirectX more than anything. There are no Win32 common controls under the hood, as it is with Windows Forms. Avalon controls are managed code and do not have their own HWNDs (with the exception of context menus and drop down lists, which need their own HWND since they can be drawn outside the containing window).

                  Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango

                  G Offline
                  G Offline
                  Giles
                  wrote on last edited by
                  #15

                  But if DirectX is built on COM, then in a way, its still the Windows (win32) subsystem and everything that comes with that as COM is built on top of Win32. What I'm saying is its not built on a subsystem that directly interfaces with the NT subsystem, like the Win32 and Posix subsystems are.

                  J 1 Reply Last reply
                  0
                  • J Judah Gabriel Himango

                    Avalon (the new gui) etc is built on top of win32 Actually, it's built on top of DirectX more than anything. There are no Win32 common controls under the hood, as it is with Windows Forms. Avalon controls are managed code and do not have their own HWNDs (with the exception of context menus and drop down lists, which need their own HWND since they can be drawn outside the containing window).

                    Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango

                    C Offline
                    C Offline
                    Chris Richardson
                    wrote on last edited by
                    #16

                    Win32 is not just the common controls, it's the entire 32 bit API. DirectX is a part of Win32, so yes, Avalon is built on top of Win32. Chris Richardson

                    J 1 Reply Last reply
                    0
                    • G Giles

                      But if DirectX is built on COM, then in a way, its still the Windows (win32) subsystem and everything that comes with that as COM is built on top of Win32. What I'm saying is its not built on a subsystem that directly interfaces with the NT subsystem, like the Win32 and Posix subsystems are.

                      J Offline
                      J Offline
                      Judah Gabriel Himango
                      wrote on last edited by
                      #17

                      You're right that WinFX is not a subsystem like Win32 or Posix. However, WinFX can make direct system calls, eliminating the middleman API (Win32). See this article[^] by Ian Griffiths for more information. Borrowing a snippet from that, Because WinFX will be a part of the OS, it will be able to have a much closer relationship with the low-level system services. In theory, WinFX could act as a peer of Win32 rather than having to be its client; it could effectively be a distinct subsystem. In practice, that's unlikely to happen any time soon for two reasons. First, where Win32 already provides the necessary services, there seems little point in WinFX reinventing the wheel. So expect those parts of the .NET Framework that are wrappers around Win32 (such as Windows Forms) to remain so for the foreseeable future. The second reason for not making WinFX an entirely independent subsystem is that P/Invoke would be tricky to implement if Win32 wasn't still there somewhere. Nevertheless, although we are likely to carry on seeing wrappers where Win32 already provides appropriate services, there's no reason for new services to be exposed at the Win32 level and then wrapped by WinFX. For platform services that are new to Longhorn, their only public API will be in WinFX. There may be corresponding undocumented system calls used by WinFX (just as there are today for many Win32 APIs) but there is no reason for there to be an equivalent new public Win32 API; Longhorn can cut out the middle man and have WinFX make system calls directly.

                      Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango

                      C 1 Reply Last reply
                      0
                      • C Chris Richardson

                        Win32 is not just the common controls, it's the entire 32 bit API. DirectX is a part of Win32, so yes, Avalon is built on top of Win32. Chris Richardson

                        J Offline
                        J Offline
                        Judah Gabriel Himango
                        wrote on last edited by
                        #18

                        Right, but the parent poster was talking about Avalon, in which he claimed was built on Win32, which isn't entirely correct. See my reply to Giles in this same thread for more info.

                        Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango

                        1 Reply Last reply
                        0
                        • B benjymous

                          I'd have thought that Microsoft would be really shooting themselves in the foot if they didn't include some kind of backwards compatibility layer for Win32 based code. After all, Win2k (not sure about XP) can still run 16 bit win3.1 and OS/2 applications (thanks to it's NT heritage) -- Help me! I'm turning into a grapefruit! Buzzwords!

                          L Offline
                          L Offline
                          Lost User
                          wrote on last edited by
                          #19

                          Can it -really- run OS/2 apps? I didn't know that! OS/2 was the thing back in da daze!

                          G B 2 Replies Last reply
                          0
                          • L Lost User

                            Can it -really- run OS/2 apps? I didn't know that! OS/2 was the thing back in da daze!

                            G Offline
                            G Offline
                            Gary Wheeler
                            wrote on last edited by
                            #20

                            Carl Mercier wrote: OS/2 Bite your tongue. While you're at it, bite every part of your body within reach of your mouth. Chew hard. OS/2. Blleeecchhh. X| X| X| X|


                            Software Zen: delete this;

                            1 Reply Last reply
                            0
                            • J Judah Gabriel Himango

                              You're right that WinFX is not a subsystem like Win32 or Posix. However, WinFX can make direct system calls, eliminating the middleman API (Win32). See this article[^] by Ian Griffiths for more information. Borrowing a snippet from that, Because WinFX will be a part of the OS, it will be able to have a much closer relationship with the low-level system services. In theory, WinFX could act as a peer of Win32 rather than having to be its client; it could effectively be a distinct subsystem. In practice, that's unlikely to happen any time soon for two reasons. First, where Win32 already provides the necessary services, there seems little point in WinFX reinventing the wheel. So expect those parts of the .NET Framework that are wrappers around Win32 (such as Windows Forms) to remain so for the foreseeable future. The second reason for not making WinFX an entirely independent subsystem is that P/Invoke would be tricky to implement if Win32 wasn't still there somewhere. Nevertheless, although we are likely to carry on seeing wrappers where Win32 already provides appropriate services, there's no reason for new services to be exposed at the Win32 level and then wrapped by WinFX. For platform services that are new to Longhorn, their only public API will be in WinFX. There may be corresponding undocumented system calls used by WinFX (just as there are today for many Win32 APIs) but there is no reason for there to be an equivalent new public Win32 API; Longhorn can cut out the middle man and have WinFX make system calls directly.

                              Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango

                              C Offline
                              C Offline
                              Chris Richardson
                              wrote on last edited by
                              #21

                              Now you're mixing it up. The original poster was talking about Avalon being implemented on top of Win32, and now you're talking about WinFX, of which Avalon is just one part. In fact the article you referenced here supports the thought that Avalon is implemented using Win32 (DirectX is just part of Win32 so yes it is a factually correct statement). There will, of course, be some things which involve new platform features all the way from WinFX's public API right down to kernel mode-- the new 'Avalon' graphics model being the most obvious example. However, there will be many more features implemented entirely in managed code. For example, although Avalon relies on platform support at all levels for performance reasons, a considerable amount of its functionality will reside entirely in managed code. (It would be rather inefficient if every single interaction your code had with Avalon objects caused calls all the way down into the lowest levels of the OS.) [emphasis mine] Avalon is implemented on top of Win32. Yes some of it's functionality is written in managed code, but without Win32 it would not function at all. Also, it sounds like most of what he's talking about are theories of what WinFX "could" do in the future; it doesn't actually talk about WinFX making syscall's just yet. Chris Richardson

                              J 1 Reply Last reply
                              0
                              • C Chris Richardson

                                Now you're mixing it up. The original poster was talking about Avalon being implemented on top of Win32, and now you're talking about WinFX, of which Avalon is just one part. In fact the article you referenced here supports the thought that Avalon is implemented using Win32 (DirectX is just part of Win32 so yes it is a factually correct statement). There will, of course, be some things which involve new platform features all the way from WinFX's public API right down to kernel mode-- the new 'Avalon' graphics model being the most obvious example. However, there will be many more features implemented entirely in managed code. For example, although Avalon relies on platform support at all levels for performance reasons, a considerable amount of its functionality will reside entirely in managed code. (It would be rather inefficient if every single interaction your code had with Avalon objects caused calls all the way down into the lowest levels of the OS.) [emphasis mine] Avalon is implemented on top of Win32. Yes some of it's functionality is written in managed code, but without Win32 it would not function at all. Also, it sounds like most of what he's talking about are theories of what WinFX "could" do in the future; it doesn't actually talk about WinFX making syscall's just yet. Chris Richardson

                                J Offline
                                J Offline
                                Judah Gabriel Himango
                                wrote on last edited by
                                #22

                                My original point (which is getting lost in all this rhetoric): There are no Win32 Common Controls under the hood, as it is with Windows Forms. Hopefully you're not refuting this point. :) I'm actually looking forward to building applications using a native framework that doesn't require me to allocate several hundred expensive HWNDs (one per control), as it is with MFC and Windows Forms. I agree with you that Win32 services are used in WinFX. Why should WinFX re-invent the wheel, after all? New functionality, such as the new Avalon UI controls, have no Win32 counterparts. That's the point I'm refuting: Avalon isn't Win32-based, it is WinFX-based. Yes, WinFX uses some Win32 services where appropriate, but that ties you to Win32 as much as the Win32 API ties you to a particular version of Windows. If WinFX were to completely do away with Win32 (which won't happen for a very long time), Avalon could care less, because it doesn't rely on Win32 API. In other words, as WinFX evolves and new functionality is added (that has no Win32 equivalent), Win32 becomes less and less used.

                                Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango

                                C 1 Reply Last reply
                                0
                                • J Joel Holdsworth

                                  Will MFC *really* support Avalon? I can barely believe that! Joel Holdsworth

                                  J Offline
                                  J Offline
                                  Judah Gabriel Himango
                                  wrote on last edited by
                                  #23

                                  I'd be surprised, personally. Nish seems to have inside sources though. :suss:

                                  Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango

                                  1 Reply Last reply
                                  0
                                  • J Judah Gabriel Himango

                                    My original point (which is getting lost in all this rhetoric): There are no Win32 Common Controls under the hood, as it is with Windows Forms. Hopefully you're not refuting this point. :) I'm actually looking forward to building applications using a native framework that doesn't require me to allocate several hundred expensive HWNDs (one per control), as it is with MFC and Windows Forms. I agree with you that Win32 services are used in WinFX. Why should WinFX re-invent the wheel, after all? New functionality, such as the new Avalon UI controls, have no Win32 counterparts. That's the point I'm refuting: Avalon isn't Win32-based, it is WinFX-based. Yes, WinFX uses some Win32 services where appropriate, but that ties you to Win32 as much as the Win32 API ties you to a particular version of Windows. If WinFX were to completely do away with Win32 (which won't happen for a very long time), Avalon could care less, because it doesn't rely on Win32 API. In other words, as WinFX evolves and new functionality is added (that has no Win32 equivalent), Win32 becomes less and less used.

                                    Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango

                                    C Offline
                                    C Offline
                                    Chris Richardson
                                    wrote on last edited by
                                    #24

                                    Judah Himango wrote: There are no Win32 Common Controls under the hood, as it is with Windows Forms. Hopefully you're not refuting this point. Like I said in my original post, Win32 != common controls. It is MUCH MUCH more than just the common controls. I don't believe I ever said that Avalon was implemented using the common controls. Here's what was said <not actual quotes>: Giles: Avalon is implemented on top of Win32. You: No it's not, it's DirectX. Me: DirectX *is part of* Win32. You: But Avalon doesn't use the common controls. Me: :confused: Anyways, Avalon is clearly written on top of DirectX and DirectX is just a part of Win32. That's the whole point I was making. :) Chris Richardson

                                    J 1 Reply Last reply
                                    0
                                    • C Chris Richardson

                                      Judah Himango wrote: There are no Win32 Common Controls under the hood, as it is with Windows Forms. Hopefully you're not refuting this point. Like I said in my original post, Win32 != common controls. It is MUCH MUCH more than just the common controls. I don't believe I ever said that Avalon was implemented using the common controls. Here's what was said <not actual quotes>: Giles: Avalon is implemented on top of Win32. You: No it's not, it's DirectX. Me: DirectX *is part of* Win32. You: But Avalon doesn't use the common controls. Me: :confused: Anyways, Avalon is clearly written on top of DirectX and DirectX is just a part of Win32. That's the whole point I was making. :) Chris Richardson

                                      J Offline
                                      J Offline
                                      Judah Gabriel Himango
                                      wrote on last edited by
                                      #25

                                      I guess my purpose of replying was to say Avalon isn't Win32-based. I can see how you would be confused by my DirectX statement, though. Maybe I should've said: "No, Avalon is WinFX-based. WinFX uses DirectX services to do the rendering though." Ah well, my fault then. That's the thing about internet message boards, you never really can understand people completely because you can't see emotions in the face or hear stresses in the voice. :)

                                      Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango

                                      C 1 Reply Last reply
                                      0
                                      • J Judah Gabriel Himango

                                        I guess my purpose of replying was to say Avalon isn't Win32-based. I can see how you would be confused by my DirectX statement, though. Maybe I should've said: "No, Avalon is WinFX-based. WinFX uses DirectX services to do the rendering though." Ah well, my fault then. That's the thing about internet message boards, you never really can understand people completely because you can't see emotions in the face or hear stresses in the voice. :)

                                        Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango

                                        C Offline
                                        C Offline
                                        Chris Richardson
                                        wrote on last edited by
                                        #26

                                        Judah Himango wrote: No, Avalon is WinFX-based. WinFX uses DirectX services to do the rendering though. That makes a lot more sense. I can see your viewpoint now, which is good. Judah Himango wrote: Ah well, my fault then. There's no fault to be had; like you said, it's hard communicating on message boards. :) That's actually part of the reason I don't post too much. It's just too difficult sometimes to not be able to see or hear the people you are talking to. Thanks for the discussion though, it was interesting. :) Chris Richardson

                                        1 Reply Last reply
                                        0
                                        • A Anna Jayne Metcalfe

                                          I wouldn't worry. MFC is likely to be supported for a long time. In fact, I wouldn't be at all surprised if Visual Studio Orcas (the successor to Whidbey/VS2005) added XAML support to MFC. :cool: Anna :rose: Riverblade Ltd - Software Consultancy Services Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.

                                          J Offline
                                          J Offline
                                          Judah Gabriel Himango
                                          wrote on last edited by
                                          #27

                                          That wouldn't surprise me; XAML is just a markup language not necessarily tied to any technology. It just so happens that Avalon-based .NET apps will be the primary user of XAML. I've read on some Microsoft blogs that XAML has been known to work for Windows Forms just fine for a long time now. It seems to me using XAML to define MFC UIs wouldn't be much of a stretch then.

                                          Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango

                                          A 1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • World
                                          • Users
                                          • Groups