New Windows and MFC
-
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.
Funny! I just blogged on this today! Is MFC dead? Does MFC have a future?[^]
-
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.
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.
-
Funny! I just blogged on this today! Is MFC dead? Does MFC have a future?[^]
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.
-
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.
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
-
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.
The 2 million plus lines of code in our product is not going to migrate all in one day ... :rolleyes:
-
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!
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
-
Funny! I just blogged on this today! Is MFC dead? Does MFC have a future?[^]
Will MFC *really* support Avalon? I can barely believe that! Joel Holdsworth
-
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
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.
-
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
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
-
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.
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
-
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
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
-
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!
-
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;
-
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
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
-
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
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
-
Will MFC *really* support Avalon? I can barely believe that! Joel Holdsworth
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
-
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
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
-
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
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
-
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
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
-
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.
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